4 min read
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?
Prepare to build policies
We recommend the following approach when planning your Zero Trust Network Access policies.
1. Determine your sources of truth
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 , the presence of a , or an API integration with a supported like Crowdstrike or SentinelOne.
2. Define your networks
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,
|Accessible by VPN?
|AWS US East - VA, USA
3. Define your applications
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.
|Accessible via IP?
|Static or dynamic IP?
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.
4. List existing policies
Gather any existing security policies or block lists that you wish to migrate from your VPN provider to Zero Trust.