ZT, ZTN, ZTNA, Oh my! (and some other things)

Hello! I’m back with another installment in a series of posts around zero-trust network access. I’ll explain some more of the architectural components (in general) and touch on the difference between the ZT, ZTN, and ZTNA nomenclatures.

So – What is the difference between ZT, ZTN, and ZTNA? Well, Zero Trust is a set of principles such as least privilege, (micro) segmentation, and machine/user identity that ZTN (Zero Trust Networks) and ZTNA (Zero Trust Network Access) build on. Depending on who you are Gartner and NIST go into great detail on ZT and ZTNA. In addition, a variety of vendors have several posts on their position or take on zero-trust and what it means to them.

As far as ZTNA goes – Zero Trust has been coupled with Zero Trust Network Access to make traditional VPN redundant in terms of remote access for the private access to your applications, where ever they are. Thinking of it another way ZTNA includes ZT and has some varying degrees of features with it that are more or less enabled by the fact that you no longer need to define a perimeter for your VPN solution. At this time I think ZTN and ZTNA are used interchangeably, though you can apply zero trust principles on networks in general for ZTN and I think that ZTNA is mostly focused on remote access to applications.

Perimeter-less remote-access solution

The idea of ZTNA is the absence of traditional VPN connectivity without sacrificing the security of the entire enterprise. In fact, one could say it’s saving the enterprise from further exploitation. Notice I didn’t say the absence of tunneling technology. The user experience is the same whether inside or outside of the corporate network. Furthermore, Depending on the architecture users connect more directly to the application you’re hosting instead of a branch and/or HQ/Data Center which may be sub-optimal. This is especially true in cases where there are global enterprises. I know I am not the only one who’s seen infrastructure built such that end-users somewhere in Asia have to connect to a hub or spoke somewhere in the US or EU (or the reverse). Not only that, remote access configurations which are typically ‘full tunnel’ VPN. The five most often referenced cons for full-tunnel VPN are:

1. Snare the SaaS-based traffic
2. Direct regular internet traffic to the HQ/branch/DC
3. Prevent local access to needed resources
4. Increased costs and usage for all that traffic traversing the network
5. Having to deal with/think about the client in any way

Moving further, ZTNA it is the complete lack of network-definition in tunnel connectivity that is at the heart of zero-trust network access infrastructure. Technically, split-tunnel happens, but it is at the application level. This generally means packet filtering or host-routes on the end-point. Each application is defined and assigned to users. They are either permitted or excluded from the use of these applications through authentication of the device already so why would you then create an underlay of a network-defined tunnel at all? Doing so is redundant. Even if a service offers a subnet-level definition of the network tunnel customers can easily (and do) define all of the RFC 1918 space in such a configuration to quickly and easily define private space where none is missed. In the end, this is just de-facto full tunnel configuration which negates all of the benefits of a ZTNA service that allows a more direct, but secure access to public and private applications without changing the experience.

But wait, there’s more!

There is one thing I haven’t touched on yet. I bet you’re thinking about your existing investment in all those firewalls all over your enterprise and in your cloud providers right? How do you connect those? What if you want to use them and this service? Well, you can! Migration paths are easy, but here is the nice part. Your firewalls go back to being…firewalls! not Firewalls and VPN concentrators and on and on. Poking holes in your firewalls to allow some of these applications outside of VPN also, potentially, is no longer needed as well.

Look Ma no policy engine

I’m just kidding, of course, there is a policy engine. But when you take a look at a ZTNA service there is little in the way of a policy engine that’s trying to win a drag race. Policy is very simple and relies heavily on your identify provider (IdP) of choice and the MFA/SSO mechanisms you configure. For instance, in a very simplified ZTNA architecture, once you have defined the application and who can access it, under some conditions access can be granted by simply using your Google account as the IdP and you’re in provided you pass.

Tunneling protocols

We can no doubt talk about tunneling protocols and the religion of such all day or several days. However, I do like the simplicity in TLS/DTLS vs IPSec tunnels. I won’t go into why, but I can tell you that almost any ZTNA architecture today is TLS/DTLS based. They are arguably easier to work with and manage than IPsec. Integration into web browsers is easier as well in terms of ZTNA architecture. There are a couple of exceptions to this were some vendors are using wireguard tunnels quite successfully in their service.

The main ZTNA parts that make up the whole

We have a few choices! Each of those choices takes the zero-trust principles and adds their flavor to it to fit a variety of target use cases that are more comfortable to enterprise customers. Below I am showing you the general architectures that you’ll run into. If you’re wondering what an SDP is below it’s called a Software Defined Perimeter. Think of it another way this is where the TLS/DTLS tunnel generally terminates and it is where enforcement happens. These are usually multi-tenant systems that are closest to the end-point, and if there is a connector, closest to the connector.

In general, there are three main parts to the architecture:

1. You have a client, hopefully, lightweight and non-intrusive. In fact, you shouldn’t have to think about this client at all. 
2. You have the SDP/Enforcement node(s)/proxy
3. You have a connector that is also a reverse proxy of some kind. The connectivity for this is ‘inside-out’ meaning that it calls home. The effect is that your applications are invisible from the public internet. Why is this important? Attack surface. You don’t have to make any ACL exceptions to host this.

Some variations of this model are as follows:

ZTNA Architecture 1 – Client + Connector + SDP

• End-point client – a lightweight, probably centrally managed
• Connector – Usually a reverse proxy VM that is deployed inside the data center or IaaS
• SDP – Software Defined Perimeter – and enforcement node that handles authentication, proxying of traffic, stitching of tunnels

ZTNA Architecture 2 – Clientless + Connector + SDP

• No client on the end-point. Traffic acquisition handled in a variety of ways such as DNS/CNAME
• SDP – Software Defined Perimeter – Honestly, the SDP/proxy/enforcement node is a pillar of any ZTNA service so I expect to always see this (and so far do)
• Connector VM or connector process. There are two flavors here which are either a full VM or a service/process, that is installed on the application server to run proxy for it. Either way, these connectors call home to the service. So again no ACL changes are needed for this.
• Could be a great ’third-party access’ use case

ZTNA Architecture 3 – No connector and no client, yes has an SDP

• No client or at most some integration into a browser
• No connector – Access to private applications can be handled by very limited exposure. When the SDP proxies the private access traffic the source IP is generally the service provider’s IP. ACL changes only within a specified IP range of the provider. Still invisible to everyone else on the public internet.
• SDP still exists, handles traffic acquisition enforcement, authentication
• Could be a great ’third party access’ use case

There are so many great use cases for ZTNA, but probably the most exciting one is the third-party or B2B use case. I’m going to save this part for another post, but imagine giving a third-party or a B2B process where you didn’t have to worry about setting up lots of vpn config, ensuring that you’re secure, or since most people I have worked with don’t want to or can’t risk offering it all, are able to do so in a secure way that doesn’t put them on your corporate network. You know what I just realized that I haven’t even gotten into how RBI (Remote Browser Isolation) can be combined with these services for enhanced third party access. So I’ll talk a little bit about how that looks as well.

If you have questions reach out! I love talking about the transformation of remote access. Effortless use, better security.

Hank