Access keys associated with IAM users in AWS are unfortunately all too common. Wiz data indicates nearly every cloud customer has at least one. These keys are problematic because they never expire, so they end up in places that non-static credentials would not, such as source code, or where they could still be found and used by an attacker years later, such as old application logs or back up files. AWS access keys have been the source of a number of security incidents that could have been prevented if the credentials had expired by the time the attacker found them. The alternative is to use IAM roles that have session credentials that expire after 36 hours at most, and often default to 12 hours or less.
In this first blog post in the series, we’ll discuss the most straightforward ways of removing AWS access keys and IAM users, which become unnecessary once the keys are removed.
In early 2023, AWS changed the console to add friction and guidance for users attempting to create AWS access keys. This series will expand on the guidance AWS offers there when new keys are being created and will provide additional guidance on what to do for existing access keys.
Remove unused access keys
The easiest AWS keys to get rid of are the ones that aren’t being used. These can be found via the credentials report by searching for either inactive keys or a last used date of “N/A” for any active keys.
Then, you should look for access keys that have not been utilized in the last 90 days, or any other time frame that seems appropriate to you. Although the CIS benchmark uses 90 days, you should ideally pick a much shorter time frame.
🔎 Wiz data shows that 31% of the average cloud customer’s access keys (mean and median) have not been active in the past 90 days.
Remove IAM users without credentials
After removing these access keys, you may be left with IAM users that do not have any credentials and therefore should be removed since they cannot be used. The credentials report can again be used to identify users that do not have active keys or a password.
Remove root access keys
There are very few reasons to ever use the root user account in AWS, and best practices recommend disabling this user entirely using a Service Control Policy (SCP). If you do have any root access keys, you should determine their purpose and find an alternative. Root access keys can be discovered with the CLI command aws iam get-account-summary.
Identify human users
Human users of AWS environments, such as employees, should be using SSO to access AWS with a federated Identity Provider. A central identity provider provides better processes for employee offboarding and access management when you have multiple AWS accounts. It can also offer additional features such as device attestation, being able to define requirements for the type of multi-factor authentication devices supported, and more.
If third-party contractors are accessing your AWS environment, you’ll need to decide whether you want to enroll them in your identity provider or have them authenticate to their own AWS account (through SSO) and establish a trust relationship with an IAM role in your account.
IAM users with password logins can be found with the previously mentioned credentials report. These can be transitioned to SSO, removing the need for access keys .
Identify AWS compute resources using access keys
AWS compute resources such as EC2s, Lambdas, and containers should be using IAM roles because they ensure credentials are temporary. The AWS SDK will check a number of places for credentials such as environment variables, files on disk, and eventually the instance metadata service of EC2s, to obtain an IAM role (a.k.a. an instance profile in this context). Moreover, the SDK will automatically refresh any expiring credentials. The easiest way to identify AWS access keys on disk is with a solution such as Wiz that can scan for them on the disk, but alternatively you can examine the CloudTrail logs for IP addresses associated with IAM user access keys in your AWS environments.
In many cases you should be able to assign an IAM role to the compute resource that has the same privileges as the IAM user that the key was associated with and then remove the static access key that was found on the resource. The SDK will automatically determine it needs to use the IAM role credentials instead of the access key.
Keeping the keys out
As you remove existing access keys, you’ll want to ensure additional ones are not being created. One way of preventing this is to use a Service Control Policy (SCP) to deny the creation of new access keys and IAM users:
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Deny",
"Action": ["iam:CreateAccessKey", "iam:CreateUser"],
"Resource": "*"
}
} SCPs like this should be deployed alongside Infrastructure-as-Code auditing rules as the developer experience is better when things are blocked as early in the development process as possible.
Additionally, this SCP will prevent access key rotation, so it should only be applied to accounts whose access keys have been removed.
Conclusion
In this post we’ve explained how to identify and remove several types of unnecessary access keys and IAM users and a way of stopping this problem from getting worse. In future posts, we’ll discuss how to reduce the privileges of the access keys and use alternative authentication solutions in order to mitigate risks.
Read the second article in this series at Part 2: Reducing Privileges.
