IAM access analyzer — A beginners guide

Architects have made architecture too complex. We need to simplify it and use a language that everyone can understand. — Toyo Ito

One of the best and simple AWS services that I encountered next to Cloudtrail is “IAM Access analyzer”

POC time : 30 min

Time to get this up in production : < 2 hours.

Benefits

If you have two or more AWS accounts, do your self a favor and start using IAM access analyzer for your organizational security. Access analyzer gives you all the AWS resources which are exposed outside of your AWS organization.

Yes! One more way to find out all your open S3 buckets in real time.

Here is a quick history of how many S3 buckets were left open to public till date.

Overview

IAM Access Analyzer continuously monitors resource policies for changes, eliminating the need to rely on intermittent manual checks in order to catch issues as policies are added or updated.

Resource policies are used to grant fine grain access control. Example : S3,SQS, LAMBDA’s etc.

With one click in the IAM console, you can enable IAM access analyzer across all your AWS accounts and continuously analyze permissions which are risky and not intended.

Yes it is free.

Resource-based policies are attached to an AWS resource example, S3, SQS, Lambda, KMS to grant fine-grained control over which actions can be performed. With resource policies, one can specify who has access to the resource and what actions one can be performed.

While overly permissive resource policies increase the development velocity of an application, it also creates unnecessary risk and provide attackers way to further penetrate into a cloud environment.

IAM Access analyzer is a free service launched by AWS to detect anomalies in AWS resource policies which can enabled at the Organization level. Yes it is just literarily click of a button, thanks to AWS for making it super easy. IAM access analyzer is regional, so you will have to enable it in every region. This can be automated with cloud formation if you are looking to enable it in all the regions.

Recommend having a different AWS account to enable Access Analyzer instead of enabling in your AWS organization account. You can add a member account in the organization as the delegated administrator to manage Access Analyzer for your organization. Here is more info on how to set this up. If you are dealing with say ten or hundred plus AWS accounts it doesn’t matter, it can be done at the Organization level which would analyze all the AWS resource policies within the AWS organization.

A, B, C’s of IAM access analyzer

Let’s find out the power of IAM access analyzer before delving into it. With the click of a button, you can detect anomalies in AWS resource policies, here are a few

• Lists SQS queues which are open to the world.
• Lists SQS queues which are accessible to AWS accounts outside your AWS organization.
• Lists AWS lambda’s which are open to the world.
• Lists AWS lambda’s which are accessible to AWS accounts outside your AWS organization.
• Lists S3 bucket policies which are open to the world.
• Lists S3 buckets which are accessible to AWS accounts outside your AWS organization.
• Lists all the IAM roles with trust policies which can be assumed from a role /account which do not belong to you.
• Lastly it’s free (yay!). You know the best things in the world come free.
• Resolved : If the resource is no longer shared outside of the zone of trust, the status of the finding is changed to Resolved. Resolved findings are deleted 90 after the last update to the finding status.
• INTERNAL_ERROR : This is the status when there is an explicit DENY. Example and S3 policy with DENY all and allow a specific IAM Role, AWS account.

Known pit falls

• Wish this was applicable to all the regions by default (Similar to CloudTrail)
• IAM is global, so every region would see IAM calls. If there is a role open to the world, you would notice this in all the regions where IAM access analyzer is enabled.

My learnings :

• Detection is only one part of the story, response is the other. If you have a SOC team ensure they are plugged in. If you are SOC less, ensure you generate an actionable alerts and mitigate the issues. ( Recommend an actionable events via JIRA or other ticketing applications)
• Remember automation is good, in the end you will have to interact with the person who actually created this. Educate your teams on the pitfalls of overly permissive policies.

Getting started

• Enable Access Analyzer Navigate to IAM → Access Analyzer → Click on Create

• Ingest the data to your data warehouse via lambda’s. Here is a quick lambda script to ingest data to S3.
• AWS Event Bridge → SQS → Lambda → S3 → Hive/ElasticSearch

TL;DR , my final thoughts

• Thanks AWS, this is a great service, in the past I used security monkey/custom scripts for these sort of things. Now with just a one click we can find anomalies in the account .Very well done.
• Enabling this at the organization level, automatically applies to all the AWS accounts in the org which is a great feature.
• One or thousand AWS accounts, it is the same amount of work and also you carry the same amount of risks when exposed.
• Findings are generated only once for each instance of a resource that is shared outside of your zone of trust ( Meaning less spam and no alert fatigue)
• Every time a resource-based policy is modified, Access Analyzer analyzes the policy and reports if needed.
• Takes up to 30 minutes after a policy is modified for Access Analyzer to analyze the resource and then update the finding.
• Finally, take action on your findings : Find out all the open issues which are public by

”detail.isPublic” !=false” and “detail.status”!=RESOLVED