Unused Access Analyzer: A Leap Toward Least Privilege, Not the End of the Journey

AWS IAM Access Analyzer can now detect action-level unused permissions. It’s a great enhancement in the native toolbox to achieve least privilege — but if you need comprehensive entitlements management at scale you will probably need additional tooling and work. Find out why and what you can do to complement it.

As part of a string of exciting announcements made at re:Invent in December 2023, Amazon introduced new AWS IAM Access Analyzer features including an Analyzer for unused access as well as custom policy checks. Tenable is proud to be a design partner integrating with the custom policy checks into Tenable Cloud Security. This integration was mentioned in the Amazon breakout session at re:Invent which discussed the announcement).

In short, an Analyzer for unused access will continuously monitor for action-level unused permissions (or overall unused roles) over a configurable period of time. The information from this analysis is also available over the AWS IAM Access Analyzer API, which can make it available for third parties.

This is a significant step forward in enabling customers to achieve least privilege through automatic analysis, an approach led and championed by Tenable Cloud Security since its earliest days.

As pioneers and long-time advocates of cloud infrastructure entitlements management (CIEM), we wanted to address questions we’ve heard since re:Invent about whether or not this capability is a solid foundation for an effective CIEM implementation. The answer, as for many questions, is: “it depends.” Finding out how and why can mean a world of difference for your security.

In this blog post, we share our experience with the new unused access Analyzer feature and talk about what it’s good for — and what can be improved — in order to be effective as a full-blown CIEM solution at scale.

Taking unused access out for a spin

The first thing we did, of course, was put unused access to use. AWS published a great blog post on getting started with the feature and I highly recommend reading it (but make sure you finish this blog post first).

I like to test drive functionality in extremes (even if it doesn’t always make operational sense), so I looked at the report for the IAM Role I use for my CI/CD pipeline which is — understandably — over-privileged with admin access.

We should note that results came really fast and the findings show up in a matter of seconds, even for an account with a decent amount of IAM Roles and Users. 

As seen in Figure 1, the Analyzer created a finding for “unused permissions.”

And diving deeper, the report shows the number of unused actions in each service. If we select one, as shown in Figure 2, we see the list of unused actions in the specified duration, and when each was used last (or “never” if not at all).

The Analyzer we configured here was for detecting unused actions over 60 days, so once an action was unused for 61 days, it was included in the report.

This complements a feature AWS released in 2021 that allows the generation of IAM policies based on access activity.

This ability is referred from the finding, where you can go directly “generate a new policy,” as shown in Figure 3.

As a quick (and valuable, don’t ask me how I know) note: if you’re using an organizational trail (which you probably are) to perform this action, you need to configure the Access Analyzer role with appropriate permissions.

Once you have generated the policy, you can then review the permission it suggests:

Then configure additional permissions as needed:

Finally, review the produced policy and edit it before applying:

Next, you need to fill out the resources info (you can see a clear indication of where this is needed by the red Xs on the side) so the policy will be complete and then you can use it instead of the over-permissive one (and of course — it's highly important you test it first).

So…what else do we need?

Not only can you use Access Analyzer to create a policy based on access activity, you now have a tool that can detect when this becomes necessary.

Could this be the Holy Grail towards least privilege using native tools?

Well, not quite.

There are still a few aspects that need to be supplemented to equip security and identity and access management (IAM) teams with the tools necessary to effectively manage permissions AT SCALE. Just in case the bold weight and CAPS were too subtle, I’m adding this sentence to make clear the importance of the scale element. I hope that does the trick.

Below, we’ll talk about several challenges you may encounter when trying to apply this approach with Access Analyzer at scale. The reason “scale” matters is that, often, when users think of the following challenges, they think of dealing with each one individually as it appears. This can make it seem feasible that native tools alone can support least privilege (though that is also not necessarily the case). But, when the challenge applies to hundreds or even thousands of identities, it becomes impossible to manage, and that’s what you have to keep in mind.

So let’s dive right in.

Challenge 1: The Access Analyzer output is NOT instantly applicable

From a practical perspective, the biggest issue with the procedure we described above is not even directly connected to the new unused access Analyzer, but with the last mile of the process — the policy generation. It should be noted that this part is NOT the new feature introduced — however, it's a significant part of the workflow of using it.

What stands out the most in Figure 6 are the red X’s along the line numbers, indicating the generated policy doesn't include the necessary resource statements, which must be inserted by the user in order for the policy to be applicable. We didn’t add these red Xs in. This is, in fact, how the suggested policy is generated. This is because the policy generated doesn’t provide the specific Amazon Resource Names (ARNs) to be included in the policy.

This may be seen as a granularity issue, as the recommendations are not given on the resource level (and in fact, we address this in the next section) but, more than anything, this requires you to invest time and effort to edit the output before you can use it.

Not only that, making these edits in an effective and responsible manner (i.e. not breaking anything) entails acquiring intimate knowledge of the architecture in which the identity using the principal operates and the functions it performs, and probably reviewing the CloudTrail logs to see firsthand what resources are actually being used. Doing this review manually is something you will have to test (and probably find mistakes with) or alternatively, use “*”s instead of specific resources, which misses the point of trying to achieve least privilege.

This, on its own, may be enough to deter you from approaching this challenge when the number of identities you manage is more than just a few.

To cement the argument that applying the procedure we described above at scale is not feasible using only native tools, we’d probably stop right here (though, we’re not going to).

Challenge 2: The Access Analyzer analysis is insufficiently granular

Arguably the most sensitive place where Access Analyzer falls short is granularity, and what it does and does not factor into its calculations.

There are a few reasons this is important, and we will explore them.

Not tracking all actions

As it seems from the AWS documentation, the actions the unused access Analyzer reviews are the same as the “last access” analysis done by Access Advisor. (For a complete list of action-level permissions that are supported for unused access findings, see IAM action last accessed information services and actions.)

This doesn’t include actions such as GetObject or PutObject in S3, for example.

As part of our experiment, we looked at a workload that only uses GetObject from a specific Simple Storage Service (S3) bucket and is grossly over-privileged for this purpose as it’s assigned with AmazonS3FullAccess.

Interestingly enough, as can be seen in Figure 7, the unused access Analyzer didn’t report “All actions unused” for S3 (as it produced, for example, for “S3 Object Lambda”).

This means that the Analyzer detected that something was used with regards to S3 (i.e., even though the action the role used is of an action it supposedly doesn’t track), but as expected, the Analyzer did NOT report the usage of GetObject.

The bigger problem here is actually not with the Analyzer finding, but with the policy created in the call to action (see Figure 3, above). Policy generation (which, as mentioned before is NOT the new feature launched but is an important part of the workflow) is known not to analyze data events and so the suggested replacement “right-sized” policy won’t take into account the GetObject actions performed, therefore the wizard for configuring the policy for it will look like this:

and the starting point for the policy to be customized will look like this:

This means that using this procedure for the process of right-sizing permissions requires extreme care.

In the best case, if you consider how Access Analyzer works, explore the principal activity yourself and then factor it in, this will lead to a lot of work and potential mistakes which will need to be weeded out in testing (again, we’re talking about the best case).

In the worst case, if you’re using it automatically without taking these actions into consideration (probably due to lack of knowledge), and apply the changes in production without proper testing — which is something that rarely happens of course, right? ;) — you may unknowingly remove access to functionality that’s being used and break legitimate business functions. The last thing you want to do as a security professional is create a denial of service on your own infrastructure.

That is why this kind of process doesn’t scale. You may be able to apply this kind of scrutiny to several identities every once in a while, but doing it for hundreds or even thousands of identities in a dynamic environment is impossible.

Not providing resource-level recommendations

As we mentioned before, Access Analyzer unused access and policy generation don’t provide resource-level analysis, which becomes a problem when you need to right-size the access to a significant number of roles at a very high frequency.

We’ve already gone into detail when describing the problem it creates from a practical point of view, so we won’t repeat ourselves, but this is an issue of accuracy, as well.

Not considering boundaries

While Access Analyzer looks at IAM policies, it’s crucial to remember that in AWS, IAM is NOT only IAM policies. There are so many things to take into account, such as Service Control Policies (SCPs), Permission Boundaries (PBs) and Resource Based Policies (RBPs).

By analyzing IAM policies alone, it’s hard to deduce if permissions are granted or not.

If a boundary implemented by an SCP, PB or a RBP prohibits access for an identity, it won’t be picked up and the report regarding “unused access” (should an IAM policy supposedly grant it) would be a false positive.

This is probably the least significant issue due to Access Analyzer accuracy; but still, it’s a good testament as to why it’s not the ultimate tool to apply at scale — because you may be alerted over permissions that are not effectively granted since they are outside a boundary. For this reason, a lot of false positives may be generated; and we all know alert fatigue is probably the worst enemy of the security professional (other than the actual cyber adversaries, of course).

Not considering resource based policies

In addition to not considering RBP as a boundary, if an RBP grants unnecessary access to an identity that won’t be detected by the unused access feature and would be a false negative — that is, we won’t remove unnecessary access which is effectively granted.

So, you’ll still be left with the task of reviewing RBPs to right-size access granted by them, and that’s also hard to do manually.

Challenge 3: Access Analyzer does not look behind the IAM role

The analysis Access Analyzer provides is done at the level of IAM users and IAM roles. At first glance, that makes sense because, supposedly, these are the principals AWS accounts offer.

However, IAM roles are often used by more than one identity; for example, when used for federation or when one IAM role is used by several workloads. In that case, analysis for that one IAM role might not be enough to home you in on the best way to structure the permissions (or even restructure the IAM roles) used by the non-IAM role identities which the IAM role serves.

When performing this kind of right-sizing activity at scale, visibility into this kind of segmentation is invaluable to ease the abovementioned tasks; performing them manually, even with input such as the unused access analyzer will produce is really difficult.

Challenge 4: The Access Analyzer output requires operationalization

The information provided by the unused access Analyzer still needs to be worked into a workflow that will trigger a response automatically, because at scale, it’s impossible to review every IAM Role or even every AWS account in search of such findings.

As the AWS blog notes, you may leverage Access Analyzer’s integration with EventBridge (creating a rule for unused access events) or Security Hub, which reduces the heavy lifting for automation, but still requires additional configuration you don’t get out of the box.

In addition, as we mentioned before, the end result of the process is the policy generated by the policy generation functionality which requires your additional attention. Again, it may not be a challenge to do every now and then, but it is very difficult to keep track of when you’re managing thousands of identities.

Challenge 5: The Access Analyzer output needs contextualization

While these challenges are tough on their own, the most significant accomplishment, harder to achieve with native tools, is probably contextualization.

As we all know, not all security findings were created equal. An unused access finding for an IAM role used by a workload that may be at significant risk due to its network configuration, vulnerable software deployed on it and / or poor posture configuration is much more important to address than one which isn’t. This also has a flipside: taking care of other risk factors for privileged identities (even if not over-privileged), is more significant than for those which aren’t.

Thus, fusing all the risk factors together — including unused access — is incredibly important to make the most of the knowledge regarding the existence of unused access.

Contextualization of these findings is crucial for prioritizing which findings to address first. In a world of resources becoming more and more limited, it is essential for you to get the most bang for your cybersecurity buck and political influence in your organization.

And in step CNAPP solutions

While the analysis Access Analyzer provides is a good start, and since there are other things you have to review to work with it, that’s exactly what it is — a start.

The most recent cloud-security product category on the block, cloud native application protection platform (CNAPP), aims to protect and secure cloud applications throughout the entire software development lifecycle, from development through production and workload. It does so by integrating several cloud security capabilities, such as posture management and workload protection, to fuse together information, properly contextualize it and prioritize security findings. CIEM is another one of these capabilities.

For this reason, CNAPP tools can enhance native tools if, in fact, they should provide more precise analysis, deeper visibility into different kinds of identities and out-of-the-box operationalization and contextualization of the insights produced. This is easier said than done, so many of the existing CNAPP solutions provide very little CIEM analysis of their own and simply rely on what the cloud service provider APIs provide.

We know this because at Tenable Cloud Security we’ve spent the past four years building cutting-edge CNAPP technology which prides itself on having the most advanced and precise CIEM layer on the market, so we know exactly what it means to have such a tool at your disposal.

Tenable Cloud Security is a CNAPP with integrated CIEM that handles the gaps we mentioned above. Tenable provides precise analysis down to the resource level and factors in Service Control and Resource-Based Policies, Permission Boundaries and anything else that may affect the effective permissions available for each identity.

We do this for AWS and other cloud service providers, so if you’re running a multi-cloud environment, you get standardized analysis presented on a single pane of glass in a way that requires very little expertise to understand.

We analyze identities federated from identity providers, string together origin identities for assumed identities such as workloads using IAM roles so you get deep visibility into what’s going on and by whom, and we top it off by producing easy-to-query tools such as activity logs, permissions mappings and clear visualizations so you can vividly understand the relationships between identities and resources in your environment.

Last but not least, we operationalize and contextualize this analysis with other security functionality we have as a CNAPP, including workload protection, network analysis and posture security, to provide an actionable and prioritized assessment of the security findings in your environment.

Verdict: Great as a jumpstart, not for crossing the finish line

As big fans of the incredible efforts AWS puts in place to make it easier for its clients to maintain a secure environment, we welcome the unused access Analyzer as a very significant step toward achieving least privilege, and we recommend trying it out.

As you may have noticed, we’ve mentioned once or twice that it might be complicated to apply this enhancement effectively at scale (there we go, we said the “s” word again) — and that’s a very significant point to make. If you only have a very small-scale deployment and / or are just starting out your experimentation with the practice of least privilege, it’s very probable that a full-blown CNAPP, or even a dedicated CIEM solution, would be overkill.

Creating an unused access Analyzer is simple and accessible, and it produces results very quickly to start your journey toward least privilege. This is a great tool to get started right-sizing the permissions in your environment — as long as you find it effective to keep serving that purpose, keep at it! As a side note: keep in mind that this new addition to AWS IAM Access Analyzer is not free. So, if you’re using it yourself — or enabling it because a third party needs its analysis as they don’t produce sufficient entitlement analysis on their own — there is additional cost.

Once you get to the point where you manage multiple accounts with many workloads and users each, the gaps we described above may become too hard to keep tabs on, and in order to not let the entitlements in your environment get away from you (which would be much, much more difficult to handle later) you should seriously consider doing proofs of concept (POCs) with CNAPP solutions and choosing the one that best fits your needs. Otherwise, you might end up with permissions spaghetti that is really easy to cook up and extremely hard to untangle with confidence that you’re not breaking anything in production.

And if you’re already facing a plate of permissions spaghetti? You should request a demo right away by visiting https://www.tenable.com/products/tenable-cloud-security