Các nhà cung cấp mô tả thiết bị này là ảo và có khả năng hai yếu tố, và không từ nào trong hai từ đó trả lời những câu hỏi quyết định việc mua. Hình ảnh hypervisor nào được hỗ trợ, những ứng dụng khách nào có thể đăng ký, yếu tố thứ hai thực sự chứng minh điều gì và điều gì xảy ra khi nhà cung cấp danh tính ngừng hoạt động vẫn còn bỏ ngỏ. Hãy biến chúng thành các giai đoạn nghiệm thu mà bạn có thể chạy trong một buổi diễn tập, và quyết định sẽ không còn phụ thuộc vào việc bảng dữ liệu có thuyết phục đến đâu. Bảng dưới đây là một cấu trúc cho những bằng chứng đó, không phải bảng xếp hạng sản phẩm.

Nhà cung cấp phải xác nhận điều gì về việc triển khai này

Hãy bắt đầu bằng việc gói triển khai vào một trang: hypervisor hoặc đám mây, kiến trúc khách, hình ảnh được hỗ trợ và các giao diện mà thiết bị mong đợi. Thêm người dùng cùng hệ điều hành của họ, việc thiết bị có được quản lý hay không, và cách đăng ký cùng đăng nhập phải hoạt động. Tiếp theo là truy cập riêng tư: ứng dụng và tiền tố, cách bố trí DNS, đường trở về, và việc một lối ra internet công cộng có thuộc phần đề nghị hay không.

Vận hành cũng thuộc cùng trang đó: ai bảo trì thiết bị, bản cập nhật đến từ đâu, nhật ký đi đâu, cấu hình được bảo vệ thế nào, và mục tiêu phục hồi nào mà doanh nghiệp thực sự đã đồng ý. Yêu cầu nhà cung cấp xác nhận đúng tổ hợp đó, chứ không phải việc phần mềm chạy trong máy ảo. Giữ các phụ thuộc bên ngoài như nhà cung cấp danh tính hoặc dịch vụ cấp phép ở trạng thái nhìn thấy được, vì chúng là một phần của triển khai dù có được cung cấp kèm hay không. Một trang triển khai không nêu tên phụ thuộc nào thường là trang triển khai có một phụ thuộc chưa biết.

Chứng minh rằng yếu tố thứ hai đúng là yếu tố thứ hai

Nêu tên bộ xác thực và luồng xác minh, và nói mỗi bước thiết lập danh tính nào. Hai lần hỏi mật khẩu liên tiếp không phải yếu tố thứ hai, và mật khẩu cộng mã dùng một lần là một khẳng định khác với bộ xác thực mật mã gắn với dịch vụ. Hãy viết ra luồng bạn đang mua, không phải nhãn trên hộp.

Khả năng chống lừa đảo là một thuộc tính riêng, và hướng dẫn của NIST về bộ xác thực xem nó đúng như vậy: một mã mà người dùng có thể bị lừa để chuyển tiếp vẫn đáp ứng xác thực đa yếu tố nhưng thất bại ở điều kiện bổ sung đó. Hãy yêu cầu thuộc tính đó một cách rõ ràng nếu nó quan trọng với bạn. Sau đó yêu cầu một cuộc trình diễn từ loại ứng dụng khách mà người dùng của bạn thực sự chạy, bao gồm đăng ký, một thử thách bị từ chối hoặc hết hạn, phục hồi sau khi mất bộ xác thực, và thu hồi một người dùng trong khi những người khác vẫn kết nối. Giữ việc xác minh danh tính của cổng trong phạm vi, vì một ứng dụng khách tin vào bất kỳ cổng nào đã di chuyển vấn đề thay vì giải quyết nó.

Viết điều kiện đạt trước khi bạn làm hỏng bất cứ thứ gì

Bảng dưới đây là phần của tờ giấy sống sót sau cuộc tiếp xúc với nhà cung cấp, vì mỗi hàng yêu cầu một bằng chứng thay vì một lời bảo đảm. Điền điều kiện đạt trước buổi diễn tập, và coi một hàng không có bằng chứng là hàng thất bại. Năm giai đoạn bao quát những gì một cổng phải làm.

Acceptance stageEvidence to keepPass condition
EnrolmentEnrolment record with the device type and the identity usedA new device enrols once, and nobody else can enrol it afterwards
Sign-in with the second factorSession record naming both factors and the gateway identity that was checkedThe session carries the expected identity and the gateway certificate validated
Denial of an unapproved destinationLog line from the control that refused the flow, with the policy nameThe flow is refused and the refusal is attributable to one control
Revocation of one userRevocation timestamp and the sessions that survived itThe named user is out and unaffected users keep working
Restore from configuration backupRestored version plus a probe of a revoked identityThe revision matches the backup and revoked identities stay revoked

Đăng ký đứng đầu vì mọi thứ phía sau đều phụ thuộc vào nó: một thiết bị không thể đăng ký thì không thể kiểm thử. Đăng nhập là một giai đoạn riêng so với đăng ký, và từ chối là giai đoạn mà hầu hết các tờ giấy quên, vì một cổng cho tất cả vào thì chưa chứng minh rằng nó từ chối ai. Thu hồi và phục hồi mang phần lớn rủi ro vận hành, và cả hai đều rẻ để diễn tập trên một bản sao.

Diễn tập trên bản sao, không phải trên cổng đang chạy

Chạy các giai đoạn gây gián đoạn trên một bản sao của nền tảng, theo quy trình triển khai được hỗ trợ, và lưu mỗi bằng chứng cùng ngày và phiên bản cấu hình của nó. Một hàng khởi động lại không được trả lời bằng việc khởi động lại từ bảng điều khiển, và một hàng phục hồi không được trả lời bằng việc xuất cấu hình. Ghi lại trạng thái nào tự trở về và điều gì phải kết nối lại, vì chính sự khác biệt đó là thứ đội vận hành thừa hưởng. Buổi diễn tập cũng là cơ hội duy nhất để bấm giờ một lần phục hồi mà không phải giải thích sự cố.

Ghi lại trạng thái của nhà cung cấp danh tính tại thời điểm mỗi lần kiểm thử, vì một hàng sự cố được kiểm thử với nhà cung cấp khỏe mạnh chứng minh điều ngược lại với những gì tờ giấy khẳng định. Hai người đánh giá trong cùng một buổi diễn tập bắt được những điều khác nhau, và người thứ hai thường tìm ra hàng mà bằng chứng là ảnh chụp màn hình của một bảng điều khiển. Giữ bằng chứng đó gắn với hàng mà nó thuộc về, không phải trong một thư mục mang tên dự án.

Đo khối lượng công việc mà đội của bạn sẽ chạy

Thống nhất một khối lượng giống một tuần bình thường, rồi đo nó tại nơi bạn định triển khai: mức đồng thời, hỗn hợp lưu lượng và cửa sổ bảo trì mà đội thực sự có. Một con số thông lượng được quảng cáo mô tả điều kiện phòng thí nghiệm và không nói gì về người dùng của bạn. Đo việc phục hồi so với mục tiêu phục hồi, không phải so với kế hoạch.

Tờ giấy hoàn tất khi mỗi giai đoạn có một bằng chứng và mỗi bằng chứng có một ngày. Một thiết bị có người bảo trì, với bằng chứng cho từng hàng, là một lần mua khác với danh sách ô đã đánh dấu dài nhất.

Bài viết liên quan