If you read through the security recommendations in Azure Security Center, you do get given out to a lot. A lot of it makes no sense if you understand Azure and the recommendations. One that appeared to make sense was to enable the relatively new firewall in Azure Storage:
- Only allow trusted subnets – nice idea to limit the attack surface on the storage account in conjunction with service endpoints.
- Allow “trusted Microsoft services” to access the storage account (on by default).
Note: A storage account can only be connected if you know one of the really long random access keys.
But if you do enable this firewall in an Azure deployment, things will break:
- Boot Diagnostics: Does not know how to write to a secured storage account, even with firewall rules and service endpoints enabled.
- Serial Console Access: Requires Boot Diagnostics to be working so that’s dead too.
- NSG Flow Logs/Traffic Analytics: Another feature that doesn’t understand a secured storage account, even with “trusted Microsoft services” marked as enabled (default).
And there might be more!
So you have to aks yourself – do you want maximum security or a usable & manageable system? Storage account firewalls are pretty new – we didn’t need them a few months ago. So we can drop that feature, and maybe use the new Advanced Threat Protection for storage accounts feature instead?
It’s a pit that some joined-up thinking and integration testing weren’t done here.
Azure Files (which uses a storage account) can’t have firewall on if you want to enable backup. So it’s either a fileshare that is reachable on the entire internet, or a solution that you can’t backup..
Another issue with firewalls on storage is you can’t write to them from Runbooks in Automation accounts, because runbooks are not classed as trusted Microsoft Services! Apparently the workaround is to install a runbook worker agent on a VM then enable access form the subnet the VM is on and tell the runbook to run on the VM, which kind of defeats the point of “serverless” runbooks!!!!