在本文中，你将了解基于零信任的条件访问方案的设计原则和依赖项。
设计原则
我们将从一些设计原则开始。
将条件访问作为零信任策略引擎
零信任Microsoft方法包括条件访问作为主策略引擎。 下面是此方法的概述：
提供零信任模型的概述的 
条件访问用作零信任体系结构的策略引擎，该体系结构涵盖策略定义和策略强制执行。 根据各种信号或条件，条件访问可以阻止或授予对资源的有限访问权限，如下所示：
下面是条件访问元素及其涵盖的内容的更详细视图：
此图显示了条件访问和相关元素，这些元素可帮助保护用户对资源的访问，而不是非交互式或非人工访问。 下图描述了这两种类型的标识。
条件访问主要侧重于保护从交互式人类到资源的访问。 随着非人类身份的数量的增长，还必须考虑从这些身份访问。 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 AlwaysOn VPN、Cisco AnyConnect、Palo Alto Networks、F5、Fortinet、Citrix 和 Zscaler 等解决方案。
- 文档、电子邮件和其他文件：通过Microsoft信息保护。
- SaaS 应用程序。
- 在其他云（如 AWS 或 Google Cloud）中运行的应用程序（基于联合身份验证）。
零信任原则
Microsoft定义的三个主要零信任原则似乎可以理解，尤其是安全部门。 但是，在设计零信任解决方案的过程中，有时忽略可用性的重要性。
可用性应始终被视为隐式原则。
条件访问原则
根据上述信息，下面是建议原则的摘要。 Microsoft建议根据符合三个主要Microsoft零信任原则的条件访问创建访问模型：
显式验证
- 将控制平面移动到云中。 将应用与 Microsoft Entra ID 集成，并使用条件访问对其进行保护。
- 将所有客户端视为外部客户端。
使用最低特权访问
- 根据合规性和设备风险评估访问权限，包括用户风险、登录风险和设备风险。
- 使用以下访问优先级：
- 使用条件访问直接访问资源进行保护。
- 使用Microsoft Entra 应用程序代理（使用条件访问进行保护）发布对资源的访问权限。
- 使用基于条件访问的 VPN 访问资源。 限制对应用或 DNS 名称级别的访问。
假设违反
- 分段网络基础结构。
- 最大程度地减少企业 PKI 的使用。
- 将单一登录（SSO）从 AD FS 迁移到密码哈希同步（PHS）。
- 在 entra ID Microsoft 中使用 Kerberos KDC 最大程度地减少对 DC 的依赖项。
- 将管理平面移动到云。 使用 Microsoft Endpoint Manager 管理设备。
下面是条件访问的一些更详细原则和建议的做法：
- 将零信任原则应用于条件访问。
- 在将策略放入生产环境之前，请使用仅限报表模式。
- 测试正面和负面方案。
- 对条件访问策略使用更改和修订控制。
- 使用 Azure DevOps/GitHub 或 Azure 逻辑应用等工具自动管理条件访问策略。
- 仅当需要和需要访问时，才使用阻止模式进行常规访问。
- 确保所有应用程序和平台都受到保护。 条件访问没有隐式的“拒绝全部”。
- 保护所有Microsoft 365 基于角色的访问控制 （RBAC） 系统中的特权用户。
- 要求对高风险用户和登录进行密码更改和多重身份验证（通过登录频率强制实施）。
- 限制来自高风险设备的访问。 在条件访问中使用具有符合性检查的 Intune 符合性策略。
- 保护特权系统，例如访问 Office 365、Azure、AWS 和 Google Cloud 的管理员门户。
- 防止管理员和不受信任的设备上的持久浏览器会话。
- 阻止旧式身份验证。
- 限制来自未知或不受支持的设备平台的访问。
- 如果可能，需要合规设备才能访问资源。
- 限制强凭据注册。
- 请考虑使用默认会话策略，如果中断之前满足适当的条件，则允许会话继续。
设计依赖项和相关技术
下图显示了依赖项和相关技术。 某些技术是条件访问的先决条件。 其他依赖于条件访问。 本文档中所述的设计主要侧重于条件访问，而不是相关技术。
显示条件访问依赖项的 
条件访问指南
贡献
本文由Microsoft维护。 它最初由以下参与者编写。
主体作者：
- 克劳斯·杰斯珀森 |首席顾问 ID&秒
若要查看非公共LinkedIn配置文件，请登录到LinkedIn。