Amazon S3 Bucket Public Access Considerations

Amazon S3 provides a rich set of mechanisms for you to manage access to your buckets and objects. An Access Control List (ACL) is one of these access control mechanisms. ACLs identify which AWS account or groups are allowed to perform what kind of actions. To learn more about the groups and types of permissions, go to Access Control List (ACL) Overview.

It has come to our attention that some customers have changed default permissions and granted public access to their buckets. Although you can grant public access to your bucket using ACLs, you must take the following issues into consideration:

• Bucket public "READ" access: This is sometimes referred to as "list" access. It allows anyone to get a complete list of your bucket content. It does not grant permissions to read content of an object. However, a list of object names can often provide more information than necessary to the public.
• Bucket public "WRITE" access: This is sometimes referred to as "put" or "upload" access. It allows anyone to add/delete/replace objects in your Amazon S3 bucket. This may result in unintended charges on your account.
• Bucket public "Write ACP" access: This is sometimes referred to as "edit permissions" access. It allows anyone to modify the access control permissions on the bucket. These entities can add grants to the ACL, opening your bucket to more public access than you want. For example, a public WRITE_ACP permission on your bucket enables anyone to modify the ACL and grant permissions such as, for example, grant write permission on your bucket to others.

You can use ACLs to grant permissions to individual AWS accounts; however, it is strongly recommended that you do not grant public access to your bucket using an ACL.

AWS Management Console provides the easiest way for you to check bucket permissions and remove any public access as described in the following section.

Use the following steps to remove any public access that you have granted to your bucket via an Access Control List (ACL).

1.       Go to Amazon S3 console at https://console.aws.amazon.com/s3/home

2.       Right-click on the bucket and click Properties

3.       In the Properties pane, click the Permissions tab.
The tab shows a list of grants, one row per grant, in the bucket ACL. Each row identifies the grantee and the permissions granted.

4.       Select the row that grants permission to everyone as shown in the following example screen shot. "Everyone" refers to the Amazon S3 All User group.

5.       Uncheck all the permissions granted to everyone (or click x to delete the row). This removes all permissions granted to public.

6.       Click Save to save the ACL.

To learn more about ACLs, see the following topics in Amazon S3 Developer Guide.

Access Control List (ACL) Overview

Managing ACLs in the AWS Management Console

You can host websites from an Amazon S3 bucket (see Hosting Websites on Amazon S3).

The website shares only the objects in your bucket that are publicly readable. This does not require that you to add any grants to your bucket ACL to provide any public access permissions. Therefore, it is strongly recommended that you remove any public access grants in your bucket ACL so that your bucket is protected from a potentially malicious user performing operations like listing all your objects, modifying objects or changing your ACLs. Follow the steps in the preceding section to remove an ACL grant that identifies everyone or the authenticated users group as the grantee.

However, you must grant read permission on the specific objects to make them publicly accessible so that your users can view them on your website. You make objects publicly readable by using either the object ACL or by writing a bucket policy. Granting read permission on object(s) does not allow users to perform any of the bucket-level operations described above.

1. Right-click the object you want to make accessible.

2. In the drop-down list, click Make Public.
   The Properties panel displays and shows a new grantee, Everyone, that has Open/Download permissions.

For information about adding grants to an object ACL, go to Managing ACLs and for information about adding a bucket policy to make bucket content public, go to Setting Up a Website in the Amazon S3 Developer Guide.

Some customers provide public access to their buckets to share their content in Amazon S3 with their users. We recommends against granting public access and provides a number of alternatives that are safer and more secure for both you and your users. However, we know our customers use S3 for a very wide range of personal and business applications, and that there are good reasons why some set of our users may still wish to grant public access. As a powerful storage platform Amazon S3 supports this flexibility for those who understand the risks, need the flexibility and have architected accordingly. We strongly encourage our customers to consider alternatives to public access, and to design carefully and with a full security review if public access is required.

1.       If your users are comfortable signing up for their own AWS Account, you can use Amazon S3's access controls to grant access to just that AWS Account. A user would then use a tool that allows them to access that shared bucket using their account. Amazon S3 provides a command-line tool, called s3curl, which enables you to share the bucket with your users. There are also 3^rd party tools that can be used as well. You can read about how to manage permissions for a bucket (or objects) and grant permissions to additional AWS Accounts in our Amazon S3 Console Documentation. The Amazon S3 developer guide also provides a general overview of how access control works with Amazon S3.

2.       Using AWS Identity and Access Management it is possible to create an IAM User for your users to employ. If your users do not want to create an Amazon AWS Account and/or you would like to control access for your users then the AWS Identity and Access Management service may be your best choice. Using an IAM User, you can grant your users fine-grained control to your Amazon S3 bucket (or objects) while also ensuring that your account has full control over everything the users do. When creating an IAM User you will need to write an IAM Policy that grants them access to your Amazon S3 bucket (or objects). See the Amazon S3 and IAM documentation for more details

3.       If you would like to provide your users with a URL that enables them to access your bucket (or objects) then pre-signed URLs are another option to consider. Pre-signed URLs can be used to provide a URL that your users can employ to upload files with predefined names, as well as granting time-limited permission to download objects or list the contents of a bucket. This provides your users with limited access to a specific resource, removing the need to grant public access to your bucket (or objects).

4.       When pre-signed URLs are too restrictive, another option is Amazon S3's POST support. This feature was specifically designed to enable you to build a web-page that allows your users to upload content to a bucket. While POST is more complicated than pre-signed URLs, it provides more control. See the Amazon S3 POST documentation for more details.

5.       Recently Amazon announced yet another option, IAM Temporary Credentials, which combines many of the benefits that both option #2 and #4 provide. Using this functionality enables you to leverage the fine grained access control that IAM User policies provides while also reducing your exposure by enabling you to further restrict and limit the request to a predefined time for each one of your users. Previously, you did not have the ability to both restrict the length of time that an individual had access to your Amazon S3 resources as well as providing fine grained access to an object, set of objects, or your bucket. See the Amazon S3 documentation for samples of how to add support for IAM Temporary Credentials into you application.