Validate access to your S3 buckets before deploying permissions changes with IAM Access Analyzer

AWS Identity and Access Management (IAM) Access Analyzer helps you monitor and reduce access by using automated reasoning to generate comprehensive findings for resource access. Now, you can preview and validate public and cross-account access before deploying permission changes. For example, you can validate whether your S3 bucket would allow public access before deploying your bucket permissions. This helps you start with intended access.

With IAM Access Analyzer, you can look before you leap, and prevent public and cross-account access before you set permissions. You can preview and validate access in the Amazon S3 console or with Access Analyzer APIs. In the S3 console, you can preview IAM Access Analyzer findings for access to your bucket before you save a bucket policy. This enables you to validate whether the policy change introduces new findings or resolves existing findings. You can also use IAM Access Analyzer APIs to validate proposed permissions for your Amazon S3 buckets, AWS KMS keys, AWS IAM roles, Amazon SQS queues and AWS Secrets Manager secrets.

In this post, first I give you a brief overview of IAM Access Analyzer. Then I show you how to use the S3 console to preview access to your bucket before you add a new bucket policy, and how to review and validate the Access Analyzer findings. Finally, I show you how to preview and validate access when scoping down an existing bucket policy.

IAM Access Analyzer overview

IAM analyzes access to help you achieve least privilege. Previously, IAM Access Analyzer analyzed existing resource permissions to help you identify and reduce external access. Now, you can also preview and validate access before deploying permission changes.

To analyze access, IAM Access Analyzer analyzes resource permissions with automated reasoning. This form of comprehensive mathematical analysis applies logic and mathematical inference to determine all possible access paths allowed by a resource policy. This is how IAM Access Analyzer provides provable security and generates comprehensive findings for potential unintended resource access.

Preview and validate access to your S3 bucket when adding a policy

Before you save your S3 bucket policy in the S3 console, you can validate access to your S3 bucket. This helps you start with intended permissions when authoring new policies or updating existing policies. It is an optional step and you can decide to save your policy at any time. To preview access to a bucket in your account, first turn on IAM Access Analyzer by creating an analyzer for the account in the IAM console.

For example, you might want to allow an external account access to a bucket in your account. You create a new bucket in your account, and now you want to add a bucket policy that grants a specific external account access to your bucket. In the S3 console bucket policy editor, you can draft the bucket policy to grant this access. But before you save the bucket policy, you want to preview findings for public and cross-account access to your bucket.

Preview access

In the S3 console, open the Edit bucket policy page and draft a policy, as shown in Figure 1.
 

Figure 1: Preview access to your S3 bucket in the S3 console

Under Preview external access, choose an existing account analyzer from the drop-down menu and then choose Preview. Access Analyzer generates a preview of findings for access to your bucket. These findings take into account the proposed bucket policy, together with existing bucket permissions, such as the S3 Block Public Access settings for the bucket or account, bucket ACLs and the S3 access points that are attached to the bucket.

Validate access

You can review and validate these preview findings to ensure that the policy only grants the intended access to your bucket. The badge next to each finding provides context about how the bucket policy would change access to the bucket if you save the policy. The following are the finding badges, along with their meanings:

• New – indicates a finding for new access that the policy would introduce.
• Resolved – indicates a finding for existing access that the policy would remove.
• Archived – indicates a finding for new access that would be automatically archived, based on the archive rules for the analyzer. Archive rules define when findings should be marked as intended.
• Existing – indicates an existing finding for access that would remain unchanged.
• Public – if this badge appears in addition to one of the previous badges, it means that the finding is for public access. If this badge does not appear, it means that the finding is for cross-account access.

In this example, Access Analyzer generates a finding for cross-account access, as show in Figure 2.
 

Figure 2: Preview of a finding for new cross-account access to your S3 bucket

In Figure 2, the badge New with the description An AWS account has read and write access indicates that this is a finding for new cross-account access that the policy would introduce. You can expand the finding to view the finding details, as shown in Figure 3.
 

Figure 3: View of the expanded finding details

In Figure 3, the External principal field shows the account ID that has cross-account access to your S3 bucket. The Access level field displays the read and write access that the account has to your bucket.

If you identify new external access that you do not intend to introduce or existing external access you do not intend to remove, you should continue to revise the policy and then choose Preview again until you have achieved the access you intend. After you validate that the findings are for access you intend, and you also validate that there aren’t any findings for access you don’t intend, you can choose Save changes to save the policy.

Preview and validate access when changing an existing policy

Continuing the example, you have an S3 bucket with an existing policy that allows public read and write access. If you preview access without updating the policy, you can see there is an existing finding for public access, as shown in Figure 4.
 

Figure 4: Existing finding for public access

Now, you want to update the policy and reduce access so that only one specific external account has read and write access to that bucket. In the policy editor, you change the existing policy so that it only grants cross-account access to that account, and then choose Preview. As shown in Figure 5, when you preview access for this policy change, you can see two findings below.
 

Figure 5: Preview of one resolved (removed) public finding and one new cross-account finding

One finding has two labels Resolved and Public, which indicates that the policy change would remove the public access and resolve that finding, as you intended. The other finding has the label New which means the policy would introduce new access, and the finding details indicate this is the cross-account access that you intended to grant. Because you validated that policy change would remove the existing public access and grant new cross-account access, you are ready to save your policy change.

Next steps

In addition to previewing bucket access in the S3 console as I described in this post, you can also use Access Analyzer APIs to preview access for your S3 buckets, KMS keys, IAM roles, SQS queues, and Secrets Manager secrets through the AWS CLI and SDK. You can use new Access Analyzer API operations CreateAccessPreview, GetAccessPreview, ListAccessPreviews, and ListAccessPreviewFindings. For CreateAccessPreview operation, you will need to pass in your account analyzer and proposed resource configuration as input. For more information, see the IAM Access Analyzer API reference.

To turn on IAM Access Analyzer at no additional cost, open the IAM console. IAM Access Analyzer is available in all AWS Regions, including AWS China Regions and AWS GovCloud (US). For more information about IAM Access Analyzer and which resources it supports, see the AWS IAM access analysis features page.

If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, start a new thread on the AWS forum for IAM or by contacting AWS Support.

Want more AWS Security how-to content, news, and feature announcements? Follow us on Twitter.