Welcome to another awakening post(I would say) as it is going to give you "What's next" mode of remediations for an 'AWS IAM User Incident Aftermath' restoration. IAM User or roles are the gateway to access any AWS Cloud service or resources via AWS CDK, SDK, Console, CLI or Powershell etc.
Well, we all know the basics which is to start with least privilege access for any user or role, which is about granting access to only those resources/services that needs to be given permissions to, as per the requirement. But is it really all that it takes to make the IAM user secure(rather the application & AWS Account safe) ? Let us see what happens if the user access keys are compromised along with quite some screenshots & steps that happens(Gear up folks!)
Google search, on AWS User keys compromised issue becomes a rabbit hole, were in it brings out all possible suggestions from the internet like rotate the keys, deactivate the keys, delete & create new keys, delete user, remove access, update policies and what not. But this post will bring in the actual happening of the incident , reporting, remediation, closure around AWS user keys exposure
- To demonstrate, I am using a demo AWS user account here. Creating a user here with some S3 Read only access(which most of the cloud people can relate with)
- Creating the access keys & download the same
- Look at the IAM User console view, where keys creation status is 'Active' but shows as 'Never used'. Just remember this status and move forward now...
- With the same AWS account user, I have opened a public repository in GitHub, to show on "Keys compromise" by committing them in GitHub
- In the public repo, I am creating a simple text file and adding in the Access & Secret keys of IAM User just created
- On commit, there is an alert that is being raised in Github giving us three options to either amend or proceed with. This is definitely a life saver. I will move ahead with 'False-positive' so that I can explain the "AWS User Access Keys exposed" issue
IAM User Keys are now compromised :-( What's next ?
- Within few minutes, AWS raises service request on behalf of your account, sends in alert emails along with 3 key ways to secure back your user & account. Here, is a snapshot of the same
- AWS now attaches a policy named 'AWSCompromisedKeyQuarantineV2' to the user for which the keys are now exposed, as below
- To see in detail, the policy is gatekeeper from the compromised keys to be used to access the resources inside the AWS Account. This policy, which is versioned from time-to-time, has key 'Deny' permissions and doesn't have any 'Allow'. This is affirmative that AWS has your back !!
- Now, observe the status of the 'Access Keys' which has been updated as 'Used Today' as it has been committed onto Github
AWS User Access Keys exposed instructions email -->
- AWS Instructions email, states three core things in the email
1) How to recover the user? Deactivate or delete the keys and generate new keys for the user
2) Trace the event activity with Cloud trail
3) Verify the resources that user had access to(example, ec2, volumes, s3 objects etc)
Lastly, AWS demands an action confirmation to the support ticket raised for the particular AWS Account, where the keys compromise has happened
- Now, deactivate the old key and generate a key for the user, so that compromised user keys are not used
So these are the sequence of the events that happens on IAM User Keys being compromised along with the remediation steps. Intention is that teams/people of different roles/background understand & stays aware of the vitality of staying secure on cloud
Cheers !!
Top comments (0)