通过

在 Microsoft Entra ID 中管理紧急访问帐户

  • 项目

请务必防止被意外锁定在 Microsoft Entra 组织之外，因为你将无法登录或激活角色。 可在组织中创建两个或更多个紧急访问帐户，缓解意外丧失管理访问权限造成的影响。

具有全局管理员角色的用户帐户在系统中具有高特权，这包括具有全局管理员角色的紧急访问帐户。 紧急访问帐户只能用于紧急情况或“破窗式”情况，即不能使用正常管理帐户时。 建议始终以将紧急帐户的使用限于绝对必要情况为目标。

本文提供有关在 Microsoft Entra ID 中管理紧急访问帐户的指导。

为何使用紧急访问帐户

在以下情况下，组织可能需要使用紧急访问帐户：

  • 用户帐户进行了联合，且由于手机网络中断或标识提供程序服务中断，联合身份验证当前不可用。 例如，如果在你的环境中的标识提供者主机停运，则当 Microsoft Entra ID 重定向到其标识提供者时，用户可能无法登录。
  • 管理员通过 Microsoft Entra 多重身份验证注册，而其每个设备或服务都不可用。 用户可能无法完成多重身份验证以激活角色。 例如，手机网络中断让用户无法应答电话呼叫或接收短信，而这是他们为其设备注册的仅有的两种身份验证机制。
  • 具有最新全局管理访问权限的人员离开了组织。 Microsoft Entra ID 将阻止删除最后一个全局管理员帐户，但它不会阻止在本地删除或禁用该帐户。 这两种情况都可能使组织无法恢复帐户。
  • 出现自然灾害等不可预见的紧急情况，导致手机或其他网络不可用。
  • 如果符合全局管理员和特权角色管理员角色的角色分配条件，激活需要批准，但未选择审批者（或目录中的审批者均被移除）。 现役全局管理员和特权角色管理员是默认审批者。 但是，除非使用紧急访问帐户，否则不会有有效的全局管理员和特权角色管理员，并且租户管理将被锁定。

创建紧急访问帐户

创建两个或多个紧急访问帐户。 这些帐户应该是使用 *.onmicrosoft.com 域且未从本地环境联合或同步的仅限云帐户。 概括而言，请按照以下步骤操作。

  1. 查找现有的紧急访问帐户，或使用全局管理员角色创建新帐户。

    在 Microsoft Entra ID 中创建紧急访问帐户的屏幕截图。

  2. 为紧急访问帐户选择以下无密码身份验证方法之一。 这些方法满足 必需的多重身份验证要求。

  3. 将紧急访问帐户 配置为使用无密码身份验证。

  4. 要求对所有紧急帐户进行防钓鱼多重身份验证。

  5. 安全地存储帐户凭据。

  6. 监视登录和审核日志。

  7. 定期验证帐户。

配置要求

配置这些帐户时，必须满足以下要求：

  • 在大多数组织中，紧急访问帐户不会与组织中的任何单个用户相关联。 凭据位于一个已知的安全位置，可供管理团队的多个成员使用，并且未与任何员工提供的设备（如电话）连接。 此方法通常用于统一紧急访问帐户管理：大多数组织不仅需要Microsoft云基础结构的紧急访问帐户，还需要本地环境、联合 SaaS 应用程序和其他关键系统。

    或者，可以选择为管理员创建单独的紧急访问帐户。 此解决方案可提升责任，并允许管理员从远程位置使用紧急访问帐户。

  • 对紧急访问帐户使用强身份验证，并确保它不使用与其他管理帐户相同的身份验证方法。 例如，如果普通管理员帐户使用 Microsoft Authenticator 应用进行强身份验证，则需要对紧急帐户使用 FIDO2 安全密钥。 考虑 各种身份验证方法的依赖项，以避免在身份验证过程中添加外部要求。

  • 设备或凭据不得过期，或者由于使用次数不多而划归到自动清理的范围内。

  • 在 Microsoft Entra Privileged Identity Management 中，应该将紧急访问帐户的全局管理员角色分配设置为永久活动，而不是符合条件。

  • 有权使用这些紧急访问帐户的个人必须利用指定的安全工作站或类似的客户端计算环境，例如特权访问工作站。 与紧急访问帐户交互时，应使用这些工作站。 有关配置具有指定工作站的 Microsoft Entra 租户的详细信息，请参阅 部署特权访问解决方案。

联合身份验证指南

某些组织使用 Active Directory 域服务和 Active Directory 联合身份验证服务（AD FS）或类似的身份验证提供者来与 Microsoft Entra ID 联合。 本地系统的紧急访问和云服务的紧急访问应区分开，彼此不相互依赖。 如果从其他系统掌控和/或获得对具有紧急访问特权的帐户的身份验证，会在这些系统发生中断时增加不必要的风险。

安全地存储帐户凭据

组织需要确保紧急访问帐户的凭据始终安全且仅为有权使用它们的用户所知。 例如，可以将 FIDO2 安全密钥 用于 Windows Server Active Directory 的 Microsoft Entra ID 或智能卡。 凭据应存储在安全、防火的保险箱中，这些保险箱位于安全、独立的位置。

监视登录和审核日志

组织应该监视紧急帐户的登录和审核日志活动，并触发目标为其他管理员的通知。 监视紧急访问帐户的活动时，可以验证这些帐户仅用于测试或实际紧急情况。 可以使用 Azure Monitor、Microsoft Sentinel 或其他工具监视登录日志，并在紧急访问帐户登录时向管理员触发电子邮件和短信警报。 本部分说明如何使用 Azure Monitor。

先决条件

获取紧急访问帐户的对象 ID

  1. 以至少用户管理员身份登录到 Microsoft Entra 管理中心。

  2. 浏览到 Entra ID>用户。

  3. 搜索紧急访问帐户并选择用户名。

  4. 复制并保存“对象 ID”属性，以便以后可以使用。

  5. 对第二个紧急访问帐户重复上述步骤。

创建警报规则

  1. 至少以监视参与者身份登录到 Azure 门户。

  2. 浏览到 监控>“Log Analytics 工作区”。

  3. 选择工作区。

  4. 在工作区中，选择“警报”“新建警报规则”。

    1. 在“资源”下，验证订阅是否与警报规则关联。

    2. 在“条件”下，选择“添加”。

    3. 在“信号名称”下选择“自定义日志搜索”。

    4. 在 “搜索”查询下，输入以下查询，插入两个紧急访问帐户的对象 ID。

      注意

      对于每个要包括的额外紧急访问帐户，请在查询中再添加一个 or UserId == "ObjectGuid"。

      示例查询：

      // Search for a single Object ID (UserID)
SigninLogs
| project UserId 
| where UserId == "00aa00aa-bb11-cc22-dd33-44ee44ee44ee"

      // Search for multiple Object IDs (UserIds)
SigninLogs
| project UserId 
| where UserId == "00aa00aa-bb11-cc22-dd33-44ee44ee44ee" or UserId == "11bb11bb-cc22-dd33-ee44-55ff55ff55ff"

      // Search for a single UserPrincipalName
SigninLogs
| project UserPrincipalName 
| where UserPrincipalName == "user@yourdomain.onmicrosoft.com"

      将紧急访问帐户的对象 ID 添加到警报规则

    5. 在“警报逻辑”下，输入以下内容：

      • 依据：结果数
      • 运算符：大于
      • 阈值：0

    6. 在“计算基于”下，选择“期限(以分钟为单位)”（希望查询运行的时长）和“频率(以分钟为单位)”（希望查询运行的频率）。 频率应小于或等于期限。

      警报逻辑

    7. 选择“完成” 。 现在可以查看此警报的每月预估成本。

  5. 选择警报要通知的用户操作组。 如果要创建一个作组，请参阅 “创建作组”。

  6. 若要自定义发送给操作组成员的电子邮件通知，请选择“自定义操作”下的“操作”。

  7. 在“警报详细信息”下，指定警报规则名称并添加可选说明。

  8. 设置事件的“严重级别”。 建议将其设置为“关键(严重性 0)。

  9. 在“创建后启用规则”下，将其设置为“是”。

  10. 若要关闭警报一段时间，请选中“阻止警报”复选框，并输入再次发出警报之前的等待持续时间，然后选择“保存”。

  11. 选择“ 创建警报规则”。

创建操作组

  1. 选择“创建操作组”。

    创建通知操作组

  2. 输入操作组名称和短名称。

  3. 验证订阅和资源组。

  4. 在操作类型下，选择“电子邮件/短信/推送/语音”。

  5. 输入操作名称，如“通知全局管理员”。

  6. 将“操作类型”选择为“电子邮件/短信/推送/语音”。

  7. 选择“编辑详细信息”以选择要配置的通知方法，输入所需的联系信息，然后选择“确定”以保存详细信息。

  8. 添加要触发的任何其他操作。

  9. 选择“确定”。

准备一个事后分析团队来评估每个紧急访问帐户凭证的使用情况

如果触发警报，请保留来自 Microsoft Entra 和其他工作负荷的日志。 对紧急访问帐户使用情况的情况和结果进行评审。 此评审将确定是否使用了帐户：

  • 计划的演练验证其适用性
  • 在实际紧急情况中管理员均无法使用其常规帐户
  • 或者由于帐户被滥用或未经授权使用

接下来，检查日志以确定个人使用紧急访问帐户执行了哪些操作，以确保这些操作与该帐户的授权使用相符。

定期验证帐户

除了培训员工使用紧急访问帐户外，还应有一个持续的过程来验证紧急访问帐户是否可供授权员工访问。 应进行定期演练来验证帐户的功能，并确认在帐户随后被滥用的情况下触发监视和警报规则。 至少应定期执行以下步骤：

  • 确保安全监视人员知道帐户检查活动正在进行。
  • 查看并更新有权使用紧急访问帐户凭据的个人列表。
  • 确保使用这些帐户的紧急破窗流程有文档记录，且是最新的流程。
  • 确保在紧急情况下可能需要执行这些步骤的管理员和保安员接受了该流程的培训。
  • 验证紧急访问帐户是否可以登录并执行管理任务。
  • 确保用户尚未将多重身份验证或自助密码重置（SSPR）注册到任何单个用户的设备或个人详细信息。
  • 如果帐户已注册为通过多重身份验证登录到设备，以便在登录或角色激活期间使用，请确保需在紧急情况下使用该设备的所有管理员都可访问该设备。 另请验证设备是否可以通过至少两个不共享常见故障模式的网络路径进行通信。 例如，设备可通过公司无线网络和移动网络提供商网络与 Internet 通信。
  • 在具有访问权限的人员离开组织后以及定期，更改任何保险箱的密码组合。

应定期执行以下步骤，进行重大更改后也应执行这些步骤：

  • 每隔 90 天至少执行一次
  • IT 人员近期发生更改时，例如离职后或职位更改
  • 组织中的 Microsoft Entra 订阅发生更改时

后续步骤