4 mins to read
In my previous post, I talked about the framework of IAM security in AWS. As a follow-up, I want to focus on accounts and talk about some common mistakes – overlooked IAM security best practices. As a primer, you should read (actually, read it a few times) the AWS IAM Best Practices guide and the AWS Well-Architected Framework for Security.
Let’s start with the two biggest, and most obvious, mistakes:
Root account access
This may surprise you, but yes, we still see organizations with either an active root account and/or access keys associated with that root account. This should be stopped ASAP. Assign a very complex password (with rotation) to the root account and lock it away. NEVER USE IT. Also, delete any API keys associated with it. There is absolutely no logical reason to use this account or access your AWS Cloud environment with a root-level API.
Accounts without MFA activated
This is a general security best practice that is very easy to rectify. Please, activate MFA for all of your accounts.
If we dig a little deeper, let’s take a look at access keys. Access keys provide long-lived access to your AWS environment programmatically as opposed to logging in via the Console using a good old user/password combo. As a general best practice, temporary credentials should be used whenever and wherever possible, not long-lived access. This can be achieved by using IAM roles…but more on that later in this blog.
Access keys on a root account
Just don’t do it. If you have done it, disable them right now. As discussed above, the Root account really shouldn’t be used for anything, if you have an access key associated with it you are just asking for trouble. Furthermore, Access Keys are not designed for any Administrative functions, so if you have Access Keys for your Admin accounts, stop doing this as well.
Access key rotation
If you are like pretty much all AWS customers, you are probably using access keys somewhere in your environment. A common issue that occurs is losing track of where those keys are being used, by whom, and for what. Often times they are left around and never changed. The best practice here is to rotate your access keys regularly to reduce the risk of a compromised key. Even if someone has a “read-only” API key, it is still essential to rotate. This could prevent a bad actor from seeing behind the curtains of your organization as well as will make your auditors and security teams very happy.
Access keys not used in the last 90 days
What’s even better than rotating your keys? Removing them completely. As a general best practice, if an access key has not been used in 90 days, delete it. You can always create a new one so why risk having them sit around for someone to take advantage.
Insecure Storage of Access Keys
When using the AWS Command Line Interface (AWS CLI) a text file is created on your local system (i.e. your laptop) containing both your Access Key and Access Secret Key in plain text. With these two things an attacker could access your AWS Account as you.
To see if you have this file on your system go to the /.aws directory and you should see a file named “credentials”. View that file and you will see something like this:
[<PROFILE 1>]
aws_access_key_id = <Key in the clear>
aws_secret_access_key = <Secret in the clear>Now that we’ve identified some common mistakes, let’s look at solutions…
Use Service Control Policies
At the Account Level, Service Controls Policies (SCPs) are an effective way to establish and maintain access control baselines across your entire AWS organization. Another way to think about this is that SCPs set the guardrails for what actions your accounts can and can’t do. For example, a well-crafted SCP can tremendously help to control egregious IAM rights.
Example SCPs
The following are some example SCPs that you can use to mitigate some of the risks mentioned in the blog post.
Prevent Root User from taking actions in an Account
This SCP prevents the Root User in an AWS Account from taking any action, either via the AWS CLI or through the AWS Console.
{
"Version": "2012-10-17",
"Statement": [
{
"Action": "*",
"Resource": "*",
"Effect": "Deny",
"Condition": {
"StringLike": {
"aws:PrincipalArn": [
"arn:aws:iam::*:root"
]
}
}
}
]
}Prevent IAM Access Key Creation
This SCP restricts IAM principals from creating Access Keys in an AWS account with an exception for a specified Administrator IAM role.
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"iam:CreateAccessKey"
],
"Resource": [
"*"
],
"Effect": "Deny",
"Condition": {
"StringNotEquals": {
"aws:PrincipalARN": "arn:aws:iam::*:role/"
}
}
}
]
}Secure Token Service “*”
In previous blogs we’ve talked about the best practice of using AWS Secure Token Service (STS) to grant temporary permissions for a short period in time instead of using long-lived, and often forgotten Access Keys. When using the wildcard “*”, the time frame and the high-level access assigned is a huge issue. This is one that you and your organization should be fully aware of and never use. This permission can give an account unlimited access within a resource or for a resource in an account, which could lead to further issues such as elevating rights. Lack of visibility to this assigned permission is also common and problematic.
Secure Storage of Access Keys
Earlier in this post we talked about how when using the AWS CLI a text file is saved to your system with your Access Key ID and Secret Access in plain text. If you need to use Access Keys and the AWS CLI, the best practice here is to protect your account and its resources by using a multi-factor authentication (MFA) device. For more information on this, please visit AWS’s Knowledge Center.
As you can see, when working with AWS accounts, and their associated access keys, there are several things that you need to keep in mind. Clear visibility into those aspects of your IAM design, along with constant auditing, is key to not leaving an opportunity for a bad actor to walk in and start taking or manipulating information in your public cloud. The list that I outlined above may seem trivial to some, but it is a great starting point to keep your organization safer.
Read the latest news and insights
07.24.2020
CouchSurfing is an online service that lets users find...
01.28.2020
Review the pros and cons of AWS, Microsoft Azure and...
