How to prevent public AWS S3 buckets 

Date Posted: 10.04.22
Read Time: 10 min

As one of the web’s leading storage services, Amazon Web Services Simple Storage Service, or AWS S3 bucket (S3), is a favorite of developers for its ease of use and robust functionality. But it’s perhaps equally well known for an otherwise infamous association: misconfigurations. 

To be clear, S3 is not inherently insecure; however, end users sometimes misconfigure S3 buckets accidentally, leading to expensive and high-profile data breaches. 

Earlier this year, a non-profit suffered a security breach, that publicly exposed more than 350,000 files and 50,000 users’ data—roughly 150 GB of data in total. The reason? A misconfigured AWS S3 bucket. 

This organization is not alone. Over the past few years alone, banks, pharmaceutical companies, and dozens of other companies have inadvertently exposed customer data by misconfiguring S3 buckets. It’s a common human error, one that hackers are waiting to exploit. 

In many cases, the users do not realize that they have misconfigured open buckets until they’ve been compromised. And by then, the damage has likely been done: compromised customer loyalties, costly fines, and legal ramifications. 

Preventing public AWS S3 buckets  

The reactive approach is to simply prescribe a more deliberate approach from your developers. But that ignores their complex, time-intensive work that inevitably—no matter how careful—leads to human error.  

There is a better way. Adopt a proactive approach, one that doesn’t eliminate human errors but rather prevents those errors from being included during the configuration process. 

Torque’s blueprint model provides a central place for DevOps admins to implement policy-based guardrails, which specify which infrastructure configurations can be deployed (or in this case, not deployed), with the assurance that these guardrails will be reflected in all subsequently launched environments. 

No matter how quickly your developers might operate, these preconfigured policies create the infrastructure definition, which prevents the inclusion of public S3 buckets. This is critical control functionality that allows AWS users to enjoy all that the service offers without the risk that their S3 buckets will be vulnerable to cyber-attacks. 

Here’s how to put them into action: 

Step 1. Ingest infrastructure configurations into a control layer 

Many organizations have amassed significant libraries of infrastructure and application configurations with tools, such as Terraform. These libraries contain valuable IP and knowledge, but often become difficult to manage at scale.  

Torque connects to the asset repositories that these teams use, such as GitHub, GitLab, and Bitbucket—and automatically discovers the Terraform scripts within them. 

The control plane ingests all infrastructure assets into one place, automatically creates a repeatable blueprint for complete environments, and allows an admin to set governance policies.

Step 2. Set a policy to allow only private AWS S3 buckets 

Once imported into Torque, admins can assign policies that control how a blueprint is configured, such as allowing only private AWS S3 buckets. If any admin tries to configure a public S3 bucket, the policy will ensure that it never goes live while alerting both the user and admin. 

Other policies include: 

  • Allowed Providers: List the allowed Terraform providers an environment is allowed to deploy on (such as AWS, Azure Resource Manager). 
  • Allowed Regions: Set the AWS regions allowed for deploying environment. 
  • Allowed Resource Types: Restrict environments to a pre-set list of AWS resource types. 
  • Prohibited AWS Instance Types: Limit the instance types that environments are not allowed to deploy on AWS. 

Restricting how public cloud services can be deployed is an easy but valuable step to mitigate these risks.  

Step 3. Create self-service access for devs and/or integrate with CI/CD and ITSM 

This approach scales via self-service access to these environments for the developers, testers, and other end users who need them. 

Because blueprints are easily provisioned to any user, the user leverages the knowledge and skills contained in the configuration without having to know anything about how the configurations were built or what they contain. Furthermore, the control mechanism prevents them from altering environments; they can only deploy them. Users get a simple “click and go” reality to access infrastructure.  

Integrating these environments within a CI/CD tool can further simplify this process by setting the pipeline to automatically deploy an environment at the onset of a specific stage and automating shutdown once that stage is complete. 

This approach eliminates the need for developers to wait for access to infrastructure or attempt to deploy it themselves.   

Control plane capabilities 

Policy setting is just one aspect of Torque’s overall control plane, which provides orchestration, visibility, and governance to optimize application environments. Collectively, this helps users find the perfect balance between application speed, governance, and cost control, helping companies achieve their digital transformation goals. 

To get started, create a free trial account of Torque now