Hello and welcome back to Siberia's Microsoft Azure Administrator. A Z 103 course. This is Episode 22 storage account access control and I'm your instructor, Will Carlson.
In today's episode, we're going to discuss access keys and some of the pain points associated with their use and how a shared access signature can help us alleviate some of those concerns but still offers some concerns of its own. And we're going to give a little bit of a nod to something coming up in a future episode
that will help alleviate the concerns of both of these items.
To get started, we're gonna jump right back into portal as usual,
and we're gonna go to the storage account that we've been living in these past few episodes.
We're gonna click down into that storage account, and we're gonna start our discussion today. Here, under settings access keys.
Now the text up here at the top of the page. Talk about these access keys as being the keys that you'll use programmatically for your applications to securely authenticate and access and azure storage account. And that's true. That's exactly what they're here for.
They also figure into shared access signatures that we're gonna talk about in just a minute so they're not your relevant for our discussion if you don't plan on doing any APP development.
So there are two keys here to facilitate a concept called Key Rolling and Key. Rolling is when if you have this key key, one in an application and it's using that key to access your storage,
and then let's say there's a compromise. Or maybe you're just being proactive with your security and you want to generate there. You want to install a new key so you don't continue to use the same old key for forever.
What you can do here because Azure was smart enough to give us two keys, is you take your application and replaced Key one with key to. Then you can click this button here and regenerate key one.
If we didn't have two keys in that scenario, when we regenerated key one in the amount of time it took us to copy and paste these connections strings and put them into however many applications we had that we're using that key, we would have downtime.
So the two keys here allows us to key role and change the keys without having any associated downtime with that practice.
One other thing that I want to mention about keys here is that you should store them in a way that's equivalent to the security you would like to provide for the data that that access KIIS securing these access keys are essentially like SSL certificates or any other encryption mechanism. If you want your data to be scared secure
and you send your access keys out via email or post them on the public Internet, you're undoing all of the security that you've tried to maintain.
So by all means, keep your access keys secure.
Also, keep these access keys in mind as we move on and talk about shared access signatures
Because shared access signatures are a way that we can provide a U. R I or uniform resource identify rhe. Essentially, this is a girl string that allows you to access a particular item in the storage account directly and to authenticate improve that you have access to that file.
So remember in our previous example, when we set up the storage account in the Blob in particular, we said that there was no public or anonymous access to our blob storage. So how do you authenticate to that blob storage? Well, you do that by using a shared access signature
you can come through and set The type of service is that you want this shared access signature to apply to. You can say that we only wanted to apply to objects that are blobs, and we're gonna go ahead and allow this shared access Signature toe have full permissions on those blobs.
We can also go in and set the date and time both for the start and the expiration of this shared access signature. One thing to keep in mind here is that this applies to a specific time zone. So when you give this to somebody, make sure that's not gonna cause any problems. If you want somebody to have access now,
it's oftentimes beneficial to go ahead and give access at the beginning of the day so that they can get in right away.
We also have the ability of here to limit what I P addresses can authenticate using this shared excess signature very similar to the way we did with the storage account firewall.
We can say we want this, http, or to allow https only. And here again, these keys show up.
Now, this key being here is important because if we generate a shared access signature with key one and then her normal course of business or because of an event we were to go into access keys and key role and regenerate that key,
it will absolutely break the shared access signature that's associated with that key.
So you do have to be careful when you're key rolling. It will break shared access signatures.
Another thing to be mindful of here with shared excess signatures is going to be that as soon as I click generate,
I will never be able to get back to these three strings ever again. You have to document them now. You cannot go back and see what they were.
The last potential gotcha here for shared access signatures is going to be that there is not a real simple way to revoke them.
Let's say, for example, we wanted to give access to our storage accounts to a temporary contractor, and I gave them access via a shared access signature.
And let's say we put this in date two years in the future, and that contractor terminated, terminated early at the end of a year. Well, clearly, I don't want him to have access to my storage any longer, but with a shared access signature, there's no way simply to revoke it. We do have a couple of options to revoke it. The 1st 1 would be
key role, the key that was used for that shared access signature that would respectively revoke the shared access signature, but with some additional costs. Right? It may break some of my applications, and at the very least, I've got to go in and key role all of my applications that use that particular keep.
I could also go in and delete the storage account or the item that the shared access signature was associated with. So if I associated this with blobs in a storage account, I could delete that blob storage or the storage account completely and then effectively revoke access to the shared excess signature.
But as you can see, those air both pretty nuclear options, deleting the storage completely or key rolling may affect a whole lot more than just these shared access signatures. So azure gives us another solution in stored access policies, which will cover in the next video when we talk about Storage Explorer.
So in today's video, we talked about what in storage access key really is why we have to the two of them in Azure and the concept of key rolling.
We also talked about shared access signatures and how that provides us with U R I to give to somebody to access our storage account. And the shared excess signature gives us more granularity on what we give them access to instead of a full boat access that the access key would give them.
And we also mentioned some of the limitations of both of these approaches, primarily that there's not a simple way to revoke access when it's handed out with a shared access signature or an access key.
So coming up in the next video, we're going to talk about a client installed piece of software called Storage Explorer, and we're gonna also touch on the concept of excess policies that help us alleviate some of the concerns we had with the access control methods discussed today.
Thanks for joining me today for this episode. I'm looking forward to the next one