Securing Azure Storage

This blog was updated to include REST APIs to quickly list Storage Accounts and their security policies

A customer recently asked me “how do I discover Azure Storage accounts that are open?”

First off, we need to define what “open” means. Does this mean “route-able from the Internet” or “anonymous access”? From there, we can share how to answer that question, both from the portal as well as via Az CLI (and REST)!

Azure Storage Security Primer

First, we need a Azure Storage primer…

Goal is not to recreate the wheel here, especially when good content already exists on this topic. So I’ll send you here. Come back in 30 minutes after giving it a good read.

Welcome back!

Hopefully a few things stood out, including:

  • Data is automatically encrypted via Storage Service Encryption
  • AAD and RBAC can (and should be) used to secure Azure Storage access
  • Delegation (time-limited!) can be granted via Shared Access Signature (SAS)
  • SAS can be revoked (and via APIs)
  • SAS can limit which IPs can take advantage of the provided access (i.e. only IP xxx.yyy.zzz.aaa

SAS and RBAC is only necessary however if the Storage is marked private. By default, Azure Storage (as of 2019-08-23) is “accessible” from anywhere in the world over HTTP or HTTPS. That said, authentication is absolutely critical when discussing Azure Storage.

Now, lets do a quick myth-bust to really make sure there is a common understanding on what this means…

Network Security

If the term “open” means it is route-able from the Internet, then this is a pretty easy discussion.

By default, all Azure Storage is route-able. That means anyone in the world can knock on the door of the Azure Storage resource. However, the protection comes in when talking authentication after you’ve reached the Azure Storage resource–only then will the door open.

Note that this is a common misconception, that Azure Storage can be implemented in such a way that only specific IPs can access it. That is not the case, at least not today. Anyone can knock on the door.

Can I change this route-able open-policy?

Yes!

Microsoft Azure Storage has Firewall and Network rules that can be configured for those who don’t want anyone just knocking on the door. Again, by default, only those with AAD privileges can enter the door, but why accept exposure where its not wanted?

Microsoft has this capability, where you can configure the firewall and virtual networks policy for that respective Azure Storage. Furthermore, you can modify the default value of this.

When creating the Azure Storage Account, you can see the policy in the Advanced tab:

If we had modified the default policy, then the ‘Selected network’ would be set with the respective configuration. In the screenshot above, this is not the case–the default policy is still set for ‘All networks’.

How do I discover Azure Storage Accounts not using the Firewall/vNet policy?

Azure Security Center has this built in for its Recommendations dashboard–which is available FOR FREE.

In the dashboard, you can see which Storage Accounts are not using the Firewall and VNet policy:

As it states, the policy checks for:

It will then list all the Azure Storage accounts not taking advantage of this–or rather, are route-able from the entire Internet (remember, this by itself doesn’t mean its ‘insecure’, it just means it may have an additional attack surface that you/CISO do not want to accept).

But I don’t want to use the dashboard…

For those who are still not convinced on the ease-of-use of using Azure’s respective dashboards and reporting, you are in luck. These are just REST API calls away.

Via the Azure CLI, you can quickly see the status of the default rules for a resource group:

az storage account show --resource-group "myresourcegroup" --name "mystorageaccount" --query networkRuleSet.defaultAction

To modify the new default policy:

az storage account show --resource-group "myresourcegroup" --name "mystorageaccount" --query networkRuleSet.defaultAction

There are PowerShell methods to do this as well.

If I wanted to measure compliance against a specific Azure Storage account, I can quickly use Az CLI:

Here you can see I created an IP rule saying only Allow 71.105.xxx.yyy to be able to knock on the door to this Azure Storage Account. Furthermore, you can see I didn’t allow any vNet to connect to this resource.

In the Portal, it would appear as follows:

Want to do this with all resources, just just for a specific resource? Az CLI has you there again. ”’az storage account list”’ has you there, which also lets you specify a --resource-group or ---subscription. In this example, I’ll focus on my resource-group.

Note that today, if we changed the output type (-o), it wouldn’t print these Network Rule Sets.

Don’t want to use Az CLI (or PowerShell)? Take advantage of the REST API, which will output all the Azure Storage Accounts and show you this information as “IpRule”.

For example, in Postman (get started quick here):

Will return the following results:

Regardless, RBAC

Regardless of your thoughts on preventing folks knocking on the door of Azure Storage or not, the best way to control who gets into that door remains strong RBAC.

The information out there is pretty complete when it comes to this, and for that, I’ll redirect you here.

By default, Containers and Blobs are Private, meaning anonymous/unauthenticated requests are not allowed to access data.

Az CLI

To quickly identify these, use the same methods we did with measuring security of our routing…

Az CLI can tell you if a container is publicAccess or privateAccess. Here I had to specify the Azure Storage Account as well as the container name.

You can script this to discover all your Storage Accounts, and then enumerate each to discover any container/blob in those Storage Accounts which are public. And of course, there are equivalent PowerShell cmdlets to do the same.

Summary

Azure Storage security is important. There is encryption, data-in-transit (which wasn’t discussed in this blog at detail), network routing and authentication.

Remember, just because something is route-able doesn’t inherently make it insecure. However, if its both route-able and ‘public’ (anonymous authentication is allowed), then that very well could be a problem if the contents are sensitive.

I hope this helps someone, somewhere, as you have a successful and secure cloud journey.

// Andrew