Policy design

  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.

​​ Considerations

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

​​ Identity

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 groups are being passed from your identity provider to Gateway.

​​ Device posture

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.

​​ 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,

​​ 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.

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.