Theres plenty of guides out there that give you 10 steps to securing your AWS account, but securing your account isn’t something that can be done with a 10 step list alone – you need to have a clear plan for your changes. AWS’s own guidance consists of references to some good documentation, but that’s only getting you part of the way there. As a result, the aim of this post (and subsequent posts) is to provide you with clearer guidance to reduce the risk and impact of someone gaining access to your AWS environment. Simply put, we’re trying to enable your AWS accounts to be more secure.
With that said, please do not confuse “more secure” with being “completely secure”. There’s no guarantees with security as no one can predict the future, so you’ll never receive complete assurance that you’re safe from a determined person or group that’s targeting you. The point of implementing AWS account security is to increase the complexity (and time taken) to gain unauthorised access, so that you have time to detect and react to an event. Additionally, we want to try to mitigate damage (if they are in any way successful) and gather any intelligence we can, so we know what to look for in future. What you don’t want to happen, is to be hacked and have someone delete all your data because there was no risk mitigation in place.
There’s a few tasks to securing your AWS account, as listed below:
- Root Account Management (this page)
- IAM Policies and Users
- Establishing an account hierarchy
- Setting up CloudTrail and Billing Alerts
- Sumo Logic (optional)
It may not seem like it, but there’s a lot here. I’m going to break this up into multiple posts for ease of reading. Also because I don’t want to drown you in words.
AWS Root Account Management
There’s several aspects to IAM and User Account security that you need to carry out. In order, the tasks you need to complete are:
- Change your root password to something complex
- Setup MFA on your root AWS account
- Set an IAM password policy
Just quickly, the difference between IAM and root account is that there’s always a root login on every AWS account. IAM accounts, by comparison, are effectively virtual logins in the AWS account. Read this AWS document around AWS security credentials if you want more information, though it doesn’t actually have much more than what I’ve written.
Change your root password to something complex
Typically, with the root password, what I’ve done for it is to set up a ridiculously long password that I hope to use rarely. You shouldn’t need to use this account in a case of emergency, instead it should be for all the administrative or billing things you want to carry out that you aren’t able to do with IAM accounts.
In every single deployment, I’ve set a 50+ character password on the root account where I can. This password is restricted from general access, so that I can greatly reduce the motivation of someone using it to login and do their work. It’s sole purpose is, in my eyes, the account of last resort. It’s worth pointing out, if you need to use your root account for emergency purposes you’re doing something wrong.
Changing the root password is relatively simple, as AWS themselves have articulated here.
In terms of storing it, I actually keep the root password for various AWS accounts (not mine) in something like 1Password or KeePass, but stored in its own database and access restricted to a limited number of people. There’s also a printed copy that’s kept in a safe place as a backup. The less temptation to use this account, the better.
Setup MFA on your root AWS account
MFA, or multi-factor authentication, is basically two factor authentication with a different name. God only knows why AWS called it that, given that Azure’s MFA product provides so many options that it is truly “multi” (though, it strangely doesn’t have a hardware option). Anyway, MFA/2FA is basically something you know (your password) and something you have (physical token or a virtual token). You can buy tokens from AWS, they’re manufactured by Gemalto so they’re reasonably good. For root accounts, I recommend that you buy the Hardware Key Fob as opposed to the Hardware Display Card, as it’s quite solid and less likely to be lost – but it’s a personal choice really.
Setting up an MFA token is actually pretty simple, you can pretty much go to the IAM console and it’ll be staring at you on the first page. I won’t go into too much detail, as you can read about it here where AWS themselves talk about how to complete the task under the “Enabling a Hardware MFA Device for Your AWS Account” section.
The value of the root account having MFA is that it becomes immeasurably harder to gain access to it. It also becomes harder to use it on a casual basis, as there is now significant disincentive to do so. Remember, the AWS root account is the most privileged user in your AWS account – it should be used sparingly.
Set an IAM password policy
If you’re familiar with Active Directory, then AWS’s password policy is akin to the password policy specified in the Default Domain group policy object. If you’re not, then a password policy defines what is an acceptable password within your AWS account and how it’s maintained, based on configurable criteria such as:
- How many characters are used
- Does it feature upper or lowercase characters
- Does it have a number or non-alphanumeric character
- Can users change their own password
- How often passwords expire
- Can users reuse old passwords
In terms of what you should set, you need to find the right balance between a complex password and not frustrating the people using the system. The account holders need to be able to login, but the passwords shouldn’t be unnecessarily simple. Broadly, I tend to configure the password to:
- have a minimum of 10 characters
- be complex (have upper/lower case, numbers and non-alphanumeric)
- expire every 60 days
- prevent password reuse for at least 10 attempts
I find that this strikes a reasonable balance between complexity and usability. Remember your audience though, these aren’t supposed to be end users logging into the AWS console. Instead, it will likely be your IT professionals who should know better.
One last point, this password policy only applies to IAM accounts. The root account is not affected by this policy.
In this article, the aim was to enable basic security on the root account and prepare for IAM user accounts. Implementing the steps listed above will get you there, however as a last bit of advice I would suggest you change the root password semi-regularly. This will mitigate inadvertent password storage, where staff may store the password in their browser or the like. It will also reduce the reliance on MFA as your only line of defence in the event of the root account password being compromised.
Over the next few articles, I’ll be looking to show you what other steps you can take to improve security for your AWS account. This will also feature some guidance I’ve received from AWS’ own Solutions Architects around how you should structure your environment.