[tarr11]

Setting permissions on s3 buckets is absurdly complicated.

Though it's no excuse, it's not surprising people leave it open, it's too hard to figure out how to lock it down.

Amazon needs to share some of the blame here and create a sane UI.

[cyberferret]

Well, I've used S3 on many projects since it pretty much came out. TBH, security is not much harder that in any &nix based systems.

Default settings are usually NO public read, and it actually takes more work to make stuff publicly readable on S3 than to just leave it as private.

I am thinking the biggest stuff up with this vendor is that they made the entire bucket or bucket key available publicly, which is a pretty dumb, and deliberate thing.

If you wanted people to access resumes on an individual basis via a known web link, then just make the documents individually publicly readable, but don't make the entire bucket readable by default.

Better still, use Amazon's 'one time' or time based permissions to make sensitive files only available to a certain person or for a limited time.

Re: UI - Amazons new S3 console is spades better than their old one - plenty of auditing and analytics tools there too which can prevent silly mistakes like this.

[bostik]

> Default settings are usually NO public read, and it actually takes more work to make stuff publicly readable on S3 than to just leave it as private.

While true, and a very sensible default, this misses one crucial point.

Setting granular permissions for an S3 bucket is hideously difficult. Want to limit access to a whitelisted set of users or origins? Write a bucket policy. This is where the UI completely fails.

0: The policies can become awfully difficult to understand even for straightforward use cases.

1: You can have policies with sensible rule sets, but the S3 UI doesn't allow to pick-and-attach any of them.

2: The "permissions" tab has a very convenient and extremely dangerous option as the top item: "allow access for any logged in user"

I'll let the last one sink in. It's not "any logged in user in MY organisation", it's really "ANY logged in AWS user". Putting the bucket essentially world-readable by accident is far too easy.

[cyberferret]

Point taken. Granular policies ARE a royal PITA to try and build. I wish their policy editor had a nice easy ARN selector, and a 'policy building' GUI that would help you with syntax and grouping.

Most of my projects use either totally restricted buckets, or buckets with access to a particular IAM, which is basic, but works.

[btown]

The one time permission links are quite simple to implement, with libraries for practically every language. So there's really no excuse.

[sbr464]

I personally believe it's a valid excuse. Amazon should be included in the blame and should play a larger part in helping to provide automatic scanning for sensitive data, virus/malware protection, automatic data protection policies and other tools that can automatically detect/protect information. It's the lack of (local enforcement?) of data protection laws as well, similar to how a bar has to ID patrons before serving alcohol or lose it's license to serve. There simply needs to stop being a Wild West mentality in IT. At a minimum it shows the importance of design & UX.