你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn。
条件访问:云应用、操作和身份验证上下文
云应用、操作和身份验证上下文是条件访问策略中的关键信号。 管理员可以使用条件访问策略将控制措施分配给特定应用程序、操作和身份验证上下文。
- 管理员可以从包括内置 Microsoft 应用程序以及任何 Azure AD 集成应用程序(包括库、非库和通过应用程序代理发布的应用程序)的应用程序列表进行选择。
- 管理员可以选择定义一个并非基于云应用程序,而是基于用户操作(如“注册安全信息”或“注册或加入设备”)的策略,使条件访问能够围绕这些操作强制实施控制 。
- 管理员可以使用身份验证上下文在应用程序中提供额外的安全层。
Microsoft 云应用程序
许多现有 Microsoft 云应用程序都包含在可供选择的应用程序的列表中。
管理员可以向 Microsoft 提供的以下云应用分配条件访问策略。 某些应用(例如 Office 365 和 Microsoft Azure 管理)包含多个相关子应用或服务。 我们会不断地添加更多应用,因此以下列表并不完整,并且可能会发生更改。
- Office 365
- Azure Analysis Services
- Azure DevOps
- Azure 数据资源管理器
- Azure 事件中心
- Azure 服务总线
- Azure SQL 数据库和 Azure Synapse Analytics
- Common Data Service
- Microsoft Application Insights Analytics
- Microsoft Azure 信息保护
- Microsoft Azure 管理
- Microsoft Azure 订阅管理
- 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 云应用影响:
- Exchange Online
- Microsoft 365 搜索服务
- Microsoft Forms
- Microsoft Planner (ProjectWorkManagement)
- Microsoft Stream
- Microsoft Teams
- 微软待办
- Microsoft Flow
- Microsoft Office 365 门户
- Microsoft Office 客户端应用程序
- Microsoft To-Do WebApp
- Microsoft Whiteboard Services
- Office Delve
- Office Online
- OneDrive
- Power Apps
- Power Automate
- 安全与合规门户
- SharePoint Online
- Skype for Business Online
- Skype and Teams Tenant Admin API
- Sway
- Yammer
可在条件访问 Office 365 应用套件中包含的应用一文中找到包含的所有服务的完整列表。
Microsoft Azure 管理
当条件访问策略面向 Microsoft Azure 管理应用程序时,在条件访问策略应用选择器中,将针对颁发给与门户紧密绑定的一组服务的应用程序 ID 的令牌强制执行该策略。
- Azure 资源管理器
- Azure 门户,其中还涵盖 Microsoft Entra 管理中心
- Azure 数据湖
- Application Insights API
- Log Analytics API
由于该策略应用于 Azure 管理门户和 API、服务或具有 Azure API 服务依赖项的客户端,因此可能会受到间接影响。 例如:
- 经典部署模型 API
- Azure PowerShell
- Azure CLI
- Azure DevOps
- Azure 数据工厂门户
- Azure 事件中心
- Azure 服务总线
- Azure SQL 数据库
- SQL 托管实例
- Azure Synapse
- Visual Studio 订阅管理员门户
- Microsoft IoT Central
注意
Microsoft Azure 管理应用程序适用于 Azure PowerShell,后者调用 Azure 资源管理器 API。 它不适用于 Azure AD PowerShell,后者调用 Microsoft Graph API。
若要详细了解如何为 Microsoft Azure 管理设置示例策略,请参阅条件访问:要求将 MFA 用于 Azure 管理。
提示
对于 Azure 政府,你应该以 Azure 政府云管理 API 应用程序为目标。
其他应用程序
管理员可以将任何已在 Azure AD 中注册的应用程序添加到条件访问策略。 这些应用程序包括:
- 通过 Azure AD 应用程序代理发布的应用程序
- 从库中添加的应用程序
- 不在库中的自定义应用程序
- 通过应用交付控制器和网络发布的传统应用程序
- 使用基于密码的单一登录的应用程序
注意
由于条件访问策略设置了服务访问方面的要求,因此你无法将其应用于客户端(公共/本机)应用程序。 换句话说,该策略不是直接在客户端(公共/本机)应用程序上设置的,而是在客户端调用服务时应用的。 例如,在 SharePoint 服务上设置的策略将应用于调用 SharePoint 的客户端。 在 Exchange 上设置的策略将应用于使用 Outlook 客户端访问电子邮件的尝试。 正因如此,云应用选取器没有客户端(公共/本机)应用程序可供选择,并且在租户中注册的客户端(公共/本机)应用程序的应用程序设置中未提供条件访问选项。
有些应用程序根本不会出现在选取器中。 将这些应用程序包含在条件访问策略中的唯一方法是包含所有云应用。
所有云应用
如果将条件访问策略应用于所有云应用,将导致针对颁发给网站和服务的所有令牌强制执行该策略。 此选项包括在条件访问策略中不能单独作为目标的应用程序,例如 Azure Active Directory。
在某些情况下,“所有云应用”策略可能会无意中阻止用户访问。 以下案例被排除在策略强制执行范围之外,包括:
实现所需安全状态所需的服务。 例如,设备注册调用被排除在面向所有云应用的合规设备策略之外。
调用 Azure AD Graph 和 MS Graph,以访问从策略中排除的应用程序常用的用户配置文件、组成员身份和关系信息。 下面列出了排除的范围。 应用仍需征得同意才能使用这些权限。
- 对于本机客户端:
- Azure AD Graph:电子邮件、offline_access、openid、配置文件、User.read
- MS Graph:User.read、People.read 和 UserProfile.read
- 对于机密/经过身份验证的客户端:
- Azure AD Graph:电子邮件、offline_access、openid、配置文件、User.read、User.read.all 和 User.readbasic.all
- MS Graph:User.read、User.read.all、User.read.All People.read、People.read.all、GroupMember.Read.All、Member.Read.Hidden 和 UserProfile.read
- 对于本机客户端:
用户操作
用户操作是可由用户执行的任务。 目前,条件访问支持两种用户操作:
注册安全信息:使用此用户操作,可以在启用了组合注册的用户尝试注册其安全信息时强制实施条件访问策略。 在组合安全信息注册一文中可以找到详细信息。
注册或加入设备:使用此用户操作,管理员可以在用户向 Azure AD 注册或加入设备时强制实施条件访问策略。 使用此操作可以针对注册或加入设备的操作精细配置多重身份验证,而无需配置当前存在的租户范围的策略。 对于此用户操作,需要注意三个重要事项:
Require multifactor authentication
是此用户操作唯一可用的访问控制,所有其他访问控制均处于禁用状态。 此限制可防止与依赖于 Azure AD 设备注册或不适用于 Azure AD 设备注册的访问控制发生冲突。Client apps
、Filters for devices
和Device state
条件在此用户操作中不可用,因为它们依赖于使用 Azure AD 设备注册来强制实施条件访问策略。- 对此用户操作启用条件访问策略时,必须将“Azure Active Directory”>“设备”>“设备设置” -
Devices to be Azure AD joined or Azure AD registered require Multifactor Authentication
设置为“否” 。 否则,将无法正确地强制实施此用户操作的条件访问策略。 在配置设备设置中可以找到有关此设备设置的详细信息。
认证上下文
身份验证上下文可用于进一步保护应用程序中的数据和操作。 这些应用程序可以是你自己的自定义应用程序、自定义业务线 (LOB) 应用程序、SharePoint 等应用程序或受 Microsoft Defender for Cloud Apps 保护的应用程序。
例如,组织可以在 SharePoint 站点中保存文件,例如午餐菜单或其烧烤酱秘制配方。 任何人都可以访问午餐菜单站点,但是,有权访问烧烤酱秘制配方站点的用户可能需要从受管理设备进行访问并同意特定的使用条款。
配置身份验证上下文
在 Azure 门户中的“Azure Active Directory”>“安全性”>“条件访问”>“身份验证上下文”下管理身份验证上下文 。
在 Azure 门户中选择“新建身份验证上下文”可以创建新的身份验证上下文定义。 组织创建的身份验证上下文定义数总共不能超过 25 个。 配置以下特性:
- “显示名称”是用于在 Azure AD 中以及在使用身份验证上下文的各个应用程序中标识身份验证上下文的名称。 建议使用可在不同资源(例如“受信任的设备”)中使用的名称,以减少所需的身份验证上下文数量。 使用更少的一组名称可以限制重定向次数,并提供更好的端到端用户体验。
- “说明”提供有关 Azure AD 管理员使用的策略以及将身份验证上下文应用于资源的策略的详细信息。
- 选中“发布到应用”复选框会将身份验证上下文播发到应用,使这些应用可供分配。 如果不选中该复选框,则身份验证上下文不可用于下游资源。
- “ID”是只读的,在令牌和应用中用于创建特定于请求的身份验证上下文定义。 此处列出了故障排除和开发用例。
添加到条件访问策略
管理员可以选择其条件访问策略中已发布的身份验证上下文,方法是转到“分配”>“云应用或操作”,然后从“选择此策略的适用对象”菜单中选择“身份验证上下文” 。
删除身份验证上下文
删除某个身份验证上下文时,请确保没有任何应用程序仍在使用它。 否则对应用数据的访问将不再受保护。 如果正在应用身份验证上下文条件访问策略,可以通过检查登录日志来确认此先决条件。
若要删除某个身份验证上下文,必须确保没有为它分配条件访问策略,且它未发布到应用。 此项要求有助于防止意外删除仍在使用中的身份验证上下文。
使用身份验证上下文标记资源
有关在应用程序中使用身份验证上下文的详细信息,请参阅以下文章。
- 使用敏感度标签保护 Microsoft Teams、Microsoft 365 组和 SharePoint 网站中的内容
- Microsoft Defender for Cloud Apps
- 自定义应用程序