AWS Security Automation - Access Key Rotation Compliance Management using AWS Lambda

Hi folks!!!

In the previous post, we discussed about control and enforcement over Public Ingress Rules in EC2 Security Groups. Feel free to have a look at it here.

Now, we will be proceeding with maintenance of IAM User Access Key hygiene. But first lets understand about the same.

AWS Access Keys are the credentials used by IAM User or the AWS account root user. They are used to sign programmatic requests to the AWS CLI or AWS API (directly or using the AWS SDK). Access Keys consist of two parts: an access key ID and a secret access key. Like a username and password, we have to provide both together to authenticate the requests. A security recommendation suggests that we should only use IAM roles instead of access keys but still in some cases we need to have the access keys handy. These access keys will provide a user complete access to a set of resources defined by the IAM User Policy. So, if the access keys are lost or went into wrong hands, your resources are at risk.

There are a set of IAM Best Practices defined by AWS to help secure your AWS resources. Related to Access Keys, this include,

1. Do Not Share Access Keys

We clearly understood the fact that Access Keys must not be shared in public and should be kept at secure place.

2. Rotate Credentials Regularly

Rotate your credentials either password/access keys regularly s.t. if a password or access key is compromised without your knowledge, you can limit how long the credentials can be used to access your resources.

3. Remove Unnecessary Credentials, etc.

It is important to remove the unused passwords and access keys not in current utilization of business requirements. For this, you can look for the users who have not used their passwords/credentials since a pre-decided particular time.

If you have plenty of users in your AWS account, it will be a tedious task to keep an eye on every user to meet the access key compliance. And manual management, can result in severe consequences.

Compliance:

According to CIS Amazon Web Services Foundations v1.2.0 - 05-23-2018, the compliance benchmark says,

Ensure credentials unused for 90 days or greater are disabled.

Ensure access keys are rotated every 90 days or less.

Strategy:

To meet the following compliance requirements, here we will be implementing an intelligent Lambda function which will take care of the following things,

-  Sanitation: If Access Key is not used since last 45 days being "Active", disable the Access Key and publish the message to Security/SecOps Team.

-  Rotation: If Access Key creation has passed 85 days, generate a new Access Key for the user and publish the message to Security/SecOps Team. Further SecOps/Security Team will inform the user to update all its apps with New Access Key. Delete the older Access Key automatically after 90 days.

-  Audit: Check the compliance everyday and generate a compliance list for all users with relevant information, scope of action required and action recommendation.

Setup:

1. Go to AWS Lambda Console using "Services" drop-down and search for "Lambda". Inside Lambda Console, Go to "Functions" and hit "Create Function". Fill the basic information required for the AWS Lambda function and move forward.

2. Post successful Lambda creation, Click on Amazon CloudWatch Logs and go down to hit "Manage These Permissions".

3. Now we will be attaching an inline policy for IAM Access Key Management permissions. Use "Edit JSON" to write the policy and review it giving a name to hit "Create Policy" button.

4. I have one more inline policy made for SNS publish. Going to attach the same now.

5. To add a trigger, go to our Lambda function, hit "Add Trigger" and fill the details as given below. Please note that we will be setting up a "Schedule expression" which will trigger the Lambda check every day at 10 am UTC. And do not check upon the "Enable trigger" for now.  

"Lambda Core Logic"

There are three parts in this Lambda function:

1. lambda_handler - It is the controller of the function which passes the usernames to check for access key compliance.

2. sns_publish - To send the notification to Security/SecOps team about the compliance status.

3. access_key_remediator - accepts the usernames and check compliance benchmark for every key attached to a username.

Compliance Check:

To check for the compliance, here I have created a set of users in this AWS account. 

When we ran the Lambda, we got a result in return as well as some log information. If we can see the log information along with the result, we can conclude,

- There are 5 users.

- User "4hathacker" has two access keys and both are disabled.

- User "LegitUser3" has one access key and it is disabled.

- User "LegitUser4" have one access key and it isn't used in any of the API call yet.

- User "LegitUser4" has  one access key which is disabled.

If you are wondering about "LegitUser1" and "LegitUser2", then I would like to tell you that, I do not have created any access key for them. Hence, they didn't appear in the logs as well as the compliance report result.

Advantages:

1. Automatic and timely Creation and Deletion of Keys.

2. Notification of Disabled Keys to SecOps/Security Team.

3. Daily Audit for compliance.

4. No manual overhead and zero maintenance.

Scope Of Improvement:

1. SecOps/Security Team needs to convey to the user about Creation of New Access Keys with complete details.

2. Can subscribe to more SNS topics with an arrangement to reach end user with appropriate notification.

This is how we have automated one more compliance check. Stay Tuned, for more posts like this...!!!

PS: I have cleared all the users and keys shared here... ;)