Policy design
Most policy building for private network access happens within the Gateway DNS and Gateway Network policy builders. For the most part, customers use a mixture of DNS resolution, SNI hostname values, and IP address groupings as the baseline for defining policies that pertain to specific applications.
Before building your policies, it is helpful to ask yourself a few questions:
- Should all users and services be able to reach all connected subnets? Are there explicit exceptions?
- Do all applications live within a primary network range, and are they defined by static or dynamic hosts and IP addresses?
- Are there DevOps workflows that rely on completely ephemeral IPs or subdomains?
- Do you have sources of truth for identity and device posture that will be used in policies?
- Do you plan to immediately implement a default-deny model? In other words, will you block all users except for those who match an explicit Allow policy?
We recommend the following approach when planning your Zero Trust Network Access policies.
Determine which identity provider you will use as the source of truth for user email, user groups, and other identity-based attributes.
If you plan to grant access to services based on group membership, view the user registry and verify that the target users have that group value in their User Registry.
Most customers will also build policies that are contingent on the use of a corporate device. For example, all users on corporate devices can access *.jira.internal.com, but users on personal devices can only access dev.internal.jira.com. In order for this to be effective, we recommend defining a source of truth for your corporate devices. This is sometimes the presence of a specific issued certificate, the presence of a process with a matched hash, or an API integration with a supported thirty-party endpoint security provider like Crowdstrike or SentinelOne.
Almost all businesses have a series of interconnected networks, either physical or virtual. Prepare a list of all relevant networks, subnets, or segments within your network that users currently access, either locally or when using the VPN. For example,
| Network name | Location | IP range | Accessible by VPN? |
|---|---|---|---|
| Corporate DC | AWS US East - VA, USA | 10.0.0.0/8 | Yes |
Next, prepare a list of all relevant internal applications on your networks that will have distinct policy requirements (for example, different user identity or device posture requirements). Each application should be defined by an IP list, a hostname/domain list, or sometimes both.
| Application name | Local IPs | Hostnames | Accessible via IP? | Static or dynamic IP? |
|---|---|---|---|---|
| Company Wiki | 10.128.0.10 | wiki.internal.com | Yes | Static |
For example, you may have an application at a.internal.com which points to a load balancer with a static IP address, balancing a series of dynamic hosts serving the application on a.internal.com. Because the IPs of the application hosts are dynamic, the best practice would be to build two policies: a network policy for the load balancer IP, and a DNS policy for the application hostnames.
On the other hand, if the IPs behind the load balancer are static or only semi-dynamic, it may make sense to directly use the application IPs in your network policy. You can build a workflow to update the application IP list via a Cloudflare API call whenever host changes are made in your infrastructure provider.
Gather any existing security policies or block lists that you wish to migrate from your VPN provider to Zero Trust.