AWS Rolls Out New Security Feature To Prevent Accidental S3 Data Leaks (zdnet.com)

Amazon's Web Services division rolled out new security features to AWS account owners last week that are meant to prevent accidental data exposures caused by the misconfiguration of S3 data storage buckets. From a report: Starting today, AWS account owners will have access to four new options inside their S3 dashboards under the "Public access settings for this account" section. These four new options allow the account owner to set a default access setting for all of an account's S3 buckets. These new account-level settings will override any existing or newly created bucket-level ACLs (access control lists) and policies. Account owners will have the ability to apply these new settings for S3 buckets that will be created from now onwards, to apply the new setting retroactively, or both.

Comments

S3?

[jfdavis668]

I didn't know my video card could leak. I'll have to open it up and check.

This is a much needed thing... even I can do it.

[ctilsie242]

This is an absolute no brainer, and IMHO, a must have. Log onto AWS, go to S3, check four checkboxes, type in "confirm", hit OK, and not worry about public buckets again, unless someone explicitly logs in as a root/admin user and unchecks them.

Hopefully more AWS customers do this.

That is the "moron" option, apparently

[gweihir]

And, very apparently, it is needed. That somebody that already fails to get access permissions for an S3 bucket set right (which is not hard to do) will obviously screw up a lot of other things as well is pretty much a given.

Re:That is the "moron" option, apparently

[ctilsie242]

In my experience, and I had a time where I bounced among a number of companies, the person with AWS access often times has no clue what they are doing, is likely using the root account itself, rather than a sub account with admin privs, and just needs things to work so the dev team can get their code going. Their goal is to get stuff up and running, even if it means ignoring security issues, since the SCRUM master and their boss is going to call them out on missed deliverables on a daily basis, but security guidelines missed and S3 buckets left public won't be something that the developer would be facing direct consequences for their actions.

Re:That is the "moron" option, apparently

[gweihir]

In other words, the usual perverted incentives and dysfunctional teams....

Jesus christ

[Njovich]

For the love of god, just make sure read rights don't include file listing rights, and the public can never be given file listing rights. This solves 99.9999% of S3 data leaks. No sane web server gives public file listing rights these days for a reason.

Re:Jesus christ

[mysidia]

Because S3 is not a website; It is a storage service --- and some organizations have some repositories or datasets which they wish to use S3 to make public - possibly using a Requestor Pays bucket, OR selling access to a S3-based product through DevPay. Either way, you need to be able to provide other people from the public access to the storage bucket.

Re:Jesus christ

[Njovich]

I didn't say disable access, I said disable public file listings. I think people that want to sell access can manage to make a listing of the files they want to make accessible. Or make it a very hard to enable option or something like that.

Re:This is a much needed thing... even I can do it

[Anonymous Coward]

So what happens when your app completely fails because the developers never built in authentication, and just relied on it being public?

These sort of system miss-configs are rarely as simple as logging in, and spending 5 minutes changing the config. It's possible the buckets were made public and don't need to be and this would work without a problem. The more likely scenario is that somewhere, some piece (or all of it) isn't authenticating, and is relying on the buckets to be public. Finding that piece is often non-trivial, and likely involves a full regression test.

what about adding all users (in your account / g)

[Joe_Dragon]

what about adding all users (in your account / group) and make the other all users read ALL AWS users (PUBLIC)

It helps our customers. Maybe from testing

[raymorris]

I wonder how many of these are left over from testing. I developer is having trouble getting something to work, so they *temporarily* open up the SG to test it, removing one variable. After they get it working they forget to secure it again.

Anyway, our AWS security service (Alert Logic) checks for this and I know we catch public buckets fairly often.

Re:It helps our customers. Maybe from testing

[phantomfive]

In the past it was a lot easier to accidentally get the settings wrong. I expect it will be less and less of a problem as things move forward and the default settings become more secure.

Re:Default Deny should be by design

[ctilsie242]

It is default deny. In the past, you were presented with the option of making it private or public on bucket creation. Now, it defaults to private. I think people got confused, set it to public, assuming that was what was needed to give other members of their AWS account access.

I wouldn't say this is Amazon's fault. It would be like a mini storage company selling padlocks with every unit, offering the units with the padlocks in place on them. Then, users unlocking the padlocks, and leaving the garage door thrown open for anyone to walk up and pick through.