Seriously, Enable MFA on Your AWS Root User

When discussing AWS security, we’re frequently asked, “how can I effectively manage MFA keys for my AWS root user in an enterprise environment?” So much so, in fact, that we decided to write this post detailing some of our best practices to securely manage the most powerful user in your AWS accounts - root.  

Security takes a different shape in the cloud. You’re no longer worried about managing badge access into the data center or hypervisor patch levels but about the strange implications of having your infrastructure accessible through API calls over the Internet. With so many new attack vectors, there’s much more to consider when securing your cloud. 

Fortunately, AWS’s shared responsibility model defines a framework for cloud security by clearly delineating what you should focus on and what you can rely on AWS to handle. There are nuances, but, generally speaking, AWS is responsible for the security of the cloud (that is, physical security of the buildings, networking hardware, and low-level infrastructure such as the hypervisor) while you’re on the hook for your security in the cloud.

Image Source: AWS

It’s your responsibility as the end-user to ensure your cloud infrastructure is well-architected and designed with security in mind. This broad responsibility requires a strong knowledge of all things AWS, running the gamut from tightly-scoped security groups in your VPC to restricting public access to your S3 buckets. 

Today, we’re focusing on a particularly meaty security topic that we frequently see go overlooked - properly securing your AWS account's root user via multi-factor authentication (MFA).

What is the Root User?

The root user is your superuser in AWS. Conceptually, it’s similar to the root user in Unix-like operating systems with similarly powerful (and dangerous) capabilities across your AWS account. According to AWS, the root user is “one identity that has complete access to all AWS services and resources in the account”. The root user has access to change nearly anything and everything, including billing information, user permissions, and security settings. Like Linux’s root user, it’s critical to use this elevated access with care.

“With great power comes great responsibility.” 

As with Linux’s root user, you should only access those elevated privileges when necessary.

Limiting Usage and Securing Root

You should never use the root user in your AWS account for day-to-day activities. Full stop.

If you currently are, follow these steps immediately to create an IAM user with appropriate permissions to use instead. AWS periodically adds additional access to the AdministratorAccess IAM policy, enabling more self-service (such as creating and deleting AWS accounts in an Organization) and further reducing the need to ever log in with the root user. The goal is to restrict the use of the root user only to the most critical account management activities.

Strangely, AWS still requires you to enable viewing access to billing data with the root user. Meaning, at least initially, only the root user can view billing data. Fortunately, it's possible to enable access to billing data for any IAM user with appropriate permissions. Once you follow these steps, you’ll be able to access valuable costing insights without needing to log in as root.

There are a few steps to take to secure the root account fully. First, we’ll assume you’ve followed the advice of this post and created IAM users to limit your use of root. From there, you’ll want to ensure you have a secure password for the root user and have deleted any API keys associated with the root user.

Most AWS accounts we encounter have made it this far, but many overlook the most critical step - securing the root user with MFA.

Managing MFA on Root in a Team Setting

MFA for the root user works the same as any other MFA you’re familiar with. There are many apps out in the wild such as Duo, Google Authenticator, Microsoft Authenticator, Authy, the list goes on. Any standard MFA tool will enable you to secure your root user with a secondary authentication method. However, this adds a complication - what happens if someone on your team needs to log in as root? How can you share this MFA token?  

That brings us to the central question of the post - what’s the best way to manage MFA on root in an enterprise environment? Let’s break it down.

Don't use your mobile device

You may begin your AWS journey with a small team (oftentimes just a "team of one"), and this won't seem like an issue in those early days.  If it's just you managing the account, it's relatively simple to grab your phone and look at your MFA code as you log in with root.  Even with one or two other people, perhaps it's quick enough for them to ask you for the code on Slack.  At some point, though, your phone may break.  Maybe you're unreachable at a critical moment.  You may simply upgrade your device and overlook resetting MFA.

iStockphoto

Using MFA on your personal device (or enterprise device) creates a dangerous single point of failure and should be avoided.

Multi-device tools seem like good ideas, but they aren't

Okay, so mobile devices are out. What are the other options? Finding an MFA solution that isn’t locked to a single point of failure is essential, like a multi-device solution such as Authy. These tools are a step in the right direction but have caveats worth considering. Let’s look at multi-device solutions.

Multi-device solutions like Authy are potent tools that solve the problem of device replacement by enabling you to manage MFA on multiple devices tied to the same account. However, this presents a few issues.  

First, you’re required to use the same account on all devices. This again requires sharing passwords and prevents the use of named users, which can obfuscate audit trails, meaning it won’t be straightforward to identify who is actually using your MFA token to log in.  

Also, Authy’s replication is inconsistent. We’ve seen cases where, at scale (many dozens or hundreds of MFA tokens), Authy doesn’t always look the same on all devices. Also, Authy lacks proper enterprise management tools to fit this use case at scale. (To be fair, Authy doesn’t advertise this use case.) The best solution that we’ve seen for using Authy is to deploy an EC2 running Windows Server, install Authy, and run Authy as a service account. It’s cumbersome, open to compromise, and still doesn’t totally solve the problem of sharing users.

Our favorite solutions

What does a real solution look like? We’ve identified the two main areas to address:

• Accountability - we need to be able to see who is using the key
• Data integrity - we need to be sure the MFA devices are resilient

Let’s look at two possible solutions - a hardware key and an enterprise password solution.

Hardware Keys

Hardware keys are a legitimate solution as long as your team is local. Using a tool like YubiKey from Yubico is a great way to secure accounts and avoid the device replacement issue. Simply storing the hardware key in a secure location that privileged users can access (a safe in a room requiring badge access, for example) enables user traceability while allowing users to share the MFA token. However, this requires the team to physically access the secure space. The pandemic has challenged the feasibility of this solution, with many unexpectedly becoming remote workers and suddenly losing access to a physical office.

So, this is a great solution as long as you can be sure you’ll have physical access to the key and the necessary security controls to manage access and monitor usage.

Password Management Tools

Password managers exploded in popularity over the past few years, and for good reason. With simple browser integrations, it’s easy to create secure passwords for various accounts and manage them with the click of a button without having to remember or even know your password for individual accounts. Many of these tools, such as 1Password and Last Pass, offer family or professional subscriptions which enable you to securely share logins with a group of people. This is where the magic happens and is our favorite solution.

Specifically looking at 1Password, it’s possible to enable a time-based one-time password (TOTP) on an individual secret.

Image Source: 1Password

This TOTP functionality can be used with any authentication that leverages secret key enrollment, including AWS root accounts. Moreover, 1Password’s business subscription integrates nicely with SSO tools such as Okta to manage access to individual Vaults in 1Password. Access can be controlled via group membership in Okta. We recommend storing your AWS logins in a secure Vault that only a small number of senior team members authorized for elevated access can use.

Thus, by combining Okta’s SSO with 1Password’s TOTP functionality, we can construct a solution that checks all of our boxes by providing a complete audit trail and a clean, secure method of sharing access to the token itself.  

Take Root MFA Seriously

AWS accelerates growth and innovation by democratizing access to complex computing power. What used to require massive budgets and lengthy purchasing cycles (not to mention access to physical facilities to deploy and host infrastructure) is now available to anybody at the press of a button.  

Naturally, this power comes with an important responsibility. As we’ve seen, AWS manages the security of the cloud, and it’s your responsibility to manage your security in the cloud. A critical component of that responsibility is ensuring you secure your AWS account’s root user, particularly by enabling MFA. Taking this simple step will dramatically increase your cloud security posture. 

As your team scales, consider the shape of that team. Will your team be remote? What level of access will you need to delegate? We recommend leveraging a password management tool with TOTP capabilities such as 1Password or LastPass to securely manage your AWS root account (including MFA) at scale. 

About Tennex

Tennex is a born-in-the-cloud AWS consulting partner that simplifies the cloud journey for growing and established biotechnology companies.  Leverage our comprehensive portfolio of infrastructure as code, automated workflows, proven delivery methodologies, and team of highly specialized AWS experts to simplify and accelerate your cloud journey.  With practical guidance, Tennex enables businesses to adopt cloud more thoughtfully and grow more intentionally.  To learn more, visit https://tennex.io - Cloud should be simpler, grow with us.