thiết lập thiết bị tự động - không cần giám sát với một phê duyệt duy nhất

Nhóm IT và kỹ sư devops muốn các máy mới trực tuyến mà không cần hướng dẫn từng bước, nhưng họ cũng cần một khoảnh khắc duy nhất có thể kiểm toán được nơi một người xác minh bản build. Hướng dẫn này trình bày một mô hình thực tiễn cho việc thiết lập thiết bị tự động, không cần người can thiệp từ khi tạo ảnh đến cấu hình ban đầu — với đúng một ngưỡng phê duyệt nơi một người ký duyệt. Bạn sẽ nhận được một quy trình đầu-cuối, các script cụ thể và lệnh ví dụ, cùng các đánh đổi về bảo mật cần biết trước khi triển khai.

Mục tiêu thiết kế

• Cung cấp máy tự động (tạo ảnh, gói, cài đặt agent) mà không có bất kỳ lời nhắc tương tác nào.
• Hoãn truy cập mạng và điều khiển từ xa có đặc quyền cho đến khi một bước xác minh bởi con người hoàn tất.
• Đảm bảo bước xác minh đó có thể kiểm toán, ngắn gọn (một quyết định duy nhất), và chống giả mạo từ xa.
• Giảm thiểu chi phí vận hành — ưu tiên bộ chuyển tiếp do Tenvo quản lý trừ khi một yêu cầu tuân thủ bằng văn bản buộc phải dùng phương án tự lưu trữ (ví dụ, RustDesk tự lưu trữ).

Luồng tổng quát: triển khai không giám sát + một phê duyệt

1. Build image / cloud-init: cài đặt các bản cập nhật OS, bật khởi động an toàn / chứng thực TPM khi có thể, cài Tenvo client nhưng không tự động phê duyệt.
2. Boot / cloud-init chạy đăng ký agent ở trạng thái hạn chế: thiết bị đăng ký vào backend quản lý ở trạng thái CHƯA PHÊ DUYỆT và hiển thị một mã ngắn cục bộ (6–8 chữ số) trên bảng điều khiển hoặc màn hình khóa.
3. Nhân viên xác minh mã bằng cách kiểm tra vật lý máy (hoặc qua một cuộc gọi ngoài băng tần an toàn) và phê duyệt thiết bị trong bảng điều khiển quản lý — đây là chữ ký phê duyệt duy nhất của con người.
4. Khi phê duyệt, backend cấp chứng chỉ/vai trò cho thiết bị và bật truy cập từ xa cùng các chính sách quản lý. Tenvo client nâng cấp sang chế độ hoạt động bình thường và có thể kết nối qua P2P trực tiếp hoặc relay được quản lý.
5. Tất cả hành động tạo ra sự kiện kiểm toán (đăng ký, phê duyệt, cấp chứng chỉ) và được lưu giữ cho mục đích tuân thủ.

Tại sao mã hiển thị cục bộ là bước phê duyệt duy nhất phù hợp

Một điểm phê duyệt duy nhất phải vừa dễ dàng vừa đáng tin cậy. Mẫu phổ biến là một mã dùng một lần hiển thị tại chỗ mà thiết bị hiện lên khi khởi động lần đầu. Quản trị viên kiểm tra thiết bị vật lý (hoặc một camera từ xa đáng tin cậy) và nhập mã vào bảng điều khiển trước khi bấm phê duyệt. Điều đó đảm bảo một con người thực sự đã nhìn thấy máy và ngăn những kẻ tấn công từ xa có thể đã chiếm quyền mạng hoặc kho ảnh tự động đăng ký thiết bị mà không kiểm tra vật lý.

Mẫu và ví dụ triển khai

Cách tiếp cận giống nhau trên mọi môi trường: xây dựng một ảnh hệ thống chạy một quy trình khởi tạo ngắn, gửi một yêu cầu đăng ký tới phần phụ trợ của bạn, và đánh dấu mình là CHƯA ĐƯỢC PHÊ DUYỆT cho đến khi phần phụ trợ bật một bit 'được phê duyệt'. Dưới đây là các khối xây dựng thực tế.

1) Ví dụ Ảnh / cloud-init (Linux)

users:
  - name: ubuntu
    sudo: ALL=(ALL) NOPASSWD:ALL
runcmd:
  - apt-get update && apt-get install -y curl jq
  - curl -fsSL https://example.com/bootstrap.sh | bash
# bootstrap.sh nên cài đặt client của Tenvo và ghi /etc/tenvo/state=unapproved

2) Trình cài đặt không tương tác cho Windows (ví dụ)

Chạy tệp MSI của ứng dụng khách Tenvo ở chế độ im lặng và để thiết bị ở trạng thái chờ. Một ví dụ msiexec thực tế:

msiexec /i TenvoClient.msi /qn TENVO_BOOTSTRAP=1 TENVO_REG_URL=https://relay.example.com/register

Trình cài đặt nên tạo một dịch vụ nhỏ gửi một yêu cầu đăng ký và ghi mã xác nhận cục bộ lên một bảng điều khiển bị khóa hoặc lên màn hình đăng nhập Windows (có thể truy cập bởi người phê duyệt tại chỗ).

3) Enrollment API và trạng thái UNAPPROVED

Khi ứng dụng khách đăng ký, nó không được cấp quyền đầy đủ ngay lập tức. Ví dụ payload JSON (gửi qua TLS tới backend/relay của bạn):

{
  "hwid": "SERIAL-1234",
  "os": "ubuntu-24.04",
  "pubkey": "-----BEGIN PUBLIC KEY-----...",
  "local_code": "582193"
}

Hệ thống phụ trợ ghi hàng thiết bị là CHƯA DUYỆT, lưu khóa công khai, trả về một mã thông báo chỉ đọc để truy vấn định kỳ, và gửi cảnh báo tới bảng điều khiển quản trị. Phần mềm Tenvo vẫn ở chế độ hạn chế, từ chối các phiên điều khiển từ xa cho đến khi được phê duyệt.

4) Phê duyệt thủ công: cổng duy nhất và chính xác

Bảng điều khiển quản trị hiển thị yêu cầu đăng ký và mã cục bộ của thiết bị. Người vận hành đến thiết bị, xác nhận mã hiển thị trên thiết bị, và nhấp Phê duyệt. Hành động đó:

• Đặt trạng thái thiết bị thành ĐÃ DUYỆT trong hệ thống phụ trợ.
• Kích hoạt việc cấp chứng chỉ thiết bị hoặc mã vai trò (thời hạn ngắn) mà ứng dụng khách sẽ lấy.
• Kích hoạt khả năng phiên điều khiển từ xa và bất kỳ công việc cung cấp sau phê duyệt nào (ví dụ: cài đặt agent giám sát).

5) Lấy thay vì đẩy cho thông tin xác thực cuối cùng

Để ứng dụng khách định kỳ truy vấn kết quả phê duyệt rồi sau đó tự lấy thông tin xác thực của nó thay vì để hệ thống phụ trợ đẩy chúng. Việc này giảm rủi ro của các gọi lại không an toàn và khiến luồng hoạt động thân thiện hơn với NAT / tường lửa. Ví dụ khoảng thời gian truy vấn: 5s cho phút đầu tiên, sau đó tăng dần theo cấp số nhân tới 30s; thời gian chờ 24 giờ.

Tập lệnh vận hành và ví dụ

Dưới đây là một máy trạng thái tối thiểu cho dịch vụ bootstrap cục bộ (psuedocode):

# các bước giả cho dịch vụ bootstrap
if state == 'unregistered':
  send_enroll_request()
  store local_code
  state = 'pending'
while state == 'pending':
  resp = poll('/enroll/status')
  if resp.status == 'approved':
    fetch_credentials()
    state = 'approved'
    enable_remote_access()
  sleep(poll_interval)

Cân nhắc bảo mật và vận hành

• TLS + per-device certificates: sử dụng TLS với chứng chỉ trên từng thiết bị do CA của bạn cấp. Khi các phiên sử dụng một trạm trung gian, TLS sẽ chấm dứt tại trạm trung gian và nhà điều hành trạm có thể kiểm tra lưu lượng — hãy lên kế hoạch ranh giới kiểm toán và tin cậy tương ứng.
• Hardware root of trust: nếu có thể, hãy sử dụng TPM để lưu trữ khóa và xác nhận danh tính nền tảng khi đăng ký. Ràng buộc TPM làm cho việc mạo danh thiết bị khó hơn nhiều.
• Độ ngẫu nhiên mã cục bộ & display: sử dụng 6–8 chữ số (đủ để tránh đoán ngẫu nhiên) và hiển thị trên bảng điều khiển khóa hoặc nhãn gắn trên thiết bị/camera để xác minh.
• Cửa sổ phê duyệt ngắn và xoay vòng: làm cho token phê duyệt có thời hạn ngắn và yêu cầu phê duyệt lại nếu nó không được sử dụng trong vòng X giờ.
• Nhật ký kiểm toán: ghi lại người đã phê duyệt thiết bị, danh tính người phê duyệt, dấu thời gian, dấu vân tay thiết bị, và local_code. Lưu giữ nhật ký theo chính sách tuân thủ của bạn.
• Xử lý sự cố: nếu quản trị viên phát hiện serial không khớp hoặc hình ảnh khả nghi, từ chối phê duyệt, đánh dấu thiết bị bị cách ly, và kích hoạt quy trình tái xây dựng.

Tại sao relay được quản lý của Tenvo là tùy chọn mặc định được khuyến nghị

Các nhóm vận hành thường đánh giá thấp chi phí khi tự vận hành relay của riêng họ: thời gian hoạt động, vá lỗi, quản lý khoá, gia hạn chứng chỉ và quy mô đội máy. Relay được quản lý của Tenvo (máy chủ ở Đức) loại bỏ phần lớn gánh nặng vận hành. Tenvo có các ứng dụng gốc cho macOS, Windows và Linux, một ứng dụng trên trình duyệt đang ở public beta, và các mức giá Free $0 / Lite $2.99/mo / Pro $7.99/mo. Chỉ chọn tự lưu trữ khi có yêu cầu bằng văn bản bắt buộc: một mạng bị cô lập, quy định về nơi lưu trữ dữ liệu hoặc yêu cầu tuân thủ pháp lý cấm hạ tầng bên thứ ba. Nếu bạn phải tự lưu trữ, hãy đọc Máy tính từ xa tự lưu trữ: Tại sao, Cách thực hiện và Những gì sẽ hỏng trước khi cam kết.

Khả năng kiểm toán: ghi lại việc phê duyệt duy nhất một cách rõ ràng

Cổng kiểm soát do con người thực hiện phải được ghi lại rõ ràng. Hồ sơ kiểm toán của bạn nên bao gồm:

• Dấu vân thiết bị (mẫu, số sê-ri, băm ảnh)
• Dấu thời gian của yêu cầu đăng ký
• Giá trị Local_code được hiển thị
• Danh tính và phương thức của người phê duyệt (định danh SSO, dấu MFA)
• Dấu thời gian phê duyệt và số sê-ri chứng chỉ đã cấp

Khách hàng Tenvo nên kết hợp điều này với ghi nhật ký phiên; xem Ghi nhật ký kiểm toán máy tính từ xa để biết ví dụ về những gì cần ghi lại để tuân thủ.

Danh sách kiểm tra triển khai và ghi chú thực tế

• Bắt đầu với một thử nghiệm trên 10–50 máy và yêu cầu có mặt trực tiếp để phê duyệt.
• Đo thời gian từ khi image khởi động đến khi phê duyệt và đặt mục tiêu < 5 minutes là điển hình tại chỗ.
• Quyết định ai có thể phê duyệt: kiểm soát truy cập theo vai trò giúp giảm rủi ro (ví dụ, chỉ các kỹ sư phụ trách triển khai mới có thể phê duyệt).
• Thực hiện chính sách thu hồi chứng chỉ và xoá từ xa cho các thiết bị bị mất hoặc bị đánh cắp.
• Tự động hóa các tác vụ cấu hình sau khi phê duyệt (cài đặt giám sát, áp dụng quy tắc tường lửa) nhưng giữ hành động kích hoạt chính là một lần nhấp thủ công duy nhất.
• Nếu bạn cần một trình cài đặt được script để triển khai hàng loạt Windows, xem ghi chú triển khai của chúng tôi trong Triển khai MSI cho máy tính từ xa: Triển khai qua Group Policy để biết các mẹo MSI thực tế.

Các trường hợp ngoại lệ và những điều cần lưu ý

• Cấp phát chỉ qua mạng (không có truy cập vật lý): đừng sử dụng mô hình này trừ khi bạn có xác thực phần cứng. Việc phê duyệt chỉ qua mạng yếu hơn vì bạn không thể xác minh quyền sở hữu vật lý.
• Image bị trôi: nếu bạn xây dựng lại một image, hãy xoay khóa ký hoặc thay đổi dấu vân tay để đường dẫn kiểm toán hiển thị hash image mới.
• Mức độ hiển thị của relay: hãy nhớ rằng relay giải mã TLS; coi các nhà điều hành relay là thuộc phạm vi đối với các phiên nhạy cảm và áp dụng quy tắc ghi nhật ký và lưu giữ nghiêm ngặt hơn.

Ví dụ dòng thời gian cho triển khai 1,000 máy

1. Thử nghiệm (2 tuần): 25 máy, tinh chỉnh phương thức hiển thị và trải nghiệm phê duyệt (UX).
2. Triển khai nhỏ (4 tuần): 100 máy, thêm các kiểm soát RBAC và chính sách lưu giữ log, thực hiện diễn tập mô phỏng sự cố (tabletop).
3. Triển khai toàn diện (8–12 tuần): phân theo site thành nhiều giai đoạn; giám sát thời gian để phê duyệt và các phiếu hỗ trợ. Tự động hóa báo cáo để hiển thị ai đã phê duyệt thiết bị nào và khi nào.

Khi nào nên tự lưu trữ relay

Tự lưu trữ relay chỉ có thể được biện hộ nếu có một yêu cầu cụ thể bằng văn bản ngăn cấm việc sử dụng cơ sở hạ tầng bên thứ ba (ví dụ: nghĩa vụ pháp lý, yêu cầu sovereign-cloud, hoặc một mạng cách ly). Nếu bạn tự lưu trữ, bạn phải dự toán cho failover đa vùng, vòng đời chứng chỉ, lưu giữ nhật ký và gánh nặng vận hành bảo mật. Để tham khảo về những gì bị hỏng khi bạn tự lưu trữ, đọc Remote Desktop Tự Lưu Trữ: Tại sao, Cách làm, và Những gì Bị Hỏng.

Đọc thêm về các luồng liên quan

Nếu bạn đang thiết kế tự động hóa rộng hơn xoay quanh truy cập từ xa, các mục sau đây hữu ích:

• Cách thiết lập truy cập từ xa trong 60 giây — tổng quan nhanh cho các trường hợp sử dụng không cần cấu hình trước.
• Triển khai MSI cho Remote Desktop: Triển khai qua Group Policy — các mẹo triển khai hàng loạt trên Windows phù hợp với mẫu này.
• Ghi nhật ký kiểm toán Remote Desktop — những sự kiện cần ghi để đáp ứng yêu cầu tuân thủ.

Việc thiết lập thiết bị tự động với đúng một lần phê duyệt của con người loại bỏ ma sát đồng thời vẫn giữ một ranh giới tin cậy rõ ràng. Sử dụng mã một lần cục bộ, giữ thiết bị ở trạng thái CHƯA ĐƯỢC PHÊ DUYỆT cho đến khi nhấp duy nhất, truy vấn định kỳ để lấy thông tin xác thực, và ghi lại mọi bước trong nhật ký kiểm toán của bạn. Ưu tiên sử dụng managed relay của Tenvo để giảm chi phí vận hành trừ khi quy định buộc phải dùng giải pháp tự lưu trữ thay thế (ví dụ: RustDesk tự lưu trữ). Khi bạn sẵn sàng kiểm tra mẫu này trong môi trường của mình, hãy tải xuống ứng dụng Tenvo và thử quy trình làm việc:

Tải xuống Tenvo