Google’s Infrastructure Security Design Overview document takes us behind the velvet rope and gives us an insight into how the company secures its servers.
Security starts with the physical premises, and Google’s measures sound like they’ve been taken directly out of a Mission Impossible movie.
It use multiple physical security layers to protect our data center floors and use technologies like biometric identification, metal detection, cameras, vehicle barriers, and laser-based intrusion detection systems.But this is just the beginning. According to the document, Google doesn’t allow any old hardware into its digital domain. Google reveals that it uses “custom-designed” server boards and the networking equipment from vendors that have been audited and validated, and goes as far as to use proprietary security hardware chips in both servers and peripherals to “securely identify and authenticate legitimate Google devices at the hardwarelevel.”
Which means an attacker can forget about physical tampering or hooking up a keylogger or storage drive to the system.
Google server machines use a variety of technologies to ensure that they are booting the correct software stack.Google use cryptographic signatures over low-level components like the BIOS, bootloader, kernel, andbase operating system image. These signatures can be validated during each boot or update. The components are all Google-controlled, built, and hardened. With each new generation of hardware we strive to continually improve security: for example, depending on the generation of server design, we root the trust of the boot chain in either a lockable firmware chip, a microcontroller running Google-written security code, or the above mentioned Google-designed security chip.
Google pays particularly close attention to hard drives, and has in place systems to prevent malicious disk firmware from being injected into drives. It also is meticulous when it comes to keeping track of storage drives, despite the fact that all the data on them is encrypted:
Google enable hardware encryption support in our hard drives and SSDs and meticulously track each drive through its lifecycle. Before a decommissioned encrypted storage device can physically leave our custody, it is cleaned using a multi-step process that includes two independent verifications. Devices that do not pass this wiping procedure are physically destroyed (e.g. shredded) on-premise.
Attacks carried out by a rogue engineer are safeguarded against by requiring that code reviews “require inspection and approval from at least one engineer other than the author,” and by keeping a detailed forensic trail of all code changes back to their source.
The document also contains some other interesting tidbits relating to what goes on behind the scenes at Google, including how Google uses KVM (kernel based virtual machines) for hardware virtualization, and the process that the company has in place for when users request that data be deleted from the cloud.