Hacker News new | past | comments | ask | show | jobs | submit login

They are private by default, but it was far too easy for a to enable public access through a bucket policy that seemed sane to the untrained eye.

In the systems I've designed, I've built multiple layers of protection around sensitive buckets. I figure it's safest to assume that someone will eventually screw up the policy.

When possible, I deny access to the bucket except for explicit whitelisted approvals (alternatively, requests coming from IAM roles or users in the current account).

I also encrypt buckets by default and often deny unencrypted uploads. The concept of public access doesn't map in quite the same way to customer-managed KMS keys, so you have good odds that S3 requests would fail on decryption even when a bucket becomes public.

Next layer of protection is monitoring via Config rules and Trusted Advisor checks, combined with alarms to ensure that these alerts are actually brought to someone's attention.

Finally, except for development accounts, I insist on automating configuration of the environment (and aim to use IAM to prevent manual changes).

This is great if you can pull it off, but you don't get there overnight. And you certainly don't get here by relying only on the basic documentation. I would say you don't even necessarily get there by relying on AWS partners. I've seen more than a couple disappoint.

All of this to say that I'm happy to add one more guardrail (with much lower overhead).




This is exactly the right approach. AWS hammers people about the “shared security model”, being in the cloud doesn’t stop you from doing stupid stuff. You have all kinds of tools to help you do the right thing.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: