Author: Peter Bjork – Principal System Engineer (@thepeb) | Office of the CTO, Global Field
Reviewers: Cameron Haight – Vice President & Chief Technology Officer, Americas and Hadar Freehling – Staff Systems Engineer
Ever since I read the Google’s BeyondCorp white papers many years ago, I’ve been thinking a lot about application protection, user experience, ease of management and trust in general.
The backdrop to BeyondCorp is that you can’t trust devices just because they are connected to your internal network. Security reports often state that many attacks originate from the internal network. Knowing this, why have different access requirements and policies for internal vs. externally connected devices? You need to place your trust into something else.
If the device is corporate owned and thereby managed you can place policies on that device, make sure antivirus software is installed and up to date, make sure the hard drive is encrypted and so on. Your trust in this device should be high.
In other words, you should allow access to your applications from any network, as long as you can verify that the device is corporate owned and managed. Which means that VPN is completely obsolete.
The Idea of a VMware Based Zero Trust Architecture
While BeyondCorp is all well-defined, and more and more vendors are supporting its architecture, I have been thinking about it from a different viewpoint. I’ve been stuck with this idea; can I build a Zero Trust architecture using only VMware’s currently available products?
After joining the Office of the CTO Global Field team, I started to explore this possibility. As a member of this team, I have the opportunity to work on side projects. After some investigation, I identified a few gaps in our offering. So, I started a dialog with the product teams to add the missing functionality and I’m happy to say that this spring, the last piece of the puzzle arrived. But more on that later.
My Take on Zero Trust
Just like with any other IT buzz words, everyone you ask will give you their own take on what Zero Trust means. I believe that my view of Zero Trust is well aligned with Google’s BeyondCorp. But to be clear, when I say Zero Trust, I mean the following:
- No network can be trusted.
- There is no difference in accessing apps whether you are connected to the internal network or the Internet.
- Access to applications uses externally routable DNS names (FQDN).
- No VPN is to be used.
- Applications have built in protection, such as only communicating over HTTPS.
- Access to applications requires corporate owned devices and a valid authentication method to identify the user. The enforcer of this is a secure application proxy which all traffic must flow through.
- Device ownership is to be checked against a corporate inventory.
- Authentication of users must support a wide range of methods, including Multi Factor and certificates.
The Zero Trust Architecture in Theory
Before I started to try and build a BeyondCorp offering using VMware only products, I had to create a theoretical architecture. While I was at it, I added enhancements to the model. The original model requires modern applications. Legacy applications are not really supported in the implementations I’ve come across.
In my theoretical architecture, I included both Internet Of Things (IOT devices), where there is no user authentication, as well as non-managed devices (typically “Bring Your Own Device”). But to make some kind of progress I chose to focus on the sweet spot. The sweet spot simply discard support for IOT devices and unmanaged devices.
The architecture I came up with looks like this:
Let me explain each layer of the architecture briefly.
Users
The users are the humans in front of the devices.
Untrusted Devices/Trusted Devices
The physical device the users happen to sit in front of at this moment in time.
Any Network
Any network the user connected his/her device to. Internal or external.
Entry point Layer
Firewall, load balancers and whatever else you need to provide access to your application from any network.
Device Authentication Bypass/Device Authentication Layer
This is the layer verifying if the device is corporate owned or not. In my initial solution, I only support corporate owned devices (remember the sweet spot). So, I am not using the bypass part of this layer. To validate the device, I’m using a device certificate. If the certificate is not present on the device, further access down the layers are blocked.
User Authentication/User Authentication Bypass Layer
If the users succeed in passing the device authentication layer, they are now prompted for an authentication method. The method used depends on policies. For some applications, you might be okay with providing accesses if users can authenticate using a single factor. But you might want to protect some apps more, by requiring Multi Factor Authentication (MFA).
Access Termination Layer
This layer exists to support legacy applications. You can easily externalize modern apps since most are accessed using Web application based techniques. But an old Win32 application you just can’t externalize. We need a layer where we can translate old legacy and proprietary protocols to modern and more secure protocols.
Application Back-End Layer
This is the layer where the actual application runs. This is all the front-end and the back-end of the application servers.
Application Proxy Ensures Protection
By now you probably see that there is an application proxy at play here. This application proxy is the component protecting the application. It makes sure no traffic is forwarded until the device has been verified as a corporate owned device. It also makes sure that the user is authenticated correctly before it lights up the real backend, i.e. the application itself.
VMware offers this very competent application proxy. We call it the VMware Unified Access Gateway. With version 3.3, the last piece of the puzzle was added. Now, Unified Access Gateway can perform device certificate authentication for its Web Reverse Proxy feature.
The Architecture Built with VMware Products
Let’s have a look at the architecture again, this time with VMware products mapped into it.
VMware Unified Access Gateway plays an important role in this architecture. Unified Access Gateway protects VMware Identity Manager. Identity Manager is VMware’s access management solution. Identity Manager supports strong user authentication and federation using standards such as SAML, OpenID Connect and more. The Unified Access Gateway in front of VMware Identity Manager requires a device certificate before it allows traffic to flow to VMware Identity Manager. The device certificate is checked against a revocation list managed by VMware AirWatch. AirWatch also handles the distribution of the device certificates. AirWatch manages the devices and have a rich compliance engine. If the device is being jeopardized and becomes non-compliant the certificate will be revoked.
Without being successfully authenticated into VMware Identity Manager, users will not be able to access any of the applications. The modern applications are federated to Identity Manger using SAML or OpenID Connect. Legacy applications tend not to support SAML, or other modern federation protocols. VMware Horizon supports SAML federation and seamless authentication into the Active Directory (AD) using the feature TrueSSO. With the help of the TrueSSO feature users can seamlessly access any application once authenticated into VMware Identity Manager. This brings modern access methods to legacy applications. Using VDI/Published Application might not be ideal from a user experience point of view, but at least you modernized those applications. Later, the IT department can focus on rewriting those applications or simply retire them and replace them with more modern applications.
To summarize: With the help of VMware products such as Unified Access Gateway, Identity Manager and AirWatch, we can build a BeyondCorp/Zero Trust architecture protecting modern applications. With the addition of VMware Horizon we can bring legacy Windows based applications into the same architecture.
This is one way of doing it. There are of course many ways of securing your applications, and you can add many more components to the mix. For instance, adding products like VMware NSX can enhance the security and automation of your infrastructure even further.
