This is the second part of the Azure Storage Best Practices series. Here I am going to focus on the best practices for authentication in Azure Storage and how to design your cloud service for security.
Best Practices for Authentication in Azure Storage
Best practices from authentication in Azure Storage and also from your client applications to a great extent. You need to choose the right authentication method. There are various authentication methods.
1) Symmetric Shared Key Authentication – This is where you go to the Azure portal, you get this two 512-bit keys that you have. You can use these 512-bit keys in trusted applications. So you can use these keys in those trusted applications because it gives that service all the power in the world to access your storage account, delete the container, delete blobs, and things of that.
2) Shared Access Signature – This is where the owner of those two 512-bit keys would say, well, I want to give maybe read access to a particular blob or to a particular container, to a subset of users. And so you will create these pre-authenticated tokens and then you give it to the users so that they can use these tokens to access it. If you’re writing a web app which is supposed to give access to your blobs, you don’t have to make all your requests flow through storage through your proxy servers as such. You can just give out SAS tokens. What this enables is for your application to just scale enough to give these SAS tokens, but not necessarily all the gigabytes per second ingress or egress that your clients need. And so it reduces your calls. You don’t need as many VM instances. You just give out the shared access signature, which is time limiting, permission limiting, and to the subset of resources that you want to give to the subset of people. And so you can use this to kind of reduce your calls in your applications through the sharing of data.
3) Public blobs – I usually use for CDN access or also if you want to give access via browsers.
Best Practices for designing your service for security
How do I store these secret keys or how do I store my shared access signatures?
A common pattern is to encrypt these using a cert and then store that cert on the nodes that need access to it so that only those nodes have access, can decrypt the keys and start utilizing, rather than storing unencrypted keys.
How to transfer SAS tokens?
Use HTTPS because anybody to gets access to this token has access to your data.
How often should I change my secret keys or SAS tokens?
As often as possible. That’s a very good practice, so we recommend you build automation around it so that this becomes a very common, mundane process as such, where we can keep executing it as needed.
How do I rotate my secret keys or the SAS token?
It’s the two 512-bit keys that come into picture. You have two 512-bit keys. So the way you would do it is, select one of them and make sure all your application configurations have changed to use this particular key. You have key one and key two. So make sure you use, let’s say, key one. Rotate your key two using service management API. And then the next time when you need to rotate, you will push key two to all the applications so they start using key two, and then you rotate key one. And so you can use this rotation mechanism to kind of make your secret keys a little more secure as such.
Best Practices for Shared Access Signatures
1) Authenticate the service that is requesting the SAS token. You can use your own kind of authentication or authorizers to hand out the SAS token.
2) Use HTTPS while giving out these SAS tokens.
3) The token provider and the consumer need to agree on a REST version. These REST versions can have breaking protocol changes, for example, or sometimes some new features that really belong in the newer version. For example, if you give out a SAS token which is for 2012 for Tables and if I get that SAS token, I cannot use JSON for stabilization. I’ll be stuck with AtomPub; right? And so you need to make sure that when you give out the SAS token, you can give multiple versions of the SAS tokens to your users depending on what client library they’re using or what version they want to use.
4) Clock skew. Clock skew is a problem out there. It’s going to exist. So the way to work around that would be, for example, if you don’t have a hard limit on the start time, to not have the start time in your SAS token so that the access begins as soon as the first request with that SAS token comes in. For the end time, make sure you have enough buffer for your end time as such.
5) Provide the right granularity of permissions
6) Restrict the resource access. So for blobs, for example, if you want to just give access to your blob, then set the resource type to be blob rather than the container, which gives access to all the blobs. Things like that you can do, and then the Table Service, you can restrict the exact key range which you want to give access to. So by using the starting PartitionKey, RowKey, and ending PartitionKey, RowKey, so you can control that access to the right set of resources.