IAM Policies: Good, Bad and Ugly(stackery.io)
stackery.io
IAM Policies: Good, Bad and Ugly
https://www.stackery.io/blog/iam-policy-examples
3 comments
:wave: I'm the author of the post! Anyone have any IAM horror stories of their own? Or examples of amazing IAM policies that really show their power?
I continue to be surprised by the so-called "S3 Bucket Negligence Award" which feels like the intersection of IAM and S3 configuration ugliness that result in so many public horror stories like:
- https://www.upguard.com/breaches/attunity-data-leak
- https://www.lastweekinaws.com/newsletter/reinforce-meant-lea...
It's hard to get it right, though that's not to shift blame away from those who spilled info about others because they couldn't figure out how to lock buckets and objects down.
One way is to scaffold in bucket policies that ensure data is always: encrypted at rest, encrypted in transit, and locked down so objects can't be public. People can override these if needed, but because these settings are the default most people don't know about them or know how to set them up.
At Stackery we always scaffold in S3 Buckets with these settings in place, while giving you the ability to check boxes to turn on website hosting or allow contents to be publicly available. That helps ensure people configure things right the first time and every time!
One way is to scaffold in bucket policies that ensure data is always: encrypted at rest, encrypted in transit, and locked down so objects can't be public. People can override these if needed, but because these settings are the default most people don't know about them or know how to set them up.
At Stackery we always scaffold in S3 Buckets with these settings in place, while giving you the ability to check boxes to turn on website hosting or allow contents to be publicly available. That helps ensure people configure things right the first time and every time!