Securing Azure Storage

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 does it mean “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 an Azure Storage primer…

Goal is not to recreate the wheel here, especially when appropriate content already exists on this topic. So, I’ll send you here. Come back in 30 minutes after giving it a thorough 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

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 critical when discussing Azure Storage.

Now, let's do a quick myth-bust to really make sure there is a mutual understanding on what this means…

Network Security

If the term “open” means it is route-able from the Internet, then this is an 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?


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 it's 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 it's ‘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 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 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 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.


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.

Finally, Azure Security Center

Azure Security Center can also provide visibility into your Storage Accounts. More information can be found here.

It can detect things such as anomalous activity (which we can’t do just by hitting ARM calls like above). It can also detect anonymous resource access — again, this is based on someone actively touching your storage account.

On top of that, it can also make recommendations to secure your Storage Accounts. On top of that, all of this can be extended via Azure Policy, which can enforce you to have a compliant, no-drift-from-Blueprint environment! All of this is outside the context of this post, but it is something to keep on the radar as the goal.


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 it's 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.


Written by

Sr Director, Public Sector Technology Strategy at CrowdStrike. Ex-MSFT, Department of Defense civilian. Advocate of human rights, privacy, decency.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store