[MUSIC]
>> Hello, my name is Klaas Langhout.
I'm a Principal Program Manager in Azure.
Today, I want to talk to you about Blob Storage
and Data Protection,
how to secure your Blob Storage.
But first, let me describe
a little bit about what Azure Blob Storage is.
Blob Storage is a PaaS defined service that is produced in Azure,
that is designed for unstructured data storage up to
exabyte scale at very low cost with a high level of control.
We see four different categories of
workloads using Azure Blob Storage.
The first one is applications.
Both Cloud native applications designed from the ground
up to use that scale and that efficiency,
as well as lift and shift from on-premise for
applications that are migrated to Azure from on-premise,
and then start to use Blob Storage.
We also see analytic workloads such as Hadoop and Spark,
that use ADLs Gen2 as
the underlying file system that expands upon Blob Storage,
providing directory and folder structure,
as well as per object
ACL and folder ACLing information.
Third, we also see high-performance computing,
including AI and ML,
such as autonomous driving,
or medical-based solutions such as genomics.
Fourth, we see cold data storage such as backups, logs,
video files, and other sorts of content,
which most people assume would go to an unstructured data store.
That is what we also see as well with Azure Blob Storage.
Now, when thinking about protection,
I want to talk about how do you protect
from a hardware failure or a regional loss.
I also want to discuss how you would handle accidental deletion,
as well as data protection.
How do you protect the data that's at rest from
modification or accidental or even malicious changes.
Then last, we have a feature called Immutable Blob Storage,
which is designed for
financial purposes as well as policy requirements,
which requires the content to
truly be immutable at a fine degree of control.
First, let me talk about how to think about protecting
against both hardware as well as regional downtime.
For that, I want to discuss the different replication options
that you would choose in your storage account for Blob Storage.
Working my way from left to right,
the left most has the least amount of durability,
even though it's quite high,
in that for LRS,
Locally Redundant Storage, we commit the right on
three different drives in three different clusters
before we acknowledge back to the application,
such that even if we were to lose a drive or
one of the hardware clusters that the drive is in,
your data would still be persisted,
we wouldn't have any data loss whatsoever.
Now, ZRS, Zone-redundant storage, expands upon that by
making sure those three different drives are in different zones.
In that situation, even if we have a zone down situation,
there's no impact to your application.
You can continue to write and read from
your application as if everything was operational.
It's a better option if you require
a higher availability for your application at run-time.
Now, we have two dual region options,
which basically adds on to what I previously talked about,
where you want to protect even against
a natural catastrophe impacting one of the Azure regions.
For GRS, Geo-redundant storage,
we copy the data after the commit from the primary site to
a secondary site and we make sure that
the sites in almost all cases are at least 300 miles apart.
That really does protect against
an earthquake or other sort of natural disaster.
Now, we also have finally GZRS,
Geo-zone-redundant storage,
which combines a ZRS account on
the primary region with an LRS account on the secondary region.
You get the same high availability of ZRS in the
primary with the Geo protectedness
of GRS to that secondary region.
With that, I want to talk about protecting against
accidental deletion and there's
different scopes to think about.
All the way from the file or Blob,
how do you protect against those being deleted,
to the container that they sit in,
to the storage account which
contains the containers and the Blobs.
With that, I have a short demo to talk about all three.
In this one, I'm going to go to my "canadaeast" storage account.
The first thing I'm going to do is go
down to "Data protection" in the "Blob service."
When I look at my options there under "Data protection,"
I can see soft delete and I can specify
the number of days to retain my deleted blobs for.
In this case, I'm going to choose 14.
Then I'm going to do the same thing for container delete.
Now the values could be different,
I like to keep them the same.
Now we also have versioning as
a little bit more of a tracking feature,
which can expand upon the other features for protection.
Now, if I go back in my account,
I can also look at locks.
To protect a storage account from being deleted,
I can set an ARM lock.
I'm going to call this "delete protection"
and I want it to be a delete lock to protect against deletions.
I can also add a note here if any other admin in
my organization isn't really clear why this lock is there,
I can add my name or contact information.
I'm just going to leave a short message here.
Now, this lock is in place.
Now, with the lock in place,
if I go back into that same storage account
and then go ahead and delete it,
it says it can't be deleted because there is a lock present.
Now, I've put in a pretty good speed bump,
where if I delegate control to my storage account and
don't provide other people with the same admin credentials I have,
I've now prevented other people from deleting my storage account.
The second main category I want to talk
about is access and security.
How do you basically use
RBAC account key and shared access signature?
What does Defender do and how do you enable it?
How do you ensure that HTTPs is
enabled for all communication to my storage account?
I will also mention that we have
a private link functionality as well as the storage firewall,
where you can create network security around your storage account.
You can set up
the storage firewall that limits access to only known
IP address ranges or
specific trusted services that you allow access to.
Then last, there's immutability where you can set
an immutability policy to prevent
any delete or modification to your Blob Storage.
With that, I'll give a demonstration.
I'm going to go to my "canadaeast" storage account.
The first thing I want to show
is understanding these access keys
and notice that they're in the plain text here,
so I'm going to remove this after this demonstration.
But the account keys is
one way that you can authorize access to your storage account,
but we don't really recommend it if you can help it,
you can also rotate the keys directly in the UI.
Now, besides an account key,
there's also a shared access signature,
which is a much better bet,
where you can specify which service you're giving access to,
you can also specify
what permissions you allow, read, write, etc.,
and you also have control over exactly how
long is this shared access signature going to be good for.
The idea is that you basically craft it with just enough access,
and then specify HTTPs only would be my recommendation,
and then you can handout that
shared access signature to customers.
Lastly, there's role-based access control,
which uses AAD identity.
In this case, I went to this IAM
page and I'm going to go ahead and add for
Chris Green or the AAD administrators
within my tenant a specific role.
Notice that there's owner, and contributor,
and reader which provides access across
all different service types or I have
specific roles explicit for blobs.
In this way, I can provide just read access for instance,
or just contributor access.
I don't have to provide more access than is
necessary to other people in my company.
That provides a lot more control as well.
Lastly, I want to look at
this configuration page and
secure transfer should always be set to enabled,
which means HTTPs is
only used for transferring to and from my account,
and then besides HTTPs and secure transfer,
I also want to look down here, allow public access.
This basically toggles whether or
not somebody can turn public access,
this does not turn public access on.
I just want to be clear about this.
This is an added feature or an added way to
control whether you can even enable that on a container.
In this case, I don't want to
allow public access to be enabled at all.
I'm just going to say disable to that.
This allows me to control what's my minimum TLS version.
TLS is the encryption,
a protocol used with HTTPs.
I can also control that if I want to,
if I was using retail or PCI compliance,
I'd have to set that to 1.3.
With that, I now want to go
to Security Center to show you how you turn on Defender.
From Security Center, it gives me
a one-stop shop for
all of the stuff that I've wanted to do in this frame.
Here, I'm picking the specific subscription that I'm managing,
and notice that Defender is off currently.
Now all I have to do to turn it on is click on
"Defender on" and it enables all of that,
including that bottom checkmark,
which talks about the threat protection
that is in place for Azure Blob Storage.
I'm going to go ahead and click that on and hit "Save" and
now I have Defender on my Storage account.
It also does other things such as
detect anomalous activity against
my storage account and other protections
that I really do
recommend that people run in their storage account.
Lastly, I want to talk about Immutable Blob Storage.
Immutable Blob Storage allows you to set either a legal tag or
a time-based policy that controls if
a Blob can be deleted or modified,
and the policy can either be locked or unlocked.
In the case of a locked policy with objects under control,
I'll add that you cannot delete the storage account,
the container, or the Blobs that are protected under that policy.
I also make it a statement that if you're going to test this,
to be careful that you don't go too far because you
might be stuck in
a situation where you can't delete your test account,
which has happened to me in the past.
With that, let me give a short demonstration.
This time, I'm going to go to a different storage account called
"westcentralusk" and I'm going to
go ahead in my storage account and create a container called test.
Then within test, I'm going to go ahead and
add an object called 512,
that happens to be 512 bytes long.
Then what I'm going to do is take a quick peek at
it and go back to the storage account,
and I'm going to go the container
and I'm going to set an access policy.
Here's where I set my Immutable Blob Access policy.
In this case, I'm going to set a time-based
policy and I'm going to set
the retention for one day
because I do want to clean this up later on.
I'm going to go and lock my policy.
We have a nice warning in there that says this is irreversible.
Now with this locked policy set in
this Blob that I just uploaded right beforehand,
I'm going to go ahead and try to delete it.
It's failed due to the immutability policy.
So now, I just want to delete the whole container.
Same thing. I get
a deletion failure due to the immutability policy.
Last but not least, I'm going to go to
the storage account and I'm going to attempt to delete it.
I get the same failure due to a locked immutability policy,
I cannot delete the storage account.
By doing this, I have protected against
Blob container as well as storage account deletion.
Hopefully, I've described how
you can protect your storage account,
pick the right redundancy level,
and also set some of the specific security settings as well
as enable Azure Defender to protect your storage account.
Please click on some of the links
following for more information
and thank you so much for your time.
[MUSIC]