I know it has been a while, but that’s what happens when your work is very interesting! So I’m back to talk a little more about ZTNA and remote access architectures.
One of the most misunderstood parts of ZTNA is the comparison between traditional VPN deployments and ZTNA services from authentication and what it provides the end-user. From a user standpoint, there may not seem like there’s much difference. Aside from the fact that you have to mess with an app and turn all these knobs and can’t reach your local systems. This is particularly true for administrators and anyone who deploys these solutions. When I talk about VPN or traditional VPN I’m not necessarily talking about the tunneling technologies themselves but the remote access infrastructure that we generally call “VPN” as a product group. So in this post, I’m going to break it down a bit more to help people understand why it matters. I’ll focus on authentication but get into some other areas around it. I’m going to take some liberties here and not be perfectly exact with everything here because I’m just trying to paint an overview picture to make a specific point.
A simplified view of traditional VPN
In traditional VPN the end-user has some client (that isn’t a browser). The client has the capability of standing up a tunnel whether that be IPSec, TLS, or some other tunneling technology. There are some knobs in there to play with, maybe they have to select where you would like to connect. See statistics or other information. Maybe they just get to hit connect and they authenticate. They have a device, maybe a firewall, maybe something else acting as a “VPN Concentrator.”
When the end-user connects to their company VPN they authenticate for the service, the tunnel, generally, a ‘full tunnel’ meaning all of your traffic no matter what it is heads for the VPN endpoint in Company XYZ. Once authenticated they’re an entitled part of the corporate network. They have an IP address provided by corporate infrastructure that is part of the network infrastructure’s IP address plan. If the end-user were to perform some port scan they would discover that they can likely reach and get a response to many hosts on Company XYZ’s network. Through policy and access control the administrator can restrict this in some ways but the fact is that the user is part of the network as if they were on-site. In earlier days we thought this was great! Employees connected as if they’re really there! People also like this because there is easy visibility into what an end-user is doing and how they’re using resources.
Not only can adding/moving/changing policy and access control be arduous and time-consuming we often forget to remove temporary access. Soon the Firewall or VPN endpoint is loaded up with unnecessary config. Wait until you move devices and you have to move all of that over because it’s too much time to walk through and figure out what’s in use and what’s not. Now multiply that across all of the VPN Endpoints/firewalls you manage.
In short, the end-user is part of the same network infrastructure that the applications are generally.
ZTNA/SDP-based remote access models
In this model, there is usually a client as well, though not always thanks to client-less (browser-based) options. However, because these services are a centrally managed cloud service (with few exceptions) the clients have a much lighter weight feel to them. There are virtually no options for the end-user to mess with and they don’t generally have to select the location they need to connect to. This is greatly reduced friction on the end-users part. Plus, because these architectures are usually cloud-hosted the termination is in the vendor of your choice instead of a device you manage.
Though there is some variation between product authentication in a full-client model is something a bit different than traditional VPN. When an end-user authenticates to the service instead of just the service they also authenticate for the entitlement of the applications that have been defined. What I mean is, that an administrator has assigned some applications (here referred to as ) to reach. Once the user finishes logging in they have authenticated to a service that has no Layer 3 defined on it and is generally not full-tunnel at all. I struggle to call this “split tunneling” but it seems to resonate with people. Anyway, The end-user is entitled to access App1 so a route (or packet filter) is installed on the end-point device. Now we have a tunnel of some kind that only allows a flow to/from App1. In some architectures, each tunnel may have a TLS (or other) tunnel of its own for proper micro-segmentation.
At this point, if an end-user were to run a port scan on they would find that (depending on policy) they would only be able to reach App1 on a specific port or set of ports. No additional changes or access control is needed at the network layer to restrict or protect the rest of the network because the end-user is not part of the network. It likely doesn’t even have an IP assigned that is part of the IP address scheme of the company. It likely uses the CG-NAT range in this case but is not directly connected to the network where the application resides. As you add application entitlement layer 3 of the tunnel changes (unless it’s packet filter). As you remove entitlement the reverse happens.
In the client-less or browser-based access, this is much more evident because the end-user opens the browser and puts in the app they’re looking to get to. One could say that this model is closest to the workflow that end-users experience when accessing SaaS applications. Through, internally to the cloud-based service the browser-based access and the full-client likely hit the same SDP which has proxy functionality in it.
Bringing it all together
So to close it off one of the biggest and most misunderstood differences between cloud-hosted ZTNA services and traditional VPN services is the fact that in traditional VPN services you authenticate for entitlement to the service and the network. You have direct connectivity to this network and if compromised have the potential to do some damage. In ZTNA models the end-user is given access to the service and the applications they are entitled to based on some centralized policy. That’s it. Aside from post-auth signaling and some service chaining for further packet processing the end-user can’t really do much damage except for maybe the apps the end-user has access to on the ports the end-user has access to. In most models, with some exceptions that use vNGFWs deployed into the cloud, the end-user isn’t even part of the network that is routable to the applications themselves.
HANKaaS 