Explore shared access signatures as a means of granting minimum privileges for accessing an Azure Storage account, limiting the access to a service, to a type of access, and even by a date/time.
- [Speaker] To adhere to the principle of minimum privilege, we will avoid using shared keys and rather use Shared Access Signatures as a way of providing the specific limited privileges in client needs for accessing a resource within the Azure Storage Account. In particular, Shared Access Signatures are use for blobs, files and other mechanisms where we want to grant a specific permission to a client to take a very specific action. Looking in the Azure portal, select one of your storage accounts.
And below the overview, below access keys, is Shared Access Signature. Click on Shared Access Signature and you'll see several options on the right hand side. So Shared Access Signature is essentially a unique token being generated for a client for specific purpose. In particular, we can limit by service. So we can't run access to just one service, be it blob, file, queue or type of storage. We can limit the access by the type of resource, service, container, object itself and of course read, write, delete, these all distinct permissions and we can select what's appropriate for the client.
In addition, you can limit this by time. So if you're granting a client access to a particular resource, you may want to limit this by time and say that, this token is now available to the client and they can conduct an upload or a download maybe in the next 10 hours. But then, expire the token so it does not left forever. You can also limit by client IP addresses, so you only allow access from certain locations. And the token itself, will also specify whether HPS is required with the both HB and HPS is allowed.
Do you notice all the way to bottom? This is dependent on the keys. So you actually use the keys from access keys, your root keys at full access to generate the size token. Let's click on generate size and when you scroll down you can see an example. There is a size token, starts with a question mark, lots of interesting information but also notice that they are URLs that encode the token. So if you look at the blob service URL, doesn't matter what it says inside at the moment.
But notice it has its HTPS, a domain name, forward slash and then that is followed by the token. So we'll see that structure throughout our current examples as well. The things to know, your shared access keys from before, are essentially root or administrator on your storage account. They can do anything. So whether they disclose inadvertently Or whether assigned to a client specifically they grant full access. SAS tokens is a better approach and that it allows us to provide minimum privilege to clients. So a client who needs to take specific action gets only the privileges permissions required for that action.
So whenever possible, use the SAS tokens instead of the shared access keys. The nice thing about SAS tokens are that they are in fact generated on the client. The server has no involvement here. The storage account actually does not participate in generating the SAS tokens at all, which means you can generate essentially an infinite number of these. Once the tokens are generated, the storage accounts keys are not necessarily on the client's side. And so you could store SAS tokens, you can exchange them and you can essentially generate them on a privilege client and then share them with the clients that needed the minimum privileges.
Bear in mind though that these SAS tokens are essentially secrets, so always use HPS. As you pass these tokens around, if you make an inappropriate copy of them, they could be misuse. So now we have two ways to access storage accounts. We can authenticate using the access keys essentially as a root or administrator user or if you use a SAS token, to authenticate and get authorization to use specific services in specific ways. And so do minimum privilege for the clients that needed specific access.
- Creating a storage account
- Shared key authentication
- Using shared access signatures (SAS)
- Granting privileges with stored access policies
- Managing the visible time property
- Queue metadata
- Queue access control (SAS)
- Performance constraints of Azure Queue Storage