规划条件访问部署对于实现组织的应用和资源访问策略至关重要。 条件访问策略提供了很高的配置灵活性。 不过，这种灵活性也意味着需要精心规划，以避免出现不利结果。
Microsoft Entra 条件访问整合了用户、设备和位置等信号，以自动做出决策，并强制实施组织的资源访问策略。 这些条件访问策略有助于平衡安全性和工作效率，可以按需强制实施安全控制，并在不需要时避免干扰用户。
条件访问是 Microsoft 零信任安全策略引擎的基础。
Microsoft 提供安全默认值，可确保在未安装 Microsoft Entra ID P1 或 P2 的租户中启用基础安全保护。 使用条件访问，可以创建提供与安全默认值相同的保护但具有粒度的策略。 不应组合条件访问和安全默认值，因为创建条件访问策略会阻止启用安全默认值。
先决条件
- 启用了 Microsoft Entra ID P1、P2 或试用版许可证的有效 Microsoft Entra 租户。 如果需要，可创建一个。
- 与条件访问交互的管理员必须具有以下一个角色分配，具体取决于他们正在执行的任务。 若要遵循最低特权零信任原则，请考虑使用 Privileged Identity Management (PIM) 即时激活特权角色分配。
- 在部署到实际用户之前，用于验证策略是否按预期工作的测试用户（非管理员）。 如果需要创建用户，请参阅快速入门：向 Microsoft Entra ID 添加新用户。
- 测试用户所属的组。 如果需要创建组，请参阅在 Microsoft Entra ID 中创建组并添加成员。
传达更改
沟通对于任何新功能的成功都至关重要。 应主动与用户交流，告知他们的体验将如何更改、何时会更改以及在遇到问题时如何获取支持。
条件访问策略组件
条件访问策略能够解答有关谁可以访问你的资源、他们可以访问哪些资源以及在什么条件下访问资源的问题。 可以将策略设计为授予访问权限、使用会话控制限制访问权限或阻止访问。 可以通过定义 if-then 语句来生成条件访问策略，例如：
| 如果符合分配要求 | 应用访问控制 |
|---|---|
| 如果你是需要访问薪资应用程序的财务部用户 | 需要多重身份验证与合规设备 |
| 如果你不是需要访问薪资应用程序的财务部成员 | 阻止访问 |
| 如果你的用户风险较高 | 需要多重身份验证和更改安全密码 |
排除用户
条件访问策略是功能强大的工具，建议从策略中排除以下帐户：
- 紧急访问或不受限帐户，用于防止因策略错误配置导致的锁定。 在极少数情况下，所有管理员都被锁定，这时可以使用紧急访问管理帐户登录，以采取措施来恢复访问。
-
服务帐户和服务主体，例如 Microsoft Entra Connect 同步帐户。 服务帐户是不与任何特定用户关联的非交互式帐户。 它们通常由后端服务使用，以便可以对应用程序进行编程访问，不过也会用于登录系统以进行管理。 范围限定为用户的条件访问策略将不会阻止由服务主体进行的调用。 对工作负载标识使用条件访问来定义面向服务主体的策略。
- 如果组织在脚本或代码中使用这些帐户，请考虑将其替换为托管标识。
询问正确的问题
下面是有关分配和访问控制的一些常见问题。 在生成策略之前，记录每个策略的问题答案。
用户或工作负载标识
- 在策略中包含或从策略中排除哪些用户、组、目录角色或工作负载标识？
- 应从策略中排除哪些紧急访问帐户或组？
云应用或操作
此策略是否适用于任何应用程序、用户操作或身份验证上下文？ 如果是：
- 该策略将会应用于哪些应用程序或服务？
- 哪些用户操作受到此策略的限制？
- 此策略将应用于哪些身份验证上下文？
筛选应用程序
使用应用程序的筛选器来包括或排除应用程序，而不是单独指定它们，这有助于组织：
- 轻松缩放和定位任意数量的应用程序。
- 轻松管理具有类似策略要求的应用程序。
- 减少单个策略的数量。
- 在编辑策略时减少错误：无需手动从策略中添加/删除应用程序。 只需管理属性。
- 克服策略大小约束。
条件
- 在策略中包括或从策略中排除哪些设备平台？
- 组织的已知网络位置是什么？
- 在策略中包括或从策略中排除哪些位置？
- 在策略中包括或从策略中排除哪些客户端应用类型？
- 是否需要针对特定的设备属性？
阻止或授予控制权
是否要通过以下一项或多项要求来授予对资源的访问权限？
- 多重身份验证
- 设备标记为“合规”
- 使用 Microsoft Entra 混合联接设备
- 使用批准的客户端应用
- 应用了应用保护策略
- 密码更改
- 已接受使用条款
阻止访问是一种强有力的控制，运用此项控制时，应具备相应的知识。 带有块语句的策略可能会产生意外的副作用。 在大规模启用此控制之前，正确测试和验证至关重要。 进行更改时，管理员应使用条件访问中仅限报告模式之类的工具。
会话控制
是否要在云应用上强制执行以下任意访问控制？
- 使用应用所强制实施的限制
- 使用条件访问应用控制
- 强制登录频率
- 使用持久性浏览器会话
合并策略
创建和分配策略时，必须考虑访问令牌的工作方式。 访问令牌根据提出请求的用户是否已获得授权并经过身份验证来授予或拒绝访问权限。 如果请求者可证明自己是所自称的身份，则可访问受保护的资源或功能。
如果条件访问策略条件未触发访问控制，则默认会颁发访问令牌。
此策略不会防碍应用凭借自身的能力阻止访问。
让我们探讨一个简化的策略示例：
用户：财务组
访问：工资单应用
访问控制：多重身份验证
- 用户 A 是财务组的成员，需要执行多重身份验证才能访问薪资应用。
- 用户 B 不是财务组的成员，但为其颁发了访问令牌，并允许其在不执行多重身份验证的情况下访问薪资应用。
为确保财务组外部的用户无法访问薪资应用，可以创建一个单独的策略来阻止所有其他用户，如以下简化策略所示：
用户：包括“所有用户”/排除“财务组”
访问：工资单应用
访问控制：阻止访问
现在，当用户 B 尝试访问薪资应用时，会阻止其访问。
建议
下面根据我们在使用条件访问和为其他客户提供支持方面取得的经验提出了几条建议。
将条件访问策略应用于每个应用
显示入站安全规则的屏幕截图。 从安全的角度来看，最好创建包含所有资源（以前为“所有云应用”）的策略。 这种做法可确保每次加入新应用程序时都不需要更新条件访问策略。
提示
在单个策略中使用“阻止”和所有应用时要非常小心。 这可能会将管理员锁在外面，并且无法为重要终结点（例如 Microsoft Graph）配置排除项。
尽量减少条件访问策略的数量
为每个应用创建一个策略并不是很有效的做法，而且会导致管理难度增加。 条件访问每租户限制为 195 个策略。 此 195 策略限制包括处于任何状态的条件访问策略，其中包括仅限报告模式、打开或关闭。
我们建议你对应用进行分析，并按对相同用户具有相同的资源要求将应用进行分组。 例如，如果所有 Microsoft 365 应用或所有 HR 应用对同一用户具有相同的要求，请创建一个策略，并包括应用该策略的所有应用。
条件访问策略包含在 JSON 文件中，并且该文件会绑定到我们不希望单个策略超出的大小限制。 如果在策略中使用 GUID 的长列表，可能会达到此限制。 如果达到这些限制，建议使用以下替代方法：
为应对中断做好计划
为降低在发生不可预见的中断时被锁定的风险，请为组织规划复原策略。
启用受保护操作
启用受保护操作会在尝试创建、修改或删除条件访问策略时再增加一层安全性。 在修改策略之前，组织可能需要新的多重身份验证或其他授权控制。
为策略设置命名标准
命名标准有助于查找策略及了解其用途，而无需在 Azure 管理门户中将其打开。 我们建议你对策略进行命名以显示：
- 序列号
- 适用该策略的云应用
- 响应
- 策略对谁应用
- 策略何时应用
示例：对于从外部网络访问 Dynamics CRP 应用的营销用户要求 MFA 的策略可能是：
描述性名称可帮助你大致了解条件访问实现。 如果需要在对话中引用策略，则序列号非常有用。 例如，当你在电话中与管理员进行交谈时，可以要求他们打开策略 CA01 来解决问题。
紧急访问控制的命名标准
除了活动策略以外，还应实施已禁用策略，这些策略在中断或紧急情况下充当辅助性的弹性访问控制措施。 应急策略的命名标准应当包括：
- 以“ENABLE IN EMERGENCY”开头，使名称从其他策略中脱颖而出。
- 它应当应用于的中断的名称。
- 一个排序序列号，可以帮助管理员了解应当以何顺序启用策略。
示例：以下名称表明，如果发生 MFA 中断，此策略是要启用的四个策略中的第一个：
- EM01 - 在紧急情况下启用：MFA 中断[1/4] - Exchange SharePoint：VIP 用户需要使用 Microsoft Entra 混合联接。
阻止从未期望从该处登录的国家/地区
可使用 Microsoft Entra ID 创建命名位置。 创建允许的国家/地区列表，然后创建将这些“允许的国家/地区”作为排除项的网络阻止策略。 对于所在地理位置较小的客户，此选项可以降低开销。 确保从此策略中排除你的紧急访问帐户。
部署条件访问策略
准备就绪后，分阶段部署你的条件访问策略。
生成条件访问策略
在准备阶段可以先参阅条件访问策略模板和面向 Microsoft 365 组织的通用安全策略。 这些模板是部署 Microsoft 建议的便捷方式。 请确保排除紧急访问帐户。
评估策略影响
我们建议使用以下工具来评估做出更改前后的策略影响。 模拟运行可以让你很好地了解条件访问策略的影响，但它不能取代正确配置的开发环境中的实际测试运行。
- 仅限报告模式和条件访问见解和报告工作簿。
测试策略
务必测试策略的排除条件。 例如，你可从要求执行 MFA 的策略中排除某个用户或组。 测试系统是否会提示已排除的用户执行 MFA，因为其他策略的组合可能会要求这些用户执行 MFA。
在测试计划中通过测试用户执行每个测试。 测试计划非常重要，它可以在预期结果与实际结果之间进行比较。 下表概述了一些示例测试用例。 根据条件访问策略的配置情况调整方案和预期结果。
| 策略 | 方案 | 预期结果 |
|---|---|---|
| 设备管理 | 经授权的用户尝试从已授权的设备登录 | 授予访问权限 |
| 设备管理 | 经授权的用户尝试从未授权的设备登录 | 阻止访问 |
在生产环境中部署
使用仅限报告模式确认影响后，管理员可以将“启用策略”从“仅限报告”切换为“打开”。
回滚策略
如果需要回滚新实施的策略，请使用以下一个或多个选项：
禁用策略。 禁用某个策略可确保当用户尝试登录时不应用该策略。 想要使用该策略时，可以随时重新启用它。
从策略中排除用户或组。 如果某个用户无法访问应用，你可以选择从策略中排除该用户。
注意
应慎用排除，请仅在用户受信任的情况下才使用。 应尽快将该用户加回到策略或组中。
如果禁用了某个策略且不再需要它，请将其删除。
排查条件访问策略问题
如果用户遇到条件访问策略问题，请收集以下信息以便于故障排除。
- 用户主体名称
- 用户显示名称
- 操作系统名称
- 时间戳（近似为正常）
- 目标应用程序
- 客户端应用程序类型（浏览器与客户端）
- 相关 ID（登录时分配的唯一 ID）
如果用户收到了包含“更多详细信息”链接的消息，则可以为你收集大部分此类信息。
收集信息后，请参阅以下资源：
- 条件访问相关的登录问题 - 通过错误消息和 Microsoft Entra 登录日志了解与条件访问相关的意外登录结果。