Zero Trust is a fine phrase, but it greatly over claims. (Unless I'm missing something, and it eliminates trust requirements for third party SSO services, software supply chains, infrastructure operators, and other common attack vectors).
It's easier to talk about zero trust by identifying the thing it is not. For example, ZT is not "it is sufficient to be inside X" where X is on a host, in a container or not, on a subnet (we are less than ten years way from having to argue with people about "why are we using encryption on our internal connections?"), or some other context, and so on.
We’re talking about situations where you have some control over both sides. If you’re authenticating with some random embedded device, you’d likely use a VPN for security.
Instead, the proponents of zero trust have redefined "untrusted network endpoints" to mean "trusted network endpoints".
When someone tries to connect to a service, instead of having a firewall verify their device is trusted by checking the IP address is within a trusted range, the device is authenticated by the Access Proxy using mutual TLS.
Authorization decisions incorporate both device and user privileges. A machine that isn't registered as being physically bolted to the floor inside a physical security domain won't be able to access certain highly restricted resources. A machine that isn't registered as being up to date on security patches will also have privileges restricted. A machine which does not present a client certificate or presents a client certificate that is no longer trusted will only be able to access services intended for the public.
Instead of treating the subnet as a de facto database of trusted machines, there's an actual database of trusted machines that is incorporated into authorization decisions at access time.
That's many more machines than a system that relies on old fashioned SSH client certs. Client certs don't really scale, but I guess Google has to give up some security, given their size.
I don't understand why a small business would reproduce all that complexity though, especially since it requires outsourcing a bunch of critical components to untrustworthy third parties.
The certificate is indeed stored in a TPM:
> Desktops and laptops use an X.509 machine certificate and a corresponding private key stored in the system certificate store. Key storage, a standard feature of modern operating systems, ensures that command-line tools (and daemons) that com- municate with servers via the AP can be consistently matched against the correct device identifier. Since TLS requires the client to present a cryptographic proof of private key possession, this implementation makes the identifier non-spoofable and non-clonable, assuming it’s stored in secure hardware such as a Trusted Platform Module (TPM).
I'd be interested to hear more about how they are trivially exploited. I had not heard that was the case, and from the quote above it seems that information had evaded Google's engineers as well since they are considering credentials stored in TPMs to be non-clonable.
The primary trouble with SSH keys is that they can only authenticate one thing: they're either something the user can exfiltrate from the machine, in which case they authenticate the user and trust the user to authenticate the machine, or they are locked to the machine, in which case they authenticate the machine and trust the machine to authenticate the user. This was a common difficulty that Google ran into when implementing Inventory-Based Access Control for their BeyondCorp system: protocols are typically designed to authenticate a single identity, which may be the user or the machine but not both, which leaves the door open for users connecting from unauthorized endpoint devices whose security posture cannot be validated (if only authenticating the user) or adversaries stealing authorized endpoint devices. The point of the Access Proxy is to provide two distinct authentication steps: one to authenticate the device via mutual TLS and one to authenticate the user via their SSO credentials.
> In the cases of gRPC and TLS traffic, we wrapped the bytes in an HTTP CONNECT request. Wrapping has the obvious downside of imposing a (negligible) performance penalty on the transported protocol. However, it has the important advantage of separating device identification and user identification at differ- ent layers of the protocol stack. Inventory-based access control is a relatively new concept, so we frequently find that existing protocols have native support for user authentication (e.g., both LOAS and SSH provide this), but extending them with device credentials is non-trivial.
The value added by private networks is not only the fact that all of the people on them are trusted, but also that (at least in enterprise systems) all of the devices on them are trusted as well. In the absence of network trust, the policy decision point needs a different way to authenticate the device to replace the authentication step that would normally be done at the time when the device attempts to connect to the VPN or the internal network. In an equivalent system that used a VPN, the database utilized to make device access control decisions would already exist, but the policy would be applied when the device attempts to join the network, and then the never again as the device freely interacts with other resources on the network. The access proxy applies that device authorization policy at resource access time instead of network admission time.