规划条件访问部署对于实现组织的应用和资源访问策略至关重要。 条件访问策略提供了极大的配置灵活性。 但是，这种灵活性意味着你需要仔细规划以避免不良结果。
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 应用时，将阻止他们。
建议
根据我们在条件访问和支持其他客户方面的经验，下面是一些建议。
将条件访问策略应用于每个应用
显示入站安全规则的屏幕截图。 从安全角度来看，最好创建包含所有资源（以前为“所有云应用”）的策略。 这种做法可确保每次加入新应用程序时都不需要更新条件访问策略。
提示
请谨慎使用单个策略中的块和所有资源。 此组合可能会锁定管理员，并且无法为重要终结点（如 Microsoft Graph）配置排除项。
尽量减少条件访问策略的数量
为每个应用创建策略并不高效，因此管理变得困难。 条件访问限制为每个租户 195 个策略。 此 195 策略限制包括处于任何状态的条件访问策略，包括仅报告模式、打开或关闭。
分析应用，并将其分组到具有相同用户资源要求的应用程序。 例如，如果所有Microsoft 365 个应用或所有 HR 应用对同一用户具有相同的要求，请创建一个策略，并包括应用的所有应用。
条件访问策略包含在 JSON 文件中，并且该文件的大小限制通常不超过单个策略。 如果在策略中使用 GUID 的长列表，可能会达到此限制。 如果遇到这些限制，请尝试以下替代方法：
为应对中断做好计划
通过 规划组织的复原策略 ，降低在意外中断期间锁定的风险。
启用受保护操作
启用 受保护的作 以添加另一层安全层，以尝试创建、更改或删除条件访问策略。 在更改策略之前，组织可能需要新的多重身份验证或其他授权控制。
为策略设置命名标准
命名标准可帮助你查找策略并了解其用途，而无需打开它们。 将策略命名为要显示：
- 序列号
- 适用该策略的云应用
- 响应
- 策略对谁应用
- 策略何时应用
示例：对于从外部网络访问 Dynamics CRP 应用的营销用户要求 MFA 的策略可能是：
描述性名称有助于概述条件访问实现。 如果需要在会话中引用策略，则序列号非常有用。 例如，当你在电话中与管理员交谈时，可以要求他们打开策略 CA01 来解决问题。
紧急访问控制的命名标准
除了活动策略以外，还应实施已禁用策略，这些策略在中断或紧急情况下充当辅助性的弹性访问控制措施。 应急策略的命名标准应包括：
- 以“ENABLE IN EMERGENCY”开头，使名称从其他策略中脱颖而出。
- 它应应用于的中断的名称。
- 一个排序序列号，可帮助管理员知道应启用哪个顺序策略。
示例：以下名称显示，如果发生 MFA 中断，此策略是要启用的四个策略中的第一个：
- EM01 - 在紧急情况下启用：MFA 中断[1/4] - Exchange SharePoint：VIP 用户需要使用 Microsoft Entra 混合联接。
阻止从未期望从该处登录的国家/地区
Microsoft Entra ID 允许创建 命名位置。 创建允许的国家/地区列表，然后使用这些“允许的国家/地区”创建网络阻止策略作为排除项。 此选项为基于较小地理位置的客户创建较少的开销。 请务必从此策略中排除紧急访问帐户。
部署条件访问策略
准备就绪后，分阶段部署你的条件访问策略。
生成条件访问策略
从以下几个核心条件访问策略开始。 许多策略都可用作 条件访问策略模板。 默认情况下，从模板创建的每个策略都处于仅报告模式。 在启用每个策略之前，测试和监视使用情况，以确保预期结果。
| 条件访问策略 | 许可证要求 |
|---|---|
| 阻止旧式身份验证 | Microsoft Entra ID P1 |
| 特权Microsoft Entra 内置角色强制实施防钓鱼方法 | Microsoft Entra ID P1 |
| 所有用户登录活动都使用强身份验证方法 | Microsoft Entra ID P1 |
| 来宾访问受强身份验证方法的保护 | Microsoft Entra ID P1 |
| 保护 MFA 注册（我的安全信息）页 | Microsoft Entra ID P1 |
| 要求使用用户作对设备加入和设备注册进行多重身份验证 | Microsoft Entra ID P1 |
| 用户登录活动使用令牌保护 | Microsoft Entra ID P1 |
| 限制设备代码流 | Microsoft Entra ID P1 |
| 身份验证传输被阻止 | Microsoft Entra ID P1 |
| 限制对高风险用户的访问 | Microsoft Entra ID P2 |
| 限制高风险登录 | Microsoft Entra ID P2 |
| 已配置特权访问工作站的条件访问策略 | Microsoft Entra ID P1 |
评估策略影响
使用可用工具检查更改前后策略的效果。 模拟运行可让你很好地了解条件访问策略如何影响登录，但它不会替换正确配置的开发环境中的实际测试运行。
管理员可以使用策略影响或仅报告模式来确认策略设置。
测试策略
务必测试策略的排除条件。 例如，你可从要求执行 MFA 的策略中排除某个用户或组。 测试是否提示排除的用户进行 MFA，因为其他策略的组合可能需要这些用户的 MFA。
使用测试用户运行测试计划中的每个测试。 测试计划可帮助你比较预期结果和实际结果。
在生产环境中部署
使用仅限报表模式确认影响后，管理员可以将“启用”策略切换从“仅报告”移动到“打开”。
回滚策略
如果需要回滚新实现的策略，请使用以下一个或多个选项：
禁用策略。 禁用某个策略可确保当用户尝试登录时不应用该策略。 在想要使用它时，始终可以返回并启用策略。
从策略中排除用户或组。 如果用户无法访问应用，请从策略中排除用户。
注意
请谨慎使用排除项，仅在用户受信任的情况下使用。 尽快将用户添加回策略或组。
如果策略已禁用且不再需要 ，请将其删除。
排查条件访问策略问题
如果用户有条件访问策略的问题，请收集此信息以帮助进行故障排除。
- 用户主体名称
- 用户显示名称
- 操作系统名称
- 时间戳（大致时间很好）
- 目标应用程序
- 客户端应用程序类型（浏览器或客户端）
- 相关 ID（登录时分配的唯一 ID）
如果用户收到包含更多详细信息链接的消息，他们可以为你收集大部分此信息。
收集信息后，请参阅以下资源：
- 条件访问的登录问题 - 了解使用错误消息和 Microsoft Entra 登录日志分析与条件访问相关的意外的登录结果。