3 Minutes to AWS Access Key Security
Take a simple approach to assigning identities in the AWS Cloud and reduce the risk of a key being published!
It happened again and it’s going to keep happening; another team made a simple mistake and their AWS Access Keys were exposed.
Operational security — the act of actually practicing security — is hard. It relies on humans and humans aren’t that reliable. That’s why AWS themselves prefer systems over humans when it comes to security.
But — and I say this as a human 🤖😉 — humans still have an essential role to play so here are a few tricks to minimize the risk of AWS Access Keys in your environment.
Don’t Use Keys
The easiest way to secure a secret like a set of access keys (the AWS Access Key and AWS Secret Key) is not to create them in the first place. If it doesn’t exist, it’s impossible to lose!
There are some use cases where access keys are required, but they are becoming less and less prominent. The most common scenario is when a third party tool outside of AWS needs access to something inside of AWS.
Even in this scenario, you can avoid permanent or long-term keys by using the AWS Security Token Service.
IAM Roles FTW
The AWS IAM (Identity and Access Management) service offers a simple primitive called a “role” that addresses 90+% of all scenarios where you might need keys.
A role is an identity that can be assumed by other objects, like a user, a resource, or an external identity.
Does your application need to access a database in Amazon Aurora?
Create a role with the appropriate permissions, then any EC2 instance, ECS container, or Lambda function can have that role assigned to get the necessary permissions.
Better yet, combine roles with access policies for way more flexibility.
Least Privilege
It’s tempting to assign “full access” to any user, role, or policy that requires access. Don’t.
A core tenant of security is, “the principle of least privilege”.
It’s a fancy way of saying that you should only give the absolute minimum permissions required to get the job done and no more.
If your Lambda function only needs to read/write a single file in an S3 bucket, that’s all the access permissions it gets.
If your Amazon Lumberyard project needs to write to an Amazon Kinesis stream, then it only gets write permissions to that particular stream.
In other environments, this was very difficult to do. IAM is integrated into the fabric of everything in the AWS Cloud. “Least privilege” is finally not only possible but realistic.
Review
Mistakes happen. The idea is to make sure that you try to not to make mistakes but if you do make one, it has the smallest impact possible.
Here are your next steps:
- Review all valid access keys and their use cases
- Disable as many keys as you can
- 15 days later, remove those keys no one has screamed about 😉
- Review all policies and assigned permissions (start with *FullAccess)
- Compare against actual usage in CloudTrail
- Remove and reduce as many permissions as possible
- Educate your teams to ensure they are aware of the issue
- Review regularly
Questions? Comments? Let me know below or on Twitter where I’m @marknca or connect with me on LinkedIn.
