计划条件访问部署

规划条件访问部署对于实现组织的应用和资源访问策略至关重要。 条件访问策略提供显著的配置灵活性。 但是，这种灵活性意味着你需要仔细规划以避免不良结果。

Microsoft Entra 条件访问 结合了用户、设备和位置等信号，以自动执行决策，并强制实施资源的组织访问策略。 这些条件访问策略有助于平衡安全性和工作效率，方法是在需要时强制实施安全控制，并在用户不在用户时保持不对。

条件访问构成了 Microsoft零信任安全策略引擎的基础。

Microsoft提供 安全默认值 ，确保租户的基本安全级别，而无需Microsoft Entra ID P1 或 P2。 使用条件访问，可以创建与安全默认值相同的保护的策略，但粒度更高。 条件访问和安全默认值不应合并，因为创建条件访问策略会阻止启用安全默认值。

先决条件

• 启用了 Microsoft Entra ID P1、P2 或试用许可证的工作Microsoft Entra 租户。 如果需要，可免费创建一个。
  • 需要 Microsoft Entra ID P2 才能在条件访问策略中涵盖 Microsoft Entra ID 保护风险。
• 与条件访问交互的管理员需要以下角色分配之一，具体取决于他们正在执行的任务。 若要遵循 最低特权的零信任原则，请考虑使用 Privileged Identity Management （PIM） 实时激活特权角色分配。
  • 读取条件访问策略和配置。
    • 安全读取者
  • 创建、修改或还原软删除的条件访问策略。
    • 条件访问管理员
• 在部署到真实用户之前，测试用户（而不是管理员）检查策略是否按预期工作。 如果需要创建用户，请参阅快速入门：向 Microsoft Entra ID 添加新用户。
• 包含测试用户的组。 如果需要创建组，请参阅在 Microsoft Entra ID 中创建组并添加成员。

传达更改

沟通对于任何新功能的成功都至关重要。 让用户了解其体验的变化、更改时间，以及如何在遇到问题时获取支持。

条件访问策略组件

条件访问策略确定谁可以访问资源、哪些资源可以访问，以及哪些条件。 策略可以授予访问权限、使用会话控制限制访问权限或阻止访问。 可以通过定义 if-then 语句来生成条件访问策略，例如：

排除用户

条件访问策略是功能强大的工具。 建议从策略中排除以下帐户：

• 紧急访问或不受限帐户，用于防止因策略错误配置导致的锁定。 在所有管理员被锁定的可能性不大的情况下，紧急访问管理帐户可用于登录和恢复访问权限。
• 服务帐户和服务主体，例如 Microsoft Entra Connect 同步帐户。 服务帐户是未绑定到任何特定用户的非交互帐户。 它们通常由后端服务用来允许以编程方式访问应用程序，但它们也用于登录系统以实现管理目的。 由服务主体发出的调用不受范围限定为用户的条件访问策略阻止。 对工作负荷标识使用条件访问来定义面向服务主体的策略。
  • 如果你的组织在脚本或代码中使用这些帐户，请将这些帐户替换为 托管标识。

询问正确的问题

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

用户或工作负载标识

• 在策略中包含或从策略中排除哪些用户、组、目录角色或工作负载标识？
• 应从策略中排除哪些紧急访问帐户或组？

云应用或操作

此策略是否适用于应用程序、用户作或身份验证上下文？ 如果是这样的话：

• 策略适用于哪些应用程序或服务？
• 哪些用户操作受到此策略的限制？
• 此策略适用于哪些身份验证上下文？

筛选应用程序

使用应用程序的筛选器来包括或排除应用程序，而不是单独指定它们，这有助于组织：

• 轻松缩放和定位任意数量的应用程序
• 管理具有类似策略要求的应用程序
• 减少单个策略的数量
• 在编辑策略时减少错误：无需从策略中手动添加或删除应用程序。 只需管理属性。
• 克服策略大小约束

条件

• 在策略中包括或从策略中排除哪些设备平台？
• 组织的已知网络位置是什么？
  • 在策略中包括或从策略中排除哪些位置？
• 在策略中包括或从策略中排除哪些客户端应用类型？
• 是否需要针对特定的设备属性？

阻止或授予控制权

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

• 多重身份验证
• 设备标记为“合规”
• 使用 Microsoft Entra 混合联接设备
• 使用批准的客户端应用
• 应用了应用保护策略
• 密码更改
• 已接受使用条款

阻止访问 是一个强大的控件。 仅当你了解影响时才应用它。 具有块语句的策略可能会产生意外的副作用。 在大规模启用控件之前进行测试和验证。

会话控制

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

• 使用应用所强制实施的限制
• 使用条件访问应用控制
• 强制登录频率
• 使用持久性浏览器会话
• 自定义连续访问评估

合并策略

创建和分配策略时，请考虑访问令牌的工作原理。 根据发出请求的用户是否获得授权和身份验证，访问令牌授予或拒绝访问权限。 如果请求者证明自己是谁，他们可以使用受保护的资源或功能。

如果条件访问策略条件未触发访问控制，则默认颁发访问令牌。

此策略不会阻止应用自行阻止访问。

让我们探讨一个简化的策略示例：

用户：财务组
访问：工资单应用
访问控制：多重身份验证

• 用户 A 是财务组的成员，需要执行多重身份验证才能访问薪资应用。
• 用户 B 不是财务组的成员，但为其颁发了访问令牌，并允许其在不执行多重身份验证的情况下访问薪资应用。

若要确保财务组外部的用户无法访问工资应用，请创建一个单独的策略来阻止所有其他用户，如下所示的简化策略：

用户：包括“所有用户”/排除“财务组”
访问：工资单应用
访问控制：阻止访问

现在，当用户 B 尝试访问 PAYROLL 应用时，将阻止他们。

建议

根据我们在条件访问和支持其他客户方面的经验，下面是一些建议。

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

显示入站安全规则的屏幕截图。 从安全角度来看，最好创建包含所有资源（以前为“所有云应用”）的策略。 这种做法可确保每次加入新应用程序时都不需要更新条件访问策略。

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

为每个应用创建策略并不高效，因此管理策略变得困难。 条件访问限制为每个租户 195 个策略。 此 195 策略限制包括处于任何状态的条件访问策略，包括仅报告模式、打开或关闭。

分析应用，并按相同用户相同的资源要求对应用进行分组。 例如，如果所有Microsoft 365 个应用或所有 HR 应用对同一用户具有相同的要求，请创建一个策略，并包括应用的所有应用。

条件访问策略包含在 JSON 文件中，并且该文件的大小限制通常不超过单个策略。 如果在策略中使用 GUID 的长列表，可能会达到此限制。 如果遇到这些限制，请尝试以下替代方法：

• 使用组或角色包括或排除用户，而不是单独列出每个用户。
• 对于应用程序，使用筛选器来包括或排除应用程序，而不是单独指定它们。

为应对中断做好计划

通过 规划组织的复原策略 ，降低在意外中断期间锁定的风险。

启用受保护操作

启用 受保护的作 以添加另一层安全层，以尝试创建、更改或删除条件访问策略。 在更改策略之前，组织可能需要新的多重身份验证或其他授权控制。

配置来宾用户设置

对于您已知且有合作关系的外部组织，您可能希望信任来宾在您的条件访问策略下提供的多重身份验证、设备合规性或混合设备声明。 有关详细信息，请参阅 管理 B2B 协作的跨租户访问设置。

为策略设置命名标准

命名标准可帮助你查找策略并了解其用途，而无需打开它们。 将策略命名为要显示：

• 序列号
• 适用该策略的云应用
• 响应
• 策略对谁应用
• 策略何时应用

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

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

紧急访问控制的命名标准

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

• 以“ENABLE IN EMERGENCY”开头，使名称从其他策略中脱颖而出。
• 它应应用于的中断的名称。
• 一个排序序列号，可帮助管理员知道应启用哪个顺序策略。

示例：以下名称显示，如果发生 MFA 中断，此策略是要启用的四个策略中的第一个：

• EM01 - 在紧急情况下启用：MFA 中断[1/4] - Exchange SharePoint：VIP 用户需要使用 Microsoft Entra 混合联接。

阻止从未期望从该处登录的国家/地区

Microsoft Entra ID 允许创建 命名位置。 创建允许的国家/地区列表，然后使用这些“允许的国家/地区”创建网络阻止策略作为排除项。 此选项为基于较小地理位置的客户创建较少的开销。 请务必从此策略中排除紧急访问帐户。

部署条件访问策略

准备就绪后，分阶段部署你的条件访问策略。 从以下几个核心条件访问策略开始。 许多策略都可用作 条件访问策略模板。 默认情况下，从模板创建的每个策略都处于仅报告模式。 在启用每个策略之前，测试和监视使用情况，以确保预期结果。

在以下三个阶段部署策略，以平衡安全改进，同时尽量减少用户中断。 组织可以根据其规模、复杂性和更改管理功能调整时间线。

第 1 阶段：基础（第 1-2 周）

建立基线安全控制并准备实施 MFA。 先决条件： 在启用强制策略之前，请确保用户可以注册 MFA。

阶段 2：核心身份验证（第 2-3 周）

为所有用户和来宾强制实施 MFA，并使用 应用保护策略保护移动设备。 关键影响： 用户需要对所有登录使用 MFA，并在移动设备上使用已批准的应用来保护应用。 确保执行通信计划，并提供支持资源。

第 3 阶段：高级保护（第 3-4 周）

添加基于风险的策略和高级攻击防护控制措施。 许可证要求： 基于风险的策略需要Microsoft Entra ID P2 许可证。

评估策略影响

使用可用工具检查更改前后策略的效果。 模拟运行可让你很好地了解条件访问策略如何影响登录，但它不会替换正确配置的开发环境中的实际测试运行。

管理员可以使用策略影响或仅报告模式来确认策略设置。

测试策略

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

使用测试用户运行测试计划中的每个测试。 测试计划可帮助你比较预期结果和实际结果。

在生产环境中部署

使用仅限报表模式确认影响后，管理员可以将“启用”策略切换从“仅报告”移动到“打开”。

回滚策略

如果需要回滚新实现的策略，请使用以下一个或多个选项：

• 禁用策略。 禁用某个策略可确保当用户尝试登录时不应用该策略。 在想要使用它时，始终可以返回并启用策略。

• 从策略中排除用户或组。 如果用户无法访问应用，请从策略中排除用户。

  注意

  请谨慎使用排除项，仅在用户受信任的情况下使用。 尽快将用户重新添加到策略或组中。

• 如果策略已禁用且不再需要 ，请将其删除。

还原已删除的策略

如果条件访问或位置遭到删除，则可以在 30 天软删除期内进行还原。 有关还原条件访问策略和命名位置的详细信息，请参阅文章 “从删除中恢复”。

排查条件访问策略问题

如果用户有条件访问策略的问题，请收集此信息以帮助进行故障排除。

• 用户主体名称
• 用户显示名称
• 操作系统名称
• 时间戳（大致时间很好）
• 目标应用程序
• 客户端应用程序类型（浏览器或客户端）
• 相关 ID（登录时分配的唯一 ID）

如果用户收到包含 更多详细信息 链接的消息，他们可以为你收集大部分此信息。

收集信息后，请参阅以下资源：

• 条件访问的登录问题 - 了解使用错误消息和 Microsoft Entra 登录日志分析与条件访问相关的意外的登录结果。

相关内容

• 详细了解多重身份验证

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