Preventing AWS S3 Data Leaks: What You Need to Know
Anyone who hasn’t been living under a rock has heard about the growing number of so-called Amazon Web Services S3 “data leaks” lately. Though many seem intent on blaming this directly on AWS or describe it as a weakness of the “cloud”, this is not an issue with AWS and its S3 offering.
The cause of these data leaks, unfortunately, is more often than not due to human intervention – specifically, users who have not correctly configured S3 bucket policies, and as a result, allowing unfettered public access to S3.
Chances are, this happened due to a lack of understanding when implementing S3, or carelessness when evaluating what should or should not be available for public consumption. Perhaps, during initial configuration, it was unrestricted to allow someone temporary access — or maybe it should have been private from the beginning. In any event, there are several precautions that you can take now to prevent such leaks, while still being able to grant limited access to specific entities if the need should arise.
First, it’s important to note that, by default, AWS S3 buckets are created with private access. One would have to specifically, and with intention, make changes to the bucket for it to be public facing. Now that that has been said, let’s discuss how not to share your bucket contents with the world. Here are things you should NOT do:
DON’T click the radio button to allow “Everyone” List, Write, or Read access in your Access Control Lists (ACL). As you can see below, it is very simple to give public access and give “Everyone” access to your bucket and the objects within it. In almost every case, if you are giving Read access to a bucket, and the contents are not used for a static website, you may want to reconsider.
DON’T set Bucket Policies that allow ALL “Principals” access to your bucket resource. As you can see in the following screenshot, this policy will essentially give everyone “Read” access to the public example bucket, regardless of ACL settings.
So, what should you do if access is needed to a file in an S3 bucket, but you really don’t want to also give everyone else access to that information? At Blue Sentry Cloud, we teach our customers there are better ways to do things, and in a more secure manner. One of our preferred methods is using S3 pre-signed URLs. Pre-signed URLs can be generated for an S3 object, allowing anyone who has the URL to retrieve the S3 object with an HTTP request.
Not only is this more secure due to the custom nature of the URL, but the available options also allow you to set an expiration on the URL, the default being one hour. Pre-signed URLs not only allow you to retrieve objects, but they can also be used to upload objects to a bucket. This can be useful in many ways, and allows for a user to have access even if they do not have AWS security credentials or permissions.
This is just one way to establish secure communication with your S3 bucket. There are other ways to accomplish this, such as using Bucket Policies properly. If you would like more information on pre-signed URLs or S3 bucket policies, check out the following links, or contact us here at Blue Sentry Cloud for a free consultation about your IT configuration.
Links:
Pre-Signed URLs: http://docs.aws.amazon.com/AmazonS3/latest/dev/ShareObjectPreSignedURL.html
Bucket Policies: http://docs.aws.amazon.com/AmazonS3/latest/dev/example-bucket-policies.html