How to Improve Your Security Posture in Just a Few Clicks with AWS IAM Access Analyzer

When talking about security on AWS, the first services that pop up are usually Security Hub, Cloud Trail, Guard Duty and so on. They are all important and have their place in your AWS environment, however there is one service which is often overlooked but it can provide a lot of value in almost no time. Yes, it is the AWS IAM Access Analyzer and its capability that finds AWS resources with external access. The best part is, this feature of AWS IAM Access Analyzer is free of charge!

Basics

What exactly is meant by external access? It means that an entity (including unauthenticated anonymous users) outside of your zone of trust can access your resource, e.g. read files in your S3 bucket or access your EBS volumes snapshots. Under the hood, AWS IAM Access Analyzer uses automated reasoning powered by Zelkova to analyze a policy (e.g. an IAM policy or a bucket policy) and provide a definitive answer whether it allows (unintended) access to the resource from outside of your zone of trust.

The zone of trust can be:

• a single AWS Account
• the whole AWS Organization if you setup an organizational Analyzer from the management AWS account or from a delegated admin account.

Important to note is that unlike IAM, the Access Analyzer is a regional service so it needs to be enabled in each region you are actively using.

Which Resources Are Supported?

Since the time I wrote my first article on this topic the number of supported resources types has more than doubled. The supported resources include those resources which you can make public by either attaching a resource policy, e.g. Secrets Manager, SQS Queue; create a grant, e.g. KMS key; or make them public explicitly, e.g. RDS Snapshots, EBS volumes snapshots.

How Does It Work?

If you are working in a multi-account setup which should be the case if you run more than one workload in more than one SDLC stage, it is a best practice to use AWS Organizations to govern and manage your AWS accounts. Going further into the best practices, it is a a recommendation to have a separate Security or Audit AWS Account to manage your security services on the organizational scale.
In that case, you need to first log in to your Administrative account and navigate to AWS IAM Access Analyzer in the web UI and select Analyzer Settings under the Access Analyzer section.

Clicking on the Add delegated administrator will allow you to specify the account ID of your Security account which you will use to manage the Access Analyzer.

Next, you need to login to the Security or Audit account which you specified in the previous step as the Delegated administrator account and navigate to the IAM Access Analyzer section and hit the Create analyzer button. It is important to select the right type of Analyzer (external access), give it a meaningful name and define the scope or the zone of trust. Since we are in a multi-account setup we are going for the Organization as the zone of trust.

Voilà, your Access Analyzer is up and running. It will take some time to populate the findings, but you just made your AWS environment much safer with almost zero effort.

Working with the Findings

After observing the findings in an environment using AWS IAM Identity Center (formerly AWS SSO) to manage identities and access, we can see that we have a lot of findings related to the IAM Identity Center roles and the SAML provider which the IAM IC creates in each account. The Access analyzer considers these SAML providers external to the Organization because theoretically you could federate with Identity Providers outside of your Organization or AWS.

So, the easy way to get rid of the findings would be to just select all findings and archive them. However, if you create another AWS account in your enviornment, the IAM IC will again create a SAML provider in it together with multiple AWS roles. So the long term solution is to create archive rules.

Creating Archive Rules

Archive AWS IAM IC findings

By navigating to Analyzer Settings, selecting the Analyzer, and hitting the Create archive rule, we can create Archive rules. They are applied automatically when new findings are created and can help us, if crafted properly, eliminate false positives.

So, to exclude (or auto-archive) the IAM roles related to AWS IAM Identity Center, the rule could look like this:

Make sure the rule matches the active findings and click the Create and archive active findings button.

Archive IAM Roles in Non-primary Regions

If you are actively using multiple regions, you will see findings for IAM roles in each region since IAM roles are global resources. To prevent these duplicates, you should pick a primary region and create an archive rules in all other regions to auto archive all IAM Roles findings, i.e. Resource Type is IAM::Role.

Integration with Other Services

Security Hub

If you are using Security Hub to manage your security posture, you will find AWS IAM Access Analyzer findings there automatically.

Event Bridge

The other option would be an SNS topic or virtually endless possibilities of integration via the Event Bridge.
The corresponding Event rule would look like this:

{
  "source": [
    "aws.access-analyzer"
  ],
  "detail-type": [
    "Access Analyzer Finding"
  ],
  "detail": {
    "status": [
      "ACTIVE"
    ]
  }
}

Currently it is not possible to drill down further in the event rule and to specify only External access type of findings.

Pricing

The external access feature of Access Analyzer that detects resources with external access is free of charge!

Tips and Recommendations

1. Always create an organizational Analyzer if you run more than one AWS account.
2. Create or use a delegated admin account for managing the organizational Analyzer to limit the needed operative tasks in the Administrative account. The delegated admin account would be usually your Audit or Security account.
3. Don't forget that AWS IAM Access Analyzer is a regional service so enable it in all regions which you are not actively blocking (e.g. by an SCP).
4. Related to the previous point, if you are using more than one region, pick a primary one where you want the Access Analyzer to scan all supported resources. In all other regions exclude the finding related to IAM roles otherwise you would see duplicit findings for the same roles in more regions.
5. General advice, unless you are just evaluating and testing the service in a sandbox environment, always use Infrastructure as Code to set up and manage your AWS services and resources.