Securing Storage Accounts

Posted by Matthew Bradley

Secure data

There have been a few instances in the news recently where data stored with a cloud provider has been compromised due to misconfiguration of the storage account.

What ‘misconfiguration’ actually means is that the storage accounts were created insecurely with things like open anonymous access enabled.  Which is like giving copies of your car keys, house keys, bank details, D.O.B, first pets name and mother’s maiden name to everyone who you meet in the street.

Luckily, the above cases are quite extreme and rare, however there are other things that sometimes get overlooked when it comes to storage security:

Access Keys

When you first create a storage account, Azure will generate Storage Access Keys that can be used to access the storage account; it even gives you a connection string that includes this key so that applications can access it. Nice!

However, Access Keys give root level access to the entire storage account and so you need to be extremely careful about where and how these are used.

If you use Access Keys on a public facing website then it is possible that people can retrieve them.  Sure, you can add encryption within the config files to protect them and restrict access to those files, but if you forget one part of this then you could be in for a really bad time. Things like this give too much room for human error and should be avoided where possible.

Even if you trust the people accessing the data with your life, someone could still accidentally delete a container or all data from an account, causing you downtime and a weekend of data recovery.

When you install a server, you wouldn’t give out the root or local admin user credentials to everyone who needs access to the server (hopefully not anyway).  Typically, you create standard users to limit the permissions that the accounts have. Which brings us on to the next point.

Shared Access Signatures

Shared Access Signatures (SAS) give you a URI that allows users or applications to connect to your storage account with far more granular control. The screenshot below shows the options available. In my example, I have set the policy so that the SAS token only allows access to Blob storage from a single IP address and with limited permissions:

The SAS is signed by one of the Access Keys (but the Access Key is not part of the URI) and a SAS token is then generated, which can then be used in a connection string:


The above may look daunting but it can very easily be broken down to explain what it means. I would recommend getting to the point where you are able to understand the permissions and limits of a SAS token just by looking at the URI.

As you can see, Shared Access Signatures do have an expiry date, but you can set this date as far in the future as you want.

The downside of Shared Access Signatures is that they can’t be revoked! There are only three things that invalidate a SAS token:

  • When the expiry date is reached.
  • If the Access Key used to sign the token is changed.
  • If the Stored Access Policy referenced by the SAS is deleted (which brings us to the next topic…)

Stored Access Policies

Stored Access Policies are used in conjunction with Shared Access Signatures and can be used to manage constraints for one or more Shared Access Signatures.  You can use a Stored Access Policy to change the start time, expiry time, or permissions for a signature, or to revoke it after it has been issued.


Stored Access Policies used with SAS tokens give far more control over storage accounts at the container level and these two should be used together where possible. 

Don’t worry, we’re nearly at the end now. There is just one more thing that I want to discuss that fits within this topic…


vNET restrictions

Having permissions set on containers is great. But where possible, you should also restrict access to your storage based on source location. If the only things that need to access the storage accounts are within your Azure subscription then you can limit access to them based on the vNET that the application servers are in. Alternatively, you can restrict based on source IP address or CIDR range for sites that are more fitted to this type of restriction. vNET policies can be set at the storage account or container level, so please use them if you can.


If you have any questions above the above then feel free to drop me a message or leave a comment.

Back to Blog