AWS Root Account Security Best Practices
I work as a Senior Cloud Analyst on Mission’s Cloud Optimization team. I frequently talk with customers about ensuring the integrity of the root user of their AWS accounts and unfortunately, the basics aren’t always known or understood. There are 3 things that we focus on: the root user email address, multi-factor authentication and API access.
Let’s start at the top. I can’t stress enough how important it is to ensure that the root user email address is in a company owned domain name. AWS recognizes the owner of an account by the root user email address. In other words, when one of your developers first signed up for that original AWS account and used their personal GMail account, that email address has unrestricted access to the account. The good news is that it can be changed. That said, it needs to be changed before it’s too late. If the user who owns that email address leaves your company for some reason, they can do whatever they want to that account and you’ll have virtually no recourse for it. Recovering the root email account after the fact can be done, but it requires a sworn affidavit and can take 6 weeks or longer to complete. This process is done directly with AWS and even as a Premier Partner, Mission can’t help to speed this up. I can assure you that when you need this, you certainly don’t want to wait that long to get access to it.
Mission strongly encourages you to to create a unique distribution group to be used for the root account email address of each account. As AWS issues service disruption notifications, retirement notices and other critical messaging, they typically only go to the root email address. If that address belongs to an individual user, only one person is going to get that notification. By using a distribution group, you eliminate that single point of failure and make sure that those notifications are distributed to a team.
Second on the list is to make sure that multi-factor authentication (MFA) is enabled on the root account. This is one of those things that has become commonplace in the world of technology, but adoption is much slower than it should be. Multi-factor authentication is a lot easier than people think, especially given the tools available to maintain those MFA tokens. The most commonly used MFA device/tool that we see is Google Authenticator but that certainly has some limitations. First of all, it’s going to restrict you to a single device being able to be used, which can be problematic in the event your mobile phone that holds that token is lost, stolen, or broken The alternative here is to use a password management application that can also hold your MFA tokens for you. This would allow you to share them with a select group of people in your organization and protect you in the event that someone leaves the company.
Finally, we get to the API keys on the root user account. As the root user has unrestricted access to your account, it’s possible to terminate anything inside the account, up to and including the account itself. If the API keys for the root user were to get into the wrong hands, the resources in your account can be programmatically deleted in a very short period of time. If you currently have API keys in use on the root user, I can’t urge you enough to determine who is using them and move that functionality over to an IAM user or IAM role with permissions restricted to only allow the tasks needed to be completed.
In summary, we strongly recommend that you do the following:
- Make sure that you have the root email address for each AWS account in a company-owned email domain, preferably using a distribution group.
- Setup multi-factor authentication on the root user account for each AWS account. Use a password manager whenever available.
- Remove any API keys from the root user and ensure that services are using IAM users or roles with minimal permissions.
And if you’re feeling extra adventurous, don’t forget to set the account security questions inside your AWS account so that you can have an easier time recovering the account in the event that something goes wrong! Make sure that you’re not using the root user on a daily basis, but rather an IAM user account with the appropriate permission set applied.