How to get rid of AWS access keys – Part 2: Reducing Privileges

In the previous post in this series, we discussed how to do some basic cleaning of AWS access keys. In this post, we’ll show how to reduce the privileges in order to mitigate their risk.

Reducing privileges and tightening IAM policies are best practices for all identity principals, be it an application’s IAM role or an IAM user with an access key. In some cases, it may be easier to reduce the risks of the access keys by first tightening the IAM policies, before transitioning them to alternative authentication solutions.

This post is the second article in the series "How to get rid of AWS access keys". Read the first article atPart 1: The easy wins.

To identify the keys posing the highest risks to your environments, it can be helpful to identify which keys have high privileges (e.g. an IAM user with the AdministrativeAccess policy attached to it). High-risk keys can also be identified by finding those keys that are in sensitive accounts or have access to sensitive data.

In order to mitigate the risks associated with a principal being compromised there are two techniques that can be used to tighten the IAM policies:

Remove unnecessary privileges

Apply additional restrictions

Removing unnecessary privileges can be done at varying levels of granularity. For instance, at the service level, an access key with the AdministratorAccess policy may be restricted to justs3:*permissions instead. You can use AWS’sIAM Access Advisor informationto identify the service level adjustments.

The next level of granularity would be to identify the specific action level privileges required, which can be done withAccess Analyzer policy generator. However, it is worth noting that the Access Analyzer’s accuracy is based on the information AWS records in CloudTrail logs which has some special cases that can cause suggestions to miss things at times.

The important privileges to watch out for are ones that offer privilege escalation or the ability to list resources. For example, privileges in theiamorstsservices may provide some form of privilege escalation, and privileges such ass3:ListAllMyBucketswill allow an attacker to see all the S3 buckets in an account. If an attacker compromises a principal with some form of S3 read or write access, but does not know which S3 buckets they have access to, it may prevent the attacker from abusing the access they have. Although removing the read or write privileges altogether would be more secure, that may prevent the legitimate needs of the principal, while the privileges to list the resources are less often required.

The next level of granularity beyond this is to specify the individual resources that the principal needs access to, which requires manually reviewing the CloudTrail logs or the source code of the application.

In some cases, you may be able to apply additional restrictions on the IAM policy such asdenying access based on the source IPusing theaws:SourceIpcondition. However, you need to be careful that the IP address will not change. Depending on your network setup, you may be able to use VPC endpoints instead, which is preferred.

Given the risks of access keys, it is worth considering whether the data they need access to can be made less sensitive or the access to it can be better controlled. This might be done through a proxy service which may add additional controls. For example, if an application needs full access to a sensitive S3 bucket via an access key, it may be better if a Lambda performed the operations on behalf of the application, and through that you could perform rate-limiting, geo-IP restrictions, and data redaction or tokenization where possible.  Although there are a number of ways to implement this type of risk mitigation, with AWS’sS3 Object Lambdas, it may be possible to implement with minimal changes to the external application.

There are sometimes cases where AWS services require access keys for certain use cases. One example is when you wantS3 pre-signed URLsthat remain valid for multiple days. There is an argument to be made that you should seek to remove that requirement for pre-signed URLs that live that long, but we’ll assume that can’t be changed for your use case.  You could isolate the functionality that generates these URLs and put it into its own microservice that has limited privileges to accomplish this goal. The main application could then call this microservice to obtain the pre-signed URLs, and the access key would therefore be isolated from certain risks that come from being part of a larger application.

This blog post explained how to reduce the risks associated with AWS access keys by applying a least-privilege strategy. This same concept can be applied to other AWS principals as well. In the final blog post in this series, we’ll discuss alternative authentication solutions for principals that use AWS access keys.

Learn security best practices to deploy generative AI models as part of your multi-tenant cloud applications and avoid putting your customers’ data at risk.

Wiz helps simplify incident response in the cloud for faster investigation of security incidents.

See what is new with Wiz at Re:Inforce and learn about how Wiz and AWS continue to strengthen a strategic relationship to secure customers’ AWS environments.

Get a personalized demo

©2026Wiz, Inc.

StatusPrivacy PolicyTerms of UseModern Slavery StatementCookie Settings