Azure Storage Security Settings

When provisioning an Azure storage account, there are a few different security considerations at play. The first is determining appropriate levels of storage encryption, which we discussed last week. In this post, we look at some of the security options for the service itself.

supportsHttpsTrafficOnly

For many years, websites typically supported serving their application over both HTTP and HTTPS. HTTPS is effectively a secured version of HTTP, making use of public key encryption/infrastructure to ensure that communication between two parties on the internet can be confidential, and that the message cannot be altered in transit. You can learn more on the EFF website.

By allowing both HTTP and HTTPS, websites opened themselves up to what are called “downgrade” attacks. This is where an attacker works to force a particular connection to use the unsecured HTTP version of a resource, rather than the secured HTTPS version.

Azure storage functions in much the same way. When this setting is turned off, you can use both HTTP and HTTPS to interact with your storage account. While HTTP is ultimately required for edge cases, such as using custom domains, it isn’t required for most use-cases today and you should be setting this to true as a secure default.

minimumTlsVersion

Downgrade attacks do not stop at just encrypted vs non-encrypted traffic, but can also affect the mechanisms used to encrypt the traffic. Over time, vulnerabilities are found in older protocols, and new variants are released to combat new techniques in traffic decryption and or inspection. Here is a good article that talks about some notable attacks against different TLS protocols and implementations.

Within Azure Storage, you can set the minimum allowed TLS version for your service. Services created after September 2020 likely have TLS 1.2 set as a default, but those before may still be sitting at older versions and should be upgraded.

allowBlobPublicAccess

From a service perspective, Azure storage has numerous use cases. Some of those may be public facing in nature, and so, Azure storage has options/configuration to support allowing anonymous access from the internet. Traditionally, public read access was a container level setting, rather than a storage account setting. While this allowed for multi-purpose storage accounts (ones with both public and private data), this had the potential of being misconfigured.

Azure Storage Accounts now support a setting, allowBlobPublicAccess, which, when set to false, overrides any container level or blob level setting you may have.

Azure Defender for Storage

Azure Defender provides continuous security monitoring capabilities for your Azure storage account. From a look through the alerts list this service will give you good coverage by monitoring for:

• Access from unusual locations
• Anonymous access
• Inspection of files being stored (for malware for example)
• Access from unusual applications
• Permission changes

It requires that you have storage logging turned on.

Conclusion

In conclusion, Azure storage is a core component of your infrastructure, and due care needs to be placed on it’s security. Over time, the Azure service has expanded to give you more control over security settings within the service. The above is a list of security settings you should consider for your deployments.

 

About Shamir Charania

Share This Article

Comments