DEV Community

Cover image for AWS IAM Access Analyzer Demystified
Karol Havrillay
Karol Havrillay

Posted on

AWS IAM Access Analyzer Demystified

Given how fast AWS release new products and features, it can be quite easy to lose track about what each individual service does or what features it provides. To make the matter even more complicated, AWS also likes to pack a broad range of functionalities under one umbrella.

Once such example is AWS Systems Manager which consists of services with functionalities ranging from storing configuration data for your applications to securely accessing your EC2 instances via a shell session or patching them at scale just to name a few.

Another example is AWS IAM Access Analyzer which provides a set of very interesting security related functionalities which do not exactly serve the same purpose, but they are covered by one service. Let’s have a look at them one by one.

Who Knows My Secrets?

Historically, this was the first functionality of Access Analyzer. It is backed by mathematical proofs, and it analyzes resource policies on subset of your AWS resources to determine whether they are shared outside of the defined boundaries. Btw, I recommend watching a great video on the internals of the service from one of the Re:Invents.

The boundary can be either an AWS account or the whole AWS Organization and the service refers to it as the Zone of trust. In case you define as a boundary the whole AWS Organization, the Access Analyzer needs to be setup in the Management account (previously known as Master) of the Organization or from an account designated by the Management account.

The list of supported resources is not particularly long but it covers some of the most critical ones:

  • IAM roles which can be assumed from outside of your zone of trust
  • KMS keys
  • Lambda functions and layers
  • SQS queues
  • Secrets Manager secrets
  • S3 buckets

So, in case you want to be notified if someone in your AWS account or an Organization opened up a way in through one of these services, this is the feature of AWS IAM Access Analyzer you should definitely enable and configure it accordingly.
Findings of externally shared resources

Is My Policy Going To Work As Intended?

Another AWS IAM Access Analyzer functionality is policy validation. There is also an API for that, but the functionality seems to be mostly useful in the web console when you are drafting or testing your policies before you deploy them finally via Infrastructure as Code, e.g. CloudFormation, Terraform or others.

In the web console you can see a similar interface as depicted in the picture when working with IAM policies, Service Control Policies and S3 bucket policies.

IAM Policy validation pointing to a mismatch between the condition value and the operator used

It comes with 100+ checks and will warn you mostly about syntactical errors in your policy e.g., a missing mandatory element. But it will also raise a warning, a security warning or a suggestion e.g., if you use the condition operators incorrectly, or your policy might end up to be way more permissive that you might have intended, especially with the iam:PassRole action which is commonly used in privilege escalation techniques.

Can I Get Fewer Permissions?

This is the latest feature of AWS IAM Access Analyzer, and its purpose is to generate least privilege policies for an IAM principal (a user or a role) based on its previous activity.

It was introduced approximately one year ago and as it often is the case with AWS, it was more of an MVP with limited functionality. It was quite restricted in terms of number of supported services, on source data (you had to have your Cloud Trail in the same account as the IAM user or role for which you wanted to generate policies), and strict quotas in terms of number of generated policies per day.

Nowadays it seems to be much more mature and returns fine-grained policies for dozens of services and less granular policies for the rest of the services. For the former, it uses CloudTrail and works fine also in enterprise environments with centrally stored CloudTrail logs in a separate account. For the latter, it uses the “last accessed” information only to find out whether the service has been used or not without returning the individual actions.

I’m quite sure that over time, the coverage of services where fine-grained policies can be generated will grow significantly.

You are prompted to fill in ARNs of the resources for actions that support resource-level permissions

Conclusion

AWS IAM Access Analyzer is a great tool, or better said, a great toolset, which can help you in many ways. Whether you are a software developer deploying code on AWS and wanting to check if your policies adhere to best practices, or a security engineer wanting to get an additional view on the security posture of your AWS Organization or if you are part of a central infrastructure or security team creating and finetuning least-privileged IAM roles and policies.

I’ve spent some deploying and using the functionalities described above and I plan to do a deep dive about some of them in one of my next articles, so stay tuned!

Top comments (0)