AWS News Blog
Amazon S3 Bucket Policies – Another Way to Protect Your Content
|
Update August 22, 2011:
We are aware of the existence of a tool that scans S3 looking for buckets that allow anonymous users READ permission. Bucket level READ permissions only allow an user to list the objects within a bucket. However, users with the ability to list could probe into the bucket looking for unprotected content, potentially resulting in undesirable access to content as well as usage charges. We have inspected the permissions of all S3 buckets and have sent an email to the owner of buckets that appear to have excessively permissive access controls granting the READ permission for anonymous users. We have also emailed the owners of all buckets that grant the WRITE or WRITE ACL permission to anonymous users. With WRITE permissions granted to Everyone, an anonymous user can access, modify or delete any object in a bucket.
We strongly encourage you to inspect and, if necessary, restrict the permissions on your buckets and on the objects in each bucket. If you are concerned about the integrity of your objects, you can inspect the modification dates in the buckets. You can also inspect the Server Access Logs for the buckets in question. The easiest way to secure your bucket is by using the AWS Management Console. First select a bucket and click the Properties option within the Actions drop down box. Now select the Permissions tab of the Properties panel. Verify that there is no grant for Everyone or Authenticated Users. If one or both exist, remove the Everyone and Authenticated Users grantees. Your bucket will now be inaccessible to anonymous users.
Earlier this year we launched a popular feature enabling our users host static websites on S3. Bucket level READ permissions for everyone the permission configuration weve warned our users about – is not required for S3 website hosting. However, S3 website hosting does require READ permissions at a per-object level. To verify that your bucket is secured against anonymous operations, use the instructions above. To verify individual objects have anonymous READ, you can use the S3 Console to view the permissions on individual objects and verify that Everyone is granted READ permission. Granting anonymous READ on every object is commonly done using ACLs but can also be done using Bucket Policies.
Users of Amazon S3 have been looking for additional ways to control access to their content. We’ve got something new (and very powerful), and I’ll get to it in a moment. But first, I’d like to review the existing access control mechanisms to make sure that you have enough information to choose the best option for your application.
The two existing access control mechanisms are query string authentication and access control lists or ACLs.
The query string authentication mechanism gives you the ability to create a URL that is valid for a limited amount of time. You simply create a URL that references one of your S3 objects, specify an expiration time for the query, and then compute a signature using your private key.
The Access Control List (ACL) mechanism allows you to selectively grant certain permissions (read, write, read ACL, and write ACL) to a list of grantees. The list of grantees can include the object’s owner, specific AWS account holders, anyone with an AWS account, or to the public at large.
Each of these mechanisms controls access to individual S3 objects.
Today, we are adding support for Bucket Policies. Bucket policies provide access control management for Amazon S3 buckets and for the objects in them using a single unified mechanism. The policies are expressed in our Access Policy Language (introduced last year to regulate access to Amazon SQS queues) and enable centralized management of permissions.
Unlike ACLs which can only be used to add (grant) permissions on individual objects, policies can either add or deny permissions across all (or a subset) of the objects within a single bucket. You can use regular expression operators on Amazon resource names (“arns”) and other values, so that you can control access to groups that begin with a common prefix or end with a given extension such as “.html”.
Policies also introduce new ways to restrict access to resources based on the request. Policies can include references to IP addresses, IP address ranges in CIDR notation, dates, user agents, the HTTP referrer, and transports (http and https).
Finally, with bucket policies we have expanded your ability to control access based on specific S3 operations such as GetObject, GetObjectVersion, DeleteObject, or DeleteBucket.
When you put all of this together, you can create policies that give you an incredible amount of access control.
You could set up a bucket policy to do any or all of the following:
- Allow write access…
- To a particular S3 bucket…
- Only from your corporate network…
- During business hours…
- From your custom application (as identified by a user agent string).
You can grant one application limited read and write access, but allow another to create and delete buckets as well. You could allow several field offices to store their daily reports in a single bucket, allowing each office to write only to a certain set of names (e.g. “Nevada/*” or “Utah/*” and only from the office’s IP address range).
Policies and ACLs interact in a well-defined way and you can choose to use either one (or both) to control access to your content. You can also convert your existing ACLs to bucket policies if you’d like.
Read more in the new Using Bucket Policies section of the Amazon S3 Developer Guide.
What do you think? How will you use this exciting and powerful new feature?
— Jeff;