Break glass account là tài khoản khẩn cấp được giữ riêng cho tình huống đặc biệt, khi chính sách đăng nhập, MFA, Conditional Access hoặc PIM khiến đội IT không còn đường vào hệ thống. Nói ngắn gọn, đây là “phao cứu sinh” để khôi phục quyền kiểm soát tenant hoặc hệ thống quản trị mà không phải chờ nhà cung cấp mở khóa. Nếu doanh nghiệp đang dùng IAM, PIM và Conditional Access, break glass account là lớp dự phòng cuối cùng chứ không phải tài khoản admin phụ để đăng nhập hằng ngày.
Tóm tắt nhanh
- Chỉ dùng khi bị lockout, sự cố xác thực hoặc mất quyền truy cập quản trị.
- Nên có ít nhất 2 tài khoản khẩn cấp, mật khẩu dài, riêng biệt và được lưu an toàn.
- Phải có runbook, cảnh báo đăng nhập và lịch kiểm tra định kỳ, không được để “đó rồi quên”.
Break glass account là gì và dùng để làm gì?
Break glass account còn được gọi là emergency access account. Đây là tài khoản được tạo để truy cập khẩn cấp vào hệ thống quản trị khi các cơ chế bảo vệ thông thường gặp lỗi, bị cấu hình sai hoặc vô tình chặn chính quản trị viên hợp lệ. Trong môi trường Microsoft 365 hay Entra ID, tình huống này thường xảy ra sau khi bạn siết chặt policy quá tay, sửa nhầm điều kiện truy cập hoặc gặp lỗi đồng bộ khiến tài khoản quản trị chính không thể đăng nhập.
Điểm cốt lõi là tài khoản này không phục vụ vận hành bình thường. Nó không nên được dùng để duyệt mail, đổi cấu hình hàng ngày hay xử lý ticket thường xuyên. Mục đích của nó chỉ là cứu hệ thống trong tình huống khẩn cấp để đội IT vẫn còn một đường quay vào, rà soát policy, khôi phục MFA, hoặc hoàn nguyên một thay đổi gây lockout.
Nếu bạn đã quen với MFA hoặc các nguyên tắc chống lừa đảo như phishing-resistant MFA, có thể hiểu break glass account là lớp bảo vệ “sau cùng”. Mọi thứ khác thất bại thì nó mới được mở ra, và mở xong thì phải đóng lại theo quy trình.
Khi nào doanh nghiệp nên dùng break glass account?
Bạn nên thiết kế tài khoản khẩn cấp ngay khi doanh nghiệp có đủ độ phụ thuộc vào cloud để một sự cố đăng nhập có thể làm tê liệt vận hành. Các tình huống phổ biến gồm: cấu hình Conditional Access sai khiến admin không vào được, rollout MFA lỗi, mất quyền truy cập PIM, lỗi đồng bộ danh tính, hoặc sự cố khiến đội vận hành không còn bất kỳ tài khoản quản trị nào đủ điều kiện để sửa lỗi.
Trong thực tế, break glass account đặc biệt hữu ích khi bạn đang làm thay đổi lớn như di chuyển tenant, siết policy cho toàn bộ người dùng, bật xác thực mạnh hơn cho nhóm admin hoặc tái cấu trúc IAM. Những lúc đó, một tài khoản khẩn cấp đúng chuẩn giúp bạn sửa sai nhanh mà không phải phá rào bằng cách tắt toàn bộ policy bảo vệ.
- Tenant hoặc hệ thống quản trị bị lockout sau khi đổi policy.
- MFA, Conditional Access hoặc PIM lỗi khiến admin hợp lệ không đăng nhập được.
- Cần khôi phục một cấu hình quan trọng khi mọi tài khoản quản trị thường ngày đều không vào được.
- Cần một đường vào cuối cùng để điều tra, chứ không phải để vận hành hằng ngày.
Break glass account khác gì admin thường, PIM và SSPR?
Break glass account thường bị nhầm với admin thường hoặc privilege account. Thực ra chúng giải quyết những bài toán khác nhau. Admin thường dùng cho vận hành bình thường; PIM dùng để cấp quyền tạm thời theo thời gian; SSPR cho phép người dùng tự đặt lại mật khẩu; còn break glass account là đường vào khẩn cấp khi mọi lớp kiểm soát khác không còn hoạt động đúng như mong đợi.
Nếu bạn đang chuẩn hóa một hệ thống truy cập, hãy đọc song song PIM, SSPR và bài về Conditional Access. Ba mảnh đó xử lý quyền, tự phục hồi và chính sách truy cập; break glass account chỉ đóng vai trò dự phòng để bạn không bị mắc kẹt trong chính hệ thống bảo mật của mình.
| Thành phần | Mục tiêu chính | Khi nên dùng | Rủi ro nếu lạm dụng |
|---|---|---|---|
| Break glass account | Đường vào khẩn cấp khi lockout | Sự cố cần khôi phục quyền quản trị | Nếu dùng hằng ngày sẽ mất ý nghĩa dự phòng |
| Admin thường | Vận hành và quản trị hằng ngày | Cấu hình, hỗ trợ, kiểm tra | Nếu có quyền quá rộng dễ tăng rủi ro |
| PIM | Cấp quyền tạm thời theo nhu cầu | Khi cần đặc quyền có kiểm soát | Nếu cấu hình lỏng thì mất lợi thế JIT |
| SSPR | Tự đặt lại mật khẩu cho người dùng | Người dùng quên mật khẩu | Không giải quyết được lockout ở tầng quản trị |
| Conditional Access | Ra quyết định theo ngữ cảnh | Siết truy cập theo thiết bị, vị trí, rủi ro | Thiết lập sai có thể khóa luôn admin hợp lệ |
Cách thiết kế tài khoản khẩn cấp an toàn
Một break glass account tốt không chỉ là “tạo xong là xong”. Bạn cần thiết kế nó như một cơ chế dự phòng có kiểm tra, có chủ sở hữu và có nhật ký. Ít nhất hãy có 2 tài khoản khẩn cấp độc lập để phòng trường hợp một tài khoản bị lỗi, quên mật khẩu hoặc bị vô hiệu hóa ngoài ý muốn. Mỗi tài khoản phải có tên rõ ràng, mô tả rõ vai trò và không được dùng chung với tài khoản nhân sự nào.
- Tạo ít nhất 2 tài khoản emergency access riêng biệt.
- Đặt mật khẩu dài, ngẫu nhiên, độc nhất và lưu trong kho mật khẩu an toàn hoặc két vật lý có kiểm soát.
- Thiết kế quyền tối thiểu cần thiết; không gán quyền thừa cho tài khoản khẩn cấp.
- Chỉ loại trừ khỏi những policy có thể gây lockout, nhưng vẫn phải bật logging, audit và alert.
- Viết runbook ngắn: ai được phép dùng, khi nào dùng, cách ghi nhận, và bước quay về trạng thái bình thường.
- Kiểm thử định kỳ để chắc chắn tài khoản vẫn đăng nhập được và quy trình khôi phục vẫn hoạt động.
Nếu bạn dùng MFA cho toàn bộ người dùng, hãy suy nghĩ kỹ trước khi áp cùng một policy cho tài khoản khẩn cấp. Điểm mấu chốt là đừng tạo ra một failure mode mới: chính policy bảo vệ lại trở thành thứ khóa cửa dự phòng của bạn. Thay vì đó, hãy quản lý ngoại lệ bằng quy trình duyệt riêng và ghi nhận rõ trong tài liệu vận hành.
Với các hệ thống nhạy cảm, nên tách rõ quyền truy cập vào kho mật khẩu, tài khoản cloud, email khẩn cấp và kênh thông báo sự cố. Khi ITDR hoặc SOC phát hiện dấu hiệu bất thường, việc kiểm tra break glass account cũng phải được đưa vào playbook theo dõi thay vì để trôi qua như một tài khoản “không ai chạm tới”.
Thiết lập break glass account trong Microsoft 365 và Entra ID
Nếu doanh nghiệp của bạn đang dùng Microsoft 365 hoặc Entra ID, hãy xem break glass account như một phần của kế hoạch khôi phục danh tính. Cấu hình tốt thường bắt đầu bằng việc tạo tài khoản cloud-only, đặt password mạnh, hạn chế quyền ở mức cần thiết rồi xác định rõ policy nào được phép loại trừ. Các policy loại trừ này chỉ nên áp dụng với lý do khẩn cấp, không phải để “cho dễ làm việc”.
Sau đó, hãy kiểm tra các điểm liên quan đến Conditional Access, PIM và SSPR để chắc chắn tài khoản khẩn cấp không bị chặn nhầm bởi cùng một lớp bảo vệ mà nó dùng để cứu bạn. Đây là lý do nhiều doanh nghiệp thiết kế break glass account cùng lúc với IAM: khi identity layer gặp sự cố, bạn vẫn có một lối đi vào hệ thống để chỉnh sửa chính identity layer đó.
Một số đội vận hành còn giữ kịch bản kiểm thử theo quý: đăng nhập vào tài khoản khẩn cấp, xác minh quyền, kiểm tra log, thử khôi phục một policy mẫu rồi đóng lại. Cách này không chỉ xác nhận rằng account vẫn sống, mà còn giúp đội IT quen với quy trình trước khi sự cố thật xảy ra.
Sai lầm thường gặp khi làm tài khoản khẩn cấp
- Chỉ tạo 1 tài khoản rồi coi như đã đủ dự phòng.
- Dùng break glass account cho công việc hàng ngày, khiến nó mất tính khẩn cấp.
- Lưu mật khẩu trong cùng email hay cùng hệ thống đang có nguy cơ lockout.
- Loại trừ quá rộng khỏi policy và vô tình mở cửa cho rủi ro cao hơn.
- Không có cảnh báo đăng nhập và không kiểm tra log sau mỗi lần sử dụng.
- Không có runbook, nên đến lúc sự cố xảy ra thì cả team phải đoán quy trình.
Một sai lầm khác là chỉ quan tâm đến việc “có vào được hay không” mà quên bước sau đó. Tài khoản khẩn cấp phải đi kèm mục tiêu đóng vòng: đăng nhập, sửa lỗi, ghi nhận, thu hồi thay đổi, kiểm tra lại policy và đóng tài khoản về trạng thái bình thường. Không có phần thu hồi này thì break glass account rất dễ biến thành cửa sau vận hành.
FAQ
Break glass account có phải là tài khoản admin đặc biệt không?
Không hẳn. Nó là tài khoản khẩn cấp, được giữ riêng để dùng trong tình huống lockout hoặc sự cố identity. Admin đặc biệt vẫn là tài khoản vận hành; break glass account chỉ xuất hiện khi bạn cần đường vào cuối cùng.
Doanh nghiệp nhỏ có cần break glass account không?
Có, nếu doanh nghiệp phụ thuộc vào cloud, SSO, MFA hoặc Conditional Access cho vận hành hằng ngày. Quy mô nhỏ không có nghĩa là ít rủi ro lockout hơn; đôi khi chính đội nhỏ lại dễ bị khóa quyền hơn khi chỉ có một vài tài khoản quản trị.
Nên có bao nhiêu break glass account?
Thực tế tốt là ít nhất 2 tài khoản độc lập. Điều này giúp bạn tránh tình huống một tài khoản hỏng, mất mật khẩu hoặc bị vô hiệu hóa rồi cả kế hoạch dự phòng cũng sập theo.
Break glass account có nên loại trừ khỏi Conditional Access không?
Chỉ khi đó là yêu cầu của quy trình khẩn cấp và được kiểm soát rất chặt. Mục tiêu là tránh lockout, nhưng bạn vẫn cần logging, cảnh báo và quy trình duyệt rõ ràng để tài khoản này không trở thành lỗ hổng.
Nếu bạn đang chuẩn hóa IAM, PIM và Conditional Access, hãy kiểm tra ngay tài khoản khẩn cấp của mình.
Đội IT nên xác nhận có ít nhất 2 break glass accounts, mật khẩu được lưu an toàn, cảnh báo đăng nhập đang hoạt động và runbook khôi phục đã được diễn tập. Khi cần, SCTT có thể hỗ trợ rà lại policy đăng nhập, cách loại trừ an toàn và luồng xử lý sự cố để giảm rủi ro lockout.
Nếu bạn muốn, bước tiếp theo nên là audit nhóm admin, rồi rà lại PIM và Conditional Access trước khi bật thêm lớp bảo vệ mới.
