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.
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.
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.
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.
It requires that you have storage logging turned on.
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.
Shamir Charania, a seasoned cloud expert, possesses in-depth expertise in Amazon Web Services (AWS) and Microsoft Azure, complemented by his six-year tenure as a Microsoft MVP in Azure. At Keep Secure, Shamir provides strategic cloud guidance, with senior architecture-level decision-making to having the technical chops to back it all up. With a strong emphasis on cybersecurity, he develops robust global cloud strategies prioritizing data protection and resilience. Leveraging complexity theory, Shamir delivers innovative and elegant solutions to address complex requirements while driving business growth, positioning himself as a driving force in cloud transformation for organizations in the digital age.