Becoming an IAM Ninja with a little help from AWS

Imagine the scene, your company has decided to move to AWS and already created a load of resources in the new environment. When all of a sudden, they are now worried about the security of these resources and the access they might have. The CSO tasks you with refining and creating new IAM policies. You’re not a security expert and have had limited exposure to Identity Access Management (IAM) in Amazon AWS. Well, don’t fear, because AWS has you covered, with the IAM Access Analyser. Which is available to you at no extra cost.

IAM Access Analyser: What is it?

amazon iamBack towards the end of 2019 AWS released a tool called IAM Access Analyser. This tool was designed to give you the ability to identify and assess your IAM roles and policies that have been shared with an external entity. Which when you get into it there are actually quite a few external entities that IAM can use, such as another AWS account, root users, another IAM user or role, a federated user or an AWS Service, as you can see it quite the list that can easily get out of control. That’s not even all of them as well.

But what does it do?

The way it does this is by it uses automated reasoning or in a more technical explanation. Access Analyser uses a system called Zelkova which parses IAM policies into logical statements whereby it runs a varying number of different types of logical solvers against the logical statements that are built-in. Phew! Hopefully, that didn’t scare you off it, but don’t worry you don’t need to know any of this for using the tool. (If you do want more of this lookup satisfiability modulo theories.)

Access Analyser works across organisations and is enabled per region. Once it finishes its evaluations of the policies in your account you are good to review those policies. Now the findings will only stay around for 90 days so don’t stand around check them out, but there is a process for archiving results as well. You might find policies that still have access granted to a company you used to audit your AWS resources or to external tooling like Snyk you might not be using anymore.

You can now tidy policies up in confidence you might not be sharing access anymore. Do note the tool can’t tell if these are active external entities, so make sure you check before changing them. The analyser will continue to monitor changes to these policies and warn you when external access has been enabled. But there’s more to this tool, we can take this to another level.

The Making of an IAM Ninja.

In 2021 AWS took Access Analyser to a new level. In March 2021 they added new functionality to Access Analyser, it can now produce fine-grained IAM policies for you! Now you can go from being a regular IAM Joe to that IAM Ninja. It doesn’t work just by you selecting what you want a policy to do in a similar fashion to when you make one from scratch currently. Instead, what it does is make use of CloudTrail. How does it do this? Well, let’s take a look.

For this you will need:

  • IAM Access Analyser enabled.
  • CloudTrailing logging enabled (called trails) for the account of the resources you want to use and in.
  • AWS resources active with IAM role attached that have been tested or used recently.

Getting into it:

If you have all of them let’s go ahead and generate a policy. Note: This will not cover the full set up and assumes some configuration has been done and is ready to work with the tool.

  1. Go to the IAM console and find the role you want to analyse.
  2. Now go to Generate policy based on CloudTrail events and give it a date range to check. If the testing you did was 10 days ago then put a date range that is up to the morning of that day to make sure you catch all CloudTrail events.
  3. Select the Trail to use and generate the policy.
  4. Wait for it to be generated (times can varying depend on the size of the trails log and date range).
  5. Review the policy and edit as needed.

You now have the building blocks to make your fine-grained IAM policies. This could take a policy from using Administrator Access all the way down to just S3: ListBucket and SQS: ReceiveMessage.

I would like to point out is that this should be the starting point on your Amazon IAM journey and not the end. You wouldn’t use it against a production service. Instead, you should really aim to use it against services and resources you plan to release to production. Instead. test the resources in your testing account. Do a full end to end application test and then use the IAM access analyser to create new policies to use. From which you would then edit to suit your needs and point at specific resources ARNs. It’s the stepping stones towards your end goal production policy.

You are now well on your way to adhering to the policy and security mantra of least privilege.

Taking it to the next level: Automation.

Now to take it even further, by putting some automation in.

Like any good AWS service, the Access Analyser has loads of API’s to be taken advantage of for making automated solutions. For me, the biggest advantage here is that it can be introduced into your CI/CD tooling to get you into the DevSecOps space.

A good example of this would be to imbed a couple of steps into a testing pipeline. Whereas once the testing is complete you put a small wait step in, say 10 minutes for the Trails to populate. Then you can use the Access Analyser StartPolicyGeneration API action to start the process of creating a new policy. Following that up with a final step of GetGeneratedPolicy to get the policy to be reviewed by your security team.

Another interesting application for it would be to embed some commands into your security scanning suite of tools. For instance, for any resources that are deployed a scan could be kicked off using StartResourceScan which would scan the policies that are attached to the resource. From there the output the results into via GetFinding into your security scanning output for review and remediation.

As you can see there a few options you can use to help secure your IAM and Security standing. I would also recommend going to the AWS blog platform. As there is currently a blog on automating the detection of public access to AWS KMS keys for a good dive into the art of the possible.

Hope this article gives you an idea of what Access Analyser can do for you, and you give it a try. You’ll be surprised by what you find.

Need help with your Cloud journey? get in touch: info@mobilise.cloud.

Enterprise and public sector trust Mobilise to securely transform their tech, teams and how they do business.

Say hello to your independence with our project enablement approach.