你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
条件访问框架和策略
本文提供了实现基于角色的条件访问体系结构的框架，如 条件访问零信任体系结构中所述。 本文详细介绍了如何形成和命名条件访问策略。 还介绍了怎么开始创建策略。
如果不使用类似此处提供的框架（包括命名标准），则策略往往以临时方式由不同人员随时间推移创建。 这可能会导致策略重叠。 如果创建策略的人员不再可用，则其他人可能很难知道策略的目的。
遵循结构化框架可以更轻松地理解策略。 它还有利于涵盖所有方案，更容易避免难以进行故障排除的冲突策略。
命名约定
正确定义的命名约定可帮助你和同事了解策略的目的，这样可以更轻松地进行策略管理和故障排除。 命名约定应适合用于构建策略的框架。
建议的命名策略基于角色、策略类型和应用。 如下所示：
<CANumber>-<Persona>-<PolicyType>-<App>-<Platform>-<GrantControl>-<OptionalDescription>
此处介绍了此名称的组件：
| 命名组成部分 | 说明/示例 |
|---|---|
| CA 编号 | 用于快速识别策略类型范围和顺序。 示例：CA001-CA099。 |
| Persona | Global、Admins、Internals、Externals、GuestUsers、GuestAdmins、Microsoft365ServiceAccounts、AzureServiceAccounts、CorpServiceAccounts。 |
| 策略类型 | 基础保护、应用保护、数据保护、身份保护、攻击面减少、合规性。 |
| 应用程序 | 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 添加单独的策略，其中需要已知的设备或多重身份验证。 |
| 身份保护 | 在每个角色的基础保护之上，可以具有与身份相关的条件访问策略。 示例：阻止传统身份验证，对于高用户风险或登录风险，要求额外的多重身份验证，需要已知设备进行多重身份验证注册。 |
| 数据保护 | 此策略类型指示在基本保护之上作为额外层保护数据的增量策略。 例子：
|
| AppProtection | 此策略类型是基本保护的另一个补充。 例子：
|
| AttackSurfaceReduction | 这种类型的策略的目的是缓解各种攻击。 例子：
|
| 合规 | 可以使用合规性策略来要求用户查看访问客户服务的来宾的使用条款。 |
应用程序
下表描述了策略名称的App组件：
| 应用名称 | 说明/示例 |
|---|---|
| AllApps | AllApps 指示所有云应用都以条件访问策略为目标。 涵盖所有终结点，包括支持条件访问的终结点和不支持的终结点。 在某些情况下，针对所有应用程序效果不佳。 建议针对基本策略中的所有应用，以便该策略涵盖所有终结点。 Microsoft Entra ID 中显示的新应用也将自动遵守策略。 |
| <AppName> | <AppName> 是一个用于标明政策所涉及的应用名称的占位符。 避免名称过长。 示例名称：
|
平台类型
下表描述了策略名称的平台组件：
| 平台类型 | 描述 |
|---|---|
| AnyPlatform | 该策略面向任何平台。 通常选择任何设备来配置此策略。 （在条件访问策略中，平台和设备一词均有使用。） |
| iOS | 该策略面向 Apple iOS 平台。 |
| 安卓 | 该策略面向 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 | 该策略需要合规的设备 AND 多重身份验证。 |
| 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 来确定请求时用户的位置。 在公共互联网中实施欺骗攻击并不容易，但网络边界提供的保护可能不如过去重要。 我们不建议仅依赖位置作为访问条件。 对于某些情况下，它可能是您可以使用的最佳控制措施，例如，如果您需要在非交互式场景中保护来自本地服务帐户的访问。
建议的条件访问策略
我们创建了一个包含建议的条件访问策略的电子表格。 可以在此处下载电子表格。
使用建议的策略作为起点。
策略可能会随时间而变化，以适应对你的业务很重要的用例。 下面是可能需要更改的一些方案示例：
- 针对使用任何非托管设备的员工实现对 Exchange Online 的只读访问权限，具体取决于多重身份验证、应用保护和批准的客户端应用。
- 实施信息保护，以确保在没有 Azure 信息保护提供的改进保护之前，敏感信息不会被下载。
- 为来宾提供防止复制和粘贴的保护。
目前，多个预览版正进入公开预览阶段，预计很快会更新建议的一组条件访问（CA）入门策略。
条件访问指南
有了一组初学者条件访问策略后，需要以受控和分阶段的方式部署它们。 建议使用部署模型。
下面是一种方法：
展示条件访问部署模型的示意图。
其思路是首先将策略部署到一个角色组中的少数用户。 可以使用名为 Persona Ring 0 的关联Microsoft Entra 组进行此部署。 验证所有功能正常后，将任务分配更改为一个名为Persona Ring 1的组，该组拥有更多成员，以此类推。
然后，使用相同的基于环的方法启用策略，直到部署所有策略。
通常手动管理圈 0 和圈 1 的成员。 环 2 或环 3 包含成百上千甚至成千上万的用户，可以通过基于给定角色中用户百分比的动态组对它们进行管理。
将环用作部署模型的一部分不局限于初始部署。 如果需要新策略或更改现有策略，也可以使用它。
完成部署后，还应设计和实现 条件访问原则中讨论的监视控件。
除了自动执行初始部署之外，你可能还希望使用 CI/CD 管道自动更改策略。 可以将 Microsoft365DSC 用于此自动化。
贡献者
本文由Microsoft维护。 它最初由以下参与者编写。
主要作者
- 克劳斯·杰斯珀森 |首席顾问 ID&Sec
若要查看非公开的LinkedIn个人资料，请登录LinkedIn。