快速提升 Entra ID 安全性

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

本文描述了应设置的用于提升安全性的Entra ID设置和配置，包括：

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

用户默认配置

默认情况下，用户可以注册应用程序和创建新租户。应将此设置更改为如下截图所示。

用户默认设置操作：

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

用户设备设置默认值

默认情况下，用户无需MFA即可将设备加入Entra。

用户设备设置操作：

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

来宾默认设置

来宾用户默认拥有与成员相同的访问权限查看Entra ID。应将此设置更改为如下所示。

来宾默认设置操作：

将来宾用户访问限制从“来宾用户拥有与成员相同的访问权限（最宽松）”更改为“来宾用户访问被限制为其自身目录对象的属性和成员身份（最严格）”。

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

最初在Azure AD/Entra ID中，用户默认拥有同意权限的权利。此配置在许多当前环境中仍然存在。现已更改为以下可用选项。

用户应用程序同意和权限建议：

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

保护 Entra ID 角色

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

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

Microsoft标记为特权且应优先保护的Entra角色如下（加粗表示更关键）：

Tier 0 Entra ID 角色

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

全局管理员
- 对Entra ID、Microsoft 365的完全管理员权限，以及一键完全控制所有Azure订阅的能力。
- 从Azure AD到Active Directory的攻击路径（2020年提及）。
混合身份管理员
- “可以使用云配置创建、管理和部署从Active Directory到Microsoft Entra ID的配置设置，以及管理Microsoft Entra Connect、直通身份验证、密码哈希同步、无缝单一登录和联合设置。”
合作伙伴二级支持
- “合作伙伴二级支持角色可以重置所有非管理员和管理员（包括全局管理员）的密码并使刷新令牌失效。”
- “虽然没有全局管理员那么强大，但该角色允许拥有该角色的主体将自己或任何其他主体提升为全局管理员。”
特权身份验证管理员
- Microsoft建议：“不要使用。”
- “可以为任何用户（包括全局管理员）设置或重置任何身份验证方法（包括密码）……强制用户针对现有的非密码凭据（如MFA或FIDO）重新注册，并在设备上撤销记住MFA，在下次登录时提示所有用户进行MFA。”
特权角色管理员
- “拥有此角色的用户可以在Microsoft Entra ID以及Microsoft Entra特权身份管理中管理角色分配。……此角色授予管理所有Microsoft Entra角色分配的能力，包括全局管理员角色。”

保护特权角色成员身份

确保高特权角色中没有标准用户账户作为成员。
确保角色成员是符合条件的，而不是永久的。
确保成员需要使用MFA。

保护可分配角色的组

可分配角色的组是将 isAssignableToRole 属性设置为 true 的安全组或Microsoft 365组，且不能是动态组。创建它们是为了解决组被添加到Entra ID角色后组管理员可以修改成员资格的潜在问题。

只有全局管理员或特权角色管理员可以创建可分配角色的组并管理其成员。
可分配角色的组的所有者可以管理它们。
有一个应用程序权限也提供管理权利。
Entra ID租户中最多可创建500个可分配角色的组。
只有特权身份验证管理员或全局管理员可以更改成员和所有者的凭据或重置MFA或修改敏感属性。

组嵌套

在Entra ID中，可以对可分配角色的组进行嵌套。

可分配角色的组所有者

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

保护高特权应用程序

Entra ID权限的结构如下：

Tier 0 应用程序

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

Directory.ReadWrite.All
- “Directory.ReadWrite.All授予的访问权限大致相当于全局租户管理员。”
AppRoleAssignment.ReadWrite.All
- 允许应用程序代表登录用户管理任何API的应用程序权限授权和任何应用程序的应用程序分配。这也允许应用程序为自己、其他应用程序或任何用户授予额外的权限。
RoleManagement.ReadWrite.Directory
- 允许应用程序在无需登录用户的情况下读取和管理租户的基于角色的访问控制设置。这包括实例化目录角色和管理目录角色成员资格，以及读取目录角色模板、目录角色和成员资格。
Application.ReadWrite.All
- 允许调用应用程序在无需登录用户的情况下创建和管理（读取、更新、更新应用程序机密和删除）应用程序和服务主体。这也允许应用程序充当其他实体并使用授予它们的权限。
- 当至少有一个应用程序是Tier 0时，此应用程序权限即为Tier 0。然后，此权限使应用程序能够为该应用程序添加凭据并模拟它。

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

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

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

典型的条件访问策略及覆盖缺口

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

当用户远程工作（不在公司网络或未通过VPN连接）时，CAP要求用户使用MFA。
假设攻击者不会在公司网络上。
攻击者可以使用用户名/密码而无需MFA。

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

要求特定用户访问特定应用程序时使用MFA。
但是，没有CAP要求管理员使用MFA。
或者……CAP只要求少数几个角色的成员使用MFA。
攻击者可以使用用户名/密码而无需MFA。

CA 策略缺口 #3：排除项

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

Microsoft 托管策略

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

关键条件访问策略

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

合作伙伴关系 - 又称委托管理

配置的合作伙伴可以拥有对客户租户的管理权限。

当合作伙伴请求访问客户环境时提供。
当客户接受此请求时：
- 合作伙伴租户中的“管理员代理”角色被授予对客户租户的有效“全局管理员”权限。
- 合作伙伴租户中的“帮助台代理”角色被授予对客户租户的有效“帮助台管理员”权限。
这些是唯一选项。它们适用于所有客户环境——没有细粒度配置。
拥有数十个客户的合作伙伴将导致这些组中的所有合作伙伴账户在所有客户环境中都拥有提升的权限。
应尽快切换到细粒度委托管理权限。

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

保护 Entra Connect

攻击 Entra Connect

入侵 Active Directory。
获取 Entra Connect 服务器（或 SQL 数据库）的管理员权限。
获取管理系统的控制权。
入侵 VMware（或其他虚拟平台）。

从 Entra Connect 攻击 Active Directory

获取 OU 管理员权限。
获取本地管理员权限。
获取 GPO 修改权限。
当密码不唯一时，获取其他系统的本地管理员密码。

从 Entra Connect 攻击 Entra ID

获取本地管理员权限。
获取 GPO 修改权限。

防御 Entra Connect

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

保护无缝单一登录

攻击 Azure AD 无缝单一登录

由 Azure AD Connect 管理。
Azure AD 暴露一个公开可用的端点，该端点接受 Kerberos 票证并将其转换为 SAML 和 JWT 令牌。
入侵 Azure AD 无缝 SSO 计算机账户密码哈希。
为用户想要冒充的用户和服务生成一个 Silver Ticket。
将此票证注入本地 Kerberos 缓存。
Azure AD 无缝 SSO 计算机账户密码不会更改。

保护无缝单一登录

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

保护 Microsoft 直通身份验证

攻击 Microsoft 直通身份验证

由 Azure AD Connect 管理。
入侵托管 PTA 的服务器（通常是 Entra Connect 服务器）。
Entra ID 发送明文密码进行用户身份验证。
注入 DLL 以入侵用于 PTA 的凭据。

保护直通身份验证

将 Entra Connect 视为 Tier 0 资产（如同域控制器）。

快速保护 Entra ID 清单

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