Hi friends – its been a while. My new gig is kicking my butt! Growing and learning quite a lot, for sure. I need to keep good information coming out, so when I saw this story about third-party developed Facebook app datasets being exposed due to a mis-configured bucket permission, I felt compelled to put together some ways to help remediate this.
Although ACLs and Bucket policies are great for protecting against leaky buckets for those who understand AWS and IAM very well, they are not something one would understand in 30 seconds – so I think some people avoid learning them to simply get their jobs done fast. Also, I think there is a general lack of Security awareness in the wild, so people do things to get a job done quickly without thinking through the implications of what they are doing… making buckets public. I believe that these two reasons are at dead center of all of the bucket leaks you read about in the papers.
First, let’s talk about detecting public buckets.
AWS has done a good job adding additional methods to detect public buckets. A year or so ago this little icon appeared in the console next to any public bucket when looking at your buckets in S3 menu:
So it made it a bit more obvious, but that still was not enough. AWS made it so Trusted Advisor Reports could check S3 Access and Flag buckets.
Also, to take a quick detour into the inventory aspect of Info Security, think about leveraging Amazon Macie for detecting certain data types (PII) are in S3 buckets and how that data is being accessed.
That’s nice, but let’s take some actions . .
Next, you can integrate Trusted Advisor with CloudWatch, so you can take actions on Trusted Advisor’s checks, but this will only fire AFTER Trusted Advisor has ran….so still not quite enough to stop bucket leaks that would occur in-between the times TA is run.
Next level up, and one of my favorites, is using AWS Config to monitor and respond to public buckets – this is powerful because it requires no human interaction…. almost. The Lambda script in the linked tutorial only notifies if a bucket permission has been changed. To fully automate I really recommend that you customize the script and add some teeth to it, so it will remediate the bucket policy. An example script is here.
Problem still not solved you say, a user should not even be allowed to set their own bucket permission? Could not agree more.. so…
I’d rather just prevent S3 Public Access in the first place.
Now, there is Amazon S3 block public access which gives the Account Administrator more power to block users from introducing ACLs with open permissions onto a bucket in the first place, by blocking this at the Account level.
And Last – would sit a Corporate Security Policy about creating any kind of Public sharing on any Cloud or third party service without explicit permission from the Security Team. Education and acknowledgement of this policy by every employee yearly is a must.
I hope this helps! Stay Safe! Stay Secure!