你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
条件访问框架和策略
本文提供了实现基于角色条件访问体系结构的框架，如条件访问零信任体系结构中所述的体系结构。 本文详细介绍如何形成和命名条件访问策略。 还介绍了怎么开始创建策略。
如果你不使用此处提供的类似框架（包括命名标准），则策略往往由不同人员随时间推移临时创建。 这可能导致策略重叠。 如果创建策略的人员不在了，则其他人可能很难知道该策略的目的。
遵循结构化框架可以更轻松地理解策略。 它还有利于涵盖所有方案，更容易避免难以进行故障排除的冲突策略。
命名约定
正确定义的命名约定可帮助你和同事了解策略的用途，从而简化策略管理和故障排除。 命名约定应适合用于构建策略的框架。
建议的命名策略基于角色、策略类型和应用。 如下所示：
<CANumber>-<Persona>-<PolicyType>-<App>-<Platform>-<GrantControl>-<OptionalDescription>
此名称的组成部分如下所述：
| 命名组成部分 | 说明/示例 |
|---|---|
| CA 编号 | 用于快速识别策略类型范围和顺序。 示例：CA001-CA099。 |
| 角色 | Global、Admins、Internals、Externals、GuestUsers、GuestAdmins、Microsoft365ServiceAccounts、AzureServiceAccounts、CorpServiceAccounts。 |
| 策略类型 | BaseProtection、AppProtection、DataProtection、IdentityProtection、AttackSurfaceReduction、Compliance。 |
| 应用 | AllApps、O365（对于所有 Office 365 服务）、EXO（对于 Exchange Online）。 |
| 平台 | AnyPlatform、Unknown、WindowsPhone、macOS、iOS、Android。 |
| 授权控制 | Block、ADHJ、Compliant、Unmanaged（其中“非托管”为设备状态，可在设备状态条件中指定）。 |
| 说明 | 策略用途的可选说明。 |
编号方案
为了简化管理，建议使用此编号方案：
| 角色组 | 编号 |
|---|---|
| CA-Persona-Global | CA001-CA099 |
| CA-Persona-Admins | CA100-CA199 |
| CA-Persona-Internals | CA200-CA299 |
| CA-Persona-Externals | CA300-CA399 |
| CA-Persona-GuestUsers | CA400-CA499 |
| CA-Persona-GuestAdmins | CA500-CA599 |
| CA-Persona-M365ServiceAccounts | CA600-CA699 |
| CA-Persona-AzureServiceAccounts | CA700-CA799 |
| CA-Persona-CorpServiceAccounts | CA800-CA899 |
| CA-Persona-WorkloadIdentities | CA900-CA999 |
| CA-Persona-Developers | CA1000-CA1099 |
策略类型
以下是建议的策略类型：
| 策略类型 | 说明/示例 |
|---|---|
| BaseProtection | 对于每个角色，这种策略都提供基准保护。 对于托管设备上的用户，这通常是已知用户和已知设备。 对于外部来宾，可能是已知用户和多重身份验证。 对于所有应用来说基本保护是给定角色中用户的默认策略。 如果特定应用应使用不同策略，则从基本保护策略中排除该应用，并添加仅针对该应用的清晰策略。 示例：假设 Internals 的基本保护是对所有云应用要求使用已知用户和已知设备，但你想要允许从任何设备访问 Outlook 网页版。 可以从基本保护策略中排除 Exchange Online，并为要求已知设备或多重身份验证的 Exchange Online 添加单独的策略。 |
| 标识保护 | 在每个角色的基本保护之上，可以创建与标识相关的条件访问策略。 示例：阻止旧式身份验证，针对高用户或登录风险需要额外的多重身份验证，需要已知设备进行多重身份验证注册。 |
| DataProtection | 这种策略在基本保护之上另加一层保护，为数据保护引入更多策略。 示例：
|
| AppProtection | 这种策略是基本保护的又一补充。 示例：
|
| AttackSurfaceReduction | 这种策略旨在缓解各种攻击。 示例：
|
| 合规性 | 可以使用合规性策略要求用户查看针对访问客户服务的来宾的使用条款。 |
应用
下表描述了策略名称的应用部分：
| 应用程序名称 | 说明/示例 |
|---|---|
| AllApps | AllApps 表明条件访问策略中面向的是所有云应用。 涵盖所有终结点，包括支持条件访问和不支持条件访问的终结点。 某些情况下，无法实现面向所有应用。 我们建议在基本策略中面向所有应用，以便该策略涵盖所有终结点。 Microsoft Entra ID 中显示的新应用也将自动遵守该策略。 |
| <应用名称> | AppName 占位符指示策略所面向的应用的名称<>。 避免名称过长。 示例名称：
|
平台类型
下表描述了策略名称的平台部分：
| 平台类型 | 说明 |
|---|---|
| AnyPlatform | 策略面向任何平台。 通常选择“任何设备”来配置该策略。 （在条件访问策略中，“平台”和“设备”一词均有使用。） |
| iOS | 该策略面向 Apple iOS 平台。 |
| Android | 该策略面向 Google Android 平台。 |
| Windows | 此策略面向 Windows 平台。 |
| Linux | 此策略面向 Linux 平台。 |
| WindowsPhone | 该策略面向 Windows Phone 平台。 |
| macOS | 该策略面向 macOS 平台 |
| iOSAndroid | 该策略面向 iOS 和 Android 平台。 |
| 未知 | 该策略面向之前未列出的任何平台。 通常选择“任何设备”并排除所有个别平台来配置此策略。 |
授权控制类型
下表描述了策略名称的授权控制部分：
| 授权类型 | 说明/示例 |
|---|---|
| 阻止 | 策略阻止登录 |
| MFA | 该策略要求使用多重身份验证。 |
| 符合 | 该策略要求使用 Endpoint Manager 所确定的合规设备，因此设备需由 Endpoint Manager 进行管理。 |
| CompliantorAADHJ | 该策略要求使用合规的设备或已加入 Microsoft Entra 混合的设备。 加入域的标准公司计算机也加入了混合 Microsoft Entra ID。 共同管理的或已加入 Microsoft Entra 的手机和 Windows 10 计算机可以是合规的。 |
| CompliantandAADHJ | 该策略要求使用已加入 Microsoft Entra 混合的合规设备。 |
| MFAorCompliant | 该策略要求使用合规设备，或者如果设备不合规的话则需要进行多重身份验证。 |
| MFAandCompliant | 该策略要求使用合规设备并进行多重身份验证。 |
| MFAorAADHJ | 该策略要求使用已加入 Microsoft Entra 混合的计算机，或者如果没有加入混合 Microsoft Entra 混合的话则需要进行多重身份验证。 |
| MFAandAADHJ | 该策略要求使用已加入 Microsoft Entra 混合的计算机并进行多重身份验证。 |
| RequireApprovedClient | 此策略需要已批准的客户端应用。 |
| AppProtection | 此策略需要应用保护 |
| 非托管 | 该策略面向 Microsoft Entra ID 未知的设备。 例如，可以使用此授权类型来允许从任何设备访问 Exchange Online。 |
命名位置
建议定义以下标准位置，以便在条件访问策略中使用：
- 受信任的 IP/内部网络。 这些 IP 子网表示具有物理访问限制或其他控制的位置和网络，例如计算机系统管理、网络级身份验证或入侵检测。 这些位置更为安全，因此不必严格执行条件访问。 考虑 Azure 或其他数据中心位置 (IP) 是否应包含在此位置，还是应有自己的命名位置。
- Citrix 信任的 IP。 如果本地具有 Citrix，则需要能够从 Citrix 会话连接到云服务时，为 Citrix 场配置单独的传出 IPv4 地址可能会很有用。 这种情况下，如果需要，可以从条件访问策略中排除这些位置。
- Zscaler 位置（如适用）。 计算机安装了 ZPA 代理，并将所有流量转发到 Internet 或通过 Zscaler 云转发。 因此，有必要在条件访问中定义 Zscaler 源 IP，并要求所有来自非移动设备的请求通过 Zscaler。
- 允许业务的国家/地区。 可以将国家/地区划分为两个位置组：一个代表员工通常工作的区域，另一个代表其他位置。 这样，可以为源自组织正常运营区域外的请求应用其他控制。
- 难以或无法进行多重身份验证的位置。 某些情况下，要求多重身份验证可能会使员工难以工作。 例如，员工可能没有时间或机会响应频繁的多重身份验证质询。 或者在某些位置，RF 屏蔽或电气干扰使得难以使用移动设备。 通常，你会在这些位置使用其他控制，否则它们可能受信任。
基于位置的访问控制依赖于请求的源 IP 来确定请求时用户的位置。 在公共 Internet 上进行欺骗并不容易，但网络边界提供的保护可能不及之前那样有效。 不建议仅将位置条件作为访问的条件。 但对于某些情况，这可能是可以使用的最好控制，比如从非交互情况下所用本地服务帐户进行访问时提供保护。
建议的条件访问策略
我们创建了包含推荐条件访问策略的电子表格。 可以在此处下载电子表格。
从使用建议的策略开始。
策略可能会随时间而变化，以适应对业务至关重要的用例。 下面的一些示例方案可能需要更改：
- 根据多重身份验证、应用保护和批准的客户端应用，对使用任何非托管设备的员工提供对 Exchange Online 的只读访问权限。
- 实施信息保护，确保在 Azure 信息保护未提供更好保护的情况下不会下载敏感信息。
- 防止来宾进行复制和粘贴。
目前，多个预览版将进入公共预览版，因此希望尽快更新建议的一组条件访问 (CA) 入门策略。
条件访问指南
现在学习了一组入门条件访问策略，你需要有控制地分阶段部署它们。 建议使用部署模型。
下面是一种方法：
也就是首先将策略部署到一个角色组中的少数用户。 此部署可以使用名为 Persona Ring 0 的关联 Microsoft Entra 组。 验证一切正常工作后，可以更改组 Persona Ring 1，向其分配更多成员等等。
然后，使用同一基于环的方法启用策略，直到部署所有策略。
通常手动管理环 0 和环 1 的成员。 环 2 或环 3 包含成百上千甚至成千上万的用户，可以通过基于给定角色中用户百分比的动态组对它们进行管理。
将环用作部署模型的一部分，这不仅用于初始部署。 如果需要新策略或更改现有策略，也可以使用它。
完成部署后，还应设计和实现条件访问原则中讨论的监视控制。
除了自动执行初始部署之外，还可以使用 CI/CD 管道自动更改策略。 可以使用 Microsoft365DSC 实现自动更改。
作者
本文由 Microsoft 维护， 它最初是由以下贡献者撰写的。
主要作者：
- Claus Jespersen | ID&Sec 首席顾问
若要查看非公开领英个人资料，请登录领英。