用户默认配置

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

这些设置应按以下截图所示进行更改：

用户默认操作：

• 将"用户可以注册应用程序"从"是"改为"否"
• 将"限制非管理员用户创建租户"从"否"改为"是"

用户设备设置默认值

用户默认能够无需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角色中，应优先保护的角色在此处以粗体显示：

第0层Entra ID角色

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

• 全局管理员 - 对Entra ID、Microsoft 365的完全管理员权限，以及一键完全控制所有Azure订阅
• 混合身份管理员 - “可以创建、管理和部署从Active Directory到Microsoft Entra ID的配置设置，使用云配置以及管理Microsoft Entra Connect、直通身份验证(PTA)、密码哈希同步(PHS)、无缝单点登录(Seamless SSO)和联合设置”
• 合作伙伴第2层支持 - “可以重置所有非管理员和管理员（包括全局管理员）的密码并使刷新令牌无效”
• 特权身份验证管理员 - Microsoft：“不要使用”。“设置或重置任何用户（包括全局管理员）的任何身份验证方法（包括密码）”
• 特权角色管理员 - “可以管理Microsoft Entra ID中的角色分配，以及在Microsoft Entra特权身份管理内”

保护特权角色成员资格

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

保护角色可分配组(RAGs)

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

只有全局管理员或特权角色管理员可以创建角色可分配组并管理它们（成员资格）。角色可分配组的所有者可以管理它们。还有一个应用程序权限(Graph:RoleManagement.ReadWrite.Directory)也提供管理权限。

在Entra ID租户中，最多有500个角色可分配组（创建最大值）。只有特权身份验证管理员或全局管理员可以更改凭据或重置MFA，或修改角色可分配组成员和所有者的敏感属性。

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

保护高特权应用程序

Entra ID权限的权限结构：

第0层应用程序 这些应用程序具有有效的完全管理权限或获得Entra ID完全管理权限的能力。限制具有这些权限的应用程序。

• Directory.ReadWrite.All - “授予的访问权限大致相当于全局租户管理员”
• AppRoleAssignment.ReadWrite.All - 允许应用程序代表登录用户管理任何API的应用程序权限授予和任何应用程序的应用程序分配
• RoleManagement.ReadWrite.Directory - 允许应用程序在没有登录用户的情况下读取和管理租户的基于角色的访问控制(RBAC)设置
• Application.ReadWrite.All - 允许调用应用程序在没有登录用户的情况下创建和管理（读取、更新、更新应用程序密码和删除）应用程序和服务主体

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

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

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

使用这些典型条件访问策略时，存在常见的覆盖差距。

CA策略差距#1：用户在公司网络外需要MFA

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

CA策略差距#2：管理员不需要MFA

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

CA策略差距#3：排除项

• CAP包括几个安全控制
• 但是，有排除项：管理员、VIP、高管、人力资源等
• 这在安全态势中造成了显著差距
• 攻击者喜欢被排除在安全控制之外！

Microsoft托管策略(MMP)

• 自动以报告模式部署
• 修改有限：排除用户、打开或设置为仅报告模式、无法重命名或删除任何Microsoft托管策略、可以复制策略以制作自定义版本
• Microsoft将来可能会更新这些策略
• MMP在引入租户90天后开启（设置为启用）
• 目前专注于3个领域：访问Microsoft管理员门户的管理员的MFA、为用户配置的每用户MFA的MFA、风险登录的MFA和重新身份验证

关键条件访问策略

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

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

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

当客户接受此请求时：

• 合作伙伴租户中的"管理代理"角色被提供对客户租户的有效"全局管理员"权限
• 合作伙伴租户中的"帮助台代理"角色被提供对客户租户的有效"帮助台管理员"（密码管理员）权限

这些是唯一选项。它们适用于所有客户环境 - 没有细粒度配置。拥有数十个客户的合作伙伴将导致这些组中的所有合作伙伴账户在所有客户环境中拥有提升的权限。

尽快转向细粒度委托管理权限(GDAP)！

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

保护Entra Connect

危害Entra Connect：

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

防御Entra Connect

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

保护无缝单点登录(SSSO)

攻击Azure AD无缝单点登录

• 由Azure AD Connect管理
• 危害Azure AD无缝SSO计算机账户密码哈希(“AZUREADSSOACC”)
• Azure AD无缝SSO计算机账户密码不会更改

保护无缝单点登录(SSSO)

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

保护Microsoft直通身份验证(PTA)

攻击Microsoft PTA

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

保护直通身份验证(PTA)

• 将Entra Connect视为第0层资产（如域控制器）

快速保护Entra ID清单

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