使条件访问和零信任保持一致
我们将从一些设计原则开始。
条件访问作为零信任策略引擎
Microsoft 的零信任方法包括作为主要策略引擎的条件访问。 下面是此方法的概述：
下载此体系结构的 SVG 文件。
条件访问用作涵盖策略定义和策略强制实施的零信任体系结构的策略引擎。 根据各种信号或条件，条件访问可以阻止或提供对资源的有限访问权限，如下所示：
以下是条件访问元素及其涵盖内容的更为详细的视图：
此图显示了条件访问和相关元素，这些元素有助于保护用户对资源的访问，避免非交互式或非人工访问。 下图描述了两种标识类型：
对资源的非人工访问也必须受到保护。 目前，无法使用条件访问来保护对云资源的非人工访问。 需要使用另一种方法，例如基于 OAuth 的访问权限的授予控制。
条件访问原则与零信任原则
根据上述信息，以下总结了建议的原则。 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 的管理员门户。
- 防止管理员和不受信任的设备上出现持久浏览器会话。
- 阻止旧式身份验证。
- 限制从未知或不支持的设备平台进行访问。
- 如果可能，需要符合要求的设备才能访问资源。
- 限制强凭据注册。
- 考虑使用在发生故障时支持继续进行会话（前提是在故障发生前满足适当条件）的默认会话策略。