Microsoft 365 / 分配管理员角色并准备紧急访问帐户
Microsoft 365管理权限不应给予所有人员全局管理员角色，而应根据工作需要分配所需的角色。同时，为了应对普通管理员帐户无法访问的意外情况，需要准备独立紧急管理员帐户，并定期进行验证。
分配管理员角色的原因
管理员角色决定了可以查看的设置范围以及可以执行的更改操作。许可证管理员、用户管理员、Exchange管理员、SharePoint管理员等角色是根据各自不同的职责设计的。如果在一个帐户上赋予不必要的广泛权限，帐户被入侵或操作失误的影响范围也会扩大。
Microsoft的Microsoft 365管理员角色指南建议使用最小权限和限制管理员数量。在分配角色时，首先列出负责人需要执行的具体任务，然后选择支持这些任务的权限范围最小且能完成任务的角色。不要仅凭角色名称推测权限，要确认详细权限。
选择工作中所需角色的示例
| 负责人工作 | 优先考虑的角色 | 需要分开确认的权限 |
|---|---|---|
| 普通员工密码重置 | 适用于密码管理员或支持工作的限制性角色 | 是否可以重置其他管理员密码取决于目标角色 |
| 产品许可证分配与撤销 | 许可证管理员 | 与产品购买和付款权限区分开 |
| 邮箱和邮件流管理 | Exchange管理员 | 无需单独赋予所有负责人邮箱内容访问权限 |
| 查看服务公告 | 消息中心读取者（Message Center Reader）等查询角色 | 安全·个人信息公告可能需要额外权限 |
例如，如果人事负责人传递新员工名单而 IT 负责人创建帐户，则可以不授予人事负责人用户管理权限，而是通过审批流程进行连接。请区分“公司所需的工作”和“此人必须亲自执行的任务”来判断。角色分配应由拥有权限的独立管理员进行。
向普通管理员分配角色的方法
- 在 Microsoft 365 管理中心打开 [角色] → [角色分配]。当前帐户必须拥有管理角色的权限。
- 选择适合工作的角色并阅读权限说明。如有需要，可在 Microsoft Entra 管理中心查看更细分的角色。
- 在 [已分配] 中添加负责人后保存。操作记录中应保留授予理由、审批人、适用范围及复审时间表。
- 确认该帐户是否可以处理所需的工作，并移除不必要的权限。由于权限反映可能需要时间，请重新启动登录会话进行确认。
在用户详细信息界面的[角色管理]中也可以更改角色。微软的角色分配流程说明了这两个路径。
保存后，被授权的负责人将在新的登录会话中确认所需的菜单和操作。如果是读取工作，则只验证查询；在检查更改权限时，需要确定批准的测试对象和可恢复的值。如出现错误，先检查组织、角色的对象范围和分配状态，不要立即提升为全局管理员。
工作结束或负责人变更时，在同一角色分配 → 对应角色 → 已分配中移除对象并重新查询。如果同时拥有多个角色，即使移除一个，也可能通过其他路径完成相同操作。如果组织使用 PIM（特权身份管理，按需激活权限的管理功能），请区分并确认活动角色和符合条件的角色。
什么是应急管理员帐户？
应急帐户是在通常使用的管理员帐户、认证方法或外部ID系统出现问题时，用于重新访问组织的帐户。这与创建一个日常工作用帐户不同。微软在应急访问帐户指南中建议准备两个以上云专用帐户，设计与正常运营帐户不同的认证路径，并对使用情况进行监控和定期测试。
应急帐户应以基本 onmicrosoft.com 域的云专用帐户创建，不依赖本地目录同步或外部认证服务器。2026年6月更新的微软指南建议使用与普通管理员不同的抗网络钓鱼身份验证手段，并在阻止或限制登录的条件访问策略中将应急帐户排除。仅报告模式的策略不会阻止登录，因此仅此原因无需排除。
此例外并不意味着应只使用密码进行访问。必须通过FIDO2通行密钥、安全密钥或准备好的公钥基础设施的证书认证等方式满足必要的多因素认证要求。如果日常帐户依赖手机认证，应急帐户不应仅依赖同一部手机。如果使用PIM，应急帐户的全局管理员角色建议处于永久活动状态，而不是需要激活批准的符合条件的状态。
紧急帐户准备和验证顺序
- 调查当前的全局管理员和认证依赖。确认是否仅依赖于关联的本地 ID 或单一认证方式。
- 根据组织政策设计两个以上仅用于云的紧急帐户。帐户名应能识别用途，但不要在公开文档或屏幕截图中暴露。
- 按照 Microsoft 指南设置全局管理员权限和认证方式，并确保日常管理员帐户之外有独立的使用路径。设置方式根据组织的许可和政策有所不同。
- 为帐户使用和设置变更制定警报和审计程序。如果使用紧急帐户登录，应记录事件并进行事后审查。
- 在受控环境下定期测试登录。测试后确认日志和警告是否正常记录，在负责人变更时更新访问程序。
定期测试中需确认的结果
Microsoft 建议至少每 90 天验证一次紧急帐户。在管理员更换、认证策略变更或存放地点变更后也要重新检查。关键是要区分“帐户存在”和“可以用于恢复”，以免在实际故障时首次登录该帐户。
- 通知安全负责人这是预定的测试，并确认已获批准的负责人能够访问凭证和指定的安全工作环境。如果凭证保管库的访问本身依赖于处于故障状态的业务帐户，则恢复路径也可能被阻断。
- 不要重用普通帐户会话，而是使用紧急帐户登录。确认所需的认证手段是否正常工作，以及是否能够访问管理功能。不要为了测试目的随意解除组织的策略。
- 确认登录和审计记录中是否留下了实际帐户和时间，以及是否向其他管理员传递了监控警告。如果未收到警告，不应认为正常运行准备已完成。
- 注销后，记录测试结果、访问者、失败项目和修改负责人。在实际紧急使用之后，调查当时执行的操作，并重新审核可能暴露的凭证和存储程序。
监控可以基于Entra登录日志中的帐户对象ID来设计。如果将通知连接到Azure Monitor或组织的安全监控工具，则必须先准备日志导出、存储及通知路径，并可能产生额外权限和费用。仅创建帐户不会自动配置警报。实际紧急帐户地址、恢复代码和安全密钥的存放位置不应记录在公开文件中，而应保留在受控的操作记录里。
