Blog
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.
FAQ
- How can organizations monitor suspicious activities or unauthorized access attempts on their AWS root accounts?
Organizations can enhance their AWS root account security by utilizing AWS CloudTrail, which provides a history of AWS API calls for an account, including actions taken through the AWS Management Console, AWS SDKs, command line tools, and other AWS services. This log can be monitored for unusual activity patterns or unauthorized access attempts. Additionally, Amazon GuardDuty offers intelligent threat detection by continuously monitoring for malicious activity and unauthorized behavior to protect AWS accounts and workloads.
- What specific steps can be taken to recover a compromised AWS root account beyond the mentioned sworn affidavit process?
- To recover a compromised AWS root account, the initial steps involve contacting AWS Support immediately and providing detailed information about the security breach. AWS provides guidance through their support team to regain control of the account. This process may involve verifying the account holder's identity, securing the root account credentials, and reviewing account activities for unauthorized changes. AWS also recommends conducting a thorough security audit post-recovery to ensure all vulnerabilities are addressed.
- Are there any AWS services or third-party tools recommended for automating the security best practices mentioned in the article, such as monitoring root account usage or enforcing MFA?
AWS offers several services that can automate security best practices for the root account. AWS Identity and Access Management (IAM) allows organizations to securely control access to AWS services and resources. Using IAM, one can create and manage AWS users and groups and use permissions to allow and deny their access to AWS resources. AWS Security Hub offers a comprehensive view of high-priority security alerts and compliance status across AWS accounts, making automating checks against best practices easier.
Supporting Documentation:
https://docs.aws.amazon.com/organizations/latest/userguide/best-practices_member-acct.html
Go Back
Share this post