NISHANT KOHLI: Welcome, everybody.
Today, we'll be walking through some of the new features
and then how to help our customers
protect and secure their data.
Joining me-- my name is Nishant Kohli.
I'm one of the outbound product managers for Cloud Storage.
And joining me today is Subhasish Chakraborty.
Subhasish, if you want to do a quick intro?
SUBHASISH CHAKRABORTY: Hi, folks.
I'm Subhasish.
I'm the Product Management Lead for Google Cloud Storage's
Security and Enterprise Governance.
NISHANT KOHLI: Thank you.
SUBHASISH CHAKRABORTY: I'm excited to talk to all of you
on some of these exciting features.
NISHANT KOHLI: Nice.
So this is a series of many videos
we're going to be looking to do.
But today is focused on some two key features
that we'll talk about and how we're
helping our customers protect their data
and secure their data.
So, Sub, let's look at some of the challenges we've
heard from our customers, generally
around how do they protect their data from being publicly
exposed, and also protecting it from malicious actors that
are out there?
So what are we doing in Cloud Storage to help our customers?
SUBHASISH CHAKRABORTY: Yeah, so I
think if you look at broadly, like if you look
at the vast swath of different public Cloud Storage offerings
out there, for the last few years,
I think we have seen a lot of instances
where customers are having that data publicly exposed.
As you alluded to it, I think broadly, there are two reasons.
One reason is you have malicious actors.
You know, some insiders might be leaking the data out
for whatever reasons.
But I think even more commonly, the reason is that--
like if you look at the scale of the various public Cloud
Storages that are out there, managing permissions at that
scale, and especially when you have fine-grained permissions--
like if you have object-level permissions, right--
managing permissions scale and ensuring
that you have the right security posture through and through,
across all this granularity is a very hard job.
So what we see is most often, customers' data
end up being in the public internet because they
don't know that they don't have the right permissions
and settings.
And in order to address this, we built
a capability, which is called this Public Access Prevention.
It's a one-click experience.
It's a single setting.
You can set it at bucket level.
You can set it in the resource hierarchy
anywhere in the organization, or in the folder,
or in the project.
It's one button you click.
And it ensures whether you are using IAM policies,
or you are using [INAUDIBLE],, or you are using IAM conditions,
right?
Whatever be the way you are managing your permissions,
there is one button, which you click,
and you say my data should not be publicly accessible.
Versus with some other public cloud storage
services out there, where you might
have to deal with nine different buttons
and figure out how to have them work together.
NISHANT KOHLI: No, that's--
I mean, it seems pretty simple to set up.
Can you talk a little bit more?
It's a great feature that we've introduced.
It's now hopefully GA and being used.
So how publicly is it being used by our customers,
or how successful are we with this spec capability?
SUBHASISH CHAKRABORTY: Yeah, so this
is one of the most popular features I have seen.
From the time of launch, it has been,
I think, roughly six months at this point.
We have over 400 enterprise customers using this feature.
We have over 400K buckets, which are protected
using Public Access Prevention.
So this feature has had one of the strongest adoptions
options across the board.
And from the time we GA'ed this feature until today
in six months, we haven't had a single customer support issue.
So it shows not just quantitatively
we have had a lot of traction, but even in terms of quality,
it has been a good feature for our customers.
And we hear from a lot of customers on a regular basis
that they are super happy with this feature.
And more and more customers are integrating
this in their Terraform flows or any kind of automation flows
so that this best practice is instilled
into all of their workflows.
NISHANT KOHLI: No, that's amazing.
So, you know, especially like you said, at the scale
that this feature can get adopted,
and getting automation in place, and ensuring
that customers at a get-go are protecting
their data from a public access seems like a great capability.
As far as going across, let's look at potentially
how easy is it?
As you mentioned, it's a simple click of a button.
So let's look at that aspect of it if you can walk us through.
SUBHASISH CHAKRABORTY: Yeah, so here
you see this is the Google Cloud Storage GUI.
This is the bucket creation flow.
And as you create a bucket, you can choose and enforce
Public Access Prevention.
So you can say Prevent Public Access.
We strongly recommend that you have this setting.
Once you have this setting on, then it
doesn't matter whether you have uniform bucket level access,
or you have fine-grained permissions,
or whether you are only dealing with IAM policies,
or you are doing with bucket [INAUDIBLE] or object
[INAUDIBLE], right?
And as I said, various other ways.
Like, you might be having IAM conditions and all that kind
of stuff, right?
Whatever way you are managing permissions
for that bucket, this one setting
with ensure that none of your data
can ever end up in the public internet, right?
And then if you go to the next page,
once you have created your bucket using this setting,
you can actually go to the Permissions tab.
And you see that your bucket is not public, right?
And this was the example where you set it at a bucket level
when you were creating a bucket.
But if you go to the next screen,
over here, what you would see is you can go to Settings.
And you can actually go to a project level.
And you can set Public Access Prevention at a project level.
That will ensure that all the buckets which are already there
under that project, or any future buckets which
get created, all of them will have Public Access
Prevention enabled.
And actually, it's not just at a project level,
anywhere in the organizational hierarchy.
So it could be folder level, it could be the org node.
At every level, you can set it on.
And that ensures all resources under that level
will have this protection on.
NISHANT KOHLI: No, that seems pretty straightforward,
simple to set up and configure.
And you mentioned once you set it up at the project level,
all the buckets within that project
will naturally adopt that capability.
And then the same thing, you mentioned when configuring PAP,
it's a bit of a superset.
So even your IAM policies, granular policies
can take effect.
But the Public Access Prevention even
protects from anybody getting visibility to bucket
from public access completely.
So it seems like a very good way of protecting customers' data.
No, it seems like a great capability.
SUBHASISH CHAKRABORTY: Yeah, one of our big concern
here was there are so many different ways to manage
permission.
Unless we build something unified like one button, which
can take care of everything, the combinatorics,
it might be hard for customers to manage.
So that was our main emphasis here,
make a very simple feature, which is unified,
which works across all different ways.
NISHANT KOHLI: No, that's awesome.
So I think this is great.
Let's talk a little bit more around the next level
capability that we are thinking.
Often, challenges when customers are protecting data
isn't external.
There generally happens to be internal.
Most data we've seen, or data losses scenarios we've seen,
are prone due to human error or maybe a rogue application gone
wrong kind of challenges.
So let's talk what we were doing in Cloud Storage
to help our customers, protecting
from internal failures or internal malicious actors.
SUBHASISH CHAKRABORTY: Yeah, so we
talked a little about how to prevent your data from getting
access to outside, right?
Like, if your data gets hacked, that's a big problem.
But I think even more common problem
is if you accidentally end up deleting your data, right?
What we have seen in the last few years is,
I would say more than 95% of the cases,
customers end up having a data loss situation on their end
or accidentally deleting their data
because of either an operator error, somebody just deleted
something by mistake, or many times,
you have various softwares where they can end up
deleting the wrong artifact or ending up
deleting the wrong version of the data
that you wanted to delete.
So I think this accidental, or fat finger in use cases,
are the major contributors to customers ending up
accidentally deleting or overwriting their data.
And in order to address this, object storage like Google
Cloud Storages and Object Storage,
it has a unique capability where it is transactional.
Every single time you write, it is a new version, right?
So if you look at, traditionally, the various file
systems or the block storage services,
they are journal-based.
So the snapshotting capability you have is point in time.
So you can say, OK, roll it back to this point in time.
And then you get the entire set of changes,
rolls back to that, right?
Versus an object storage, you can be super fine-grained
because every single write is a new version.
So we took care of--
we took advantage of that capability.
And we put together a new feature,
which is called a Soft Delete.
So what Soft Delete does is, it uses versioning.
This capability that our object storage has, versioning,
and it also uses object lifecycle management together.
And it gives you a capability where
if you are creating a bucket, we would recommend
that you have at least one version saved for seven days
if it is your standard storage tier.
And as you get to older storage tier,
it could be one version for 30 days.
Or it could be one version for 90 days per coldline
or one version for one year for archive, right?
So in this feature, we wanted to ensure while you actually
are protected with versions, but at the same time,
it is cost-effective.
You don't end up in a situation where
you have no control over how many versions your data
may end up having and what would be the implication on cost.
So Soft Delete ties together versioning
with object lifecycle management and ensures
you can specify how many copies of version,
how many versions you want to retain, and for how many days
you want to retain.
So that is the magic of Soft Delete.
NISHANT KOHLI: So it sounds like what we're doing is
we can't prevent human errors.
But at least we can prevent resolving from those errors.
So combining our capability with soft delete and versioning,
we're able to help customers prevent failures.
And you mentioned in the general, when
these failures used to happen previously,
what was the customer experience when
we didn't have this feature?
SUBHASISH CHAKRABORTY: So when we did not have this feature,
usually the customers would file a support ticket.
And they would work with the Google Cloud Storage
Engineering.
And it was a difficult experience for everyone
because our policy was per customer during the lifecycle
of engagement with the customer, we
would only entertain it once.
And we would then recommend that they use versioning.
But customers had some challenges
with versioning because versioning
without requisite object lifecycle management rules
can have implications on your cost.
So since the time we have launched this capability, now
the new experience is that it is self-service, where in the UI
or in the API, you actually see, OK,
these are all my deleted versions.
These are non-current versions, we call them.
And then you can actually restore.
So it's a self-service experience.
It's an experience of ordering the GUI, and the API,
and all the tools as well.
And what that has resulted into is
today we have 16 million buckets which
are protected with versioning.
And since that time we have launched it,
around the same timeline as PAP, in the last six months,
what we have seen is there are 8,000 instances where customers
have self-serviced restores.
You know, and it was an instantaneous experience.
Like, they just went into GUI.
They just restored it.
It was instantaneous.
They didn't have to engage with customer support,
buy the ticket, go through all these high touch
point experiences.
NISHANT KOHLI: Yeah, so it sounds
like having this capability helps our customers not
necessarily prevent from the failures,
but resolve from the failures on their own.
They can resurrect the previous versions and go back.
You mentioned some of the settings.
Hopefully in the next few slides,
we can kind of show some screenshots.
So let me go to that and help our customers prevent
from maybe using too much storage as they
provide this capability.
So let's walk through some of the things
that we have for here.
SUBHASISH CHAKRABORTY: Yeah, so this is, again,
the bucket creation flow.
So as you create a bucket, with soft delete abilities,
you can actually choose object versioning.
You can say, yes, I want versioning
to be enabled for my bucket.
And then you can choose what is the max number of versions
that you want to retain in this bucket per object, right?
So this is the example of the standard storage class.
So you say, by default, we have one version in seven days.
By the way, these numbers are-- as you can see,
you can edit these numbers.
If you say, oh, I'm not comfortable with one version--
I want to keep three versions, and I'm not OK with seven days.
I want to keep 30 days.
This is my organization's policy.
This is my compliance requirement, right?
So you can change these numbers.
By default, we have kept numbers which we think
are fine for most customers.
But these numbers can be overridden.
So this is the bucket creation flow in the bucket creation
flow.
As you can see, we tied together versioning
and object lifecycle management.
And then if you go to the next screen, so here, after you have
created the bucket, you can see that object versioning
is enabled.
And you can also see right below it
that you have your object lifecycle management policies.
If you want to manage the rules, you can go there.
So one is at the time of creation.
But later on, if you want to modify,
you can go and actually manage the rules as well.
And then if you go further, so this
is when you delete something.
So when you are trying to delete something, this [INAUDIBLE]
is telling you that, although you are deleting--
but because versioning is enabled,
you might have a non-current version of this saved, right?
So if you go through--
so we are now in a situation where
you have deleted something.
But you can see in object versioning that
is a live object and then there is
a older version of the object.
So now you want to recover.
So say you want to restore from the older version.
So you select that older version.
And you say I want to copy from this older version
into the current namespace.
So you do a copy.
We call it a copy, which is more like an export operation.
And this way, you can restore.
And the beauty of this is you might
have your existing live object.
And now you have restored from an older version.
And this doesn't override the existing live object.
Now you have two.
And then you can reconcile.
Then you can say, OK, the one that I
restored is the one I want.
And you can say, oh, I restored it.
But it's not really the one I want I want.
I'm OK with the live one.
So we give this capability to customers.
NISHANT KOHLI: No, it sounds like customers have a lot more
power, control in case of a failure,
or even in the case of an override
that happened while they were working on an object.
So this gives the better granularity and control
from any either application errors or even human errors
that customers may have at the object level.
So, no, it sounds like this is a great feature of functionality
and heavily being used with our customers
to help prevent from failure.
So this kind of concludes our series of two key features
that we recently introduced and are heavily,
popularly used by our customers, from not just protecting
their data from internal errors, but also
helping customers prevent exposures
from external malicious actors and giving them
a very simple, easy way of ensuring that data
is protected at all times.
SUBHASISH CHAKRABORTY: Yeah, and we already
hear from customers, all the customers who
are using this features, how it has
made their life so much better and less exciting in good ways.
So the reason we are doing this podcast,
we are doing this session, is to basically share
that with a broader audience and ensure more and more
customers have awareness of these capabilities.
And hopefully, they can use these capabilities.
And it can make them sleep better at night.
NISHANT KOHLI: Well, thank you very much, Subhasish.
And thank you, everyone, for joining us.
And stay tuned.
We'll be continuing more of these series
to help you understand your data protection strategies
and preventing your data from getting leaked
or being destroyed accidentally as we go through from a Cloud
Storage perspective.
Thank you very much.
SUBHASISH CHAKRABORTY: Thank you.