微软Entra ID特权角色分层管理模型详解

第一部分：微软对特权角色的定义…及其遗留问题

当我们的团队对微软Entra、365或Azure进行加固审查时，我们总是强调保护特权用户账户。这不可避免地引出一个问题：哪些Entra角色是真正需要保护的特权角色？ 遗憾的是，向微软寻求答案的过程，客气地说，是令人困惑的。因此，我们决定自己以一种清晰、一致且实用的方式来回答这个问题。毕竟，如果定义特权角色本身并不能帮助你保护它们，那又有什么意义呢？

在本博客中，我们将主要做三件事：

探讨微软关于Entra中特权角色的说法，以及为什么这对我们来说还不够。
展示我们的答案：Entra特权分层模型。
深入剖析该模型，解释如何使用它来保护拥有这些角色的账户，以及我们做出某些选择的原因。

准备好了吗？让我们开始吧。

微软怎么说？

首先看看微软官方关于特权Entra角色说了什么。第一个查阅点是微软学习文章《Microsoft Entra内置角色》，我们在那里找到了所有内置Entra角色的列表，并看到其中一些被标记为“特权”。另一篇文章《Microsoft Entra ID中的特权角色和权限》则解释了“特权”标签的含义。

具体来说，一个特权角色被定义为：

拥有一个或多个特权权限的内置或自定义角色。

而特权权限的定义是：

在Microsoft Entra ID中，可用于将目录资源的管理委托给其他用户、修改凭据、身份验证或授权策略，或访问受限数据的权限。

查看内置角色列表，我们看到有28个角色被标记为特权：

Attribute Provisioning Reader
Application Administrator
Application Developer
Attribute Provisioning Administrator
Authentication Administrator
Authentication Extensibility Administrator
B2C IEF Keyset Administrator
Cloud Application Administrator
Cloud Device Administrator
Conditional Access Administrator
Directory Writers
Domain Name Administrator
External Identity Provider Administrator
Global Administrator
Global Reader
Helpdesk Administrator
Hybrid Identity Administrator
Intune Administrator
Lifecycle Workflows Administrator
Partner Tier1 Support
Partner Tier2 Support
Password Administrator
Privileged Authentication Administrator
Privileged Role Administrator
Security Administrator
Security Operator
Security Reader
User Administrator

但这还没完。

接下来，我们转向安全默认值，这是微软为新创建的Entra租户默认启用的最低保护措施。启用安全默认值后，要求16个管理员角色在每次登录时都必须执行MFA：

Application Administrator
Authentication Administrator
Authentication Policy Administrator
Billing Administrator
Cloud Application Administrator
Conditional Access Administrator
Exchange Administrator
Global Administrator
Helpdesk Administrator
Identity Governance Administrator
Password Administrator
Privileged Authentication Administrator
Privileged Role Administrator
Security Administrator
SharePoint Administrator
User Administrator

最后，我们可以查看由微软管理的条件访问策略《访问Microsoft管理门户的管理员的多重身份验证》，该策略覆盖了它描述为“高度特权”的14个角色：

Application Administrator
Authentication Administrator
Billing Administrator
Cloud Application Administrator
Conditional Access Administrator
Exchange Administrator
Global Administrator
Helpdesk Administrator
Password Administrator
Privileged Authentication Administrator
Privileged Role Administrator
Security Administrator
SharePoint Administrator
User Administrator

综合来看这些来源，我们得到了一个包含33个内置角色的列表，这些角色似乎以某种方式被认为是“特权”或“管理员”角色。有趣的是，没有任何一个来源包含完整的列表。托管条件访问策略缺少安全默认值覆盖的两个（2）个角色。安全默认值列表包含了微软学习内置角色参考中未标记为特权的五（5）个角色，包括Exchange Administrator和SharePoint Administrator。

此外，所有这些列表都缺少我们认为需要保护的特权角色，例如目录同步账户、组管理员和Teams管理员。

此时，你可能会有很多和我们第一次比较所有这些信息时一样的疑问：

所以到底哪些角色是特权的？
为什么安全默认值和托管条件访问策略等内置管理保护措施没有覆盖所有标记为特权的角色？
为什么安全默认值和托管条件访问策略彼此不一致？
为什么安全默认值和托管策略覆盖的某些角色在微软学习文档中没有被标记为特权？
“特权”到底意味着什么？
我们真的需要对Application Developer和Global Administrator应用相同的保护措施吗？
我们到底该如何处理这些信息？！

第二部分：TrustedSec开发的Entra特权分层模型

幸运的是，我们天生无法满足于现状。（这也是我们擅长工作的部分原因！）因此，我们深入研究并回答了这些问题，至少是其中的大部分。（不，我们仍然不知道为什么微软的来源如此不一致。）

我们的团队已经评估和/或加固了超过一百个微软云环境，目标始终是为客户提供有效且可操作的建议。

因此，在审视这些角色时，我们专注于一个目标：以一种能够驱动保护行动、且无需量子力学博士学位就能理解的方式来描述和分类特权Entra角色！

我们分析了所有内置Entra角色，评估每个角色在Entra租户或连接服务中的能力、如果拥有该角色的账户被恶意攻击者入侵对组织的影响，以及我们期望为防止或减轻此类入侵而采取的保护措施。初步审查得出了三（3）大类角色，并且我们看到了与AD管理分层模型明显的相似之处。

在此基础上，我们为每个层级制定了定义和逻辑标准，以确保一致性和可重复性。

因此，我们推出适用于Microsoft Entra ID角色的Entra特权分层模型，我们将角色分类为三（3）个特权层级，可以总结如下：

Entra第0层：Entra租户本身的核心管理和安全控制
Entra第1层：微软云环境中主要服务组件的管理控制
Entra第2层：有限范围或只读权限

以下是每个Entra特权层级的完整定义，包括每个层级内的角色、对这些实体的预期安全保护，以及该层级访问权限被入侵后的影响。

Entra第0层

Entra第0层代表了权限最高的Microsoft Entra ID角色，其定义是控制Entra ID租户的角色，包括核心租户管理、安全控制配置和特权用户管理。那些固有地具备升级到第0层权限的路径（不依赖于错误配置或其他干预）的角色也被视为第0层。

应极其严格地限制Entra第0层角色的使用。必须监控其分配并严格管理，严格执行最小权限分配。必须实施健壮、抗攻击的身份验证和会话管理控制。Entra第0层访问权限被入侵，预计会导致微软云环境的关键影响，直至Entra ID租户以及任何下游服务（例如任何连接的Microsoft 365环境和/或Azure订阅）被完全攻陷。

以下角色被视为Entra第0层：

Application Administrator
Cloud Application Administrator
Conditional Access Administrator
Global Administrator
Hybrid Identity Administrator
Partner Tier2 Support
Privileged Authentication Administrator
Privileged Role Administrator
Security Administrator

Entra第1层

Entra第1层的定义是非第0层，但符合以下任何标准的角色：

在Entra租户内提供管理（写入）能力。
控制微软云环境内的服务，包括Microsoft 365服务组件和Microsoft Azure订阅。
基于环境中常见的错误配置或因素组合，存在通往第0层权限的已知间接提权路径。

应限制、监控Entra第1层角色的使用，并遵循最小权限分配原则。应实施抗攻击的身份验证和会话管理控制。Entra第1层访问权限被入侵，预计会对微软云环境造成重大影响，包括Entra ID租户的中断和部分被攻陷，和/或受影响的微软云服务的完全被攻陷。

以下角色被视为Entra第1层：

AI Administrator
Attribute Assignment Administrator
Attribute Provisioning Administrator
Authentication Administrator
Authentication Extensibility Administrator
Authentication Policy Administrator
B2C IEF Keyset Administrator
Cloud App Security Administrator
Compliance Administrator
Directory Synchronization Accounts
Directory Writers
Domain Name Administrator
Dynamics 365 Administrator
Exchange Administrator
External ID User Flow Administrator
External Identity Provider Administrator
Global Secure Access Administrator
Groups Administrator
Helpdesk Administrator
Identity Governance Administrator
Intune Administrator
Knowledge Administrator
Lifecycle Workflows Administrator
Microsoft 365 Backup Administrator
Microsoft 365 Migration Administrator
On Premises Directory Sync Account
Partner Tier1 Support
Password Administrator
Power Platform Administrator
Security Operator
SharePoint Administrator
Skype for Business Administrator
Teams Administrator
Teams Telephony Administrator
User Administrator
Windows 365 Administrator
Yammer Administrator

Entra第2层

Entra第2层的定义是在微软云服务内提供有限管理能力和/或提供对敏感安全与配置信息的读取权限的角色。这些敏感信息可用于识别漏洞或错误配置，从而促进对Entra ID租户和微软云服务的权限提升或其他攻击。Entra第2层访问权限被入侵，预计会对微软云环境造成中度影响，且影响仅限于受影响的特定服务。

以下角色被视为Entra第2层：

Application Developer
Azure DevOps Administrator
Azure Information Protection Administrator
B2C IEF Policy Administrator
Billing Administrator
Cloud Device Administrator
Customer Lockbox Access Approver
Exchange Recipient Administrator
External ID User Flow Attribute Administrator
Global Reader*
License Administrator
Microsoft Entra Joined Device Local Administrator
Security Reader*
Teams Communications Administrator
Teams Communications Support Engineer

注意：对于拥有第0层或第1层角色的专用管理员账户，我们建议将Global Reader和/或Security Reader角色分配给这些账户并设为“活动”状态，而不是“符合条件”。这降低了特权会话被入侵的风险，因为用户无需先提升到更高权限级别，即可执行报告、诊断和其他只读功能。

关于Entra特权分层模型的结论

组织可以使用Entra特权分层模型来理解Microsoft Entra ID中角色的安全影响，并实施适合每个层级的有效安全控制，确保没有敏感角色被遗漏。未在分层中列出的内置Entra角色被视为非特权角色。随着微软在Microsoft Entra和Microsoft 365中添加或修改角色和功能，未来可能需要对各层级中的角色进行更新。Azure订阅角色不包含在此模型中。

第三部分：深入剖析模型

基于层级的安全

正如我们一开始所说，实用性很重要。这项工作必须有助于提高安全性，否则价值不大。因此，在不深入细节的情况下，以下是这些层级如何影响Entra安全态势的一些方面：

特权与非特权

首先，我们在特权用户账户和非特权用户账户之间划清一条明确的红线。任何被分配了上述模型中列出的角色的用户都被视为特权用户。必须对这些登录强制执行健壮的、抗攻击的MFA方法，并且还应实施诸如会话持续时间和浏览器持久性限制等控制措施。我们还会寻找Entra ID P2或同等级别的许可，以确保账户已获得PIM许可，从而可以对用户实施主动的基于风险的控制。

接下来，让我们按层级升序（第2层 → 第0层）介绍安全控制措施，请注意每个层级的控制都建立在下层控制的基础上：

第2层安全

角色分配：第2层角色的分配应通过PIM为人类用户进行管理，配置为“符合条件”并仅在有限时间内激活。
账户分离：用户账户应与个人的常规使用账户分开，并且特权用户账户不应分配生产力许可证（例如，访问Outlook、OneDrive、Teams等的权限）。这些分离措施显著降低了常规使用账户被入侵后攻击者获得Entra租户权限的可能性。
实际操作：然而，我们也考虑到实际情况。此层级中的一些用户可能不属于IT垂直部门（例如，使用Billing Administrator角色的会计部门人员），并且可能对维护单独账户等要求有所抵触。因此，在这个特权层级，我们接受组织根据风险做出知情决策，为了生产力和部门间关系而放宽某些建议。这不是“最安全”的选择，但对某些情况来说可能是正确的选择。话虽如此，如果你确实选择将第2层角色分配给拥有生产力许可证的常规使用账户，则PIM和抗攻击MFA的使用是必不可少的。

第1层安全

在第1层，“安全”与“易于使用”之间的天平明确地倾向于“安全”。

账户分离：特权账户必须与常规使用账户分开，并且不得分配生产力许可证。
PIM与MFA：对于人类用户，还需通过PIM进行符合条件的角色分配、实施抗攻击的MFA以及条件访问会话控制。

第0层安全

最低限度下，拥有第0层角色分配的账户必须遵守所有针对第1层账户的控制措施。

此外，最小权限分析对此层级至关重要。我们经常发现，为了图方便，用户被授予（或启用）Global Administrator或其他第0层角色，而实际上较低层级的角色就已足够。因此，定期评估这些角色分配和使用情况，询问以下问题：此账户是否需要此级别的访问权限，还是可以使用较低层级的角色代替？

还应将较低权限的角色分配给被分配了高权限角色的管理员，并培训他们只在必要时激活所需的最低权限角色。某人激活Global Administrator来编辑邮件流规则、修改SharePoint站点，甚至配置非特权用户账户，都是没有充分理由的。这也是为什么将Global Reader和/或Security Reader角色分配给第0层或第1层用户账户是有益的，因为这样做减少了管理员需要进一步提升权限的次数。微软提供了一些很好的资源，用于确定执行不同任务所需的最低权限角色：

虽然这些控制措施对许多组织来说可能已经足够，但让我们更进一步考虑。规模较大、风险状况较高或具有更成熟IAM安全计划的组织，应实施专用的特权访问工作站，以更全面地将所有高特权管理活动与非特权工作站和账户隔离开来。请参考微软学习文章《保护设备作为特权访问故事的一部分》和《旧版特权访问指南》。（微软可能称其为“旧版”，但对于不追求微软完整企业访问模型方法的组织来说，它仍然具有参考价值。）

就本文的范围而言，这可能已经足够深入了。值得一提的是，我们在微软云加固审查中专门用一个章节来评估客户Entra租户的特权账户安全性。

为什么这个角色在那个层级？

一旦我们阐明了特权层级的定义，将每个角色分配到层级大多是清晰明了的。然而，我们团队确实对一些角色进行了反复讨论，我们认为解释一些我们的理由会有所帮助：

Exchange管理员

论点：考虑到恶意接管电子邮件租户可能对组织造成巨大损害，Exchange Administrator难道不应该被视为第0层吗？
理由：因商业电子邮件欺诈及相关诈骗造成的财务损失是无可争辩的，更不用说被入侵的Exchange Administrator账户可能带来的权限提升和敏感数据窃取机会。但最终，该角色恰好符合第1层的定义。它控制着微软云环境中的一项服务。该角色不直接影响核心租户管理、安全配置或特权用户管理。该角色可以结合错误配置、社会工程学或其他战术、技术和程序（TTPs）来攻击并可能获得第0层访问权限，但它本身并不具备第0层的原生访问权限。在这方面，该角色与SharePoint Administrator等角色并无不同。Exchange Administrator角色绝对值得强有力的保护，这正是它位于第1层的原因。

Intune管理员

论点：Intune Administrator难道不应该是第0层吗？被入侵的Intune Administrator账户可能对广泛的资产造成损害，并可能利用工作站访问来捕获更高层级的凭据。此外，如果PAW通过Intune管理，那么Intune管理员就管理着用于第0层使用的专用工作站。
理由：恶意的Intune管理员对第1层或更低层级资产的潜在影响，正是使其成为第1层角色的原因。对于PAW，我们建议不要通过Intune管理设备，从而将设备完全移出Intune管理员的管理范围。如果你的组织采取不同的方法，那么你可能需要根据具体情况调整层级划分。

这只是我们关于角色分层讨论的一个缩影，但我们希望这种幕后视角能有所帮助。

结论

总结一下：

Entra中的角色可以分为三（3）个特权层级，类似于许多读者已经熟悉的AD管理分层。这些层级是：
1. Entra第0层：Entra租户本身的核心管理和安全控制。
2. Entra第1层：微软云环境中主要服务组件的管理控制。
3. Entra第2层：有限范围或只读权限。
这些层级为Entra中的配置和访问控制的实用、可操作的安全控制以及务实、基于风险的决策制定提供信息。

通过这个Entra特权分层模型，我们希望你能更有能力去理解、管理和保护Entra及Microsoft 365中的特权角色和用户，从而使你的租户，并最终使你的组织得到更好的保护。