Microsoft Entra 身份验证管理操作参考指南

Microsoft Entra 操作参考指南的这一部分介绍了在保护和管理凭据、定义身份验证 (AuthN) 体验、委派分配、衡量使用量，以及基于企业安全状况定义访问策略时应该采取的检查和操作。

注意

这些建议截至发布之日为最新，但可能会随着时间而改变。 组织应持续评估其标识实践，因为 Microsoft 产品和服务会不断发展。

关键操作过程

将所有者分配到关键任务

管理 Microsoft Entra ID 需要持续执行关键操作任务和过程，这可能并不属于一个推出项目。 设置这些任务对于优化环境仍非常重要。 关键任务及其建议所有者包括：

任务	所有者
管理 Microsoft Entra ID 中的单一登录 (SSO) 配置的生命周期	标识和访问管理 (IAM) 运营团队
为 Microsoft Entra 应用程序设计条件访问策略	InfoSec 体系结构团队
在安全信息和事件管理 (SIEM) 系统中存档登录活动	InfoSec 运营团队
存档 SIEM 系统中的风险事件	InfoSec 运营团队
会审和调查安全报告	InfoSec 运营团队
会审和调查风险事件	InfoSec 运营团队
会审和调查标记为有风险的用户和漏洞报告（由 Microsoft Entra ID 保护提供）	InfoSec 运营团队

注意

Microsoft Entra ID 保护需要 Microsoft Entra ID P2 许可证。 要根据需要查找合适的许可证，请参阅比较 Microsoft Entra ID 免费版和 Microsoft Entra ID P1 或 P2 版本的正式发布功能。

查看列表时，你可能会发现你需要为缺少所有者的任务分配所有者，或调整其所有者与上述建议不符的任务的所有权。

所有者方面的推荐读物

• 在 Microsoft Entra ID 中分配管理员角色

凭据管理

密码策略

安全地管理密码是标识和访问管理的最关键部分之一，并且通常是首当其冲的攻击目标。 Microsoft Entra ID 支持多种功能，这些功能可帮助防止攻击得逞。

使用下表查找用于缓解需要解决的问题的建议解决方案：

问题	建议
不存在防范弱密码的机制	启用 Microsoft Entra ID 自助服务密码重置 (SSPR) 和密码保护
不存在用于检测泄漏密码的机制	启用密码哈希同步 (PHS) 以深刻了解
使用 AD FS，并且无法迁移到托管身份验证	启用 AD FS Extranet 智能锁定和/或 Microsoft Entra 智能锁定
密码策略使用基于复杂性的规则，例如长度、多个字符集或过期时间	重新考虑采用 Microsoft 推荐做法，将你的方法切换为密码管理并部署 Microsoft Entra 密码保护。
用户未注册，无法使用多重身份验证	注册所有用户的安全信息，以便将其用作验证用户标识及其密码的机制
不存在根据用户风险吊销密码的措施	部署 Microsoft Entra 标识保护用户风险策略，以使用 SSPR 强制对泄露的凭据进行密码更改
没有智能锁定机制，无法防止来自已识别身份 IP 地址的不良参与者进行恶意身份验证	使用密码哈希同步或直通身份验证 (PTA) 部署云托管的身份验证

密码策略方面的推荐读物

• Microsoft Entra ID 和 AD FS 最佳做法：防御密码喷雾攻击 - 企业移动性和安全性

启用自助服务密码重置和密码保护

支持人员接到的支持电话中，绝大部分是来自需要更改或重置密码的用户，这也是最主要的成本。 除了成本之外，将密码更改作为一种缓解用户风险的工具也是提高组织安全状况的基本步骤。

在完成前，建议至少部署 Microsoft Entra ID 自助服务密码重置 (SSPR) 和本地密码保护：

• 转移对支持人员的呼叫次数。
• 替换临时密码的使用。
• 取代依赖于本地解决方案的任何现有自助服务密码管理解决方案。
• 消除你的组织中的弱密码。

注意

对于具有 Microsoft Entra ID P2 订阅的组织，建议部署 SSPR，并将其用作标识保护用户风险策略的一部分。

强大的凭据管理措施

密码本身的安全性无法防止恶意参与者获取对你的环境的访问权限。 至少，任何具有特权帐户的用户都必须启用多重身份验证。 理想情况下，应该启用组合式注册，并要求所有用户使用组合式注册体验来注册多重身份验证和 SSPR。 最终，我们建议采用一种策略来提供复原能力，以降低由于不可预见的情况而导致锁定的风险。

本地中断身份验证复原能力

除了简单和能够检测凭据泄漏的优势之外，Microsoft Entra 密码哈希同步 (PHS) 和 Microsoft Entra 多重身份验证还允许用户访问服务型软件 (SaaS) 应用程序和 Microsoft 365，即时是由于网络攻击（如 NotPetya）导致本地中断。 与联合身份验证一起使用时，也可以启用 PHS。 启用 PHS 允许在联合身份验证服务不可用时回退身份验证。

如果本地组织缺乏中断复原策略，或者有一个策略，但未与 Microsoft Entra ID 集成，则应该部署 Microsoft Entra PHS 并定义包含 PHS 的灾难恢复计划。 启用 Microsoft Entra PHS 后，假如本地 Active Directory 不可用，用户可以向 Microsoft Entra ID 进行身份验证。

要更好地理解你的身份验证选项，请参阅选择 Microsoft Entra 混合标识解决方案的正确身份验证方法。

以编程方式使用凭据

使用 PowerShell 的 Microsoft Entra ID 脚本或使用 Microsoft Graph API 的应用程序都需要安全身份验证。 如果执行这些脚本和工具时凭据管理不当，则会增加凭据被盗的风险。 如果你使用的脚本或应用程序依赖于硬编码的密码或密码提示，你应该首先查看配置文件或源代码中的密码，然后替换这些依赖项并尽量使用 Azure 托管标识、集成的 Windows 身份验证或证书。 对于之前解决方案无法解决问题的应用程序，请考虑使用 Azure Key Vault。

如果确定某些服务主体具有密码凭据，并且不确定这些密码凭据如何由脚本或应用程序保护，请与应用程序所有者联系，以便更好地了解使用模式。

Microsoft 还建议你联系应用程序所有者，以了解使用模式（如果某些服务主体带有密码凭据）。

身份验证体验

本地身份验证

如果在公司网络内部，并以本地域控制器为目标，则采用集成 Windows 身份验证的联合身份验证 (IWA)、采用密码哈希同步的无缝单一登录 (SSO) 托管身份验证或者直通身份验证，用户体验最佳。 它最大程度地减少了凭据提示造成的疲劳，并降低了用户遭受网络钓鱼攻击的威胁。 如果已在 PHS 或 PTA 中使用云托管的身份验证，但用户在本地进行身份验证时仍需要键入密码，则应立即部署无缝 SSO。 另一方面，如果你目前采用联合身份验证并且计划最终迁移到云托管的身份验证，则应将无缝 SSO 作为迁移项目的一部分实现。

设备信任访问策略

与组织中的用户一样，设备也是要保护的核心标识。 可以使用设备标识随时随地保护你的资源。 对设备进行身份验证并考虑其信任类型可通过以下几个方面改善你的安全状况和易用性：

• 在设备受信任的情况下，避免摩擦（例如，通过多重身份验证）
• 阻止来自不受信任设备的访问
• 对于 Windows 10 设备，提供无缝单一登录本地资源的功能。

要实现此目标，可以使用下述某种方法将设备标识引入 Microsoft Entra ID 并对其进行管理：

• 组织可以使用 Microsoft Intune 来管理设备并强制实施符合性策略、证明设备运行状况，并根据设备是否合规来设置条件访问策略。 Microsoft Intune 可以管理 iOS 设备、Mac 桌面（通过 JAMF 集成）、Windows 桌面（最初使用适用于 Windows 10 的移动设备管理，以及通过 Microsoft Configuration Manager 进行共同管理）和 Android 移动设备。
• 在具有 Active Directory 加入域的计算机设备的环境中，Microsoft Entra 混合联接通过组策略或 Microsoft Configuration Manager 提供管理功能。 组织可以通过 PHS 或通过采用无缝 SSO 的 PTA 来部署托管环境。 在 Microsoft Entra ID 中使用自带设备时，可通过跨云和本地资源的 SSO 最大限度提高用户生产力，同时使你能够通过条件访问来确保对云和本地资源的访问安全。

如果你的 Windows 设备已加入域，但未在云中注册，或已在云中注册但没有条件访问策略，则你应注册未注册的设备，而且在上述两种情况下，均应在条件访问策略中使用Microsoft Entra 混合联接作为控件。

如果要使用 MDM 或 Microsoft Intune 管理设备，但未在条件访问策略中使用设备控件，则建议在这些策略中使用要求将设备标记为合规作为控件。

设备信任访问策略方面的推荐读物

• 如何：规划 Microsoft Entra 混合联接实现
• 标识和设备访问权限配置

Windows Hello 企业版

在 Windows 10 中，Windows Hello 企业版将电脑上的密码替换成了强双重身份验证。 Windows Hello 企业版可为用户提供更简单的多重身份验证体验，并减少对密码的依赖。 如果尚未开始推广 Windows 10 设备，或仅部分部署了 Windows 10 设备，则建议升级到 Windows 10，并在所有设备上启用 Windows Hello 企业版。

如果想了解有关无密码身份验证的更多信息，请参见利用 Microsoft Entra ID 实现无密码世界。

应用程序身份验证和分配

应用的单一登录

要让用户获得最佳体验，降低风险，获得报告能力和治理能力，为整个企业提供标准化的单一登录机制至关重要。 如果使用的应用程序支持通过 Microsoft Entra ID 实现 SSO，但目前已配置为使用本地帐户，则应重新配置这些应用程序以将 SSO 与 Microsoft Entra ID 一起使用。 同样，如果正在使用的应用程序支持通过 Microsoft Entra ID 实现 SSO，但目前使用另一个标识提供者，则应将这些应用程序重新配置为也将 SSO与 Microsoft Entra ID 一起使用。 如果应用程序不支持联合身份验证协议，但支持基于表单的身份验证，我们建议你将应用程序配置为使用密码保管与 Microsoft Entra 应用程序代理。

注意

如果你没有一种机制来发现组织中非托管应用程序，我们建议使用诸如 Microsoft Defender for Cloud Apps 之类的云应用程序安全代理 (CASB) 来实施发现过程。

最后，如果你有一个 Microsoft Entra 应用库，并将支持 SSO 的应用程序与 Microsoft Entra ID 结合使用，我们建议将该应用程序列在应用库中。

单一登录方面的推荐读物

• 什么是使用 Microsoft Entra ID 进行应用程序访问和单一登录

将 AD FS 应用程序迁移到 Microsoft Entra ID

将应用从 AD FS 迁移到 Microsoft Entra ID 可实现更高的安全性、更一致的可管理性和更好的协作体验。 如果之前在 AD FS 中配置的某些应用程序支持通过 Microsoft Entra ID 来实现 SSO，则应重新配置应用程序以将 SSO 与 Microsoft Entra ID 一起使用。 如果之前在 AD FS 中配置的应用程序具有不太常见的配置，而 Microsoft Entra ID 不支持这些配置，则应联系应用的所有者以了解特殊配置是否是应用程序的绝对要求。 如果不是绝对需要，则应重新配置应用程序以将 SSO 与 Microsoft Entra ID 一起使用。

注意

可以使用 Microsoft Entra Connect Health for AD FS 来收集有关或许能够迁移到 Microsoft Entra 的每个应用程序的配置详细信息。

将用户分配给应用程序

最好是使用组将用户分配到应用程序，因为组具有更大的灵活性和大规模管理能力。 使用组的优点包括基于属性的动态组成员身份和应用所有者的委派。 因此，如果你已在使用和管理组，建议你采取以下操作来改进大规模管理：

• 向应用程序所有者委派组管理和治理任务。
• 允许对应用程序进行自助访问。
• 如果用户属性可以一致地确定对应用程序的访问权限，则定义动态组。
• 使用 Microsoft Entra 访问评审将证明实施到用于应用程序访问的组。

另一方面，如果找到已分配给单个用户的应用程序，请务必围绕这些应用程序实施治理措施。

为应用程序分配用户方面的推荐读物

• 将用户和组分配到 Microsoft Entra ID 的应用程序中
• 在 Microsoft Entra ID 中委托应用注册权限
• Microsoft Entra ID 中组的动态成员身份规则

访问策略

命名位置

使用 Microsoft Entra ID 中的命名位置，可以在组织中标记受信任的 IP 地址范围。 Microsoft Entra ID 使用命名位置来：

• 预防风险事件中的误报。 从受信任的网络位置登录可降低用户的登录风险。
• 配置基于位置的条件访问。

根据优先级，使用下表找到最符合组织需求的推荐解决方案：

优先级	方案	建议
1	如果您使用 PHS 或 PTA，但尚未定义命名位置	定义命名位置以提高风险事件的检测
2	如果你采用联合身份验证并且未使用“insideCorporateNetwork”声明，而且尚未定义命名位置	定义命名位置以提高风险事件的检测
3	如果没有在条件访问策略中使用命名位置，并且条件访问策略中没有风险或设备控件	配置条件访问策略以包含命名位置
4	如果你采用联合身份验证并且使用“insideCorporateNetwork”声明，而且尚未定义命名位置	定义命名位置以提高风险事件的检测
5	如果你将受信任 IP 地址与多重身份验证（而不是命名位置）结合使用，并且将这些 IP 地址标记为受信任	定义命名位置，并将其标记为受信任，以改善风险事件的检测

基于风险的访问策略

Microsoft Entra ID 可以计算每次登录和每个用户的风险。 使用风险作为访问策略中的条件可以提供更好的用户体验（例如，减少身份验证提示）和更好的安全性（例如，仅在需要时提示用户），并且可以自动完成响应和修正。

如果你已拥有的 Microsoft Entra ID P2 许可证支持在访问策略中使用风险，但未使用风险条件，我们强烈建议将风险添加到安全状况。

基于风险的访问策略方面的推荐读物

• 如何：配置登录风险策略
• 如何：配置用户风险策略

客户端应用程序访问策略

Microsoft Intune 应用管理 (MAM) 能够将数据保护控件（如存储加密、PIN、远程存储清理等）推送到兼容的客户端移动应用程序（例如 Outlook Mobile）。 此外，还可以创建条件访问策略，以限制访问，即只能从经过批准或兼容的应用访问云服务（如 Exchange Online）。

如果你的员工安装支持 MAM 的应用程序（如 Office 移动应用）来访问公司资源（如 Exchange Online 或 Microsoft 365 中的 SharePoint），并且你还支持 BYOD（自带设备），我们建议你部署应用程序 MAM 策略，以在不注册 MDM 的情况下管理个人拥有的设备中的应用程序配置，然后更新你的条件访问策略，以仅允许从具有 MAM 功能的客户端进行访问。

如果员工为了访问公司资源而安装了具备 MAM 功能的应用程序，但访问权限在 Intune 托管设备中受到限制，那么您应该考虑部署应用程序 MAM 策略以管理个人设备的应用程序配置，并更新条件访问策略以仅允许具有 MAM 功能的客户端进行访问。

条件访问实现

条件访问是改善组织的安全状况的重要工具。 因此，请务必遵循以下最佳做法：

• 确保所有 SaaS 应用程序都至少应用了一种策略
• 避免将“所有应用”过滤器与“阻止”控件结合使用，以避免发生锁定风险
• 避免将“所有用户”用作筛选器，避免无意中添加“来宾”
• 将所有“旧版”策略迁移到 Azure 门户
• 捕获用户、设备和应用程序的所有条件
• 使用条件访问策略来实现多重身份验证，而不是使用基于用户的 MFA
• 指定一小部分可应用于多个应用程序的核心策略
• 定义空的异常组，并将它们添加到策略中以获得异常策略
• 在没有多重身份验证控制的情况下，规划不受限帐户
• 通过为 Exchange Online 和 Microsoft 365 中的 SharePoint 等服务实现相同的控件集合， 确保跨 Microsoft 365 客户端应用程序（例如 Teams、OneDrive、Outlook 等）提供一致的体验
• 应通过组（而不是个体）来实现策略的分配
• 定期检查策略中使用的例外组，以限制用户超出安全状态的时间。 如果你有 Microsoft Entra ID P2，则可以使用访问评审来自动执行此过程

条件访问方面的推荐读物

• Microsoft Entra ID 中条件访问的最佳做法
• 标识和设备访问权限配置
• Microsoft Entra 条件访问设置参考
• 常用条件访问策略

访问外围应用

旧式身份验证

强凭据（如多重身份验证）无法使用旧式身份验证协议保护应用，这使其成为恶意参与者首选的攻击途径。 锁定旧身份验证对于改善访问安全状况至关重要。

“旧身份验证”一词是指应用程序使用的身份验证协议，比如：

• 不使用新式身份验证的早期 Office 客户端（例如 Office 2010 客户端）
• 使用邮件协议（例如 Internet 消息访问协议 (IMAP)/简单邮件传输协议 (SMTP)/入网点 (POP)）的客户端

攻击者强烈倾向于使用这些协议，事实上，几乎 100% 的密码喷涂攻击都使用旧的身份验证协议！ 黑客使用旧身份验证协议，因为旧协议不支持交互式登录，而其他安全质询（如多重身份验证和设备身份验证）刚好需要交互式登录。

如果你的环境中广泛使用了旧身份验证，则应计划尽快将旧客户端迁移到支持新式身份验证的客户端。 在同一令牌中，如果某些用户已在使用新式身份验证，但其他用户仍使用旧身份验证，则应执行以下步骤来锁定旧版身份验证客户端：

1. 使用登录活动报告来识别仍在使用旧身份验证的用户并计划进行补救措施：

   1. 针对受影响的用户，升级到持新式身份验证的客户端。

   2. 计划转换时间范围，按以下步骤进行锁定。

   3. 确定哪些旧应用程序强烈依赖旧式身份验证。 请参阅下面的步骤 3。

2. 对于未使用旧身份验证的用户，请在源位置（例如 Exchange 邮箱）禁用旧版协议，以免暴露更多信息。

3. 对于其余帐户（最好是非人工身份，例如服务帐户），请使用条件访问来限制旧协议后身份验证。

旧身份验证方面的推荐读物

• 启用或禁用对 Exchange Server 中的邮箱的 POP3 或 Internet 消息访问协议 v4 (IMAP4) 访问

同意授权

在违法许可授权攻击中，攻击者将创建一个 Microsoft Entra 注册的应用程序，该应用程序请求访问数据（如联系信息、电子邮件或文档）。 当用户登录到恶意网站时，可能会由于网络钓鱼攻击而导致授予对恶意应用程序的同意。

对于 Microsoft Cloud 服务，你可能希望仔细检查下列具有权限的应用：

• 具有应用或委托 *.ReadWrite 权限的应用
• 具有委托权限的应用可以代表用户读取、发送或管理电子邮件
• 被授予了以下权限的应用：

资源	权限
Exchange Online	EAS.AccessAsUser.All
	EWS.AccessAsUser.All
	Mail.Read
Microsoft Graph API	Mail.Read
	Mail.Read.Shared
	Mail.ReadWrite

• 被授予登录用户的完整用户模拟权限的应用。 例如：

资源	权限
Microsoft Graph API	Directory.AccessAsUser.All
Azure REST API	user_impersonation

为避免这种情况，请参阅在 Office 365 中检测和修正违法许可授权，以识别和修复具有非法授权的应用程序或者授权超过了必要限度的应用程序。 接下来，删除自助服务并建立治理过程。 最后，计划好定期审查应用权限，并在不需要时删除权限。

同意授予方面的推荐读物

• Microsoft Graph 权限概述
• Microsoft Graph API 权限

用户和组设置

如果没有明确的业务需求，则可以锁定以下用户和组设置：

用户设置

• 外部用户 - 外部协作可以通过 Teams、Power BI、Microsoft 365 中的 SharePoint 和 Azure 信息保护等服务在企业中有机进行。 如果你有显式约束来控制用户启动的外部协作，则建议你通过使用 Microsoft Entra 权利管理或受控操作（如通过帮助台）来启用外部用户。 如果您不想允许服务进行随机外部协作，则可以全面阻止成员邀请外部用户。 此外，也可以在外部用户邀请中允许或阻止特定域。
• 应用注册 - 启用应用注册后，最终用户可以自行将应用程序加入并向应用程序授予对数据的访问权限。 应用注册的一个典型示例是用户能够让 Outlook 插件或语音助手（如 Alexa 和 Siri）阅读其电子邮件和日历或代表他们发送电子邮件。 如果客户决定关闭应用程序注册，则必须将 InfoSec 和 IAM 团队纳入例外管理（根据业务需求而需要的应用注册），因为这两个团队需要使用管理员帐户注册应用程序，并且大多数情况下，可能需要设计一个流程以使该流程具有可操作性。
• 管理门户 - 组织可以锁定 Azure 门户中的 Microsoft Entra 边栏选项卡，这样，非管理员就无法访问 Azure 门户中的 Microsoft Entra 管理，避免造成困惑。 在 Microsoft Entra 管理门户中转到用户设置以限制访问：

注意

非管理员仍可通过命令行和其他编程接口访问 Microsoft Entra 管理接口。

组设置

自助服务组管理/用户可以创建安全组/Microsoft 365 组。 如果云中当前没有适用于组的自助服务计划，客户可以决定将其关闭，直到组准备好使用此功能。

组方面的推荐读物

• 什么是 Microsoft Entra B2B 协作？
• 将应用程序与 Microsoft Entra ID 集成
• Microsoft Entra ID 中的应用、权限和同意。
• 在 Microsoft Entra ID 中使用组管理对资源的访问权限
• 在 Microsoft Entra ID 中设置自助式应用程序访问管理

来自意外位置的流量

攻击者来自世界各个角落。 使用条件访问策略管理风险，并以位置作为条件。 使用条件访问策略的位置条件，可以阻止没有商业理由登录的位置的访问。

如果可用，请使用安全信息和事件管理 (SIEM) 解决方案来分析和查找跨区域访问的模式。 如果你没有使用 SIEM 产品，或者该产品没有从 Microsoft Entra ID 中提取身份验证信息，我们建议你使用 Azure Monitor 来确定跨区域的访问模式。

访问使用情况

Microsoft Entra 日志存档并与事件响应计划集成

有权访问 Microsoft Entra ID 的登录活动、审核和风险事件对于故障排除、使用情况分析和取证调查至关重要。 Microsoft Entra ID 通过具有有限保留期的 REST API 提供对这些源的访问。 安全信息和事件管理 (SIEM) 系统或等效的存档技术，是长期存储审核和可支持性的关键。 要启用 Microsoft Entra 日志的长期存储，则必须将其添加到现有的 SIEM 解决方案中或使用 Azure Monitor。 存档日志，可作为事件响应计划和调查的一部分使用。

日志方面的推荐读物

• Microsoft Entra 审核 API 参考
• Microsoft Entra 登录活动报告 API 参考
• 使用证书通过 Microsoft Entra 报告 API 获取数据
• 适用于 Microsoft Entra ID 保护的 Microsoft Graph
• Office 365 管理活动 API 参考
• 如何使用 Microsoft Entra ID Power BI 内容包

总结

安全的标识基础结构有 12 个方面。 此列表将帮助你进一步保护和管理凭据、定义身份验证体验、委派分配、衡量使用情况，并根据企业安全状况定义访问策略。

• 将所有者分配到关键任务。
• 实施解决方案来检测薄弱密码或泄漏的密码，提高密码管理和保护，并进一步保护用户对资源的访问。
• 管理设备的标识以随时随地保护你的资源。
• 实施无密码身份验证。
• 在整个组织中提供标准化的单一登录机制。
• 将应用从 AD FS 迁移到 Microsoft Entra ID，以实现更好的安全性和更一致的可管理性。
• 使用组将用户分配到应用程序，以允许更大的灵活性和大规模管理。
• 配置基于风险的访问策略。
• 锁定旧身份验证协议。
• 检测并修正违法许可授予。
• 锁定用户和组设置。
• 支持长期存储 Microsoft Entra 日志，以便进行故障排除、使用情况分析和取证调查。

后续步骤

开始学习标识治理操作检查和操作。