|
|
|
|
|
|
by cyberferret
3211 days ago
|
|
|
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. |
|
|
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.