Microsoft Entra ID：安全团队需要了解的内容

Microsoft Entra ID（原名 Azure Active Directory（Azure AD））是 Microsoft 365、Azure 以及成千上万已连接的 SaaS 应用背后的身份与访问管理服务。如果你的组织使用 Microsoft 产品，那么 Entra ID 几乎可以确定就是决定谁可以登录、以及他们可以访问哪些内容的系统。

这种居于核心的地位，使其成为任何 Microsoft 环境中最重要、也最容易成为攻击目标的部分之一。攻击者通常会利用被泄露的凭证、OAuth 同意滥用以及会话劫持来在 Entra ID 中进行横向移动，这意味着正确配置的重要性与“把它部署出来”同等关键。

本指南将介绍 Entra ID 是什么、它如何工作、六项核心安全能力、八项加固优先级，以及在混合环境中原生工具的不足之处。

Microsoft Entra ID 是什么？

Microsoft Entra ID 是 Microsoft 的云端 身份和访问管理（IAM） 服务。它是用于控制谁可以登录你们组织的 Microsoft 365 环境、Azure 资源以及连接的第三方应用，并在登录后允许他们执行哪些操作的系统。

该平台支持单点登录（SSO）、多因素身份验证（MFA）、条件访问、生命周期管理，以及对用户、设备和应用的身份保护。组织可通过 OAuth、SAML 和 OpenID Connect 将其连接到数千个 SaaS 应用。

作为更广泛的身份产品组合扩展的一部分，Microsoft 将 Azure AD 更名为 Microsoft Entra ID。名称虽然发生了变化，但核心服务保持不变。如果你一直在管理 Azure AD，那么你其实已经在使用 Entra ID。

注意： Entra ID 替代的是 Azure AD 的名称，而不是本地（on-premises）的 Active Directory。两者是独立的产品。大多数 Microsoft 环境都会同时运行两者，并使用 Microsoft Entra Connect 在两者之间同步身份。这样的混合部署意味着，安全团队需要保护两个相互连接、但架构不同、攻击面也不同的系统。

Microsoft Entra ID 是如何工作的？

从高层来看，Entra ID 位于用户与他们需要访问的应用程序之间。当有人尝试登录 Microsoft 365、Azure 资源或已连接的 SaaS 应用程序时，Entra ID 会处理身份验证（authentication）和授权（authorization）的决策。

每当用户请求访问时，Entra ID 都会验证其身份（通过密码、MFA 或免密码方式，例如 FIDO2 密钥）。随后，它会在授予或阻止访问之前评估条件访问（Conditional Access）策略。

这些策略可以纳入多种因素，包括设备合规性、位置、应用程序敏感度，以及来自 Identity Protection 的实时风险信号。

对于同时使用本地 Active Directory 和 Entra ID 的组织，Microsoft Entra Connect 会在两种环境之间同步用户身份、组成员身份和凭据。这意味着，在本地 AD 中已预配的用户无需维护单独的云身份，也可以通过 Entra ID 对云资源进行身份验证。

Entra ID 还支持大规模的应用集成。第三方 SaaS 应用会向租户注册，并使用 OAuth 2.0 和 SAML 2.0 等协议进行联合身份验证——这也是单点登录体验如何在数百个应用之间发挥作用，而无需每个应用都管理自己独立的用户数据库。

Microsoft Entra ID 中的核心安全与 IAM 功能

安全团队无需了解 Entra ID 中的每一项功能。但有 6 个能力领域会直接影响你的安全态势。

• 身份验证与 MFA： Entra ID 支持 SSO、基于密码的身份验证，以及无密码选项，包括 FIDO2 passkeys、Windows Hello for Business 和基于证书的身份验证。MFA 通过 Conditional Access 策略来强制执行，而不是依赖旧式的按用户设置。对于特权帐户，应优先采用抗钓鱼的方法（passkeys 和 FIDO2 密钥）。
• 条件访问： 这是 Entra ID 访问架构的核心策略引擎。在授予或阻止访问、或要求采取其他控制措施之前，它会评估用户身份、设备合规性、位置、应用程序敏感性以及实时风险信号。
• 身份保护： 身份保护使用 Microsoft 信号来检测存在风险的登录和风险用户，并可将这些信号传递到条件访问中，以实现自动化响应。
• 特权身份管理（PIM）： PIM 为特权角色提供即时（Just-in-time）激活、审批工作流、具时间限制的分配，以及在提升特权时必须提供的理由。其目标是取消常驻的管理员访问权限，避免特权账户一直处于等待被攻破的状态。
• Microsoft Entra ID 治理： 这款身份治理解决方案通过自动化的入职/变更/离职（joiner-mover-leaver）工作流、具有可配置到期时间的访问包，以及定期的访问认证活动来管理访问生命周期，从而最大限度地减少孤立账户和权限“越涨越多”（privilege creep）。
• 监控与集成： Entra ID 通过 API 将审计日志、登录日志和风险数据流式传输到 Microsoft Sentinel、Microsoft Defender for extended detection and response（XDR），以及第三方安全信息与事件管理（SIEM）平台。

其中许多功能需要 Entra ID P2 或 Entra ID Governance 许可证。使用基础版或 P1 许可证的组织缺少 Identity Protection 和 PIM，这会显著限制身份安全态势。

安全团队的 8 条 Microsoft Entra ID 最佳实践

以下是安全团队应优先考虑的 8 项实践。

1. 强制启用抗钓鱼认证

标准 MFA 已经不再足够。密码喷射（password spraying）活动仍在大规模攻破账户，而对手在中间（adversary-in-the-middle，AiTM）的钓鱼工具包可以劫持合法的 SSO 流程来窃取会话令牌，从而完全绕过 MFA。

像 SMTP AUTH、POP3 和 IMAP4 这样的旧协议会让情况更糟，因为它们提供的认证路径会完全绕过条件访问（Conditional Access）。

优先事项是首先将特权账户迁移到抗钓鱼的方法：FIDO2 Passkey、Windows Hello for Business，或基于证书的认证。

使用条件访问（Conditional Access）的认证强度控制来强制实施，并在整个组织中阻止旧版认证协议。对所有剩余用户启用标准 MFA 是底线，而不是目标。

2. 使用 PIM 和最小特权来加固特权角色

每一个永久的 Global Admin 账号都相当于一份随时可被利用的邀请函。如果其中一个账号被攻破，攻击者就可能提升权限、创建后门，并在任何人察觉之前修改安全策略。

Privileged Identity Management (PIM) 通过用“按需的实时提升（just-in-time elevation）”替代“长期驻留的访问权限”，从而消除这种暴露风险。管理员在需要时发起访问请求，并配套审批流程、时间受限的会话（最多八小时是适合你们组织的合理上限），以及在启用时强制要求多因素认证（MFA）。

在使用 PIM 之外，也要把“爆炸半径（影响范围）”控制得尽可能小：

• 尽量减少对 Global Administrator 的分配，并使用作用域（scoped）的角色，确保管理员只获得其工作所需的权限。
• 保留两个仅云端的 break-glass 账号，并对任何登录活动设置告警。
• 每月审查特权角色分配。

PIM 和最小特权能减少攻击者所能触及的范围。下一步是控制最初授予任何人（不论是否拥有特权）访问权限的条件。

3. 设计并持续调整条件访问（Conditional Access）策略

条件访问（Conditional Access）是策略引擎，负责让其他所有 Entra ID 安全控制发挥作用。如果你的策略存在漏洞，那么下游不会有任何东西来弥补。

从基础覆盖范围开始：

• 要求所有用户启用 MFA
• 阻止高风险登录
• 保护管理门户

然后针对访客访问、高价值应用以及未受管理的设备叠加场景特定规则。

先以仅报告（report-only）模式部署新策略；在强制实施前使用 What-If 工具模拟效果；并使用应用程序标记，确保每个已集成的应用至少覆盖在一项策略之下。

策略漂移的风险比缺失策略更大。临时的组排除、从不撤销的测试例外，以及对身份验证要求的随意更改，都会制造出缺乏保护的访问路径，并在不知不觉中不断累积。

应监控审计日志，以发现非获批准人员对策略所做的修改；并且至少每季度一次审查 Conditional Access 的覆盖范围。

4. 启用 Identity Protection，并自动化风险响应

Identity Protection 能检测高风险登录和高风险用户，但如果没有自动化响应，仅有检测本身就只是噪音。 如果 Identity Protection 信号没有与强制执行操作的 Conditional Access 策略关联，那么被入侵的账户会一直保持活跃状态，而告警则会堆积在一个无人能足够快处理的队列中。

解决方法是将 Identity Protection 信号直接连接到执行(强制)环节。配置 Conditional Access：对中等风险的登录要求 MFA，并对高风险用户强制进行安全的密码重置。

随后将登录日志、审计日志和风险事件实时传输到您的 SIEM ，以便安全运营中心（SOC）能够为“不可能的旅行”(impossible travel)、旧式认证尝试以及权限提升模式构建检测规则。自动化强制执行与 SOC 级可视性相结合，能够弥补检测与响应之间的差距。

5. 控制应用注册与 OAuth 授权同意（OAuth consent）

OAuth 授权同意（OAuth consent）是 Entra ID 中最容易被忽视的持久化机制之一。早在 Mail.Read 年前获得授权的应用，只要没有人明确撤销，它就会无限期保留该访问权限；而大多数组织并没有针对企业应用权限的定期审查流程。

攻击面不仅限于过期的授权（stale grants）。威胁行为者已利用设备代码授权流程（device code authorization flows），诱使用户在攻击者的名义下通过合法的 Microsoft 登录页面进行身份验证，从而获取可绕过 MFA 的访问令牌。

为降低这种暴露风险，请限制或关闭自助授权同意（self-service consent），以便用户在未获得批准的情况下无法授予租户范围的权限。

对任何高权限（high-privilege）权限请求都要求管理员同意（admin consent）工作流；将应用注册限制为仅管理员；并按月审查服务主体（service principals）和企业应用（enterprise app）权限。若不进行定期审查，每一项已授予的权限都可能成为攻击者可继承的持久性（persistence）机制。

6. 管理（Govern）来宾与 B2B 访问

来宾账户很容易创建，也很容易被遗忘，这使得它们成为大多数 Entra ID 租户中的一项治理（governance）漏洞。每一个未受治理的来宾用户，都是一个你的安全团队并未预先配置（provision）且可能并不知道其存在的身份；只要没有人主动将其移除，该身份的访问权限就会持续存在。

要做到更严格，首先要限制谁可以邀请来宾，并为所有来宾用户要求 MFA。每个来宾账户都应指定一个内部负责人（owner），负责持续的访问理由（access justification）。

跨租户访问策略通过控制外部身份可以访问到的范围，增加了另一层保护；同时，定期的访问审查能够发现那些原本会被长期保留的非活动账户。

通过结合责任主体、MFA 要求和定期审查，可以防止访客访问成为盲点。

7. 将 Entra ID 集成到 identity threat detection and response (ITDR) 和 SOC 监控中

当身份信号与其他遥测信息进行关联时，其价值会大大提升。仅凭一次可疑登录本身，可能只是误报。将同一次登录与显示横向移动的终端数据配对，或与显示异常数据传输的网络日志配对，就会变成值得调查的高置信度指示器。

这种关联分析需要将 Entra ID 的登录日志、审计日志以及 Identity Protection 的风险信号输入到你的 SIEM 或 XDR 平台中。身份事件也应与终端和网络数据一起纳入事件响应运行手册。

这样，当触发基于身份的告警时，SOC 就拥有评估影响范围和影响程度所需的上下文，而无需在彼此断开的工具之间来回切换。

8. 定期评估 Entra ID 的安全态势

定期的安全态势审查能够发现主要安全项目之间逐渐累积的配置问题。配置漂移会通过一些在单独看起来似乎无害的小改动逐步形成。例如，可能是一个在其论据不再成立后仍然保留的条件访问（Conditional Access）排除项；也可能是拥有广泛权限的测试应用注册；或者是在项目结束很久之后仍保持激活状态的特权角色分配。

如果不加以处理，这些问题会逐步削弱你在前七个步骤中建立的安全态势。Microsoft Secure Score 提供了有用的持续性指标，但它不应成为唯一的评估机制。

结合 Center for Internet Security（CIS）Benchmarks 以及定期的人工审查来补充，并制定与每个控制领域的风险特征相匹配的检查节奏：

• 特权角色分配与 OAuth 同意授权：每月。
• 访客访问与 B2B 配置：根据访问量，每月或每季度一次。
• 条件访问（Conditional Access）策略：每季度一次；在任何重要的租户变更之后，还需进行临时/额外的复查。

这八项优先事项将显著强化您的 Entra ID 环境。但即使是配置得很好的租户也有边界，理解原生能力的终点同样重要——与把配置做对一样重要。

Microsoft Entra ID 无法解决的事项（以及您还需要哪些能力）

Entra ID 覆盖了很多方面，但它并不是为了覆盖所有方面而设计的。在混合环境中，通常会出现三个差距：

• 本地部署（on-premises）与非 Microsoft 系统： Entra ID 对诸如 DCSync、Golden Ticket 或 Kerberos 滥用之类的本地部署 Active Directory 攻击向量没有可视性。域控制器保护、混合同步服务器安全以及本地部署权限提升检测均不在其适用范围之内。
• 数据安全与治理： Entra ID 管理身份与访问。它不会对敏感数据进行分类，也不会监控文件级访问模式，或强制执行数据丢失防护（DLP）策略，尤其是在本地部署文件服务器和非 Microsoft 存储库之间。若您的合规要求包含了解敏感数据存放位置以及谁在访问它，则需要具备单独的能力。
• 跨平台 ITDR： Entra ID 的 Identity Protection 覆盖 Microsoft 生态系统内的认证阶段风险信号。认证后的横向移动、本地部署 AD 的攻击链，以及跨非 Microsoft 身份源的关联分析，都需要专门的 ITDR 工具。

对于受监管且混合的环境，实用的架构是将 Entra ID 作为身份控制平面，并辅以独立工具，以实现可视性、保留（retention）以及跨-Netwrix Strongpoint 它不提供的能力。

Netwrix 如何补充 Microsoft Entra ID

Netwrix 填补了 Entra ID 的原生工具所遗漏的关键空白，尤其是在本地（on-prem）AD 可视性、长期审计留存以及将身份风险与数据暴露关联起来方面。仅通过改进 Entra ID 的配置，这些空白无法得到解决。需要额外的工具：

• 同时具备 Entra ID 与本地（on-prem）AD 的可视性，而不是只看其中一方
• 超过原生日志限制的审计留存
• 将身份暴露与数据暴露关联起来的风险上下文
• 审计人员真正认可的合规证据

这就是 Netwrix 在不增加已超负荷安全团队复杂度的情况下所填补的空白。

Netwrix 1Secure 可在无需部署任何基础架构的情况下，让您获得 Microsoft 365 与混合身份环境的可视性。对于 Entra ID，1Secure 会跟踪登录活动，揭示特权升级，并通过近实时同步监控云端与本地 Active Directory 中的权限变更。

风险评估仪表板会突出显示过多的权限、存在风险的账户配置、仍保留访问权限的长期未使用账户，以及在遭受入侵时会扩大“爆炸半径”的错误配置。基于 AI 的整改建议帮助团队优先处理最需要先修复的问题。

Netwrix Auditor 为受监管行业提供以合规为导向的审计。凭借 30 分钟即可完成部署，并可在数小时内获得报告，Auditor 会覆盖 Entra ID、Active Directory、文件服务器和 Exchange，提供审计追踪。

对审计日志进行交互式搜索，使调查人员能够回答“谁在何时访问了什么”，覆盖整个混合环境；同时提供的长期审计历史记录会远超原生 Entra ID 的日志保留期限。

在您的 Entra ID 和 Microsoft 365 环境中进行特权访问时，Netwrix Privilege Secure 提供按需即时（just-in-time）的账号/权限开通机制，可移除长期存在的管理员权限，并通过会话录制生成审计追踪记录。

预约 Netwrix 演示 了解您可以多快弥补 Entra ID 留下的可视性与治理方面的差距。