In the previous diary, I explained the three public access levels of Azure Blob Storage, and how to investigate the setup for any issues. Until a couple of months ago, there was no reliable way to prevent the problem from occurring in the first place, but thankfully, Microsoft has finally seen the light.

At the level of the Storage Account, there is now a new setting "Allow Blob Public Access", which can be set to "Disabled".  

Once disabled, the access level set on the containers within this storage account no longer matters, public unauthenticated access will always be denied:

This adds a welcome additional safety net, because the Containers within this storage account cannot be set to "public access" anymore, not even by mistake:

Even better, there is now also a "preview" rule available for this setting in Azure Policies. Go to Policies -> Definitions, then search for "Public", to find the Policy Definition named "[Preview]: Storage account public access should be disallowed". 

Click on it, select "Assign", and push it to a scope of your choice. Set the parameter to "Deny", and once the policy is active, new storage accounts can only be created in your tenant or subscription if they have public access turned off. If the corresponding setting ("Allow Blob Public Access") under the "Advanced" tab of the "Create storage account" dialog is not set to "disabled", all new storage account creation attempts will fail.

Refer to https://docs.microsoft.com/en-us/azure/storage/blobs/anonymous-read-access-prevent and https://docs.microsoft.com/en-us/azure/storage/blobs/anonymous-read-access-configure for more information, how to audit for issues before pushing a "deny" rule, and any other possible side effects. But once you have this resolved and rolled out as a "deny" policy for your Azure subscription or tenant, you'll sleep better, knowing that you significantly reduced the likelyhood of accidential data breaches via exposed storage accounts in your environment.