How to Go Zero Trust, Part 5: Migrating Resources Behind an Access Fabric

My previous post in this series covered how to implement the access controls that make up a real world Zero Trust system, which we are now going to put into action by migrating live resources over. It should go without saying that this is a critical moment on the Zero Trust journey, however, not one to fear. If you’ve been following this blog series, you’ll know to come prepared and take things in stride.

What’s an Access Fabric?

Before digging in, if this blog series is the first time you’ve heard the term Access Fabric, that’s expected - we recently introduced the concept. At a high level, it’s a globally distributed authentication and authorization engine capable of making lightning fast, intelligent trust decisions based on dynamic user and device conditions. Architecturally, an Access Fabric carries similar properties as a CDN, with a focus on auth processing at the edge. The ScaleFT Platform is backed by an Access Fabric, which we operate as a service on behalf of our customers.

Migrating Your Resources

The workflow that follows is how applications are deployed via ScaleFT Web Access, which is a fully hosted cloud platform. If you are building a Zero Trust system yourself, there will be additional considerations in terms of the deployment makeup, ongoing operations, and the supporting PKI. Make sure you read and fully understand all four BeyondCorp papers from Google before going down the DIY path.

Choosing the Right Application to Start With

Taking the migration process in stride means carefully selecting the right resources to start moving to your new environment, but what are the characteristics one should look for? My view is to stay away from your complex, mission critical apps to start. I recommend beginning with a simple application where coarse-grained rules generally apply, and where the sensitivity of the data is relatively low. A good example might be an internally developed employee directory or company knowledge base.

When done right, the access controls of a Zero Trust will be more secure than traditional perimeter-based methods, however, you want to ensure the proper workflows are in place first and foremost. You wouldn’t want to risk leaking customer data while testing the system’s resilience. To thwart this risk, Google deployed their BeyondCorp system side-by-side their traditional network, moving applications over gradually as they gained more confidence with the environment.

Moving the Application Behind the Access Fabric

Google placed a lot of emphasis on the fact that all resources backed by the BeyondCorp model are deployed to the public Internet, removing the need for network segmentation. You may not want to be that bold right away – which is okay! We’re introducing better access controls at the application layer, but that doesn’t necessarily mean you have to rid yourself of your network-based protection methods. Subnets, network ACLs, and firewall rules are a good thing to preserve. Eventually, you will no longer rely on the network as more than pure transport, at which point you can choose to remove VPNs from your architecture entirely.

With fully operational access controls, all you need to do to protect your resources is point your traffic to the Access Fabric. With ScaleFT, enrolling a web app in the platform generates a unique ScaleFT App Name – such as impartial-werewolf-1234.accessfabric.net. We also generate an SSL certificate for the fully qualified domain name using Let’s Encrypt. With this, simply set the CNAME record of your domain to the ScaleFT App Name through your DNS provider, which places the access gateway in front of your origin – a web server or a load balancer.

In this environment, all traffic will flow through the Access Fabric, handling the authentication and authorization processes independently, while brokering the encrypted connections between the client and origin.

Securing the Application

With all traffic is flowing through a central gateway, it’s important to ensure the connection with the application is secure. Every request must be fully encrypted from end-to-end, which means only allowing traffic over HTTPS from the client to the gateway and the gateway to the origin. This does mean you must trust the gateway to handle TLS termination properly as traffic is intercepted and forwarded. The gateway is the ideal location to perform this handoff, as another key part it plays in the workflow is logging and monitoring for event auditing and traffic inspection purposes.

A secure tunnel is not enough, though. You also want to ensure that all traffic to the application originates from the gateway and that every request is fully authenticated and authorized. There are a few ways to do this independently of an integrated vendor solution – one method would be to sign the request certificate or token along with its associated metadata, and then configure the application to verify. There may also be cases where you want to whitelist all traffic from specific IPs, such as a database server or webhook trigger.

Enrolling Users and Devices

Zero Trust redefines corporate identity as a user plus their device at a point-in-time, which means that we need to be able to get to that data in a streamlined manner to make a valid trust attestation. Static attributes such as the user id and their group membership are extracted from the system of record, but dynamic state such as the device’s OS version and whether the disk is encrypted must be captured in real-time. The sum of the user and device attributes and state make up the identity profile that is authenticated and authorized.

To accomplish this, users must run an application on their devices to communicate with the system on every request. The goal of this application isn’t necessarily to operate as a full blown endpoint protection service, per se, but rather to provide the appropriate information to make a valid decision, and to enforce the rules inherent in the access policies. Using an example I’ve used before in this series – if a policy states that a user must have the latest version of their OS to gain access to the company wiki, and theirs is out-of-date, then the request should be blocked and a message should be delivered to the user explaining why. The easier that message is to understand, the more capable the user is of self-remediating versus the status quo - calling IT to complain!

Inspecting the Results

It’s critical that you monitor all traffic and capture all events as you migrate resources over to the new environment. This inspection is important to ensure everything is working properly but also provides you with valuable data to tune your access policies according to behavioral patterns.

Aside from network inspection, what you’re looking for here is an audit log of all auth events. A proper Zero Trust system will capture every authentication and authorization event, granted or denied, with the referenceable user and device attributes and state. You can compare this data with your policies to see if the results line up with your intentions. For example, if a minor software update policy blocks all requests, it may frustrate your employees, so you may want to consider giving everyone a few days to remediate. I covered policy tuning in more detail with regards to behavioral patterns in the third post in the series.

Conclusion

We’ve reached the end of this blog series, which is what I hope leads you to begin your Zero Trust journey. You’ve learned why the architecture matters in Part 1, then what relevant data to collect in Part 2, which led into creating your access policy framework in Part 3. The access controls implemented in Part 4 were put into action with real applications in this post

Zero Trust is a new architecture that introduces a lot of new concepts such as the Access Fabric we designed at ScaleFT.