AWS Root User Best Practices

Voiced by Amazon Polly

AWS (Amazon Web Services) root user best practices are similar to those for any AWS user with high-level permissions. However, as the root user is a particularly high-level user, it requires extra care and oversight to keep safe.

At Logicata, we frequently help our customers secure their AWS accounts as part of our InfrAssure managed AWS service. Over the years, we have developed a set of best practices for AWS root user management, and we share the details in this article.


 

AWS root account, root user, and administrator users: key differences

The account you first create when signing up for AWS has a single user: the root user, which has ownership and access to all the resources in your AWS environment. In this article, we use the terms root user and root account interchangeably. The root user account has access to everything you configure in AWS, so if it gets deleted or you lose access to it, you risk losing your entire AWS infrastructure, including virtual machines, customer data, backups, and billing history.

Administrator accounts, however, are regular AWS Identity and Access Management (IAM) user accounts that can be used to perform administrative tasks. They are safer to use, as there’s no risk of performing root-only actions, such as deleting your account. Administrator accounts are also usually created for a particular person, so if someone within your company performs an unintended action, you can track who did it.

There are only ten tasks in AWS that require root user credentials, so administrator accounts can be used for the vast majority of AWS configuration and maintenance.

Why is it important to follow best practices for your AWS root account?

Because of the level of control over an AWS environment that the root account offers, root user credentials can be a high-profile target for malicious actors. Additionally, it is worth investing the effort to protect yourself against classic human errors that can cause almost as much havoc as a deliberately malicious actor, like forgetting your password and getting permanently locked out of your account.

If you’re hoping to get certified as compliant with ISO 27001, SOC 2, or CIS, you will need to demonstrate good security practices, including for your AWS root account. Following the tips in this article will help you improve the security of your AWS account and make it easier for auditors and compliance officers to see how your company keeps track of technical changes.

The benefits of a multi-account strategy

While you can only have one root user for each AWS account, your organization doesn’t need to have everything on AWS running within a single AWS account. In fact, the opposite is true: having multiple AWS accounts within a single organization allows you to segregate different business functions, such as different team functions, billing, and security. A multi-account setup keeps users from interacting with AWS resources and settings that they should not have access to, limiting any unintentional or deliberate damage.

AWS Organizations allows you to tie multiple AWS accounts together and logically group accounts into different organizational units (OUs). Once created, you can convert your new, empty AWS account into an AWS Organizations account. This account becomes the management account for your organization and can be used for billing purposes and managing other accounts within your company. You can then create additional accounts within the AWS Organizations area or invite existing AWS accounts to become part of your organization.

In order to make an AWS Organizations account easier to manage, we recommend that our clients use AWS Control Tower. Control Tower is a highly useful way of managing your AWS Organizations if you have plans to scale the number of accounts beyond more than a handful. Control Tower creates an AWS Organization for you with existing accounts for management, log archival, and auditing. Control Tower allows you to group accounts into OUs; by default, the logging and auditing accounts fall under a security OU. You can then add extra OUs and accounts for different projects and teams. As you create more accounts, it can be useful to give each account an alias to make it easier for users to identify which account they’re logging in to. A multi-account structure that we recommend for most companies is shown below.

Multi-tiered AWS account structure that Logicata recommends for most businesses.
Multi-tiered AWS account structure that Logicata recommends for most businesses.

Monitoring your AWS root account usage

Setting up automated monitoring for AWS root account usage can help you get ahead of any unauthorized or unexpected sign-ins with root credentials. You can use services like Amazon GuardDuty or AWS CloudTrail to send automated email alerts any time the root account is accessed. This ensures that if someone with root credentials is trying to secretly access the root account, their activity won’t stay secret for long.

AWS Config is another service that can be helpful for tracking root account actions. AWS Config allows your organization to track changes in its AWS account so that it is always clear which account has made changes to resources. AWS Config also offers change management tools that you can use to evaluate your existing configuration against desired configurations.

Preventing unauthorised access to an AWS root account

When creating your first AWS account (which will be your root account), you must enforce multi-factor authentication (MFA) on the account. To keep your account even more secure, you can use a physical hardware MFA device such as a YubiKey instead of the standard authenticator phone apps.

Once your AWS account is set up, immediately create an administrator account, and use that instead of the root account for virtually everything going forward. Do not add a programmatic access key to the root account because this creates one extra way for a hacker to gain access, and as the root account will almost never be used for API access, there is no need for that account to have API permissions. If your root account has an API token associated with it, delete it.

To ensure that no one with root access uses the account when they don’t need to, you can set up AWS policies to restrict what the root account is allowed to do. If you decide to use AWS Control Tower, you should know that it has its own predefined policies called guardrails. The guardrail names are written in plain English, making them easier to use. You can also set up your own guardrails — for example, you could define an allow-list of IP addresses that may access the root account. (You can use this to specify that anyone using the root account must be on the corporate VPN.) It’s also possible to set up guardrails so that an administrator is alerted if there is a guardrail violation.

Avoiding unintended changes at the root level

You should only make your AWS root account credentials available to a small group of tech professionals. If the size of your company allows it, more than one person should have access because one person could become incapacitated, leave the company, or decide to sabotage the system. Three people is a good number, as the third person can cast a deciding vote in any decisions regarding the root user. You should regularly review who has and who should have access to the root account.

It is a good practice to follow the principle of least privilege. This means giving users the level of access they require to perform a task but no higher. You can also temporarily elevate someone’s permissions if they only need a higher level of access for a short amount of time. It can be tempting to cave in to demands for root access from demanding users (even your CEO or CTO!), but it is perfectly possible to give them sufficient access to any systems they need without giving up the root password.

Ensuring you can recover your root account if you lose access

Make sure you add account contacts with valid email addresses and phone numbers so that AWS support agents can get in touch with your team if you get locked out of your AWS root account. Regularly review your account details and keep them up to date.

Although it can be tempting, you should never completely block access to the root account, as you will need it if something ever goes wrong with the administrator accounts below it.

What to do when a root account user leaves your company

A good offboarding procedure is essential when a team member who had access to AWS root account credentials leaves the company. You’ll need to revoke their access to MFA tokens, change the root account password, and revoke access to any email addresses or phone numbers associated with the root account.

When initially setting up your AWS account, we recommend creating a separate email address on your corporate domain specifically for use as the AWS root account (for example, aws@example.com). This way, if an employee responsible for the account leaves, it is not tied to their personal email address, and access can be given immediately to another person on the team.

It’s vital to maintain control over not only the AWS root account’s email address but also your domain registration and associated email DNS records. You can do this by keeping your domain registration with a registrar other than AWS — this way, if anything happens to your AWS account, you still control the domain and just need to recreate all your AWS resources.

Conclusion

There are many suggestions in this article that you can consider for securing your AWS root account. Tools such as AWS Control Tower can provide a useful structure for following many of the best practices that will help you with compliance, particularly as your infrastructure scales.

Don’t have the resources, time, or expertise to implement these AWS root account best practices for your company?

At Logicata, we specialize in helping small- and medium-sized technology-enabled businesses configure and manage AWS deployments. Contact us today for a free discovery call.

You Might Be Also Interested In These...

Approved certificate medal icon in flat style. Check mark stamp vector illustration on white isolated background. Accepted, award seal business concept.

AWS Reliability – A Core Pillar of Your Architecture

In this post I’m going to give an overview of the AWS Well Architected Framework, then give a deep dive on the Reliability pillar, which is one of the 5 core pillars that should underpin your AWS architecture.   AWS Well Architected Framework The AWS Well Architected Framework is a series of best practise principles, […]

View Post
AWS reInvent

28 AWS Launches Announced by Andy Jassy at re:Invent 2020

Today, AWS CEO Andy Jassy launched the first online AWS re:Invent conference via live stream from Seattle.  With a lively 30 minute set from Zach Person, the online event kicked off on as much of a high as the Vegas conferences.  Awesome production quality as we’ve come to expect from AWS events.   Before getting to […]

View Post
Abstract Amazon DynamoDB

AWS DynamoDB Pricing: 13 Tips to Reduce Costs

In this post, Karl Robinson introduces the technical elements of Amazon DynamoDB, and how to calculate DynamoDB Pricing. He also shares 13 invaluable tips on configuration to keep your Amazon DynamoDB Costs under control.   What is Amazon DynamoDB? Amazon DynamoDB is the AWS fully managed NoSQL database service, enabling AWS customers to build NoSQL […]

View Post
ebook featured image

5 Steps to a Successful

AWS Migration

DOWNLOAD FREE EBOOK