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