大多数私有网络访问策略的构建都在 Gateway DNS 和 Gateway Network 策略生成器内完成。在很大程度上，客户使用 DNS 解析、SNI 主机名值和 IP 地址分组的混合组合作为定义特定应用程序相关策略的基线。
在构建策略之前，自问以下几个问题大有裨益：
- 所有用户和服务是否都应该能够访问所有连接的子网？是否存在明确的例外情况？
- 所有应用程序是否都位于主网络范围内，且由静态或动态主机和 IP 地址定义？
- 是否存在依赖完全临时 IP 或子域名的 DevOps 工作流？
- 你是否拥有将在策略中使用的身份和设备姿态的单一事实来源（Source of truth）？
- 你是否计划立即实施默认拒绝（default-deny）模型？换句话说，你是否会阻断除匹配明确 Allow 策略的用户之外的所有用户？
在规划 Zero Trust Network Access 策略时，我们建议采取以下方法。
确定你将使用哪个身份提供者作为用户电子邮件、用户组和其他基于身份的属性的单一事实来源。
如果你计划根据组成员身份授予对服务的访问权限，请查看用户注册表并验证目标用户在其用户注册表中是否具有该组值。
大多数客户还会构建依赖于企业设备使用的策略。例如，企业设备上的所有用户都可以访问 *.jira.internal.com，但个人设备上的用户只能访问 dev.internal.jira.com。为了使该策略生效，我们建议为你的企业设备定义一个单一事实来源。这有时是存在特定的已签发证书、存在具有匹配哈希值的进程，或者是与受支持的第三方终端安全提供者（如 Crowdstrike 或 SentinelOne）进行 API 集成。
几乎所有企业都拥有一系列物理或虚拟的互连网络。准备一份用户当前在本地或使用 VPN 时访问的所有相关网络、子网或分段的列表。例如，
| 网络名称 | 位置 | IP 范围 | 可通过 VPN 访问？ |
|---|---|---|---|
| Corporate DC | AWS US East - VA, USA | 10.0.0.0/8 |
是 |
接下来，准备网络上所有将具有不同策略要求（例如不同的用户身份或设备姿态要求）的相关内部应用程序列表。每个应用程序应由 IP 列表、主机名/域名列表或两者兼有来定义。
| 应用程序名称 | 本地 IP | 主机名 | 可通过 IP 访问？ | 静态或动态 IP？ |
|---|---|---|---|---|
| Company Wiki | 10.128.0.10 |
wiki.internal.com |
是 | 静态 |
例如，你可能在 a.internal.com 有一个应用程序，它指向一个具有静态 IP 地址的负载均衡器，并在 a.internal.com 上平衡一系列提供该应用程序的动态主机。由于应用程序主机的 IP 是动态的，最佳实践是构建两条策略：一条针对负载均衡器 IP 的网络策略，以及一条针对应用程序主机名的 DNS 策略。
另一方面，如果负载均衡器后面的 IP 是静态或半动态的，则直接在网络策略中使用应用程序 IP 可能是合理的。你可以在基础设施提供程序中更改主机时，构建一个通过 Cloudflare API 调用更新应用程序 IP 列表的工作流。
收集你希望从 VPN 提供商迁移到 Zero Trust 的任何现有安全策略或拦截列表。