快速提升Entra ID安全性

在2025年10月的BSides北弗吉尼亚州（BSides NoVa）会议上，我发表了一场关于如何快速提升Entra ID安全性的演讲。本文捕捉了我演讲幻灯片中的关键信息。

本文描述了应设置哪些Entra ID设置和配置以提升安全性，包括：

• 用户默认配置
• 访客默认设置
• 用户应用程序同意和权限
• 保护Entra ID角色
• 特权角色成员保护
• 可分配角色的组配置
• 高特权应用程序
• 条件访问策略
• 合作伙伴访问
• 保护Entra Connect
• 快速保护Entra ID清单

用户默认配置

默认情况下，用户能够注册应用程序和创建新租户。

这些设置应按下方截图所示进行更改。

用户默认操作：

• 将“用户可以注册应用程序”从“是”设置为“否”。
• 将“限制非管理员用户创建租户”从“否”设置为“是”。

用户设备设置默认值

用户默认拥有将设备加入Entra的能力，而无需多因素认证。

用户设备设置操作：

• 将“用户可以将设备加入Microsoft Entra”设置为“选定”，并添加一个允许将设备加入Entra的组。
• 配置一个条件访问策略，要求在将设备加入Entra时进行MFA；或者将配置“注册或将设备加入Microsoft Entra需要多重身份验证”设置为“是”。

访客默认设置

访客用户默认拥有与查看Entra ID相同的权限。

此设置应按下方所示进行更改。

访客默认操作：

• 将访客用户访问限制从“访客用户拥有与成员相同的访问权限（最具包容性）”更改为“访客用户访问仅限于其自身目录对象的属性和成员资格（限制最严格）”。

用户应用程序同意和权限默认值

最初在Azure AD/Entra ID中，用户拥有同意权限的默认权利。此配置在许多当前环境中仍然存在。

现在已更改为以下可用选项。

用户应用程序同意和权限建议： 将用户对应用程序的同意设置为“允许用户同意来自已验证发布者的应用，针对选定权限”；或者更好的选择是“让Microsoft管理您的同意设置（推荐）”。

保护Entra ID角色

截至2025年10月，共有117个Entra ID角色。这使得了解需要保护什么以及保护到什么级别变得具有挑战性。

微软已将28个角色标记为“特权”。这些角色应受到保护，尽管保护级别不同。例如，全局读取者与全局管理员角色不同，全局管理员角色中账户的保护级别应高于全局读取者。

微软标记为特权的Entra角色中，应优先保护的角色在此处以粗体显示。

第0层Entra ID角色

有五个（5）角色应在最高级别（如第0层）受到保护。确保这些角色的成员被要求始终使用MFA（最好是FIDO2），并且成员资格非常有限。

• 全局管理员

  • 对Entra ID、Microsoft 365拥有完全管理权限，并可一键完全控制所有Azure订阅。
  • 从Azure AD到Active Directory（通过Azure）——一条未预料到的攻击路径（2020）。

• 混合身份管理员

  • “可以使用云配置创建、管理和部署从Active Directory到Microsoft Entra ID的配置设置，以及管理Microsoft Entra Connect、直通身份验证（PTA）、密码哈希同步（PHS）、无缝单点登录（无缝SSO）和联合设置。”

• 合作伙伴第2层支持

  • “合作伙伴第2层支持角色可以重置所有非管理员和管理员（包括全局管理员）的密码并使刷新令牌失效。”
  • “虽然没有全局管理员那么强大，但该角色确实允许拥有该角色的主体将自己或任何其他主体提升为全局管理员。”——你（可能）从未听说过的最危险的Entra角色。

• 特权身份验证管理员

  • 微软：“请勿使用。”
  • “为任何用户（包括全局管理员）设置或重置任何身份验证方法（包括密码）。……强制用户重新注册现有的非密码凭证（如MFA或FIDO），并撤销设备上记住的MFA，在下一次所有用户登录时提示进行MFA。”

• 特权角色管理员

  • “拥有此角色的用户可以在Microsoft Entra ID内以及Microsoft Entra Privileged Identity Management中管理角色分配。……此角色授予管理所有Microsoft Entra角色（包括全局管理员角色）分配的能力。”

保护特权角色成员资格

• 确保高特权角色中没有标准用户账户作为成员。
• 确保角色成员是“符合资格”的，而非“永久”的。
• 确保成员被要求使用MFA。

保护可分配角色的组

可分配角色的组是安全组或Microsoft 365组，其属性isAssignableToRole设置为true，且不能是动态组。创建它们是为了解决组被添加到Entra ID角色后，组管理员可以修改成员资格的潜在问题。只有全局管理员或特权角色管理员可以创建可分配角色的组并管理其成员资格。可分配角色的组的所有者可以管理它们。还有一个应用程序权限（Graph: RoleManagement.ReadWrite.Directory）也提供管理权限。Entra ID租户中最多可创建500个可分配角色的组。只有特权身份验证管理员或全局管理员可以更改凭证或重置MFA，或修改可分配角色的组成员和所有者的敏感属性。

组嵌套

在Entra ID中，可分配角色的组不能被嵌套在其他可分配角色的组中。然而，标准组可以被嵌套在可分配角色的组中。例如，你可以创建一个名为“T0 Admins”的可分配角色的组，然后嵌套一个名为“Security Team”的标准组。好处是：你可以授予“Security Team”组管理权限（管理其成员），而不会授予他们管理“T0 Admins”组成员的权限。

可分配角色的组所有者

配置在可分配角色的组上的所有者能够管理该组的成员资格。确保所有者是管理员账户，并且受到与该可分配角色的组所属角色相同级别的保护。

保护高特权应用程序

Entra ID权限的权限结构如下图所示：

第0层应用程序

这些应用程序拥有有效的完全管理权限或能够获得对Entra ID的完全管理权限。限制拥有这些权限的应用程序。早在2021年，我就强调了最令人担忧的应用程序权限：

• Directory.ReadWrite.All

  • “Directory.ReadWrite.All授予的访问权限大致相当于全局租户管理员。”*

• AppRoleAssignment.ReadWrite.All

  • 允许应用代表已登录用户管理任何API的应用程序权限授予以及任何应用的应用程序分配。这也允许应用程序为自己、其他应用程序或任何用户授予额外特权。

• RoleManagement.ReadWrite.Directory

  • 允许应用在没有已登录用户的情况下读取和管理租户的基于角色的访问控制（RBAC）设置。这包括实例化目录角色、管理目录角色成员资格，以及读取目录角色模板、目录角色和成员资格。

• Application.ReadWrite.All

  • 允许调用应用在没有已登录用户的情况下创建和管理（读取、更新、更新应用程序机密和删除）应用程序和服务主体。这也允许应用程序充当其他实体并使用授予它们的权限。
  • 当存在至少一个第0层应用程序时，此应用程序权限就属于第0层。然后，此权限为应用程序提供了向该应用程序添加凭据并模拟它的能力。

使用条件访问策略保护Entra ID

条件访问策略在第一因素身份验证（用户名和密码）之后应用。这需要Entra P1许可。条件访问基于以下因素采取行动：谁在连接、他们从哪里连接、连接发生到或来自哪个应用程序和/或设备，以及何时适用。

有一些常见的条件访问策略：

• 阻止从不可信位置访问
• 要求对所有用户进行MFA
• 阻止访客用户访问

通过这些典型条件访问策略，存在一些常见的覆盖缺口。

CA策略缺口 #1：用户在非公司网络时需要MFA

• 条件访问策略要求用户远程工作时（不在公司网络或通过VPN连接）进行MFA。
• 假设没有攻击者会在公司网络上。
• 攻击者可以使用用户名/密码而无需进行MFA。

CA策略缺口 #2：管理员不需要MFA

• MFA被要求某些用户访问特定应用程序。
• 但是，没有条件访问策略要求管理员使用MFA。
• 或者……条件访问策略只要求少数几个角色的成员使用MFA。
• 攻击者可以使用用户名/密码而无需进行MFA。

CA策略缺口 #3：排除项

• 条件访问策略包含多项安全控制：
  • 要求MFA
  • 要求AAD已加入且合规的设备
  • 基于位置的访问
• 但是，存在一些排除项：
  • 管理员
  • VIP
  • 高管
  • HR
  • 等等
• 这在安全态势上造成了重大缺口。
• 攻击者喜欢被排除在安全控制之外！

微软托管策略

• 自动部署在报告模式下。
• 修改受到限制：
  • 可以排除用户。
  • 可以打开或设置为“仅报告”模式。
  • 无法重命名或删除任何微软托管策略。
  • 可以复制策略以创建自定义版本。
• 微软将来可能会更新这些策略。
• 微软托管策略在引入租户90天后启用。
• 目前主要关注3个领域：
  • 管理员访问微软管理门户时进行MFA。
  • 对已为用户配置每用户MFA的用户进行MFA。
  • 对风险登录进行MFA和重新身份验证。

关键条件访问策略

• 要求管理角色的账户使用MFA（最好是FIDO2）。
• 阻止旧式身份验证（用户名和密码身份验证）。
• 按地理位置阻止位置。
• 阻止设备代码流。
• 在所有设备上强制执行设备合规性。
• 按位置限制对应用程序的访问。
• 要求访客用户使用MFA。

合作伙伴关系——也称为委派管理

配置的合作伙伴可以拥有对客户租户的管理权限（“委派管理”）。 当合作伙伴请求访问客户环境时提供此权限。 当客户接受此请求时：

• 合作伙伴租户中的“管理员代理”角色获得对客户租户的有效“全局管理员”权限。
• 合作伙伴租户中的“帮助台代理”角色获得对客户租户的有效“帮助台管理员”（密码管理员）权限。

这些是唯一的选择。 它们适用于所有客户环境——没有细粒度配置。 一个拥有数十个客户的合作伙伴将导致这些组中的所有合作伙伴账户在所有客户环境中都拥有提升的权限。 尽快转向细粒度委派管理权限！

在此处检查您租户的合作伙伴配置：https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/PartnerRelationships

细粒度委派管理权限

GDAP提供了：

• 细粒度、时间限制的、可审核的合作伙伴访问。
• 要求合作伙伴请求访问。
• 不再提供对客户租户的“管理员代理”或“帮助台代理”权限。

保护Entra Connect

危害Entra Connect：

• 危害Active Directory。
• 获取Entra Connect服务器（或SQL数据库）的管理员权限。
  • OU管理员权限。
  • 本地管理员权限。
  • GPO修改权限。
  • 获取其他系统上的本地管理员密码（当密码不唯一时）。
• 获取管理系统控制权。
  • Microsoft SCCM（或类似工具）。
  • 漏洞扫描器。
• 危害VMware（或其他虚拟平台）。

从Entra Connect到Active Directory

• Active Directory对象的修改会同步到Entra ID。
• 如果控制了Entra Connect，就可以更改写入回Active Directory的属性。

从Entra Connect到Entra ID

• Entra Connect服务器对Entra ID拥有提升的权限。
• Entra Connect服务器对同步的OU中的Active Directory对象拥有提升的权限。

防御Entra Connect

• 将Entra Connect服务器、SQL服务器/数据库和服务账户视为第0层资产（类似于域控制器）。
• 确保Entra Connect服务器和SQL服务器/数据库位于顶级管理OU中。
• 限制应用于Entra Connect相关系统的组策略。
• 限制Entra Connect相关系统上的本地管理员权限。

保护无缝单点登录

攻击Azure AD无缝单点登录

• 由Azure AD Connect管理。
• “Azure AD公开了一个公开可用的端点，该端点接受Kerberos票证并将其转换为SAML和JWT令牌。”
• 危害Azure AD无缝SSO计算机账户密码哈希（“AZUREADSSOACC”）。
• 为要模拟的用户和服务“aadg.windows.net.nsatc.net”生成一个白银票据。
• 将此票据注入本地Kerberos缓存。
• Azure AD无缝SSO计算机账户密码不会更改。

保护无缝单点登录

• 对于Windows 10、Windows Server 2016及更高版本，建议使用通过主刷新令牌进行的SSO。
• 对于Windows 7和Windows 8.1，建议使用无缝SSO。
• 确保Azure AD无缝单点登录密钥（密码）每年更改几次。

保护Microsoft直通身份验证

攻击Microsoft PTA

• 由Azure AD Connect管理。
• 危害托管PTA的服务器（通常是Entra Connect服务器）。
• Entra ID发送明文密码（不是哈希值！）以验证用户身份。
• 注入DLL以危害用于PTA的凭证。

保护直通身份验证

将Entra Connect视为第0层资产（类似于域控制器）。

快速保护Entra ID清单

• 将“用户可以注册应用程序”设置为“否”。
• 将“限制非管理员用户创建租户”设置为“是”。
• 将“用户可以创建安全组”设置为“否”。
• 将访客用户访问限制设置为“访客用户访问仅限于其自身目录对象的属性和成员资格（限制最严格）”。
• 限制谁可以将设备加入Microsoft Entra，并要求MFA。
• 将访客邀请设置设置为“只有分配给特定管理员角色的用户才能邀请访客用户”。
• 将用户同意设置设置为“让Microsoft管理您的同意设置（推荐）”。
• 审查第0层角色成员资格，确保成员是管理员账户，符合PIM资格，并且不同步自本地环境。
• 如果您使用可分配角色的组，请确保在第0层角色上未设置所有者。
• 仔细审查任何拥有第0层应用程序权限的应用程序。
• 确保条件访问要求第0层角色成员每次身份验证都使用MFA，最好是FIDO2/Microsoft Authenticator推送（服务账户和服务主体除外）。
• 删除任何标准的委派管理，并转向细粒度委派管理权限。
• 将Entra Connect视为第0层资产（类似于域控制器）。
• 确保云管理员使用单独的浏览器进行管理活动（最低要求），或连接到专用的云管理服务器（推荐）。
• 确保至少配置了1个紧急访问管理员账户，并配备FIDO2密钥。