Zero Trust Network Topology and Why It Matters

We consider enterprise architecture to be broad in scope, including applications, access methods and data flows, as well as the underlying network infrastructure and network topology. We define network topology to be a logical view of devices and systems and how they are connected to one another. Enterprise networks are usually complex, with many interdependent parts, such as DNS, IP address management and routing across LAN, WAN, cloud and SD-WAN segments. It can also involve newer types of networks, especially IaaS environments.

A Zero Trust Network Access (ZTNA) project requires that you have a good understanding of your network; where private enterprise resources are running; what is connected to what (i.e., its topology); and how these interdependent systems work. ZTNA requires thoughtful changes to how users access resources across the network, as well as changes to the network itself. The benefits of ZTNA are substantial, but it does need to be deployed against a well-crafted strategy.

What are the two primary Zero Trust network topology models?

There are two primary models for Zero Trust network topology, which we call cloud-routed and direct-routed. Gartner refers to these as service-initiated and endpoint-initiated, while other analysts use the terms software-defined perimeter and identity-aware proxies. These are depicted in the diagrams below, where we’re using the standard Zero Trust terms of Policy Decision Point (PDP) to represent the control plane and Policy Enforcement Point (PEP) to represent the data plane. Also note that for this discussion, we’re just focused on user access to private enterprise resources. We’re not looking at user access to public web resources.

In both cases, the control plane resides in the vendor’s security cloud infrastructure. This is how vendors deliver this as a service, providing management, monitoring and upgrades for customers, thus simplifying operations and reducing complexity.

Cloud-routed vs. direct-routed network topology models

In the cloud-routed model, the vendor cloud acts a centralized place where connections “meet in the middle.” Remote users connect to the nearest vendor PEP for control of their network access to private enterprise resources. Resources, which may be business applications or data, can be running in an on-premises data center, an IaaS cloud environment or both. The vendor’s connector software runs beside the resources and establishes an outbound connection to the closest PEP in the vendor cloud. Since the connector makes an outbound connection, it typically simplifies deployment, but often limits use cases to remote user access for Web apps only.

Implications of the cloud-routed model are that all user traffic must traverse the vendor cloud, potentially across multiple hops as the user and enterprise resource connect to different vendor PEPs. This adds latency and requires the enterprise to trust the vendor with this traffic. It also makes cloud-routed architecture unsuitable for on-premises users accessing local resources. In this case, user traffic routes up through the vendor cloud and back down to the user’s location, which is why this model is often only used for remote access, not for universal access. (To be fair, some vendors utilizing this approach have added local routing for on-premises users to avoid this problem). Another disadvantage is the inability to support all network protocols or server-initiated connections. It can handle web applications, but struggles with applications that need other TCP protocols, UDP or ICMP, or need a connection initiated to a user device such as with VOIP or IT remote control software.

Let’s compare this to the direct-routed model. With this architecture, the vendor cloud is only used as a control plane. The data plane is never visible to, or accessible by, the vendor because enterprises deploy the vendor PEPs into their environments to run alongside their resources. Once authenticated, users obtain a security token that allows them to securely establish connections directly to the PEPs—hence the direct-routed name. Network traffic flows between the user device and the resource via the PEP. This minimizes network hops and reduces latency. Also, traffic routing is under control of the enterprise, allowing it to manage data residency requirements, for example.

The direct-routed model supports all network protocols (web, non-web, any TCP, UDP and ICMP) and handles server-initiated connections seamlessly. It also supports the universal ZTNA concept because on-premises users accessing local resources will have their network traffic remain entirely within the local enterprise network. Because the PEP needs to be deployed where the resources live, some firewall changes are usually required. This architecture is more suited to support the most complex and sophisticated enterprise environments.

Why Appgate?

At Appgate, we are strong believers in universal ZTNA and customer choice. As such, we’ve architected our cloud-native, cloud-delivered Zero Trust platform for the direct-routed model, and to support all network protocols and connection types. This allows our customers to define holistic access policies applicable for all users on all devices, across all enterprise networks and environments. And we embrace the fact that some users can have an agent running on their device, while others cannot.

Enterprise security is hard—networks are complex, applications and requirements are constantly changing, and business demands often conflict with compliance and security needs. We believe that Zero Trust access is a better way to achieve your security and business goals and that you need an architecture that supports you, rather than constrains you.

To that end, Appgate SDP, the industry’s most comprehensive ZTNA solution, is a powerful, immensely flexible solution that can be configured to meet your exact security and compliance requirements regardless of network topology or complexity. The five pillars that underpin Appgate SDP’s system design are:

• Cloaked infrastructure
• Identity-centric
• Dynamic and continuous
• Microperimeters
• Progammable and adaptable

These pillars ensure that enterprise customers can deploy a Zero Trust platform that’s secure, adaptive and effective, and which takes advantage of all the benefits of a direct-routed model.

Additional ZTNA resources

Blog: The Operational and Business Benefits of Appgate’s Zero Trust Platform
Video: 8 Key Concepts that Underpin Appgate SDP’s Design
Blog: Universal ZTNA: Zero Trust Network Access Anywhere Comes of Age
Data sheet: Appgate’s Zero Trust platform overview