Hacker News new | ask | show | jobs
by syscomet 1385 days ago
Defense in depth. First, the common RPC identity and authorization system provided RPC identity to the GFS API calls, and there was a common user/group system. GFS had ACLs and so despite what was said up-thread most people could _not_ access the data in the Gmail GFS cells. The team membership vs runtime user setup also ensured that Gmail SREs using their own credentials could not directly access the GFS cells (but once you have root on the storage boxes, that somewhat disappears). Second, on top of that you have encryption, using an encryption key service which would spot anomalies in things asking for the decryption keys to decode the stored data.
1 comments

They publish a bunch of whitepapers on this stuff, including how storage encryption keys are unwrapped on behalf of services:

https://cloud.google.com/docs/security/encryption/default-en...

How services authenticate each other:

https://cloud.google.com/docs/security/encryption-in-transit...

And how insider risk is mitigated by monitoring the provenance of production software:

https://cloud.google.com/docs/security/binary-authorization-...

The insider risk stuff always was really cool to me and, IMO, represents ways that the big tech companies do way more than everybody else in this space. BCID can be a huge pain in the ass but being able to say "hey, it actually would be pretty tricky for a single disgruntled employee to execute code to steal user data" is quite powerful.