Your AWS keys will be leaked or stolen. Prepare yourself.

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.

Good luck!