What to Do If You Inadvertently Expose an AWS Access Key

Keeping your AWS keys secure is one of the most important things you can do. This week Will Kruse, Security Engineer on the AWS Identity and Access Management (IAM) team, explains the steps to safeguard your account in the event you inadvertently expose your AWS access key.

Your AWS credentials (access key ID and secret access key) can be the literal keys to your account. If somebody has a copy of those credentials, she can perform any action in your account permitted by the policies associated with those credentials, such as launching an Amazon EC2 instance and storing objects in Amazon S3. Therefore, just like you’d never hand over the keys to your home to a complete stranger, you should never share your AWS credentials.

But what happens if you do inadvertently share your credentials? If this happens, follow these steps:

1. Determine what resources those credentials have access to 
What do these credentials have permission to do and what resources can they access? Root credentials, which will be listed under the Security Credentials page of the AWS Management Console, have full access to all of the resources in the AWS account. IAM credentials will be associated with an IAM user and you should review the user’s IAM policies. Tools such as the IAM policy simulator or the IAM console can help you review.

After you’ve determined what access the credentials provide, you can decide what steps to take in response and in what order. For example, if the credentials allow read and write access to sensitive data, you might wish to disable access promptly (see step 2). On the other hand, if the credentials only allow read access to data you intended to make public, you might choose to create new credentials first (see step 4), transition to these new credentials, and then disable the old credentials. As a third example, if the credentials allow write access to data with important integrity requirements, you’ll want to identify any attempts to modify that data and restore a trustworthy copy from a backup (see step 5).

2. Invalidate the credentials so they can no longer be used to access your account 
The potential for unintended access with these credentials remains until this step is completed. Follow the instructions in the documentation for disabling credentials: root credentials or IAM user credentials.

When you disable or delete credentials, any applications that are still using them will be affected. We recommend disabling credentials as a first step instead of deleting them, because disabled credentials can be restored if needed (for example, in case an application was affected unexpectedly).

3. Consider invalidating any temporary security credentials that might have been issued using the credentials
Temporary credentials might be in use in your account for features like roles for EC2, federation, or cross-account access. Temporary credentials have a limited lifetime (anywhere from 15 minutes to 36 hours, depending on how they were obtained), unlike IAM user credentials, which are valid until you disable or delete them. If you want to promptly invalidate any temporary security credentials that might have been issued by using the exposed credentials, and not simply wait for them to expire at the end of their lifetime, see “Invalidating Temporary Security Credentials” later in this post.

4. Restore appropriate access
Because access was disabled in previous steps, consider the following options to restore access:

• If you deleted an IAM user, create a new one with a new access key. If you disabled root credentials, consider removing access keys for the account altogether. Instead, create an IAM user and use the credentials for that user for AWS access.
• Instead of using a long-lived AWS credential like the access key for an IAM user, consider using IAM roles or federation. The advantage of roles or federation is that they use temporary security credentials so there are no long-lived AWS credentials to protect (or inadvertently expose).

5. Review access to your AWS account
Use AWS tools to determine what might have occurred in your account:

• Check the AWS account for persistent or residual access.
• Review all available S3 bucket logs and AWS CloudTrail logs to understand what actions might have been performed on your AWS resources.
• If the credentials that were exposed had permission to create, modify, or delete company data, determine the effect associated with that access. For example, you might want to restore data from a backup that was made before the credentials were exposed.

Invalidating Temporary Security Credentials

If you inadvertently expose long-lived credentials (for the account or for an IAM user), the credentials can be used to create temporary security credentials. The credentials have a limited lifespan, but you can also invalidate them so they stop working within minutes.

Rotating the credentials for the IAM user whose credentials were exposed will not invalidate any temporary credentials that were obtained using the user’s credentials. However, if it’s practical for you to delete the IAM user, do that. This causes authentication attempts for temporary credentials associated with that user to fail.

If you don’t want to delete the user, you can invalidate temporary credentials that are based on that user by amending or adding IAM policy information for the user. One approach is to attach the following AWS policy to the user (or to the group that the user is a member of). This policy denies all access to temporary security credentials that were issued before the specified date and time.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Deny",
    "Action": "*",
    "Resource": "*",
    "Condition":
    {
      "DateLessThan":
        {"aws:TokenIssueTime": "2013-12-15T12:00:00Z"}
    }
  }]
}

To test this approach, before you make the policy change, request temporary credentials, making sure that you do so before the date and time that you intend to put into the policy. Then apply the policy. Make a request with those temporary session credentials and verify that the request is denied.

Another approach is to temporarily attach the following “deny all” policy to the IAM user and keep the policy in place for 36 hours (the maximum lifespan for temporary credentials). You can attach this as an additional policy to the user, and it denies all access to the user, regardless of what other permissions the user might be granted in other policies. After 36 hours, you can remove this “deny all” policy, and the user’s original permissions are restored.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Deny",
    "Action": "*",
    "Resource": "*"
  }]
}

To test this policy, apply the policy to the IAM user whose credentials you want to temporarily block. Then make a request using either temporary credentials obtained using that IAM user or using the user’s long-lived credentials. Verify that the request is denied.

Note that these guidelines focus primarily on temporary credentials obtained by calling GetFederationToken or GetSessionToken, which are invoked using root credentials or IAM user credentials. Temporary credentials that are obtained by using AssumeRole have a short lifespan (maximum of one hour) and therefore have a comparatively limited impact. If you want to invalidate temporary security credentials that are obtained by calling AssumeRole, add a “deny all” statement to the role’s access policy, as shown earlier.

Update 5 Aug 2014 If you’re creating a mobile application that makes calls to AWS, we recommend that you use Amazon Cognito and that you manage credentials in the application using the Cognito credentials provider. For an overview and examples of how to use the provider, check out Using the Amazon Cognito Credentials Provider on the AWS Mobile Development blog.

More Information

For additional details about working with access keys and tracking AWS usage, we recommend the following resources:

• Best Practices for Managing AWS Access Keys
• IAM Best Practices
• Managing IAM Policies
• AWS CloudTrail documentation
• Amazon S3 Server Access Logging
• AWS Security Audit Guidelines

In Summary

Always store your AWS credentials securely and rotate them periodically as a security best practice. In the unlikely event that you inadvertently expose your credentials, follow the steps we list in this post. Please don’t hesitate to contact AWS Support if you have any questions or concerns about the security of your account. Finally, if you have any comments on ways to improve this guide, feel free to add comments here or post them to the AWS IAM forum.