How to prevent public AWS S3 buckets
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, pharmaceuticals, and dozens of other organizations have inadvertently exposed customer data by misconfiguring AWS S3 buckets. It’s a common human error, one that hackers are waiting to exploit.
To be clear, AWS S3 is not inherently insecure; however, end users occasionally misconfigure or deploy public S3 buckets accidentally, leading to expensive and high-profile data breaches.
In many cases, the users do not realize that they have misconfigured open buckets until after 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
Our users mitigate this risk with policy-based guardrails governing which infrastructure configurations their teams can deploy, with the assurance that these guardrails will be reflected in all subsequently launched environments.
No matter how quickly your developers might operate, these policies prevent end users from deploying specific unapproved infrastructure or configurations, including public AWS S3 buckets.
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, Helm, or AWS CloudFormation. These libraries contain valuable IP and knowledge, but often become difficult to manage at scale.
Quali’s Torque connects to the asset repositories that these teams use, such as GitHub, GitLab, and Bitbucket, and automatically discovers the infrastructure assets within them.
Once they’ve imported their assets into Torque, they can select the assets they need for a specific use case, and Torque will automatically orchestrate a complete, repeatable environment based on those assets.
This repeatable blueprint reduces the need to configure that environment manually in the future, while providing a central place to manage configurations.
Step 2. Set a policy to allow only private AWS S3 buckets
With infrastructure scripts managed via Torque, admins can assign policies that control how blueprint is configured, such as allowing only private AWS S3 buckets.
If anyone 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 providers an environment is allowed to deploy on (such as AWS, Azure, GCP).
- 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.
Additional 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.