How to Go Zero Trust, Part 4: Implementing Access Controls

This is part 4 in a series of blog posts dedicated to helping companies learn what it takes to achieve a Zero Trust security architecture of their own; much like Google’s BeyondCorp.

My previous post in this series talked about how to create the right access policy framework for your company, which we are now going to put into action with the proper controls. The policies set the foundation for your secure environment, but are fairly meaningless by themselves without enforcement. This is where you will begin the actual implementation of your Zero Trust system, ensuring that your sensitive corporate resources are secure.

We have looked closely at Google’s BeyondCorp as a guide to get to this point, but here is where we will start to branch out. Unless you are one of the handful of companies who operate at that level of scale, and who can manage everything in-house, your system will likely be composed of a mix of internal and external services for things like Identity Governance, Fleet Management, Access Management, and Monitoring Tools to name a few. While the final architecture of the system may closely resemble BeyondCorp with similar behaviors, the components will be arranged slightly different to match your environment.

As a refresher, the design of a Zero Trust network requires that every request to a protected resource be fully authenticated, authorized, and encrypted. The access controls built around your policy framework must perform the duties necessary to accomplish this secure workflow from end-to-end.

Zero Trust Access Controls

Let’s design our Zero Trust architecture by examining the desired characteristics and behaviors of the access controls, and how they fit together to form a cohesive system.

The New Role of Identity Governance

I’ve spoken before about how Zero Trust redefines corporate identity as a user plus their device at a point-in-time. The challenge to overcome here is that traditional systems place many of the access controls within the Identity Provider itself. For a lot of companies, this is might just be a single Active Directory instance running on a server in the office. With roles and permissions stuck in the back office, developers are forced to build complex interfaces via legacy protocols not suited for modern cloud environments.

I’ll call this the “microservices moment” of Zero Trust, where we aim to decouple the auth logic from monolithic systems to enable more flexible trust assertions. This means that the Identity Provider your company uses – Active Directory, Google Apps, or Okta to name a few – should now provide Identity Governance purely as a system of record for raw user data. Similarly, if you use a Fleet Management service, the inventory component should purely exist as the system of record for raw device data.

By decoupling the auth logic from the system of record, we are able to effectively build a dynamic identity profile that can be evaluated in real-time. The policies can easily be changed, and the respective workflows will adapt accordingly. This is key to a proper Zero Trust system.

Centralized Traffic Handling

When dealing with protected company resources, you want all traffic to flow through a central location, but in such a way that doesn’t impact the end user experience. The last thing you want to do is force an even worse experience on your employees than the already painful VPN login workflow. The component that handles all traffic is the Access Gateway – which is a reverse proxy service that centralizes the authentication and authorization processes. It’s this gateway that really ties the whole Zero Trust system together as it unifies all auth processing while acting as the ideal logging and monitoring point for further inspection.

A proxy service is also how the PKI is implemented to support encryption with each hop in the workflow. All requests are served to the gateway over HTTPS, where the user and device data is extracted to perform the authentication and authorization. For successful requests, the PKI of the platform should generate a single use client-certificate scoped to the request. The same can be done with JWTs. This is better than using static credentials because you can better control the expiration and scope, eliminating a common insider threat vector. The certificate, or token, is injected with the user and device data, and then used to initiate a secure session with the resource over a direct SSH, RDP, or TLS connection.

This means there is inherent trust between the gateway and the protected resources, limiting the attack surface significantly. In an ideal environment, the resources themselves will not be open to the Internet at all, with the gateway responsible for brokering connections and requests, which may bridge back into a more traditional enterprise network where the application is still hosted, or into micro-segmented cloud environments.

Making Smarter Trust Decisions

The ability to create a dynamic identity profile at a point-in-time means we can make smarter authentication and authorization decisions. That’s what we’re really after with a Zero Trust system – the ability to perform trust attestation based on meaningful conditions as opposed to purely by the network location. But what does that entail, and what do we mean by “smarter”?

As covered in the previous post, the policy framework you define for your company sets the foundation for the decision making process and end user workflows. To be smart about this means to factor in the right elements, with a logical response based on behavioral patterns. Nothing is more damaging to a company than letting someone in who shouldn’t be allowed, and nothing is more frustrating to a user than being denied access when it wasn’t warranted. While the system is automated to make the trust attestation, someone has to make the call on the policy. The easier the policy framework is to understand across the entire organization, the more confident you should be that your team is incorporating smart decision making. The trick is to analyze the policy decisions over time and adapt accordingly based on common behaviors.

There’s no hotter topic on the street than that of machine learning, which starts to enter the picture here. After a while, your system will begin to understand commonalities and train itself to make its own intelligent decisions. With humans, we want the decision-making process to be smarter; with machines, we mean to make it intelligent. This is the natural evolution of Zero Trust, which is only made possible by the architecture itself.

Implementing the Access Controls

Google has described in detail the components of BeyondCorp that accomplish these access controls across their environment, but where does that leave other companies? As mentioned, you likely won’t operate at Google scale, nor have the resources or motivation to design, build, and operate such a complex system with so many moving parts yourself. Luckily, there are vendor solutions emerging, including the ScaleFT Access Management Platform. A key piece of this platform is the Access Fabric, which is a globally distributed, real-time authentication, authorization, and encryption broker that acts as the data plane users interact with to gain access to company protected company resources.

For a deeper dive into the Access Fabric, our CTO, Paul Querna, wrote a technical post: How we built an Access Fabric to eliminate VPNs. 

What’s Next

We’ve come a long way in this series, and only have one more topic to cover - deploying resources protected by the access controls. Stay tuned!