BeyondCorp: The Access Proxy
Abstract
This article details the implementation of BeyondCorp's front end infrastructure. It focuses on the Access Proxy, the challenges we encountered in its implementation, and the resulting lessons we learned in its design and rollout. We also touch on some of the projects we're currently undertaking to improve the overall user experience for employees accessing internal applications.
In migrating to the BeyondCorp model (previously discussed in BeyondCorp: A New Approach to Enterprise Security and BeyondCorp: Design to Deployment at Google), Google had to solve a number of problems. One particular challenge was figuring out how to enforce company policy across all our internal-only services. A conventional approach might integrate each back end with the device Trust Inferer in order to evaluate applicable policies; however, this approach would significantly slow the rate at which we're able to launch and change products.
To address this challenge, Google implemented a centralized policy enforcement front end Access Proxy (AP)--to handle coarse-grained company policies. Our implementation of the AP is generic enough to let us implement logically different gateways using the same AP codebase. At the moment, Access Proxy implements both the Web Proxy and the SSH gateway components, according to the terminology used in the previous article. As the AP was the only mechanism that allowed employees to access internal HTTP services, all internal services were required to migrate behind the AP.
Unsurprisingly, attempting to deal with only HTTP requests proved inadequate, so we had to provide solutions for additional protocols, many of which required end-to-end encryption (e.g. SSH). These additional protocols necessitated a number of client-side changes to ensure that the device was properly identified to the AP.
The combination of the AP and an Access Control Engine (a shared ACL evaluator) for all entry points provided a couple of main benefits: a common logging point for all requests allowed us to perform forensic analysis more effectively, and we were also able to make changes to enforcement policies much more quickly and consistently.
In migrating to the BeyondCorp model (previously discussed in BeyondCorp: A New Approach to Enterprise Security and BeyondCorp: Design to Deployment at Google), Google had to solve a number of problems. One particular challenge was figuring out how to enforce company policy across all our internal-only services. A conventional approach might integrate each back end with the device Trust Inferer in order to evaluate applicable policies; however, this approach would significantly slow the rate at which we're able to launch and change products.
To address this challenge, Google implemented a centralized policy enforcement front end Access Proxy (AP)--to handle coarse-grained company policies. Our implementation of the AP is generic enough to let us implement logically different gateways using the same AP codebase. At the moment, Access Proxy implements both the Web Proxy and the SSH gateway components, according to the terminology used in the previous article. As the AP was the only mechanism that allowed employees to access internal HTTP services, all internal services were required to migrate behind the AP.
Unsurprisingly, attempting to deal with only HTTP requests proved inadequate, so we had to provide solutions for additional protocols, many of which required end-to-end encryption (e.g. SSH). These additional protocols necessitated a number of client-side changes to ensure that the device was properly identified to the AP.
The combination of the AP and an Access Control Engine (a shared ACL evaluator) for all entry points provided a couple of main benefits: a common logging point for all requests allowed us to perform forensic analysis more effectively, and we were also able to make changes to enforcement policies much more quickly and consistently.
