本文将介绍基于零信任的条件访问方案的设计原则和依赖项。
设计原理
我们将从一些设计原则开始。
条件访问作为零信任策略引擎
Microsoft 的零信任方法包括作为主要策略引擎的条件访问。 下面是此方法的概述：
下载此体系结构的 SVG 文件。
条件访问用作涵盖策略定义和策略强制实施的零信任体系结构的策略引擎。 根据各种信号或条件，条件访问可以阻止或提供对资源的有限访问权限，如下所示：
以下是条件访问元素及其涵盖内容的更为详细的视图：
此图显示了条件访问和相关元素，这些元素有助于保护用户对资源的访问，避免非交互式或非人工访问。 下图描述了两种标识类型。
条件访问主要侧重于保护人类对资源的交互访问。 随着非人类标识数量的增长，还必须考虑这些标识的访问。 Microsoft 提供了两项与保护工作负载标识的访问和被访问相关的功能。
- 保护对由工作负载标识表示的应用程序的访问，该标识在 Microsoft Entra 条件访问门户中不可选择。 使用安全属性支持此选项。 将安全属性分配给工作负载标识并在 Microsoft Entra 条件访问门户中选择这些标识是 Microsoft Entra ID P1 许可证的一部分。
- 保护对由工作负载标识（服务主体）启动的资源的访问。 支持此应用场景的单独许可证中提供了新功能“Microsoft Entra Workload Identities”。 该功能涵盖工作负载标识的生命周期管理，其中包括使用条件访问保护对资源的访问。
企业访问模型
Microsoft 之前提供了基于分层模型访问本地资源的指南和原则：
- 第 0 层：域控制器、公钥基础结构 (PKI)、Active Directory 联合身份验证服务 (AD FS) 服务器和管理这些服务器的管理解决方案
- 第 1 层：托管应用程序的服务器
- 第 2 层：客户端设备
此模型仍适用于本地资源。 为了帮助保护对云中资源的访问，Microsoft 建议采用以下访问控制策略：
- 完整统一。
- 在整个技术堆栈中严格应用安全原则。
- 足够灵活，可满足组织的需求。
基于这些原则，Microsoft 创建了以下企业访问模型：
企业访问模型将替代旧的层模型，后者侧重于控制本地 Windows Server Active Directory 环境中未经授权的特权升级。 在新模型中，第 0 层扩展为控制平面，第 1 层由管理和数据平面组成，第 2 层涵盖用户和应用访问。
Microsoft 建议将控制和管理转移到使用条件访问作为主要控制平面和策略引擎的云服务中，从而定义和强制执行访问。
可将 Microsoft Entra 条件访问策略引擎扩展到其他策略实施点，包括：
- 新式应用程序：用新式身份验证协议的应用程序。
- 旧版应用程序：通过 Microsoft Entra 应用程序代理。
- VPN 和远程访问解决方案：Microsoft Always On VPN、Cisco AnyConnect、Palo Alto Networks、F5、Fortinet、Citrix 和 Zscaler 等解决方案。
- 文档、电子邮件和其他文件：通过 Microsoft 信息保护。
- SaaS 应用程序。
- 运行在其他云中的应用程序，如 AWS 或 Google Cloud（基于联合）。
零信任原则
人们似乎已经了解 Microsoft 定义的三个主要零信任原则（安全部门尤为了解）。 但在设计零信任解决方案时，有时会忽略可用性的重要性。
应始终将可用性被视为隐式原则。
条件访问原则
根据上述信息，以下总结了建议的原则。 Microsoft 建议根据符合三个主要 Microsoft 零信任原则的条件访问创建访问模型：
显式验证
- 将控制平面移至云。 将应用与 Microsoft Entra 集成并使用条件访问保护它们。
- 将所有客户端视为外部客户端。
使用最低特权访问
- 根据合规性和风险（包括用户风险、登录风险和设备风险）评估访问权限。
- 使用以下访问优先级：
- 直接访问资源，使用条件访问进行保护。
- 使用 Microsoft Entra 应用程序代理发布资源访问权限，使用条件访问对其进行保护。
- 使用基于条件访问的 VPN 访问资源。 限制对应用或 DNS 名称级别的访问。
假定数据泄露
- 将网络基础设施分段。
- 最大程度地减少企业 PKI 的使用。
- 将单一登录 (SSO) 从 AD FS 迁移到密码哈希同步 (PHS)。
- 通过在 Microsoft Entra ID 中使用 Kerberos KDC，最大程度减少对 DC 的依赖。
- 将管理平面移至云。 使用 Microsoft Endpoint Manager 管理设备。
以下是有关条件访问的一些更为详细的原则和推荐做法：
- 将零信任原则应用于条件访问。
- 在将策略运用于生产环境之前，请使用仅限报告模式。
- 测试积极和消极场景。
- 对条件访问策略使用更改和修订控制。
- 使用 Azure DevOps/GitHub 或 Azure 逻辑应用等工具自动管理条件访问策略。
- 仅在需要访问时才使用阻止模式进行常规访问。
- 确保所有应用程序和平台都受到保护。 条件访问没有隐式“全部拒绝”。
- 保护所有 Microsoft 365 基于角色的访问控制 (RBAC) 系统中的特权用户。
- 对于高风险用户和登录，要求更改密码和进行多重身份验证（通过登录频率强制执行）。
- 限制从高风险设备进行访问。 在条件访问中配合使用 Intune 合规性策略和合规性检查。
- 保护特权系统，例如访问 Office 365、Azure、AWS 和 Google Cloud 的管理员门户。
- 防止管理员和不受信任的设备上出现持久浏览器会话。
- 阻止旧式身份验证。
- 限制从未知或不支持的设备平台进行访问。
- 如果可能，需要符合要求的设备才能访问资源。
- 限制强凭据注册。
- 考虑使用在发生故障时支持继续进行会话（前提是在故障发生前满足适当条件）的默认会话策略。
设计依赖项和相关技术
下图显示了依赖项和相关技术。 其中某些技术是条件访问的先决条件。 其他技术依赖于条件访问。 本文档中所述的设计主要侧重于条件访问，而不是相关技术。
条件访问指南
有关详细信息，请参阅基于零信任和角色的条件访问设计。
作者
本文由 Microsoft 维护， 它最初是由以下贡献者撰写的。
主要作者：
- Claus Jespersen | ID&Sec 首席顾问
若要查看非公开领英个人资料，请登录领英。