Evaluating public and cross account access at scale with IAM Access Analyzer for Amazon S3

Note: This is a more in-depth follow-on post from our high-level, introductory blog on IAM Access Analyzer for S3.

Organizations generate, use, and store more data today than ever before. With securing data a top priority, many enterprises focus on implementing the principle of least privilege access, or limiting users to the minimum necessary access that they require, and they often set up audit workflows to ensure proper implementation. These workflows evaluate and remediate policies that control access to each resource. To automate auditing workflows, both to reduce time and increase auditing accuracy and repeatability, users are increasingly looking for simple tools that evaluate broad access control guardrails to answer questions such as “What data do I have that is publicly accessible?” and “What data can be accessed by which users?”

Amazon S3 supports a suite of access control mechanisms to help organizations achieve this goal. Users can use broad guardrails such as S3 Block Public Access to make sure their data is not openly accessible to the internet and implement more granular controls with bucket and AWS Identity and Access Management (IAM) policies. For auditing, AWS Identity and Access Management (IAM) Access Analyzer is a tool that enables you to set, verify, and refine permissions to identify and remediate Amazon S3 resources that have overly permissive external access.

In this post, I walk through setting up and using Access Analyzer for S3, including reviewing the findings and remediating access. Access Analyzer set up is a one-time activity, and once set up, simplifies the process to recognize and remediate overly permissive access to help you ensure that you are applying the principle of least privilege access.

Solution walkthrough

The solution walkthrough section goes through the following steps:

1. Navigate to IAM Access Analyzer for S3
2. Create an analyzer
3. Viewing findings
4. Reviewing the findings and remediation
   1. Public buckets
   2. Cross-account access

Step 1: Navigate to IAM Access Analyzer for S3

You can find IAM Access Analyzer for S3 in the navigation panel on the left side of the Amazon S3 console. IAM Access Analyzer is AWS Region-specific – so you must create a new Analyzer for every AWS Region in which you have buckets in order to generate findings for them. When you open up the console page for the first time, you see a notification that Access Analyzer is not enabled for the Region. If you haven’t enabled IAM Access Analyzer for S3 before, select the IAM Access Analyzer link in the blue box (Figure 1) to navigate to the IAM Access Analyzer console to set up an analyzer.

Figure 1: IAM Access Analyzer for S3 page before you have enabled IAM Access Analyzer for the Region

Step 2: Create an analyzer

In this section we will walk through the process of creating an analyzer, naming it and defining the correct zone of trust.

1. Select the Create analyzer button (top right of the page, Figure 2), which will guide you to a wizard to create your analyzer.

   

   Figure 2: IAM Access Analyzer landing page

2. On the Create analyzer page (Figure 3), you can choose to change the Name of your analyzer and optionally add Tags.
3. In the Zone of trust, we recommend you use Current Account rather than Current Organization (where the option to make the selection is available – as if you’re doing this for an organization management account). Choosing Current Organization treats your whole organization as a zone of trust and only generates findings for access paths from accounts you may have that are outside of your organization or through public access, and will not send your results back to the Amazon S3 console. Choosing Current Account helps generate findings for cross-account and public access from your selected account and sends the findings back to the Amazon S3 console where you can navigate to them quickly.
4. Select Create analyzer.

Figure 3: Create analyzer page that allows you to choose the Name and Zone of trust for the analyzer

Step 3: Viewing findings

Navigate back to the IAM Access Analyzer for S3 page to view the findings from the analysis. As you can see in Figure 4, findings are split into two sections:

1. Buckets with public access: This section lists buckets that can be accessed by anyone on the internet – in other words, where the user does not need valid AWS credentials to access your data. Access Analyzer evaluates bucket policies and Access Control Lists (ACLs) on your buckets to find resources that can be accessed this way.
2. Buckets with access from other AWS accounts – including third party AWS accounts: This section lists buckets that have been configured for cross-account access. Access Analyzer evaluates the bucket policies and the ACLs on your buckets to find resources that have been shared with other AWS accounts.

Figure 4: Example findings on the IAM Access Analyzer for S3 page after you’ve created the analyzer

Step 4: Reviewing the findings and taking action

In this section, I cover reviewing and remediating findings for buckets that are public as well as those that allow cross account access.

Public buckets

If the bucket should not have public access, you can select the bucket and Block all public access to the bucket with two clicks. This action immediately applies the S3 Block Public Access policy on your bucket. S3 Block Public Access blocks unauthenticated access to your bucket, so that a user must have valid credentials to access your bucket. Other restrictions as defined in your bucket policy continue to apply. You can also validate if the IAM users or roles that need access to your bucket actually have it by reviewing the bucket policy.

Figure 5: Selecting a bucket from the list on the IAM Access Analyzer for S3 page

After you type “confirm” and select Confirm, this finding should disappear as public access is now blocked.

Figure 6: Blocking all public access to an S3 bucket from the IAM Access Analyzer for S3 page

If you have a valid use case for public access for your bucket (for example if your bucket hosts files that you share on the internet without user authentication), you must first select the finding you wish to archive.

Figure 7: Selecting a finding that you wish to archive on the IAM Access Analyzer for S3 page

 You can then type “confirm” and select Confirm to archive the finding. Archiving the finding does not remove a bucket from the list of buckets with public access, and you can mark the finding as active later on.

Figure 8: Archiving your findings on the IAM Access Analyzer for S3 page

If you use your bucket to host a static website, then we recommend you use Origin Access Control with Amazon CloudFront, which in addition to providing HTTPS support, can cost less for certain workloads such as audio and video hosting that benefit from caching, while allowing you to block public access to your bucket.

Cross-account access

As with public buckets, you can archive findings and mark findings as active. When reviewing buckets with cross account access, you see whether that permission was granted through a bucket policy or ACL.

Let’s look at an example where the permission was granted through a bucket policy. You should start by reviewing the bucket policy and confirm that each of the accounts in that policy has a need to be able to access the relevant Amazon S3 resources in your account. The following sample policy allows user1 in Account 123456789012 to read (getObject) from and write (putObject) into S3-bucket.

Figure 9: Sample bucket policy

 As you review policies and ACLs, you may find cases where a permission is no longer needed. In those cases, you can remove the ACL or edit the bucket policy to remove the access. Once you have confirmed that the bucket policy only allows intended cross-account access, you can archive the finding on the bucket.

Additional considerations

1. We recommend setting up IAM Access Analyzer for S3 in every AWS Region where you have buckets so that findings are generated whenever you create new buckets in those AWS Regions.
2. IAM Access Analyzer for S3 does not support object-level access controls. You can use Amazon S3 Inventory Reports to find Amazon S3 ACL metadata on your objects and Amazon S3 Server Access Logs and AWS CloudTrail to see when they were used to authorize access to your resources. You can either disable the ACLs one by one or use the Amazon S3 Block Public Access settings to turn ACLs off at the bucket or account level, if you consider this necessary. Remember, without the Bucket Owner Enforced setting, IAM roles or users in your account can still use object ACLs to make your data publicly available if they have the permission, and so we recommend disabling object ACLs completely. If you need to map identities in directories, such as Active Directory (AD) or IAM Principals, to datasets in Amazon S3, then we recommend using Amazon S3 Access Grants.
3. Consider using IAM Access Analyzer for your whole organization. IAM Access Analyzer has expanded functionality beyond the capabilities we covered in this post, such as custom policy checks, rules for refining access, and integration with services such as AWS Security Hub and Amazon EventBridge. Read more about unused access and checking policies before deployment in the IAM Access Analyzer documentation

Conclusion

In this post, we walked through setting up IAM Access Analyzer for Amazon S3 and taking actions on findings. We covered the process of blocking public access to public buckets as well as archiving findings. We also covered evaluating cross-account access.

Setting up IAM Access Analyzer for S3 can reduce the time and effort to audit access to S3 resources. You can set up an analyzer once for a region and the analyzer will evaluate all your resources in that region.

Thanks for reading this post, if you have comments or questions, don’t hesitate to leave them in the comments section.