条件访问：目标资源

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

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

只要服务主体出现在其租户中（Microsoft Graph 除外），管理员可以从Microsoft向云应用分配条件访问策略。 Microsoft Graph 作为一个综合性资源。 使用受众报告查看基础服务，并在您的策略中针对这些服务。 某些应用（如 Office 365 和 Azure 服务管理 API ）包括多个相关的子应用或服务。 创建新的 Azure 云应用程序时，一旦在租户中创建服务主体，它们就会显示在应用选取器列表中。

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 应用程序作为目标时，将对发放给与门户紧密绑定的一组服务的令牌强制执行策略。 此组包括以下项的应用程序 ID：

• Azure Resource Manager
• Azure 门户，其中还涵盖 Microsoft Entra 管理中心
• Azure Data Lake
• Application Insights API
• 日志分析 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 设置示例策略，请参阅条件访问：需要 MFA 以进行 Azure 管理。

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

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

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

有些应用程序根本不会出现在选取器中。 在条件访问策略中包括这些应用程序的唯一方法是包括 所有资源（以前为“所有云应用”）， 或使用 New-MgServicePrincipal PowerShell cmdlet 或使用 Microsoft Graph API 添加缺少的服务主体。

条件访问适用于非客户端的资源，除非客户端是请求 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. 调整筛选器，根据登录中使用的客户端凭据查看特定日志集。

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

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

如果策略中排除了任何应用，为了不无意阻止用户访问，则会从策略强制实施中排除某些低特权范围。 这些范围允许调用基础图形 API，例如 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），则替代方案是针对 Azure Active Directory 创建单独的条件访问策略 (00000002-0000-0000-c000-000000000000)。 Azure Active Directory（也称为 Azure AD Graph）是一种资源，表示存储在目录中的数据，例如用户、组和应用程序。 Azure Active Directory 资源包含在 “所有资源 ”中，但可以使用以下步骤在条件访问策略中单独定位：

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

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

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

• 注册或加入设备：使用此用户操作，管理员可以在用户向 Microsoft Entra ID 注册或加入设备时强制实施条件访问策略。 使用此操作可以针对注册或加入设备的操作精细配置多重身份验证，而无需配置当前存在的租户范围的策略。 对于此用户操作，需要注意三个重要事项：

  • Require multifactor authentication 是此用户操作唯一可用的访问控制，所有其他访问控制均处于禁用状态。 此限制可防止与依赖于 Microsoft Entra 设备注册或不适用于 Microsoft Entra 设备注册的访问控制发生冲突。
  • Client apps、Filters for devices 和 Device state 条件在此用户操作中不可用，因为它们依赖于使用 Microsoft Entra 设备注册来强制实施条件访问策略。

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

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

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

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

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

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

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

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

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

• 使用敏感度标签保护 Microsoft Teams、Microsoft 365 组和 SharePoint 网站中的内容
• Microsoft Defender for Cloud Apps
• 自定义应用程序

• 条件访问：条件
• 条件访问常见策略
• 客户端应用程序依赖关系