Shared Access Signatures and Stored Access Policies give control features for accessing data. Learn how to configure Shared Access Signatures.
- [Instructor] As we now know, each storage account is provisioned with two storage account keys, and Microsoft recommends that you do not share these keys. Shared access signatures allow you to securely delegate access to resources without sharing those keys, and stored access policies provide another layer of control in conjunction, with the shared access signature. You'll want to use shared access signatures or SAS when you want to restrict access to storage. By default, the primary and secondary keys allow for full administrative access to your storage account.
SAS allows us to restrict those permissions. SAS will allow us to set an expiry date. When a certain date arrives, that resource is no longer available. We can provide granular access to resources. For example, we can allow read, write, or delete, or a combination of these. If we need to restrict access based on an IP, we can do it using SAS. We can also restrict access based on the protocol. Being HTTP or HTTPS.
There are two types of shared access signatures. The first one is an account shared access signature. Which delegates access to multiple storage services and allows for read, write, and delete. The service SAS delegates access to only one storage service. Only the service SAS can reference a stored access policy for additional security. We'll be discussing shared access policies shortly. Before you go ahead and jump in and start sharing everything using your shared access signatures, there's a few risks you need to be aware of.
If the shared access signature is leaked, anyone who has that SAS can compromise your storage account. If you have applications that depend on that SAS link to have access to the storage account, those applications will be affected when that SAS link expires. This is something you'll manually have to manage. And you'll always want to validate the system use of resources that are accessible via SAS. To add another layer of control on top of SAS we use stored access policies.
A stored access polity provides more control by further restricting our access to the storage account. By linking the SAS to the stored access policy, you can modify the permissions to the resource without recreating the SAS link. Your shared access signature will reference the stored access policy. Which will then allow you to change the start time, change expiry time, change the signature permissions, and revoke that signature without changing the access key. Stored access policies or SAP are supported on blob containers, file shares, queues, and tables.
And keep in mind a maximum of five policies can be set at one time. If you try to exceed this, an error code of 400 will be returned. Now that we've covered off the basics of shared access signatures, let's go ahead and create one. This is a very simple process. You can use the portal, PowerShell, or the new Storage Explorer. Which is currently in preview. I'm going to show you how to create a SAS using the portal and the Azure Storage Explorer. I've logged into Azure and I'm looking at my existing resource groups.
We're going to focus in on our resource group called manage access, and you'll notice that I have two storage accounts here. The one we've been working with, which is our access demo, and we have a second account called storage demo SB. We're going to continue to focus in on our access demo. In order to generate a shared access signature, we can go ahead and click Shared access signature under Settings. Going to scroll over a little bit just to give us a clearer view, and if you will notice that we do have a blurb up at the top.
Microsoft is further explaining why we use a shared access signature. We can now go ahead and configure our shared access signature. Our first option is allowed services. Do we want the shared access signature to allow access to a blob, file, queue, and or table? I'm going to go ahead and uncheck queue, and you'll notice our allowed permissions for process has been grayed out, and now I'm going to go ahead and uncheck table. And now update has been grayed out. You're only going to be able allowed to set permissions on objects where those permissions are valid.
Next, which resource types are we going to allow for? A service container or object. I'm going to leave all three as is, and then our allowed permissions. Our read, write, delete, list, add, and create. I'm going to go ahead and click Delete. Next we have our start and expiry date and time. You'll want to keep your expiry time short to reduce long term exposure. Especially for one offs or add hawk scenarios, and a little trick, if you want that link to be valid now, set your start time to 15 minutes prior to the current time, or remove that time completely.
When you set the time for 15 minutes prior, it reduces the chance of failures during the first few minutes of provisioning, and when you remove the start time completely, the link will be valid immediately. You'll set your end time, you'll pick your UTC or local depending on what option you prefer. Next we can allow for IP addresses. Traffic coming from the listed IP address will have access to that storage account. Next we have our allow protocols. Microsoft does recommend HTTPS only, and then our sign in key.
Key one or key two, and again these sign in keys refer back up to our access keys. And then we're going to go ahead and generate the SAS. I'm going to scroll down a little bit. You'll notice that we now have a blob service URL and a file service URL. Let's take a look at these in a little bit more detail. I'm going to go ahead and copy them, and now I'm going to paste these into Notepad just so we can see them a little bit easier. I'm now going to copy that URL into Notepad.
I'll make it a little bit bigger. It's a little bit easier to see. First you'll notice we have our URL. Storage services version VSV gives us our version. Next we have the type of storage service. We have blob and file. Next we have our permissions. Those are the permissions that we set when we created the SAS link. Then we have our start time and our expiry time. Finally we have our protocol and key one.
Now let's go ahead and show you the same process using Storage Explorer. I've launched the Microsoft Azure Storage Explorer. Please note this is still in preview, but if you're looking for a way to manage your storage accounts within Azure, this tool is fantastic. I've been using this the last couple weeks and loving it. I'm going to go ahead and locate my storage account. Again, this is access demo, and then down at the bottom you'll notice under Actions, I can go ahead and generate a shared access signature.
I could also go ahead and right-click on the storage account as well. And we'll have the same variables here as we did when we did this through the portal. You'll go ahead and pick and choose the permissions that you would like for that shared access signature, and then you go ahead and click Create. I'm going to go ahead and click Cancel. Using shared access signatures and stored access policies allow you to finally control who and what has access to your storage accounts, and for how long.
- Implementing storage blobs and Azure files
- Managing access
- Configuring diagnostics, monitoring, and analytics
- Enabling and viewing logs
- Implementing Azure SQL databases
- Implementing recovery services
- Creating an Azure Backup vault
- Configuring the Azure Backup agent
- Backing up and restoring files
- Backing up an Azure virtual machine