SAMRAT RAY: Welcome to the Google Cloud Security Showcase,
a special web series where we'll focus on security use cases
that customers consult with Google Cloud.
My name is Samrat, and I am a product manager
at Google Cloud.
Today, we'll be walking through one of the top questions we
get from customers--
how do I prevent a data breach via personal storage buckets
on GCP?
While this is a complex topic, we
will provide a simple explanation
of how you can mitigate this risk on GCP
using a unique feature called VPC Service Controls.
Most breaches occur either because, one, policies
are complex and are easy to misconfigure,
or two, clients with broad access to data
have been compromised.
In this demo, we will show how to create
a defense and a posture assuming that a client to cloud storage
has been compromised.
Before we jump into the demo, it's
important to understand that there are three network
interfaces to a managed public cloud service like Google Cloud
Storage.
The three network interfaces are, from the internet,
from a VPC network using private access,
and between resources of cloud services.
The last network interface is least understood
and is generally ignored as part of a security posture.
But it is one of the more important network interfaces
because it's a very high bandwidth way of moving data
outside your control.
And in today's demo, we'll cover that.
In my demo, we have a source bucket with sensitive data
and a publicly writable personal bucket that I
created to exfiltrate data.
To make it obvious, the publicly writable bucket
is called the attacker bucket.
And the attacker bucket doesn't require
any credentials to write to it.
The client, which we are going to use to exfiltrate the data,
is a VM within a VPC network, and has
no access to the internet.
We will assume, for the purposes of this demo,
that the client has been compromised,
and therefore the shell is being used to exfiltrate data.
With this, let's jump to the demo
and to the command line of this private VM inside your VPC
network.
So as you can see, I've got the commands in my memory just--
of the shell memory-- just to make it easy for you to see,
right?
And this, the VPCSC secure bucket,
is the bucket which contains sensitive data as we see here.
It has employed PII, which is the sensitive data.
I've created an attacker bucket.
And even though I have no access to the internet,
I do have access to GCS.
Therefore, I can access all resources on GCS,
like the attacker bucket.
Right now, the attacker bucket has no data on it.
So how hard is it to exfiltrate this data once I
have compromised the client?
It's fairly trivial, as we will see here.
I could run a single command, like a sync command that
effectively copies all data from the source bucket
to this attacker bucket.
As we can see, all the data is copied at very high bandwidth
on the Cloud backend itself.
So now if you look at the attacker bucket,
it contains my EmployeePII in it,
and the data has been exfiltrated.
So how can I mitigate this risk on Google Cloud Platform?
To see that, I'm going to delete the data in the attacker bucket
now, and we'll switch over to the console
to create a VPC Service Control service perimeter.
So how do we do that?
So we go to the console.
If you have the right privileges at the org level,
you can create a new perimeter under Security and then
VPC Service Controls.
So this is where we are.
And in there, I'm going to create a new perimeter.
In the perimeter page, I name my perimeter.
So let's call this The Production Perimeter.
And there are two things that I must do in order
for the perimeter to work.
First, I have to decide what are my production
projects that I would like to include into the perimeter.
For that, I'm just going to do a quick search.
And this is the VP6SC compute project, has the shell
that we were just looking at.
So it contains a network of the VM.
The other project that I must protect
is the storage where the sensitive data is.
Let's say, for example, if I had a big query data set
and I wanted to predict that too.
So I'm going to select that.
And I'm going to add these three projects to my perimeter.
After that, I must define what services
do I want to control using this perimeter controller.
And for the purposes of this demo,
I actually just need one service,
which is the storage service.
But I'm just going to select everything.
And why not, right?
I'm going to say this is a highly secure environment
and I want to select all the services
and make sure those services are protected by VPC Service
Controls.
So thus, I have 21 services that I have protected here.
And I'm going to save this perimeter.
At this point in time, the bucket
is no longer accessible from the internet.
I cannot access the GCS bucket from the internet.
The important thing to understand
is that once I set up this perimeter,
the VM no longer has access to the attacker bucket anymore.
So let's go back to the command line
and repeat that exfiltration attempt
that we managed to do so easy.
So here's the rsync command that had
exfiltrated the data before.
Let's run it.
And as you can see, it has an access denied exception
from VPC Service Controls.
Thus, even though my VM is inside a privileged network,
and it continues to have access, as you can see,
to the sensitive data, which I do need for my business
purposes, it no longer has access to the attacker bucket
anymore, and I cannot copy the data to the attacker bucket
anymore.
So for example, if I tried to run this RM command, which
is actually trying to operate on the attacker bucket,
I can no longer operate on the attacker bucket anymore.
Thus, VPC Service Controls provides you
with a key feature that allows you
to obtain the benefits of using managed public cloud
services with the security of a private cloud.
Thank you for tuning in.
Please visit that cloud.google.com/security
for more content from Google Cloud experts.