What are the biggest security risks with S3 buckets and how can we prevent public exposure?

All answers to this question.

Always follow the Principle of Least Privilege. No user should have s3:* permissions. Only grant the specific actions (like PutObject) they need for their specific job.

   Answered 2024-01-11 by Brian Mitchell

• Spot on, Brian. We recently audited our roles and found a "dev" role that had delete permissions on production. Cleaning that up is a boring but necessary part of cloud hygiene.

     Commented 2024-01-12 by Amanda Collins

The "Shared Responsibility Model" is key here; the provider secures the infrastructure, but you secure the data. On AWS, the first thing you should do is enable "Block Public Access" at the account level—this acts as a master kill-switch. Secondly, move away from long-lived Access Keys and Secret Keys; use IAM Roles and Instance Profiles instead. For sensitive data, always enforce AES-256 encryption at rest. I also highly recommend using AWS Macie, which uses machine learning to automatically discover and protect sensitive data like credit card numbers that might have been uploaded accidentally to the wrong folder.

   Answered 2024-01-12 by Michelle Garcia

Are you currently using any Infrastructure as Code (IaC) tools like Terraform or Pulumi to deploy your storage, or are your teams still creating buckets manually?

   Answered 2024-01-15 by Christopher Evans

• Christopher, that’s a vital point. Manual creation leads to "Snowflake" configurations. By using Terraform, we can bake security "Guardrails" into our templates. For example, our scripts literally won't deploy a bucket if the public_access_block isn't set to true. This shifts security "Left" in the development lifecycle, meaning the mistake is caught in the code review before it ever hits the live production environment. It's much safer than trying to fix things after the fact.

     Commented 2024-01-18 by James Taylor