AWS Security Maturity Roadmap Summit Route
IAM User Access Keys never expire. They regularly wind up in source code that finds its way onto public
GitHub repos and when configured to be used by the AWS CLI, they exist as plain-text in
~/.aws/credent
ials
, which poses risks. For these reasons, you should avoid IAM Users entirely and instead use IAM Roles.
For human users, you should use SSO for access. This gives you a central location for creating and removing
users, or rolling their credentials if they are compromised. You can either have a single "Identity" AWS
account that users log into via SSO and then assume into roles from there to the different accounts, or you can
have them SSO directly into the different AWS accounts they have access to
34
. Solutions exist for different
providers for working from the command-line with SSO, including the AWS CLI v2.
If you do have requirements to use IAM access keys, for any human users, they should also be using aws-vault
35
.
If possible, for all access keys, you should create a single "Identity" account that they will then assume roles
from in order to access other accounts. This ensures you have only a single account with IAM access keys
and allows you to setup alerts if the access keys are used without assuming roles into other accounts.
You should audit your IAM Users and Roles to identify ones that have not been used for a certain amount of
time. For the remaining ones, use Access Advisor to reduce the privileges of the IAM roles to only those
services they use. Ideally, you should reduce this further to only the necessary Actions and Resources, but
that is a harder problem, we’ll aim for later. For now, the main thing you want to do is find roles with admin
(or near admin) privileges, especially when these are associated with EC2s.
Using Access Advisor data, there are some additional S3 privileges you can get information about. You can
identify who has used
s3:ListAllMyBuckets
and you should remove that from any applications that are not
using it. Very few applications should need that privilege.
You should implement a solution to detect secrets being committed to source-code repos to avoid having
IAM User access keys added to public, or even private, repos. One solution is Yelp’s detect-secrets
36
project.
As you deploy SSO, you should give thought to how accounts will be accessed and how they will be connected.
In addition to humans accessing your accounts, you also have applications that need access to resources
across different accounts. This includes resources such as IAM roles and S3 buckets that allow you to share
access with other accounts, and network resources that you’ll need to connect using VPC peering, transit
gateways, etc. You should give thought to the ways in which you want accounts to be connected, especially
as you accumulate more and more accounts. Separate accounts are a strong security boundary, but this can
become blurred and complicated as trust relationships are created between accounts. You should document a
plan for when and how new accounts will be created and connected.
Stage 6: Reduce attack surface and mitigate compromises
Apply SCPs.
Have no publicly facing EC2s or S3 buckets.
Enforce IMDSv2 on all EC2s.
SCPs (Service Control Policies) can be used to restrict actions an account can perform. See examples in my
post AWS SCP Best Practices
37
. You can make exceptions so only a special IAM role, such as that used for
Stack Set deployments, can bypass the restrictions. You can apply different SCPs to different accounts and
these can ensure that no one, not even the root user, can perform certain actions.
The SCPs to apply should include:
Deny root user access.
34
"Identity federation with multiple AWS accounts" by Alex Smolen - https://medium.com/@alsmola/identity-federation-
with-multiple-aws-accounts-61065d00e461
35
https://github.com/99designs/aws-vault
36
https://github.com/Yelp/detect-secrets
37
https://summitroute.com/blog/2020/03/25/aws_scp_best_practices/
Page 8 of 11 Copyright 2021, Summit Route. All rights reserved.