To use Amazon S3 effectively, you need to be aware of the security mechanisms provided by AWS to control your S3 resources. This is the first part in a three-part series on S3 security. In this part, we will discuss the three different access control tools provided by AWS to manage your S3 resources.
Table of Contents
Background: Amazon S3 Access Control Tools
AWS has three different options for controlling access to your S3 buckets and objects. Each option is tailored for different circumstances. The three options are:
- User Policies: Use the AWS IAM policy syntax to grant access to IAM users in your account.
- Bucket Policies: Use the AWS IAM policy syntax to manage access for a particular S3 bucket;
- Access Control Lists (ACLs): Use XML syntax to grant access to specific S3 buckets or objects.
One useful distinction between the S3 access control types is whether they are attached to a user or to a resource. User policies are attached to a particular IAM user to indicate whether that user can access various S3 buckets and objects. In contrast, bucket policies and ACLs are attached to the resource itself -- either an S3 bucket or an S3 object -- to control access.
Everything about backing up to Amazon S3:
In the sections that follow, we’ll review each of the three types of access control methods and describe when you should use each one.
Managing Access with IAM Policies
The most common way to manage access to your S3 resources is via IAM policies. IAM is AWS’s comprehensive tool for managing identity and access control across all of its services. IAM allows you to set fine-grained access rules on your S3 resources for a particular user, from the wide ability to read, write, and destroy all S3 resources to a narrow ability to read a single S3 object.
Generally, you should prefer using IAM policies to manage access to your S3 bucket. User policies fit naturally with the broader AWS access management ecosystem, so you can manage all of your access policies in a central place. The tooling and capabilities around IAM are mature and can be used to identify human users or AWS resources -- such as EC2 instances or Lambda functions -- that have access to your end resources.
IAM user policies are written in JavaScript Object Notation (JSON) and have a consistent structure across all AWS services. An IAM user policy will look similar to the following:
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"s3:GetObject"
],
"Resource":"arn:aws:s3:::mybucket/*"
}
]
}
This policy would allow any user that is associated with it to read any object (via the “s3:GetObject” action) in the S3 bucket called “mybucket”.
Parts 2 and 3 of this Amazon S3 Security series will take a deeper look at writing S3 user policies and managing IAM identities, including creating IAM policies with MSP360 Explorer.
Controlling Access with Bucket Policies
The second mechanism of S3 access control is via bucket policies. Bucket policies are similar to IAM user policies. They’re written in the same JSON syntax and can be used to provide granular permissions on S3 resources. The main difference from IAM user policies is that bucket policies are attached to an S3 resource directly rather than to an IAM user.
There are three occasions where you may want to use a bucket policy rather than a user policy. First, if the only AWS service you’re using is S3, you may find it easier to manage permissions directly within S3 via bucket policies. This mostly comes down to personal preference. However, if you’re doing more advanced AWS usage, I would recommend using IAM for all access control where possible for the reasons mentioned in the previous section -- the tooling is more mature, and it’s a centralized place for all identity management.
The second occasion where you may want to use bucket policies is for allowing access from a different AWS account. While you can delegate IAM permissions across AWS accounts, it can be complex. Bucket policies are slightly easier to allow access to a different AWS account or even a particular IAM user within a separate AWS account.
The final situation where you might need to use bucket policies is for when you want to allow access to S3 resources based on something other than AWS IAM identity. For example, you could limit S3 access to requests from particular IP addresses. You could also limit access to media assets in your S3 bucket to requests from a specific referrer so as to only allow your website to display images and video.
While bucket policies may be helpful in specific circumstances, it is best to use IAM user policies where possible. IAM user policies can do almost everything that S3 bucket policies can do, plus IAM provides a centralized location for all of your AWS access control. It can be difficult to debug unexpected user access when you are spread across both IAM user policies and S3 bucket policies.
Setting Bucket Policies with MSP360 Explorer
You can use MSP360 Explorer to easily manage your S3 bucket policies.
First, when looking at your buckets in MSP360 Explorer, select the bucket to which you wish to add a bucket policy. Then, click the “Bucket Policy” button in the toolbar, as shown below.
This will open a wizard to help you write a bucket policy. You can use the wizard to construct your policy by specifying which permissions you want to apply, the principal to whom they will apply, the resource to which they will apply, and the conditions that will apply. A completed statement will look as follows:
You can check the syntax that will be created from the wizard by clicking the “Show Script” button. It will display your bucket policy statement as follows.
For more on writing bucket policy statements, check out Part 2 of this series on Amazon S3 Security In-Depth. In that section, we do a deep dive on the syntax of writing IAM and bucket policies to provide access to your S3 resources.
Using ACLs for S3 Access Control
The final mechanism to control S3 access is using access control lists (ACLs). ACLs are similar to bucket policies in that they are attached directly to an S3 resource, either a bucket or an object. ACLs are more of a legacy feature and generally should be avoided. IAM user policies and bucket policies should be used whenever possible.
That said, there are a few situations where ACLs may be used to control S3 access. First, if you want to enable Server Access Logging on your S3 bucket, you will need to provide a bucket-level ACL that allows AWS’s Log Delivery group to write to a particular S3 bucket.
A second situation when you may want to use ACLs is if you want to provide cross-account access on an object-level basis, rather than on a bucket-level basis. As discussed in the previous section, it can be difficult to manage cross-account access via IAM policies. Bucket policies can assist with this but they can only be applied to a bucket. While it’s possible to apply rules to prefixes within a bucket, it can still be difficult to provide the granular access control that you need. ACLs let you attach access control rules to S3 objects directly, giving you more flexibility.
There is one final note about ACLs that often trips up users. Each ACL rule you create must include a “Grantee” that specifies to whom the ACL applies. The Grantee may be either a specific AWS account or one of three predefined groups of users provided by AWS. The three predefined groups are the “Log Delivery group” (used for the Server Access Logging described above), the “All Users” group (indicating that the ACL applies to all requests to the given S3 resource), and the “Authenticated Users” group.
The “Authenticated Users” group is a common source of confusion with ACLs. Many AWS users believe this means “any authenticated IAM user within my AWS account.” However, the group actually includes all users in any AWS account. Essentially, this gives access to the given S3 resource for anyone that is making a signed, authenticated request for your S3 resource. There are very few reasons to use the “Authenticated Users” group in ACL policies.
Managing ACLs with MSP360 Explorer
You can use MSP360 Explorer to set and update your ACLs on S3. Like bucket policies, ACLs can be attached to S3 buckets. Unlike bucket policies, ACLs can also be attached to individual S3 objects. In this section, you will learn how to use MSP360 Explorer to set ACLs on an S3 object. The experience is similar to set ACLs on an S3 bucket.
First, navigate to the S3 object for which you wish to manage its ACL. After selecting it, right click and choose the “ACL Settings” menu item as shown in the following image.
This will open a wizard to manage your ACL policies for the S3 object. In setting an ACL, you need to think about two questions:
- To whom you wish to grant permissions
- Which permissions you wish to grant
In choosing the Grantee (“To whom” you will grant permissions), you can specify a particular AWS account, either by its root email address or by its account ID, or you can choose one of the predefined groups from AWS. Please read the preceding section on ACLs to know more about the predefined groups.
When choosing permissions, you can choose to provide read and write permissions on the object itself. You can also provide read and write permissions on the ACLs for the object. Finally, you can choose to give “Full Control”, which gives the ability for the Grantee to read and write both the object and the ACLs on the object.
In the screenshot below, you can see how to set ACLs with MSP360 Explorer.
Conclusion
The S3 object storage service provided by Amazon Web Services is a rock-solid service that powers a huge portion of the internet. Introduced in 2006, S3 serves as the underlying technology for big data processing, media asset serving, and long-term archiving. However, the use of S3 to store large amounts of data and assets means that owners need to be careful to avoid data leakage or extravagant bills.
S3 security is a difficult area as evidenced by the frequency of S3 data breaches by major companies and tech consultancies. In this article, we reviewed the three different mechanisms that AWS provides for S3 access control. In general, you should prefer using IAM user policies whenever possible, falling back to bucket policies and ACLs only when IAM user policies do not meet your specific needs.
In part 2 of this series, we’ll take a deeper look at writing IAM user policies to control access to S3 resources.
- Introduction to Amazon S3 access tools
- Writing IAM policies
- Mastering Amazon S3 identities
