Managing Storage Access: Secure Cloud-native Development Series

Build secure cloud-native applications by avoiding the top five security pitfalls we lay out in our Secure Cloud-native Development Series. This blog is the third part of the series, and it will teach you how to secure cloud storage and handle access controls on S3 buckets.

Each cloud provider has managed storage services that your organization is already probably utilizing.  Cloud storage such as Amazon Simple Storage Service (Amazon S3) or Azure storage tools are tightly integrated into the other managed services which makes it simple to manage. We will discuss specifically Amazon’s S3 storage service and how it relates to secure cloud-native development.   

An Introduction to Secure Cloud Storage and Access Control Configuration 

Amazon recently turned-on default server-side encryption (SSE) for all users using AES-256. Though most likely we already (or at least should have) had encryption turned on, it’s now one less thing to worry about. Additionally, tools such as Terraform can help automate the creation of new buckets, which automatically enable encryption.   

Access control is the other piece we need to ensure is configured correctly. Amazon in recent years has secured this service by setting stronger defaults as well as adding multiple confirm checks, that ensure that this is what we want to enable, when configured through the console. This little option has been the result of many breaches.  

The default is now set to ‘block all public access’ by default. Which when set, means that the bucket, any objects currently stored in it, as well as any new objects, will not be accessible by anyone externally.  

However, our web application for example, may require that a client access certain files or images from a bucket. We would not be able to ‘block all public access’. This is where Bucket policies, and access control lists (ACLs) come into play.   

In the console, all of these warnings are helpful. However, we’re not generally configuring resources like this through the console, but rather we’re using infrastructure as code (IaC) tools or a software development kit (SDK) which does not display these warnings. So, we need to ensure we have configured our ACLs correctly. 

Tools to Help Detect Storage and Access Control List Misconfigurations 

Though there are a multitude of tools that will help us detect S3 bucket misconfigurations, here are a few I have found helpful and continue to use myself. 

Security Tool 1: Prowler 

Prowler is an open source security tool used to perform AWS and Azure security best practice assessments, audits, incident response, continuous monitoring, hardening, and forensics readiness.  

You can specify certain checks if needed, but simply running the tool will run through all cloud services and generate a report in the format of your choosing. Below we can see an excerpt from the generated report after having run the tool against the test environment, showing the bucket allowing public access. 

Why it’s important: This tool is great for ease of use and report generating and runs quick.  It runs locally and requires access keys with at least read-only access. Our organization most likely has config rules enabled in our cloud provider to ensure guard rails are in place to prevent these kinds of things from getting deployed, but it is always good to have an audit tool that can ensure our intended configurations have been deployed. Prowler will scan both AWS and Azure services, too! 

Security Tool 2: Trivy 

Trivy is a tool that does a lot more than scan S3. It has similar checks to Prowler, but it also can scan Container images, Kubernetes configurations, as well as entire cloud environments. I like this tool as it again is quick and easily able to get results. 

Why it’s important: Trivy can be very helpful as you are building out the infrastructure. It allows you to scan the deployed S3 resources or scan the intended IaC (Infrastructure as Code) configuration prior to deployment in a variety of SDKs. Trivy can also be integrated into your CI/CD to automate the scanning and report generation. 

Takeaways 

Cloud storage may be the most utilized cloud service available. Even on-prem web applications may ingest cloud storage in some manner, which makes it even more essential that it is configured correctly. Using tools like the two we discussed can help to find vulnerabilities, as well as unintended deployments. As stated previously, much has been done to help minimize access control mistakes, but when we are working with bucket policies, and ACLs, it is always good to double check our work with an audit tool.

Now check out Part 4 of our Secure Cloud-native Development Series, where we'll discuss enabling encryption.