Hello, Siberians. Welcome to this lesson on azure storage security. This lesson is part of the eight model off the Is that 500 Microsoft Azure Security technologist cars.
Quick information on what will be covering in this lesson was started. An overview off what are just average is would then discuss the security best practices of other storage would discuss the security concept, off stoppage key management, shared access signatures, access control options
and started service encryption as it relates to as your storage.
Let's get into this.
Let's start by reviewing as your storage
I just love. It is Microsoft's cloud storage solution from modern data storage scenarios. It consists of the following cost services.
First, the Blob Service. This is object based storage for text and by an avid data access years. Invest a P I. Then we have the foul service, which is also object based storage. It can be access using the vest AP high or using the traditional SNB protocols. Useful network shares
that we have the table service. This is a stall for structured, no see called data access over rest a p I. R. Using or data. And finally we have the Cure service. This is a message in service that could be used for communication between the couple application component
on that access using the vest a p i
now for the purpose off the exam objectives. This cost focuses on the blob and foul services. So our conversations going forward or mainly about this to services.
Let's review the security best practices when it comes to adjust of its service. Now this light is just a quick review as we'll be looking at some of the men Point in Ma details shortly. The first best practice is to protect the storage account keys and connection strengths.
Every storage account asked to access keys,
a primary key and a second Ricky. That key grants full access to the storage account on toe all the resources in it. So we don't want that key falling into the wrong hands. So we have to closely guarded this case by controlling we converted them and was access to them. The next best practice is to use
stoppage access controls
on will see the options that are possible in a few minutes.
From an encryption standpoint. Encryption at rest is enabled by default and cannot be disabled. It's called storage service Encryption s E
encryption in trusts, it's It's usually also enabled by default. However, this can be disabled. So what I want to do it wants to ensure that the configuration is set to disable insecure protocols like http SMB Vision 2.1
on SMB vision to re point or without encryption,
make sure those are disabled. Next, we want to ensure that we implements network level protection. Also, this is for defense in debt. We can use the service firewall to configure an I p allowed least. We can also use private endpoint to configure private network access. And finally,
we can implement stoppage Advance trade protection, which is an additional paid Savvis.
They can analyze storage service logs to detect indicators off compromise. Let's look at some of the key best practices in more details. I mentioned earlier that every storage account asked two keys, a primary key and a second Ricky. The best practice is to rotate the keys periodically
on. This is something that we can do manually from the azure Pato. Another option is to integrate as a storied with azure key vote on. We can let key vote Ondo, the periodic automatic Kiva generation.
Now there are four steps to do this.
The first step is to assign the storage account key operator service row to the key vote service on this gives key votes the permissions to least on veg, innovates the storage keys. The naturally wanted you to want toe configure a Kiva generation period are often do we want to regenerate the keys?
After we've done that,
we can assign permissions to the client for them to be able to generate shared access. Signature Talking's signed by the keys that I managed by key vote
and finally, auto vice clients can make calls to keep about two generates a stockings signed by the Stravinsky.
Now at the moment off this recording, configuring all of these options is only possible years in the command line. It's not yet available to configure this year's in the Pato.
Now, even though we have the option to use the storage account keys, it's not recommended to use them just because of the risk involved on the privilege level that a key grants toe weather holds it.
So what can we use instead of the keys we can use a shared access signature talking sass. Talking a SAS token is a your eye that grant access to it protected storage resource for a specific time interval.
It allows client applications toe access, the resource with dodges in the storage account key.
And I said, Best practice. When we're using sass tokens, we can configure the option toe only allow them to be used over https. They're two men waste to generate sash tokens. The first option is at dock with access creation.
We make every quest to the storage service to generate a sash token.
The permissions, the starts time, the expiration time are stored within the talk in the downside, is once with issued the talkin, we cannot change or revoke the access to the talking after has been issued. If we want to change the permission level, we have to re issue in new talking
with the right level of permissions on. If we want to revoke a talking, we after rotates or regenerated the storage account key that was used to sign that token,
and that may involve a lot of management overhead. The other option is to use a start access policy on a start access policy provide an additional level off control over disaster kids that were issuing on the server side. First of all, we create a star access policy
would define the parameters that we want to the starts time, the expiry time on the permissions. We don't make a request to create a SAS token against that policy,
and we can distribute the talking to the users. Are the clients if want to make any for the changes in the future to the permission of the talkin? All one needs to do is modify the start access policy so we can control things on the seventh site
when it comes to access control. We also have other options for resources, and I just storage for the blob services. We have the stoppage keys and the SAS stricken options.
Apart from these, we have the option off using a jury 80 for authentication on authorization off blob service resources. We also have the option to configure on authenticated and only most access, which is not recommended except for specifications cases.
Now for the fire service, we have the storage keys and sass talking options. Obviously, we also have the option to configure as your aided based authorization. But this requires another at your service called as your a D. D s.
Another option is we can use our on premises active directory authentication.
But this requires that was synchronize our credentials from on premises 82 Rajoy 80
as the best proxies. Identity based access control options like a joy 80 on on premises Eddie are considered to be more secure
regarding encryption are just average service. Encryption for detailed rest helps us to protect our data
in autumn. It organization security and compliance commitment with this feature the adjust image platform automatically encrypt our data using A s 256 encryption before persistent that data disks in the azure data centers.
Now S S E is enabled for all new and existing storage account. And it's something that we cannot disable. The process is completely transparent to users
by the fault. SSE uses platform manage keys.
However, customers can and Nancy's would die. One encryption keys start in azure key votes.
Here are some supplemental links for further studies on the topics covered in this lesson.
And here's a somebody off what we covered.
We started with an overview off azure storage with discussed are just average security best practices. And then we discussed the concept off storage Key management shared a sack signature access control options and storage service. Encryption
times very much for watching, and I'll see you in the next lesson.