通过

条件访问：目标资源

  • 项目

目标资源（以前的云应用、操作和身份验证上下文）是条件访问策略中的关键信号。 管理员可以使用条件访问策略将控制措施分配给特定应用程序、服务、操作或身份验证上下文。

  • 有应用程序或服务列表可供管理员选择，这些应用程序或服务包含内置的 Microsoft 应用程序和任何 Microsoft Entra 集成应用程序（其中包括库、非库和通过应用程序代理发布的应用程序）。
  • 管理员可以选择定义一个并非基于云应用程序，而是基于用户操作（如“注册安全信息”或“注册或加入设备”）的策略，使条件访问能够围绕这些操作强制实施控制。
  • 管理员可以将来自全局安全访问的流量转发配置文件设定为目标，以增强功能。
  • 管理员可以使用身份验证上下文在应用程序中提供额外的安全层。

显示条件访问策略和目标资源面板的屏幕截图。

Microsoft 云应用程序

许多现有 Microsoft 云应用程序都包含在可供选择的应用程序的列表中。

管理员可以将这些Microsoft云应用程序分配条件访问策略。 一些应用（例如 Office 365 和 Windows Azure 服务管理 API）包含多个相关的子应用或服务。

重要

可用于条件访问的应用程序将经历载入和验证过程。 这些应用程序不包括所有Microsoft应用。 许多应用程序是后端服务，它们不打算直接应用策略。 如果你正在寻找某个缺少的应用程序，可以联系特定的应用程序团队，或者在 UserVoice 上提出请求。

Office 365

Microsoft 365 提供基于云的高效生产和协作服务，如 Exchange、SharePoint 和 Microsoft Teams。 Microsoft 365 云服务已深度集成，以确保用户拥有顺畅的协作体验。 在创建策略时，这种集成可能会造成混淆，因为某些应用（如 Microsoft Teams）依赖于 SharePoint 或 Exchange 等其他一些应用。

使用 Office 365 套件可以同时将这些服务作为目标。 建议使用新的 Office 365 套件，而不是以单个云应用作为目标，以避免服务依赖项出现问题。

以此组应用程序作为目标有助于避免因策略和依赖关系不一致而导致的问题。 例如：Exchange Online 应用关联到邮件、日历和联系人信息等传统的 Exchange Online 数据。 相关元数据可以通过不同的资源（例如搜索）来公开。 为了确保所有元数据按预期方式受到保护，管理员应将策略分配到 Office 365 应用。

管理员可以将整个 Office 365 套件或特定 Office 365 云应用从条件访问策略中排除。

可在条件访问 Office 365 应用套件中包含的应用一文中找到包含的所有服务的完整列表。

Windows Azure 服务管理 API

在针对 Windows Azure 服务管理 API 应用程序时，策略会强制执行对于发放给与门户紧密绑定的一组服务的令牌。 此组包括以下项的应用程序 ID：

  • Azure 资源管理器
  • Azure 门户，其中还涵盖 Microsoft Entra 管理中心
  • Azure 数据湖
  • Application Insights API
  • Log Analytics API

由于该策略应用于 Azure 管理门户和 API、服务或具有 Azure API 服务依赖项的客户端，因此可能会受到间接影响。 例如：

  • Azure CLI
  • Azure 数据工厂门户
  • Azure DevOps
  • Azure 事件中心
  • Azure PowerShell
  • Azure 服务总线
  • Azure SQL 数据库
  • Azure Synapse
  • 经典部署模型 API
  • Microsoft 365 管理中心
  • Microsoft IoT Central
  • SQL 托管实例
  • Visual Studio 订阅管理员门户

注意

Windows Azure 服务管理 API 应用程序适用于调用 Azure 资源管理器 API 的 Azure PowerShell。 它不适用于 Microsoft Graph PowerShell，后者调用 Microsoft Graph API。

有关如何为 Windows Azure 服务管理 API 设置示例策略的更多信息，请参阅条件访问：要求将 MFA 用于 Azure 管理。

提示

对于 Azure 政府，你应该以 Azure 政府云管理 API 应用程序为目标。

Microsoft 管理门户

对 Microsoft 管理门户云应用使用条件访问策略时，将对颁发给以下 Microsoft 管理门户的应用程序 ID 的令牌强制实施该策略：

  • Azure 门户
  • Exchange 管理中心
  • Microsoft 365 管理中心
  • Microsoft 365 Defender 门户
  • Microsoft Entra 管理中心
  • Microsoft Intune 管理中心
  • Microsoft Purview 合规性门户
  • Microsoft Teams 管理中心

我们会不断向列表添加更多管理门户。

注意

Microsoft 管理门户应用仅适用于列出的管理门户的交互式登录。 此应用程序未涵盖对基础资源或服务（如 Microsoft Graph 或 Azure 资源管理器 API）的登录。 这些资源受 Windows Azure 服务管理 API 应用的保护。 通过此分组，客户无需影响依赖于 API 和 PowerShell 的自动化，即可完成管理员的 MFA 采用过程。 准备就绪后，Microsoft 建议使用 策略，要求管理员始终执行多重身份验证 (MFA) 以实现全面保护。

其他应用程序

管理员可以将任何已在 Microsoft Entra 中注册的应用程序添加到条件访问策略。 这些应用程序可能包括：

注意

由于条件访问策略设置访问服务的要求，因此无法将其应用到客户端（公共/本机）应用程序。 换句话说，策略不会直接在客户端（公共/本机）应用程序上设置，而是在客户端调用服务时应用。 例如，在 SharePoint 服务上设置的策略将应用于所有调用 SharePoint 的客户端。 在 Exchange 上设置的策略将应用于使用 Outlook 客户端访问电子邮件的尝试。 这就是为什么在应用选取器中，客户端（公共/本机）应用程序不可用，以及在租户中注册的客户端（公共/本机）应用程序的应用程序设置中，条件访问选项不可用。

有些应用程序根本不会出现在选取器中。 将这些应用程序包含在条件访问策略中的唯一方法是包括“所有资源(以前为‘所有云应用’)”。

了解不同客户端类型的条件访问

条件访问适用于非客户端的资源，除非客户端是请求 ID 令牌的机密客户端。

  • 公共客户端
    • 公共客户端是在桌面版Microsoft Outlook 等设备上本地运行的客户端，或者Microsoft Teams 等移动应用。
    • 条件访问策略不适用于公共客户端本身，但根据公共客户端请求的资源应用。
  • 机密客户端
    • 条件访问适用于客户端请求的资源，如果机密客户端请求 ID 令牌，也适用于机密客户端本身。
    • 例如：如果 Outlook 网页版请求 Mail.Read 和 Files.Read 范围的令牌，条件访问将适用于 Exchange 和 SharePoint 的策略。 此外，如果 Outlook Web 请求 ID 令牌，条件访问也会应用 Outlook Web 的策略。

若要从 Microsoft Entra 管理中心查看这些客户端类型的登录日志，请执行以下操作：

  1. 至少以报告读取者身份登录到 Microsoft Entra 管理中心。
  2. 浏览到“标识”>“监视和运行状况”>“登录日志”。
  3. 为“客户端凭据类型”添加筛选器。
  4. 调整筛选器，根据登录中使用的客户端凭据查看特定日志集。

有关详细信息，请参阅 公共客户端和机密客户端应用程序的文章。

所有资源

将条件访问策略应用于 所有资源（以前为“所有云应用”），而不排除任何应用程序，会导致对网站和服务（包括 全局安全访问流量转发配置文件）的所有令牌请求强制执行策略。 此选项包括条件访问策略中不能单独定位的应用程序，例如 Windows Azure Active Directory （000000002-0000-0000-c0000-000000000000000）。

重要

Microsoft建议创建面向所有用户和所有资源（没有任何应用排除项）的基线多重身份验证策略，如 要求所有用户多重身份验证中所述。

当所有资源策略具有应用排除时的条件访问行为

如果策略中排除了任何应用，为了不无意阻止用户访问，则会从策略强制实施中排除某些低特权范围。 这些范围允许调用基础图形 API，例如 Windows Azure Active Directory（000000002-0000-0000-c000-0000000000000）和 Microsoft Graph （000000003-00000-0000-00000000000000），以访问应用程序常用的用户配置文件和组成员身份信息作为身份验证的一部分。 例如：当 Outlook 请求 Exchange 令牌时，它还要求 User.Read 范围能够显示当前用户的基本帐户信息。

大多数应用具有类似的依赖项，这就是为什么每当 所有资源 策略中存在应用排除时，这些低特权范围都会自动排除。 这些低特权范围排除不允许数据访问超出基本用户配置文件和组信息。 排除的范围如下列出，应用仍需同意才能使用这些权限。

  • 本机客户端和单页应用程序（SPA）有权访问以下低特权范围：
    • Azure AD Graph：email、offline_access、openid、profile、User.Read
    • Microsoft Graph: email、offline_access、openid、profile、User.Read、People.Read
  • 机密客户端可以访问以下低特权范围（如果它们被排除在“所有资源”策略之外）：
    • Azure AD Graph：email、offline_access、openid、profile、User.Read、User.Read.All、User.ReadBasic.All
    • Microsoft Graph：email、offline_access、openid、profile、User.Read、User.Read.All、User.ReadBasic.All、People.Read、People.Read.All、GroupMember.Read.All、Member.Read.Hidden

有关提到的范围的详细信息，请参阅 Microsoft Graph 权限参考 和 Microsoft 身份平台中的范围和权限。

保护目录信息

如果由于业务原因而无法配置无应用排除项的建议基线 MFA 策略，并且组织的安全策略必须包含与目录相关的低特权范围（User.Read、User.Read.All、User.ReadBasic.All、People.Read、People.Read.All、GroupMember.Read.All、Member.Read.Hidden），则替代方案是针对 Windows Azure Active Directory 创建单独的条件访问策略 (00000002-0000-0000-c000-000000000000)。 Windows Azure Active Directory（也称为 Azure AD Graph）是一种资源，表示存储在目录中的数据，例如用户、组和应用程序。 Microsoft Azure Active Directory 资源包含在 所有资源 中，但可以按照以下步骤在条件访问策略中单独进行定位：

  1. 以属性定义管理员和属性分配管理员身份登录到 Microsoft Entra 管理中心。
  2. 浏览到“保护”>“自定义安全属性”。
  3. 创建新的属性集和属性定义。 有关详细信息，请参阅在 Microsoft Entra ID 中添加或停用自定义安全属性定义。
  4. 浏览到“标识”>“应用程序”>“企业应用程序”。
  5. 删除 应用程序类型 筛选器，并搜索以 000000002-00000-0000-0000-000000000000 开头的 应用程序 ID。
  6. 选择 Windows Azure Active Directory>自定义安全属性>添加分配。
  7. 选择要在策略中使用的属性集和属性值。
  8. 浏览到“保护”>“条件访问”>“策略”。
  9. 创建或修改现有策略。
  10. 在“目标资源”>“资源”（以前称为云应用）>“包含”下，选择“选择资源”>“编辑筛选器”。>
  11. 调整筛选器，以包含之前的属性集和定义。
  12. 保存策略

使用全球安全访问的所有 Internet 资源

“使用全球安全访问的所有 Internet 资源”选项允许管理员从 Microsoft Entra Internet Access 定位 Internet 访问流量转发配置文件。

这些全球安全访问中的配置文件使管理员能够定义和控制通过 Microsoft Entra Internet 访问和 Microsoft Entra 专用访问路由流量的方式。 可将流量转发配置文件分配给设备和远程网络。 请参阅如何将条件访问策略应用于 Microsoft 365 流量配置文件一文，查看有关如何将条件访问策略应用于这些流量配置文件的示例。

有关这些配置文件的详细信息，请参阅全局安全访问流量转发配置文件一文。

用户操作

用户操作是用户执行的任务。 目前，条件访问支持两种用户操作：

  • 注册安全信息：使用此用户操作，可以在启用了组合注册的用户尝试注册其安全信息时强制实施条件访问策略。 在组合安全信息注册一文中可以找到详细信息。

注意

当管理员应用一项以用户行为为目标的策略以注册安全信息时，如果用户帐户是来自Microsoft个人帐户（MSA）的来宾，使用“需要多因素身份验证”控制时，将要求 MSA 用户向组织注册安全信息。 如果来宾用户来自其他提供商（如 Google），则访问将被阻止。

  • 注册或加入设备：使用此用户操作，管理员可以在用户向 Microsoft Entra ID 注册或加入设备时强制实施条件访问策略。 使用此操作可以针对注册或加入设备的操作精细配置多重身份验证，而无需配置当前存在的租户范围的策略。 对于此用户操作，需要注意三个重要事项：
    • Require multifactor authentication 是此用户操作唯一可用的访问控制，所有其他访问控制均处于禁用状态。 此限制可防止与依赖于 Microsoft Entra 设备注册或不适用于 Microsoft Entra 设备注册的访问控制发生冲突。
    • Client apps、Filters for devices 和 Device state 条件在此用户操作中不可用，因为它们依赖于使用 Microsoft Entra 设备注册来强制实施条件访问策略。

警告

为条件访问策略配置了“注册或加入设备”用户操作时，必须将“标识”“设备”“概述”>“设备设置”> 设置为“否”。> - Require Multifactor Authentication to register or join devices with Microsoft Entra 否则，将无法正确实施包含此用户操作的条件访问策略。 在配置设备设置中可以找到有关此设备设置的详细信息。

认证上下文

身份验证上下文可用于进一步保护应用程序中的数据和操作。 这些应用程序可以是你自己的自定义应用程序、自定义业务线 (LOB) 应用程序、SharePoint 等应用程序或受 Microsoft Defender for Cloud Apps 保护的应用程序。

例如，组织可能会保留 SharePoint 站点中的文件，如午餐菜单或其机密 BBQ 酱料食谱。 所有人都可以访问午餐菜单站点，但是有权访问机密 BBQ 酱料食谱站点的用户可能需要从托管设备访问并同意特定使用条款。

身份验证上下文适用于用户或工作负载标识，但不在同一条件访问策略中。

配置身份验证上下文

身份验证上下文在“保护”“条件访问”>“身份验证上下文”下进行管理。

显示身份验证上下文管理的屏幕截图。

通过选择“新建身份验证上下文”来创建新的身份验证上下文定义。 组织只能总共创建 99 个身份验证上下文定义 c1-c99。 配置以下特性：

  • “显示名称”是用于标识 Microsoft Entra ID 以及使用身份验证上下文的应用程序中的身份验证上下文的名称。 建议使用可在不同资源（例如“受信任的设备”）中使用的名称，以减少所需的身份验证上下文数量。 使用更少的一组名称可以限制重定向次数，并提供更好的端到端用户体验。
  • “说明”提供有关策略的详细信息，这些信息由管理员以及向资源应用身份验证上下文的管理员使用。
  • 选中“发布到应用”复选框会将身份验证上下文播发到应用，使这些应用可供分配。 如果未选中，身份验证上下文将不可用于下游资源。
  • “ID”是只读的，在令牌和应用中用于创建特定于请求的身份验证上下文定义。 此处列出了故障排除和开发用例。

添加到条件访问策略

管理员可以选择其条件访问策略中已发布的身份验证上下文，方法是转到“分配”“云应用或操作”，然后从“选择此策略的适用对象”菜单中选择“身份验证上下文” 。

显示将条件访问身份验证上下文添加到策略的屏幕截图

删除身份验证上下文

删除某个身份验证上下文时，请确保没有任何应用程序仍在使用它。 否则，不再保护对应用数据的访问。 如果正在应用身份验证上下文条件访问策略，可以通过检查登录日志来确认此先决条件。

若要删除某个身份验证上下文，必须确保没有为它分配条件访问策略，且它未发布到应用。 此项要求有助于防止意外删除仍在使用中的身份验证上下文。

使用身份验证上下文标记资源

有关在应用程序中使用身份验证上下文的详细信息，请参阅以下文章。

后续步骤