Securing Blob Storage

Securing Blob Storage

So one question, that I find is largely overlooked but very much critical is specifically how to secure blob storage. The idea being that you are storing data in the cloud, using blob storage, but the question becomes how does an application make use of those storage accounts in a secure way.

And just like anything, there are a lot of steps you can take to secure your blobs to make them accessible without adding a lot of complexity to your application.

Encryption-At-Rest

So by default the azure blog storage, will encrypt your data at rest. And there’s a great write up for that here. But more than that, you can also use customer managed keys. Now the biggest benefit to that, being that you have complete control over the keys used for encryption.

Encryption-In-Transit

From a client side and transit perspective, all of the SDKs, and client communication with Azure Blob Storage is done enforcing https. So by default, the communication is secured using https. So this is abstracted for the most part.

Securing the Endpoint

You do not have to expose your blob storage accounts to the internet via a public endpoint if you don’t want to.  As denoted here (or here), you can use service endpoints to lock down traffic to a blob storage account to only traffic within a specific virtual network.  So you are not required to use public endpoints.  We also now have additional options of using Private Link to further provide isolation to allowing traffic to move through the azure backbone only. 

Just-In-Time Blob Access

Every security technology will point to “Just-In-Time” access as being a strategy for preventing breaches. And storage is not different, and the recommendation is to not use the key that could grant access to an entire blob account or container.

Instead the recommendation would be that you leverage SaaS tokens, which can be configured to control the access, scoping down to a specific blob, and setting an expiration time.  This ensures that you can leverage a single token for a single use, and lock down the actions that token can be used for.

Here is an article that goes over how to do this in C# as an example using the SDK.  Additionally, you can leverage Stored Access Policy to standardize and lock your SaaS tokens, so that no developer can create an application that violates your standards on this to ensure traffic is secured. 

This ensures that you are giving a “single use” token that cannot be violated as you’ve mentioned above.  Additionally you can make this more secure by using Service Principals and Azure AD to secure the token generation, and block all access to the blobs without Azure AD or Ad Hoc SaaS tokens. 

The best thing that we can do here is to make sure you are using short lived tokens, which is the common practice I have leveraged in the past to prevent the ability for people to be able to “crack” the key.  We also have a listing of the recommendations we have for access with blob storage. There is also additional options to enable Threat Protection and Security Center around Azure Storage.

Leave a Reply

Your email address will not be published. Required fields are marked *