计划条件访问部署

规划条件访问部署对于实现组织的应用和资源访问策略至关重要。

Azure Active Directory (Azure AD) 条件访问可分析各种信号(例如,用户、设备和位置),以自动做出决策,并强制实施组织的资源访问策略。 条件访问策略允许构建条件来管理安全控制,这些控制可以用于阻止访问、要求多重身份验证,或根据需要限制用户会话并阻止用户访问。

通过此评估和强制执行,条件访问定义了 Microsoft 零信任安全手势管理

Conditional Access overview

Microsoft 提供安全默认值,可确保在未安装 Azure AD Premium 的租户中启用基础安全保护。 使用条件访问,可以创建提供与安全默认值相同的保护但具有粒度的策略。 不应组合条件访问和安全默认值,因为创建条件访问策略将阻止启用安全默认值。

先决条件

了解条件访问策略组件

策略回答有关谁应访问你的资源、他们应访问哪些资源以及在什么条件下访问资源的问题。 可以将策略设计为授予访问权限、使用会话控制限制访问权限或阻止访问。 通过定义 if-then 语句:如果满足分配,则应用访问控制,可以生成条件访问策略

询问正确的问题

下面是有关分配和访问控制的一些常见问题。 在生成策略之前,记录每个策略的问题答案。

用户或工作负载标识

  • 将在策略中包括或从策略中排除哪些用户、组、目录角色和工作负荷标识?

  • 应从策略中排除哪些紧急访问帐户或组?

云应用或操作

此策略是否适用于任何应用程序、用户操作或身份验证上下文? 如果是,

  • 将策略应用到哪些应用程序?
  • 哪些用户操作将受此策略的限制?
  • 此策略将应用于哪些身份验证上下文?

条件

  • 将在策略中包括或从策略中排除哪些设备平台?

  • 组织受信任的位置有哪些?

  • 将在策略中包括或从策略中排除哪些位置?

  • 将在策略中包括或从策略中排除哪些客户端应用类型?

  • 你是否有策略排除已建立 Azure AD 联接的设备或已建立混合 Azure AD 联接的设备?

授予或阻止

是否要通过以下一项或多项要求来授予对资源的访问权限?

  • 要求 MFA

  • 要求将设备标记为合规

  • 要求使用已建立混合 Azure AD 联接的设备

  • 需要批准的客户端应用

  • 需要应用保护策略

  • 要求更改密码

  • 使用使用条款

会话控制

是否要在云应用上强制执行以下任意访问控制?

  • 使用应用所强制实施的限制

  • 使用条件访问应用控制

  • 强制登录频率

  • 使用持久性浏览器会话

  • 自定义连续访问评估

访问令牌颁发

访问令牌根据提出请求的用户是否已获得授权并经过身份验证来授予或拒绝访问权限。 如果请求者可证明自己是所自称的身份,则可访问受保护的资源或功能。

Access token issuance diagram

如果条件访问策略条件未触发访问控制,则默认情况下会颁发访问令牌。

这不会阻止应用获得单独的授权来阻止访问。 例如,请在以下情况下考虑使用策略:

  • 如果用户属于财务团队成员,则强制 MFA 访问其工资单应用。

  • 如果非财务团队成员用户尝试访问工资单应用,则向该用户颁发访问令牌。

  • 为确保财务组外部用户无法访问工资单应用,应创建单独的策略来阻止所有其他用户。 如果除财务团队和紧急访问帐户组以外的所有用户访问工资单应用,则阻止访问。

遵循最佳做法

条件访问提供了极大的配置灵活性。 不过,极大的灵活性也意味着应先仔细检查每个配置策略,然后才能发布,以免产生不良结果。

设置紧急访问帐户

如果错误配置了策略,则该策略会将组织锁在 Azure 门户之外。

通过在组织中创建两个或更多紧急访问帐户,可缓解意外锁定管理员造成的影响。 创建专用于策略管理并从所有策略中排除的用户帐户。

将条件访问策略应用于每个应用

确保每个应用至少已应用一个条件访问策略。 从安全角度来看,最好创建包含所有云应用的策略,然后排除不希望应用该策略的应用程序。 这可确保每次载入新应用程序时都不需要更新条件访问策略。

重要

在单个策略中使用“阻止”和所有应用时要非常小心。 这可能会将管理员锁在 Azure 管理门户之外,并且无法为重要终结点(例如 Microsoft Graph)配置排除项。

尽量减少条件访问策略的数量

为每个应用创建一个策略并不是很有效的做法,而且会导致管理难度增加。 条件访问只会对每个用户应用前 195 个策略。 我们建议你对应用进行分析,并按对相同用户具有相同的资源要求将应用进行分组。 例如,如果所有 Microsoft 365 应用或所有 HR 应用对同一用户具有相同的要求,请创建一个策略,并包括应用该策略的所有应用。

为应对中断做好计划

如果你依靠单一访问控制(如 MFA 或网络位置)来保护 IT 系统,那么当该单一访问控制不可用或配置错误时,很容易发生访问失败。

为了降低在不可预见的中断期间被锁定的风险,计划为你的组织采用的策略。

为策略设置命名标准

命名标准有助于查找策略及了解其用途,而无需在 Azure 管理门户中将其打开。 我们建议你对策略进行命名以显示:

  • 序列号

  • 策略应用到的云应用

  • 响应

  • 策略对谁应用

  • 何时应用(如果适用)

Screenshot that shows the naming standards for policies.

示例:对于从外部网络访问 Dynamics CRP 应用的营销用户要求 MFA 的策略可能是:

Naming standard

描述性名称可帮助你大致了解条件访问实现。 如果需要在对话中引用策略,则序列号非常有用。 例如,当你在电话中与管理员进行交谈时,可以要求他们打开策略 CA01 来解决问题。

紧急访问控制的命名标准

除了活动策略以外,还应实施已禁用策略,这些策略在中断或紧急情况下充当辅助性的弹性访问控制措施。 应急策略的命名标准应当包括:

  • 以“ENABLE IN EMERGENCY”开头,使名称从其他策略中脱颖而出。

  • 它应当应用于的中断的名称。

  • 一个排序序列号,可以帮助管理员了解应当以何顺序启用策略。

示例

以下名称表明,如果发生 MFA 中断,此策略是要启用的四个策略中的第一个:

  • EM01 - ENABLE IN EMERGENCY:MFA 中断 [1/4] - Exchange SharePoint:VIP 用户需要混合 Azure AD 联接。

阻止你一定不会从该处登录的国家/地区。

Azure Active Directory 允许你创建命名位置。 创建允许的国家/地区列表,然后创建一个网络阻止策略,并将这些“允许的国家/地区”作为排除项。 对于主要居住于地理位置区域较小的客户而言,该项开销较低。请务必从此策略中免除紧急访问帐户。

部署条件访问策略

新策略准备就绪后,分步部署条件访问策略。

生成条件访问策略

有关开端计划,请参阅常见的条件访问策略。 出于方便,可以使用 Microsoft 建议随附的条件访问模板。 请确保排除紧急访问帐户。

评估策略影响

在生产环境中查看条件访问策略的影响之前,我们建议使用以下两个工具来运行模拟。

设置“仅限报告”模式

默认情况下,每个策略都是在仅报告模式下创建的,我们建议组织在启用每个策略之前测试并监视使用情况,以确保达到预期效果。

在“仅报告”模式下启用策略。 在仅限报告模式下保存策略后,可以在登录日志中看到对实时登录的影响。 从登录日志中选择一个事件,然后导航到“仅限报告”选项卡,以查看每个仅限报告策略的结果。

你可以在见解和报告工作簿中查看条件访问策略的总体影响。 若要访问该工作簿,需要 Azure Monitor 订阅,并且需要将登录日志流式传输到 Log Analytics 工作区

测试策略

务必测试策略的排除条件。 例如,你可能从要求执行 MFA 的策略中排除了某个用户或组。 测试系统是否会提示已排除的用户执行 MFA,因为其他策略的组合可能会要求这些用户执行 MFA。

在测试计划中通过测试用户执行每个测试。 测试计划非常重要,它可以在预期结果与实际结果之间进行比较。 下表概述了示例测试用例。 根据条件访问策略的配置情况调整方案和预期结果。

策略 方案 预期结果
设备管理 经授权的用户尝试从已授权的设备登录 授予访问权限
设备管理 经授权的用户尝试从未授权的设备登录 阻止访问

在生产环境中部署

使用“仅报告”模式确认影响后,管理员可以将“启用策略”从“仅报告”切换至“开”。

回滚策略

如果需要回滚新实施的策略,请使用以下一个或多个选项:

  • 禁用策略。 禁用某个策略可确保当用户尝试登录时不应用该策略。 想要使用该策略时,可以随时重新启用它。

enable policy image

  • 从策略中排除用户或组。 如果某个用户无法访问应用,你可以选择从策略中排除该用户。

exclude users and groups

注意

应该慎用此选项,仅在用户受信任的情况下才使用。 应该尽快将该用户加回到策略或组中。

  • 删除策略。 如果不再需要该策略,请将其删除

排查条件访问策略

如果用户遇到条件访问策略问题,请收集以下信息以便进行故障排除。

  • 用户主体名称

  • 用户显示名称

  • 操作系统名称

  • 时间戳(近似为正常)

  • 目标应用程序

  • 客户端应用程序类型(浏览器与客户端)

  • 相关 ID(这对于登录是唯一的)

如果用户收到了包含“更多详细信息”链接的消息,则可以为你收集大部分此类信息。

Can’t get to app error message

收集信息后,请参阅以下资源:

后续步骤

详细了解多重身份验证

使用 Microsoft Graph API 管理条件访问策略