4 ms·
Aws should start taking blame for this shit, then maybe they would start auditing their customers setups...
by coding123 6y ago
Aws should start taking blame for this shit, then maybe they would start auditing their customers setups...
- _vertigo 6y ago* how should AWS know when its customers want the permissions they choose and when they don't? * the cost of auditing would be spread across all customers equally, punishing competent customers and benefitting incompetent ones..
- deleted 6y ago[deleted]
- ceejayoz 6y agoAWS does audit this. You get a huge warning when you make a bucket public in this way, and they send you emails about it.
- l33tman 6y agoThere are big signs on world-accessible buckets when you go into the S3 console. It's a fairly new thing but they are (slowly) trying to help auditing and finding these things I guess. However I'm not sure if there are any built-in tools to find weird nested policies attached that could cause a similar permission to be granted to all..
- x86_64Ubuntu 6y agoWhat does AWS have to do with this? Sure, the technical debt of S3 being one of the first services is clear to see. But it was a world writable bucket. What is AWS going to do about that? Eventually, you have to know and care about what the hell you are doing.
- aka1234 6y agoAWS's shared responsibility model is clear. AWS is responsible for security of the cloud. The customer is responsible for the security in the cloud (i.e. the customer's resources). By the way, enterprise support customers do get access to well-architected reviews by AWS. If you ask for help from AWS, AWS will provide it. It may not be free, but it's available. Even if AWS were to start proactively auditing customer setups, how in the world is AWS supposed to know what a customer's usecase is? Nevermind the fact it's a breach of the customer's privacy to just go rooting around in the customer's account without permission. But let's assume AWS is going to take responsibility for customers' configuration decisions and violate customers' privacy by proactively auditing their accounts. Would AWS auditing Twilio's configuration here work? The default is for S3 buckets to be private. The customer has to take specific, affirmative steps to give s3 buckets public access. You really have to jump through hoops to make a bucket public accessible. Since the Twilio chose to make their bucket public, AWS auditing Twilio's setup wouldn't be helpful. AWS would just assume the Twilio knows what they're doing. How is AWS supposed to know there is a misconfiguration? Because Twilio clearly decided to make their S3 bucket publicly available.
- donor20 6y agoNot only do you have to jump through hoops to make it public, if you are worried can't you use Amazon Macie and have a separate org level view that alerts you to any public buckets? https://aws.amazon.com/macie https://aws.amazon.com/macie I don't bother because it seems pretty clear what buckets are public. That said, quick tip to make your life easier. DON'T use S3 ACL's DON'T use S3 policies. If I was AWS and didn't have so many customers I'd probably just create one mental model (IAM policies probably) as the place to manage things and block the rest.