Beyond Corp: The Access Proxy
Venue
Login (2016)
Publication Year
2016
Authors
Batz Spear, Betsy (Adrienne Elizabeth) Beyer, Luca Cittadini, Max Saltonstall
BibTeX
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.