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 the first of three distinct areas
of cloud security risk--
access.
[MUSIC PLAYING]
BRAD ACTOR: Hello, cloud detective.
You showed that you understand cloud's shared security model,
but can you solve this?
What can you do to stop the wrong people
from accessing your resources?
For example, I could use a man-in-the-middle attack
to intrude on an existing connection,
intercepting and modifying all network traffic between two
devices.
If I intercepted an admin's traffic,
I'd even be able to act on your system
with all the privileges of your admin.
What can you do to stop that?
For your sake, I hope you know the answer.
CARTER MORGAN: OK, here's what we know.
A man-in-the-middle attack involves an attacker getting
access to credentials they shouldn't have.
We could solve this, but there's actually
a broader problem here--
access.
Access represents ensuring that only the right identities have
access to the right resources for your system.
For example, you might not want developers
to be able to delete resources on your system,
so you have to enact a policy, or access control,
to prevent that from happening by accident or ill will.
Or you might want to prevent malicious access exploits
like phishing, where an attacker tricks individuals
into giving out their credentials,
or denial of service attacks, where an attacker works
to overwhelm a web service to keep it
from functioning properly.
Luckily, Google Cloud provides a lot of tools and services
to protect its users.
Some of those protections include encrypted traffic
and load balancers to combat man-in-the-middle and DDoS
exploits, universal two-factor authentication to minimize
phishing, Cloud Identity-Aware Proxy to make sure that only
the right people get access to applications,
endpoint management to make sure that users are using secure
devices to access company resources, and more.
Let's see how they work.
So how do these tools keep the wrong people
from accessing your system?
I know that to combat man-in-the-middle and DDoS
exploits, Google Cloud encrypts all internet access
at the network level by default, eliminating the concern
of a passive adversary listening for sensitive information.
Let me show you how.
Since TLS requires that servers prove their identity,
active man-in-the-middle attacks are also much more difficult.
And Google Cloud's front end and load balancers support TLS
termination while providing an entry point to Google's massive
serving resources, making a successful DDoS attack quite
challenging.
Here's how it works.
Load balancers report information
about incoming traffic to a central DDoS service.
If it detects that a DDoS attack is occurring,
it can configure the load balancers to drop or throttle
the traffic.
Google's central identity service,
which users see as the Google login page,
asks for a user name and password
and assesses risk factors such as whether users
have logged in from the same device or location in the past.
The service issues credentials, such as cookies
and OAuth tokens, to further protect users.
Oh, and second factors, such as one-time passwords
or phishing-resistant security keys,
can also be used by users when signing in to help
prevent phishing.
In fact, in order to make phishing less effective,
Google pioneered the U2F Titan Security Key,
a hardware second factor that can be associated
with an account so that login is only possible when
the second factor is present--
the idea being if you pair something
you know, like a password, with something you have,
like a security key, phishing becomes very difficult.
And it's easy to set up, too.
Once you set these keys up and change
the two-step authentication to only use security keys
in the Google Admin UI, then the next time
a developer logs on, after they enter their password,
they'll be asked to touch their security key.
Hmm.
How else can we limit unauthorized access?
What about Cloud Identity-Aware Proxy, or IAP?
IAP makes it easy for you to put up an application on the cloud
and configure a central policy users
have to authenticate against.
Best of all, since IAP is enforced at the network layer,
Cloud IAP requires little to no application code changes.
So if you had a legacy application that
was hosted on-premise behind a firewall,
and wanted to migrate it to a public endpoint on the cloud,
you could drop Cloud IAP in front of it
to require authentication and authorization against a Google
Group or G Suite domain with little to no changes
to the application at all.
But that still leaves the case of,
what if the laptop of an admin is compromised by malware?
Hmm.
That's where endpoints management comes in.
If your platform can be accessed from your employee's
own personal phone or tablet, you
can use G Suite Endpoint Management
to keep your company data safe while letting employees
use their favorite personal device.
And with endpoints, it becomes easy to do things
like set up policies.
Like, on Android devices, work apps
will be separated from personal apps,
or since Chrome OS is designed for security from the ground up
and doesn't allow the installation of software,
only use admin access if the admin is using a Chromebook.
I figured it out!
I've got the answer!
BRAD ACTOR: Hello, detective.
I see you've been busy.
You've answered my question-- what can you
do to stop the wrong people from accessing your data?
You noticed that Google Cloud could help secure access
and authentication.
Google Cloud provides help through Identity-Aware Proxy,
endpoint verification, universal two-factor, and more.
All of these features are building up
context associated with the access
to make sure it follows the rules.
The access should come from a Chromebook,
the user should have proper credentials to log in,
they should have the required access levels,
and they need to have a hardware second factor in order
to get to the particular API.
These individual protections layer on top of each other
to help keep your cloud safer and more secure.
Very good, very good.
You've answered today's question,
but be ready, because next time I
want to see what you can do to keep your data safe.
CARTER MORGAN: So there you have it--
another episode of "Cloud Security Basics."
Next episode will focus on the second of three distinct areas
of cloud security risk--
data.
In the meantime, if you want to take a deeper
dive into securing access in the cloud,
then check out the article linked in the description
below, and stay tuned for the rest of the Cloud Security
Basics series because when it comes to security,
you can't let bad actors win.
[MUSIC PLAYING]