Any company with a substantial AWS cloud presence will have a bunch of AWS access keys all over the place. Eventually, one of these keys will get leaked (e.g., when a developer accidentally commits their keys to GitHub) or stolen (e.g., from a compromised laptop).
There are several steps worth taking in advance, which will help reduce the blast radius when the inevitable happens. Even if you’re super lucky and your keys never get stolen, doing these things will greatly improve the security of your AWS infrastructure overall.
Remind users not to share their keys
Users should treat their keys like passwords. Do not share them. Do not post them on the wiki. Do not email them to your friends. It helps to remind people about these things once in awhile.
One key per user (per account)
The only time a user needs two AWS keys for their account is during a key rotation. Otherwise, one is plenty and easier to keep track of.
Reduce permissions whenever possible
Do all your users need read access to every S3 bucket? How about the one with your database backups? Probably not. Reduce permissions through IAM policies to the best of your ability.
Don’t store keys in source control
AWS keys (and all other credentials) do not belong in source code or configuration files. These end up in GitHub, and sometimes in public repositories. Instead, adopt a secure credential store like Vault or credstash. The sooner you do this, the easier it will be. Retrofitting an existing application can be tricky.
Use IAM roles in EC2
Rather than hand out a bunch of keys for service accounts, use IAM roles instead.
Require MFA for console authentication
This is an obvious step, but don’t skip it. All users must enable MFA for AWS console access. Even for “throw away” accounts, which have a habit of sticking around and becoming critical production services.
Require MFA for API authentication
This is perhaps the most important thing you can do to reduce the impact of stolen AWS keys. Requiring MFA for API usage does create more friction, but you at least should do this for any privileged accounts and sensitive operations.
Enable CloudTrail logging
Again, this is pretty obvious. You need logs for security monitoring and incident response. Enable those logs, in all regions!
Monitor logs and create alerts
Don’t just collect CloudTrail logs, use them wisely. Create automation to alert you when AWS keys are being misused. I wrote a blog post on this previously.
Design apps for key rotation
It shouldn’t be too painful to rotate keys. Design your apps with this in mind, because you know you’ll have to do it eventually. Making it easy upfront will pay dividends down the road.
Rotate keys on a regular basis
That way, if someone did post them on the wiki three months ago, at least they won’t work anymore!
Have an incident response plan
And don’t forget to test it, assuming you don’t have security incidents very often. An IR plan doesn’t have to be complex.
Did I miss something? Shoot me a comment or find me on Twitter.