通过

条件访问：目标资源

  • 项目

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

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

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

Azure 云应用程序

许多现有的 Azure 云应用程序都包含在你可以从中进行选择的应用程序列表中。

管理员可以向 Microsoft 提供的以下云应用分配条件访问策略。 一些应用（例如 Office 365 和 Azure 服务管理 API）包含多个相关的子应用或服务。 我们会不断地添加更多应用，因此以下列表并不完整，并且可能会发生更改。

  • Office 365
  • Azure Analysis Services
  • Azure DevOps
  • Azure 数据资源管理器
  • Azure 事件中心
  • Azure 服务总线
  • Azure SQL 数据库和 Azure Synapse Analytics
  • Common Data Service
  • Microsoft Application Insights Analytics
  • Azure 信息保护
  • Azure 服务管理 API
  • Microsoft Defender for Cloud Apps
  • Microsoft Commerce Tools 访问控制门户
  • Microsoft Commerce Tools 身份验证服务
  • Microsoft Forms
  • Microsoft Intune
  • Microsoft Intune 注册
  • Microsoft Planner
  • Microsoft Power Apps
  • Microsoft Power Automate
  • Microsoft 必应搜索
  • Microsoft StaffHub
  • Microsoft Stream
  • Microsoft Teams
  • Exchange Online
  • SharePoint
  • Yammer
  • Office Delve
  • Office Sway
  • Outlook Groups
  • Power BI 服务
  • Project Online
  • Skype for Business Online
  • 虚拟专用网络 (VPN)
  • Windows Defender ATP

重要

适用于条件访问的应用程序已完成加入和验证过程。 此列表并不包括所有 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 应用套件中包含的应用一文中找到包含的所有服务的完整列表。

Azure 服务管理 API

在将 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 订阅管理员门户

注意

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

要详细了解如何为 Azure 服务管理 API 设置示例策略，请参阅条件访问：需要 MFA 以进行 Azure 管理。

Microsoft 管理门户

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

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

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

注意

Microsoft 管理门户应用仅适用于列出的管理门户的交互式登录。 此应用程序未涵盖对基础资源或服务（如 Microsoft Graph 或 Azure 资源管理器 API）的登录。 这些资源受 Azure 服务管理 API 应用保护。 这样，客户便能够在管理员的 MFA 采用过程中移动，而不会影响依赖于 API 和 PowerShell 的自动化。 准备就绪后，Microsoft 建议使用要求管理员始终执行 MFA 的策略进行全面保护。

注意

由于条件访问策略设置了服务访问方面的要求，因此你无法将其应用于客户端（公共/本机）应用程序。 换句话说，该策略不是直接在客户端（公共/本机）应用程序上设置的，而是在客户端调用服务时应用的。 例如，在 SharePoint 服务上设置的策略将应用于所有调用 SharePoint 的客户端。 在 Exchange 上设置的策略将应用于使用 Outlook 客户端访问电子邮件的尝试。 正因如此，云应用选取器没有客户端（公共/本机）应用程序可供选择，并且在租户中注册的客户端（公共/本机）应用程序的应用程序设置中未提供条件访问选项。

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

所有资源

如果将条件访问策略应用于“所有资源(以前为‘所有云应用’)”，则将导致针对颁发给网站和服务的所有令牌强制实施该策略。 此选项包括不能在条件访问策略中单独定位的应用程序，例如 Microsoft Entra ID。

在某些情况下，“所有资源(以前为‘所有云应用’)”策略可能会无意中阻止用户访问。 以下案例被排除在策略强制执行范围之外，包括：

  • 实现所需安全状态所需的服务。 例如，设备注册调用被排除在面向“所有资源”的合规设备策略之外。

  • 调用 Azure AD Graph 和 Microsoft Graph，以访问从策略中排除的应用程序通常使用的用户配置文件、组成员身份和关系信息。 下面列出了排除的范围。 应用仍需征得同意才能使用这些权限。

    • 对于本机客户端：
      • Azure AD Graph：电子邮件、offline_access、openid、配置文件、User.Read
      • Microsoft Graph：email、offline_access、openid、profile、User.Read、People.Read
    • 对于机密/经过身份验证的客户端：
      • Azure AD Graph：电子邮件、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 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”是只读的，在令牌和应用中用于创建特定于请求的身份验证上下文定义。 此处列出了故障排除和开发用例。

添加到条件访问策略

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

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

删除身份验证上下文

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

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

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

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

后续步骤