Microsoft 365 应急访问账户：设置与审计指南

先说结论：Break-glass 账户（微软称“应急访问账户”）是一个仅云端的全局管理员账户，用于正常管理员无法登录的那一天。依据微软 2026 年 6 月 4 日更新的指引：至少保留两个；用通行密钥（FIDO2）或证书登录，不依赖手机；从阻止或限制登录的条件访问策略中排除；每次使用都告警；至少每 90 天测试一次。

每个 Microsoft 365 租户迟早会遇到管理员全部登录不了的下午：条件访问策略写错了，手机网络中断收不到 MFA 提示，或者唯一的全局管理员已经离职。没有应急账户，只能联系微软支持并等待；有账户却没人找得到，或者在清理时被禁用，结果一样。

本文回答几个实际问题：需要几个账户；在管理门户已强制 MFA 的 2026 年怎样设置；应该排除哪些策略；怎样告警；以及怎样用半小时审计整个安排。内容依据 Microsoft Learn 页面 Manage emergency access admin accounts，我们于 2026 年 11 月 10 日阅读。

什么是 Microsoft 365 的 break-glass 账户？

它是 Microsoft Entra ID 中拥有全局管理员角色的用户账户，只在正常管理账户无法使用时才用。它不是为方便准备的备用管理员，也不是 IT 团队日常共用的登录。它的作用是让一次故障（错误的策略、身份提供方宕机、管理员离职）不至于把整个组织锁在自己的租户之外。

微软列出的场景包括：联合身份不可用；管理员的 MFA 设备或 MFA 服务不可用；最后一位全局管理员离开；灾害造成手机网络中断；所有特权角色都是“符合条件”而非“活动”，且没有人能批准激活。

需要几个应急访问账户？

两个或以上。微软写明“创建两个或更多”，并在安全护栏中列出“至少保留两个以实现冗余”。对大多数中小租户，两个刚好：一个出问题（钥匙丢失、被误禁用）时另一个还在。超过三个只会增加要保管的凭据，不会增加韧性。

全局管理员总数是另一个问题。小型租户有两三位管理员加上应急账户就够。如果审查时发现十个以上长期全局管理员，那本身就是一项发现。

2026 年怎样设置？

微软现行步骤与旧做法不同，主要因为管理门户已强制 MFA。概括如下：

创建仅云端用户，使用 *.onmicrosoft.com 域名，不要联合身份，也不要从本地 Active Directory 同步。
分配全局管理员角色；在 Privileged Identity Management 中设为永久活动，而不是符合条件。
选择防钓鱼的登录方式。微软推荐通行密钥（FIDO2）；已有 PKI 的组织可用证书身份验证。两者都满足强制 MFA 的要求。
与日常管理员使用不同的方式。日常用 Authenticator 应用，应急账户就用硬件安全密钥。
不要绑定到个人或个人手机。凭据应放在多位授权管理员都能取得的地方，例如不同地点的保险柜。
确保凭据不会过期，也不会被“长期未使用账户”自动清理扫到。

为什么不直接用一个很长的密码？

旧建议是用超长密码并把账户排除在 MFA 之外。这个建议已经过时。微软页面现在的说法是，由账户上登记的防钓鱼方式来保护它，所列方式也正是满足强制 MFA 的那些。只有密码又排除 MFA 的账户，正是审计人员和攻击者最先找的东西。

应急账户要从条件访问中排除吗？

要，但只针对阻止或限制登录的策略。原因是：强制要求 MFA、合规设备或指定位置的策略，可能让账户在它本应应对的紧急情况下无法使用。两点实践建议：

建一个专用安全组，例如 EmergencyAccess，排除这个组，而不是逐个用户。以后新建策略只需记得添加这一个排除项。
按同一页面的说法，仅报告（report-only）策略不会阻止访问，不需要排除。

多数租户在这里会向两个方向出错：要么账户受“所有用户要求 MFA”策略约束，真正锁死时无法登录；要么排除了一切却没人盯着。只有账户凭据够强并且受到监控，排除才是安全的。如果你还在决定策略怎样设计，可先看我们对安全默认值与条件访问的比较。

怎样监控应急账户？

应急账户每一次登录都应通知不止一位管理员。微软的示例是把 Entra 登录日志送到 Azure Monitor，针对这些账户的对象 ID 建立基于查询的告警，阈值大于 0、严重性 0（严重），并通过邮件或短信操作组通知。Microsoft Sentinel 等工具同样可行。重点在原则而不是产品：没人计划的登录，必须在几分钟内送到真人面前。

有两处容易漏掉。登录日志必须先送到工作区，告警才能触发；审计日志也要开启，并且保留足够长的时间供事后查看。我们的 Microsoft 365 审计日志保留检查说明了各种许可证保留多久。

任何一次使用之后，微软建议做简短复盘：是计划内演练、真实紧急情况还是滥用？所做操作是否符合授权用途？

怎样审计应急账户？

这是我们使用的清单，你自己在 Entra 管理中心一小时内就能走完。

数量。至少两个吗？你能说出名字吗？列出全局管理员，找 breakglass、emergency、ea- 之类名称。
类型。是仅云端的 onmicrosoft.com 账户吗？来自本地同步或联合域都算发现项。
角色。全局管理员是永久活动吗？“符合条件”意味着要先激活，而激活本身可能被卡住。
登录方式。登记了通行密钥或证书吗？与日常管理员方式不同吗？密码加登记在某个人名下的手机号码，不符合微软自己的要求。
条件访问。对每个启用且会阻止或限制登录的策略，应急组被排除了吗？用 What If 工具测试；仅报告策略不需要排除。
告警。这些账户的登录有实时告警吗？谁收到？在计划演练时让人登录一次，看告警是否到达。
上次测试。上一次授权人员登录并执行管理操作是什么时候？微软说至少每 90 天一次，IT 人员或订阅变动后也要做。
保管。凭据放在哪里，谁能取得？有权限的人离开后换过保险柜密码吗？
卫生。账户没有分配邮箱许可证，不用于日常工作，也不在正常登录报告里出现。

不合格的结果长什么样？

常见发现包括：只有一个应急账户；账户仍是从本地同步的用户；账户排除了 MFA 却只有密码；账户在清理时被禁用后没有恢复；告警发到没人看的邮箱。这些都不罕见，而且光看配置就能发现。

这和完整的 Microsoft 365 安全审计是什么关系？

应急访问只是更广泛审查中 Entra ID 与特权访问部分的一项控制。我们的 Microsoft 365 CIS Benchmark 审计通过只读 Microsoft Graph 应用读取租户配置，检查包括：谁拥有全局管理员、他们的登录如何受保护、存在哪些条件访问排除。报告设计为可作为常见网络保险问卷和 Cyber Essentials 中管理员访问相关问题的证据，不读取邮件或文档内容。发现项的呈现方式可看样本报告解读，完整检查范围见 Microsoft 365 安全审计服务页（英文页）。

关于谁应该持有管理员角色，可延伸阅读我们的 Microsoft 365 与 Entra ID 安全审计说明。