How to Secure AWS Account Root User - Best Practices

Posted by Ben Potter on Saturday, November 28, 2020

Contents

I’ve written this post to share the latest and real best practices for securing your AWS account root user. As the security pillar lead of AWS Well-Architected I get annoyed when people release the wrong information and their own “best practices” for AWS. This is especially true for the account root user, I’ve seen articles recently that say having access keys for root user is ok if you rotate them - WRONG!

What is the AWS account root user?

In AWS, the root user is the first and only identity that exists when you create an AWS account. You login by using the email address you signed up for that account with and the password you set. The root user has a password to access the console, and optionally access keys (access key IDs and secret access keys) for accessing the API’s. If you have configured the AWS Organizations service, it manages the root user for accounts you create using it.

Why secure the root user?

The AWS account root user has full access to everything in your account, and it can even close the account. Unlike AWS Identity & Access Management Users & Groups the root user cannot have a policy attached to restrict the level of access. Anyone with access to your root user email address and password has full access to all resources and data in your account in every region. If someone with malicious intent had your root user credentials, like a disgruntled employee or contractor, they could easily do a lot of harm. In many cases AWS is unable to recover your data, as its your responsibility as part of the shared responsibility model to protect your account, infrastructure, and data appropriately.

Best practice #1: Remove access keys

You should never have access keys for your root user, you should delete or deactivate them immediately. The reason for this is access keys cannot have an MFA device linked to them, so if you were to accidentally leave them somewhere public, like a GitHub repository, then anyone with them can immediately use them. Remember, they have full access to your account!

If you really must have an access key for a valid reason, like using a tool to upload your data to S3 and that is the only option available, then there is something that you can do instead. If you don’t have time to explore Well-Architected best practices like using temporary credentials from AWS Security Token Service (AWS STS) then you could temporarily create an IAM user with access keys instead and a policy to restrict the allowed actions. If you have an EC2 instance or Lambda function that needs to access the AWS API’s, you can simply use a role to get temporary credentials.

Best practice #2: Enable multi-factor authentication (MFA)

A MFA virtual or hardware device can be added to your root user to provide an additional layer of authentication. Adding MFA requires you to enter or activate it every time, and also requires your email address and password still. If you loose your password and someone tries to access your account, they will also need your virtual or hardware MFA device.

There are some caveats to enabling MFA; If you use a virtual device, like Google Authenticator, there is a secret code that is generated (and associated QR code) that can be copied or shared. This is great if you need access from more than one location, like multiple teams around the world. It’s also a challenge in that it can easily be copied or photographed, and by sharing you can easily loose control of who has had access to the code. Do you really need to login as the root user from more than one location, or want to risk the virtual code being copied? A hardware MFA device can be easily controlled as its physical, even stored in a safe. The main two types of devices are Gemalto tokens with a 6 digit rolling code, and U2F security keys which include YubiKey. The U2F keys have the advantage of being used for many AWS accounts, while the Gemalto ones can only be used for a single account.

There is an argument against having an MFA device at all. At the login prompt you can simply select forgot password to start the recovery process. The recovery requires access to the registered email address, and the phone number. If a phone number is not associated then you’ll need to contact AWS Support. Then the security of the email address and phone number are in question - who has access to them, and can they be trusted, or is it an email alias and call center? The best practice for this process is not defined, as it depends on your organization, and you may have processes already for managing access.

Best practice #3: Stop using the root user

There are only a few tasks that require you to use the root user:

  • Change your account settings. This includes the account name, email address, root user password, and root user access keys. Other account settings, such as contact information, payment currency preference, and Regions, do not require root user credentials.
  • View certain tax invoices. An IAM user with the aws-portal:ViewBilling permission can view and download VAT invoices from AWS Europe, but not AWS Inc or Amazon Internet Services Pvt. Ltd (AISPL).
  • Close your AWS account.
  • Restore IAM user permissions. If the only IAM administrator accidentally revokes their own permissions, you can sign in as the root user to edit policies and restore those permissions.
  • Change your AWS Support plan or Cancel your AWS Support plan. For more information, see IAM for AWS Support
  • Register as a seller in the Reserved Instance Marketplace.
  • Configure an Amazon S3 bucket to enable MFA (multi-factor authentication) Delete.
  • Edit or delete an Amazon S3 bucket policy that includes an invalid VPC ID or VPC endpoint ID, or explicitly denies access.
  • Sign up for GovCloud.

This list is up to date at time of writing but you can find it here. My personal opinion is that MFA delete should not be used as the risk of using root vs simply applying an explicit deny bucket policy (that’s a policy that denies both the deletion of objects, and also denies bucket policy actions). Also S3 object lock can be used to store objects using a write-once-read-many (WORM) model.

Best practice #4: Centralize identity management

As you definitely should not be using your AWS account root user, the recommended best practice from Well-Architected is to Rely on a centralized identity provider for workforce identities, e.g. people like you and I. This best practice is somewhat in conflict with the IAM documentation which recommends you create individual IAM users. Creating and using IAM users is much better than using root, however there is a better way!

AWS Single Sign-On (SSO) allows you to configure users, including yourself, in the service. The users can have permissions following least-privilege, and the best feature I believe is they can be used across all your AWS accounts in your AWS Organization. SSO provides you access to the AWS console, and can even generate you temporary credentials including an access key. AWS SSO also helps you manage access and permissions to commonly used third-party software as a service (SaaS) applications, AWS SSO-integrated applications as well as custom applications that support Security Assertion Markup Language (SAML) 2.0. The best part of SSO is there is no cost! I use SSO even for a couple of my personal testing accounts so I’d encourage you to do the same. If you already have a central identity/directory service, it most likely supports SAML 2.0 or Open ID Connect (OIDC). If SSO is not for you, then you can enable federation with IAM.

Best practice #5: Configure AWS account alternate contacts

Alternate contacts enable AWS to contact another person about issues with the account, even if you are unavailable.

  1. Use your AWS account email address and password to sign in as the AWS account root user and open the AWS account settings page at https://console.aws.amazon.com/billing/home?#/account/.
  2. Navigate to alternate contacts configuration section.
  3. Enter contact details for billing, operations and security.
  4. Click Update

Best practice #6: Get notified when root user is used

Getting notified automatically when your root user is used helps you understand who is using it, and detect unauthorized access. There is an easy to implement AWS CloudFormation template that can setup notification to an email address (which could be an alias for the team responsible). While emails can get lost, and you should instead use a real time chat application or ticketing system, this is a good starting point.