CARTER MORGAN: Welcome to Cloud Security Basics, a new series
where we explain the ins and outs of securing
your application on Google Cloud.
Sound fun?
Then stick around because in this episode,
you'll learn about Google Cloud's physical defense
of their data centers and hardware.
[MUSIC PLAYING]
BRAD ACTOR: Hello, cloud detective.
You may have solved last week's question
about securing customers' data.
But what about securing the data centers
and other physical hardware that runs your software?
You may have everything else and your ecosystem is secure.
What will you do about machine or supply chain-related issues?
How can you be sure the physical devices are
being properly secured?
Or what if some bad actor plants malware
on your precious machines?
What can you do to stop that?
For your sake, I hope you know the answer to my question.
CARTER MORGAN: OK, here's what we know.
Physical security has two components-- securing
the physical servers and the data centers that data lives on
and ensuring the physical and virtual systems
that applications rely on are secure,
like with a route of trust.
If the physical devices aren't being properly secured,
someone could steal a machine with your data
on it, plant malware on it, or otherwise
tamper with the machines, compromising
the security of anyone who uses those instances.
Luckily, Google Cloud provides a lot of tools and services
to protect its users.
When it comes to securing the physical premises and hardware,
access to Google data centers is limited
to a small number of specially qualified Google employees.
Less than 1% of googlers will ever
set foot into a data center.
Access to the data center floor is
only possible via security corridor, which
implements multi-factor access controls using security badges
and biometrics.
When it comes to securing the virtualization and hardware
component software runs on, Google
has designed a lot of custom tooling to protect its users.
Google data centers have thousands
of server machines connected to a local network providing
an initial layer of security.
Both the server boards and the networking equipment
are custom designed by Google to adhere to their tough security
requirements.
And Google's custom-designed Titan hardware security chip
can be deployed on both servers and peripherals,
allowing Google to identify and authenticate devices
at the hardware level.
With security like that, you can be
sure the hardware your software runs on is secure.
Let's see a few specific examples
of how Google secures the platform.
So how does Google Cloud secure the data centers
and other physical hardware that runs your software?
Hmm, first, let's talk about securing the data center.
On top of the technologies, like biometric identification,
metal detectors, camera, physical barriers,
and laser-based intrusion detection,
as you get closer to the data center floor,
security measures also increase.
Access to the data center floor is
only possible via security corridor, which
implements multi-factor access controls using security badges
and biometrics.
Plus, data centers are routinely patrolled
by experienced security guards who
have undergone rigorous background checks and training.
So that's the physical defense of data centers.
But what about virtual and real hardware security?
Well, there's a Titan chip.
Titan is a secure low-power microcontroller
designed with Google security, requirements, and hardware
scenarios in mind.
Titan provides a hardware based route of trust
that establishes a strong identity for a machine, which
enables Google to make important security decisions
and validate the "health" of the system.
Titan offers integrity verification of firmware
and software components.
The system's strong identity ensures
that there's a true audit trail of any changes done
to the system.
Tamper-evident logging capabilities
help identify actions performed by an insider with root access.
All of these features come together
to allow Google to securely run operating systems that
have been verified and authenticated.
And then there's KVM or the kernel-based virtual machine
that Google uses as the foundations of Google Compute
Engine and Google Kubernetes engine.
KVM is an open source virtualization technology
built right into Linux and lets you turn Linux
into a hypervisor that allows one host machine to run
multiple isolated VMs.
Plus, Google invests in additional security hardening
and protections based on his research and testing
experiences.
For example, the Google Security team
performs thorough code reviews each time
they adopt a new feature or version of KVM
and uses an extensive set of proprietary fuzzing tools
for KVM to further test it.
Google removes unused KVM components, like legacy mouse
drivers, to reduce the attack service
for potential adversaries to exploit.
And instead of using the more complex QEMU emulator built
into KVM, Google wrote its own user space
virtual machine monitor and hardware emulator, which
is simpler, better tested, and offer significant security
advantages.
These are just a few of the steps
Google's taken to heart in KVM for its services
and its customers.
So we see how Google uses hardware, virtualization,
and physical security to protect its tooling.
Mm, and I see how to answer Brad Actor's question.
BRAD ACTOR: I see you've been busy, Detective.
Somehow you answered my little question.
How do you secure the platform?
The data center's another physical hardware
that runs your software.
I see you found the crux of the argument.
Google's commitment to security first design
keeps the platform secure.
Google Cloud manages security throughout the data lifecycle
from the data center to the device using a range
of technologies and approaches.
Very good-- very good.
You seem to have the basics covered, but be wary.
I'll return with questions about forensic and preventative
actions.
You've been warned, Detective.
Ha, ha, ha.
CARTER MORGAN: So there you have it.
That's another episode of Cloud Security Basics.
If you want to take a deeper dive in how Google secures
its data centers and physical hardware,
check out the article linked in the description below.
Next, we're going to start looking
at some preventative and forensic actions.
Stay tuned because when it comes to cloud security,
you can't let bad actors win.
[MUSIC PLAYING]