Amazon S3 Bucket Policies – Another Way to Protect Your Content
Update August 22, 2011:
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.
What do you think? How will you use this exciting and powerful new feature?