In my previous post, I took deep dive into
AWS S3 permissions to outline the myriad of ways someone could expose their AWS S3 buckets and objects to everyone on the Internet.
As I discussed there, the complexity of the S3 permission system is very powerful and provides users with a lot of flexibility; however, it also makes it very easy to accidentally expose your sensitive files and suffer yet another S3 storage breach.
Microsoft Azure offers a similar storage service to S3 called Azure Storage, and it offers similar capabilities to expose the objects you have stored there to anonymous read access over the Internet.
The public access level system that Azure provides, however, is far less complex than AWS S3’s. While some may feel more constrained by a less flexible system, in my opinion, it’s a far better one if security is a concern.
We all know that complexity is often the antithesis of security, and I believe that the simplicity of Azure’s public access policies greatly reduces the risk of suffering an Azure Storage Breach similar to the AWS S3 Storage
breaches we so often see in the news.
In fact, you’ll be hard-pressed to find any news articles about a similar breach for Azure Storage that has been made as public as the S3 breaches have been made – and while that may partly lend itself to AWS being more widely used than Azure today, I think the difference in complexity between the two public access control models is certainly a contributing factor.
Regardless, it’s just as possible to incorrectly configure your Azure Storage containers to expose sensitive information to everyone on the Internet, so steps must be taken to ensure you don’t suffer a storage breach.
Let’s dive a bit into how Azure permits users to expose their objects in Azure Storage.
Azure's equivalent to S3’s buckets are called containers, and the equivalent to S3’s objects are called blobs. Each of these containers has a public access level setting that determines whether or not the blobs in that container are exposed publicly on the Internet. Each blob inherits the public access level from the container it resides in.
Of course, Azure does provide additional methods of granting access to containers and blobs for more fine-grained control of access to your blobs, such as by granting access via a
Shared Access Signature (SAS).
However, if preventing an Azure Storage breach is your main concern, your first and most important step to securing your Azure Storage environment is ensuring that your blobs are in the correct containers and that your containers have the correct public access level set so that you aren’t unintentionally exposing sensitive files to anonymous read access.
That’s it! It doesn’t get any more complex than that if your concern is exposure to anonymous read access.
So, how do you do this yourself?
Well, you can click through the Azure portal and look at each of the containers that you have to ensure that the public access setting is set to “private” for every container that contains blobs that should not be exposed.
Of course, this also means you’ll need to dig through each container to identify each of the blobs in any containers not set to “private” to ensure that you haven’t exposed anything you shouldn’t have. And you’ll want to do this manual assessment on an on-going basis to ensure that nothing has changed from your previous assessment.
Alternatively, you can install the Azure CLI tool and use the following commands to get the public access level for each container:
az storage container show-permission --name container-name
And you can use the following command to get a list of each of the blobs in each of the containers, and can associate the permissions from that container with the blobs inside it.
Az storage blob list --container-name container-name
How Tripwire Can Help
Using the
Tripwire Enterprise Cloud Management Assessor, we can automatically assess your Azure Storage Containers and Blobs to determine if they are exposed for anonymous access and to report on blobs that have become newly exposed.
The Cloud Management Assessor will scan each of the containers and blobs you have stored in Azure to retrieve metadata, file contents, and public access information. And we can monitor all of this on a continual basis and monitor your Azure Storage environment for changes and new exposures.
You can then view the Azure Storage dashboard to see charts visualizing new containers and blobs that have become exposed and drill into the details of all your exposed files.
Next, you can use Tripwire Enterprise’s approval system to promote any changes to the new baseline, marking intentionally exposed files as approved.
If you want to know more about the Cloud Management Assessor, feel free to check out the datasheet on it
here.
