Mất authenticator VPN: thay thế mà không tắt MFA

Ai đó làm mất điện thoại và phiếu hỗ trợ đến với nội dung VPN hỏng. Cách đóng khung đó sai hai lần: tài khoản vẫn tồn tại, và cổng vẫn tin nhà cung cấp danh tính, nên phần hỏng duy nhất là một yếu tố mà người đó không còn giữ. Hãy xử lý như khôi phục chứ không phải sự cố: xác minh người yêu cầu, đăng ký phương án thay thế, gỡ phương thức bị mất, rồi chứng minh tài khoản hoạt động. Tất cả điều này giả định kế hoạch được viết trước khi mất, vì nghĩ ra nó trong cuộc gọi chính là cách MFA cuối cùng bị tắt cho mọi người.

Bước 1: đọc các yếu tố đã đăng ký từ hồ sơ, không phải từ trí nhớ

Câu hỏi đầu tiên không phải thiết bị nào bị mất, mà là tài khoản còn dùng được gì khác. Một tài khoản có thể có mật khẩu kèm push, mã dựa trên thời gian, khóa phần cứng và mã khôi phục in sẵn, và mất một trong số đó là sự kiện hoàn toàn khác với mất cái duy nhất. Hãy đọc danh sách phương thức từ hệ thống danh tính thay vì yêu cầu người dùng ghi nhớ nó, và trong tenant Microsoft Entra truy vấn chỉ một dòng:

Get-MgUserAuthenticationMethod -UserId [email protected]

Sau đó ghi hồ sơ khôi phục khi tài khoản còn hoạt động: định danh tài khoản, các yếu tố đã đăng ký, nơi lưu mã khôi phục, ai có thể xác minh người yêu cầu một cách độc lập, và tài khoản tiếp cận những hệ thống nào. Hãy giữ nó trong kho được bảo vệ mà nhóm đã dùng, không bao giờ trong ghi chú cũng chứa mã đang hoạt động. Năm trường đó biến một cuộc gọi hoảng loạn thành danh sách kiểm tra, và hướng dẫn của NIST về vòng đời authenticator coi khôi phục là một phần của thông tin xác thực chứ không phải ngoại lệ.

Ghi kênh xác minh thành một trường riêng, vì đó chính là phần mọi người bỏ qua. Số điện thoại gắn với tài khoản không phải kênh độc lập khi người yêu cầu cũng kiểm soát điện thoại.

Bước 2: xác minh người yêu cầu ngoài đường dẫn hỏng

Thực hiện kiểm tra danh tính qua một kênh không phụ thuộc vào VPN, hộp thư hay thiết bị bị mất. Gọi lại số từ hồ sơ nhân sự, hoặc kiểm tra trực tiếp với quản lý đã có trong danh bạ, cả hai đều hiệu quả; tin nhắn trò chuyện gửi từ tài khoản đang khôi phục thì không. Việc kiểm tra nói về con người, không phải khả năng trả lời câu hỏi về tài khoản, vì chi tiết tài khoản bị rò rỉ. Ghi lại ai đã xác minh yêu cầu và khi nào, vì người đánh giá tiếp theo sẽ cần cả hai.

Khi yêu cầu đến với sự khẩn cấp và áp lực bỏ qua kiểm tra, đó chính là lúc phải chậm lại. Gian lận khôi phục trông giống hệt một đồng nghiệp nhiệt tình đang vội.

Bước 3: đăng ký phương án thay thế, rồi gỡ yếu tố cũ

Đăng ký authenticator mới qua luồng đăng ký bình thường, không bao giờ qua đường vòng quản trị. Sau đó gỡ phương thức bị mất một cách rõ ràng, vì đăng ký phương án thay thế để authenticator trước vẫn được ủy quyền cho đến khi ai đó gỡ nó. Nếu thiết bị cũ có thể nằm trong tay người khác, hãy coi việc gỡ là khẩn cấp và theo quy trình sự cố thay vì quy trình khôi phục. Thu hồi các phiên hiện có trong cùng lượt, vì phiên được tạo trước thay đổi có thể sống lâu hơn nó:

Revoke-MgUserSignInSession -UserId [email protected]

Gỡ yếu tố cho tất cả người khác, hoặc nới lỏng kiểm tra chứng chỉ của cổng, đánh đổi việc khôi phục của một người lấy sự cố ảnh hưởng toàn bộ triển khai. Giữ thay đổi trong phạm vi một tài khoản và leo thang nếu bằng chứng cho thấy xâm phạm rộng hơn. Ghi vào phiếu yếu tố nào đã bị gỡ và yếu tố nào thay thế nó.

Bước 4: chứng minh tài khoản hoạt động theo cả hai chiều

Đăng nhập một lần bằng yếu tố mới qua ứng dụng khách được hỗ trợ, rồi xác nhận tài khoản vẫn tiếp cận các tài nguyên mà nó đã tiếp cận trước khi mất. Thử một tài nguyên cần đường hầm và một tài nguyên không cần, để lỗi chỉ đúng tầng. Thử đăng nhập bằng yếu tố đã gỡ và mong đợi bị từ chối thay vì được nhắc, điều đó chứng minh việc gỡ đã có hiệu lực. Thử thách thất bại từ một thiết bị đã đăng ký hiện có là vấn đề nhắc nhở, không phải lý do đăng ký lại mọi thứ.

Sau đó đề nghị người dùng hoàn tất cùng lần đăng nhập mà không có hướng dẫn. Bài kiểm tra thành công của bạn chứng minh cấu hình; nỗ lực của họ chứng minh việc bàn giao.

Đóng phiếu với dấu thời gian của lần đăng nhập thành công và tên yếu tố đang được dùng. Cập nhật hồ sơ khôi phục trong cùng lượt, để lần mất tiếp theo bắt đầu từ kho chính xác chứ không phải kho cũ.

Bước 5: loại bỏ điều kiện khiến việc này đau đớn

Mỗi cuộc gọi khôi phục là bằng chứng về thiết kế đăng ký. Nếu tài khoản chỉ có đúng một yếu tố, hãy yêu cầu yếu tố thứ hai cho mọi người trong nhóm đó. Nếu mã khôi phục nằm trên laptop bị mất, hãy đổi nơi lưu. Nếu việc xác minh cần một quản lý đang nghỉ phép, hãy chỉ định người thay thế. Mỗi bản sửa tốn một buổi chiều và loại bỏ giờ tệ nhất của sự cố tiếp theo.

Sau đó đọc lại hồ sơ từ bước một đối chiếu với thực tế. Nó có liệt kê những yếu tố thực sự tồn tại không, và kênh xác minh còn đến được với con người không? Một cuốn sổ tay không ai cập nhật sẽ thoái hóa thành tài liệu mà mọi người bỏ qua trong chính cuộc gọi mà nó được viết ra.