AWS Root vs IAM User: What to Know & When to Use Them | BeyondTrust

In Amazon Web Services (AWS), there are two different privileged accounts. One is defined as Root User (Account owner) and the other is defined as an IAM (Identity Access Management) User. In this blog, I will break down the differences of an AWS Root User versus an IAM account, when to use one account versus the other, and best practices for protection of these identities in the cloud.

What is an AWS Root User?

The AWS Root User is the first cloud service identity created by default when you create your cloud service provider account. It is important to note—all cloud service providers have some form of root account. Depending on the provider, you may be allowed to have more than one such account. The more root accounts you have, the larger the risk surface. Because of its omnipotence, the AWS root account is a prime target for threat actors because it can control everything in your instance and in your account profile.

While you can log into AWS as a root user by using the email address and password you used to create the account, as a security best practice, you should not. This security principle holds especially true in a production environment. As a security best practice, the default root account should be disabled, or even deleted, and never used unless absolutely necessary.

Consider this:

• A root user (identity) has full access to all the resources and assets in the account and associated instances. This explains the risk they represent if compromised
• The only way to restrict permission to a root user is by having a Service Control Policy applied to your account, but even this control has its limitations

With the above considerations in mind, avoid using your root user to perform everyday tasks (even administrative ones). To mitigate the risks of the default root account, organizations should create an IAM user with administrative-like privileges to manage their AWS environment in adherence to the principle of least privilege.

What is an AWS IAM User?

An AWS IAM User can be created by a root user or another IAM user who has entitlements to create additional IAM users.

Here are some potential attributes and capabilities of AWS IAM users:

• Can authenticate or start a remote session using their IAM User credentials and their Account ID or alias (if required), if entitlement is granted
• Can correspond to a human, application, process, or another machine-based identity
• Depending on the use case, individual IAM users can be assigned to entitlements or role-based-access groups

AWS Root User versus IAM User

An AWS IAM user granted administrative privileges can do almost everything a root user can do, except for a few tasks that are restricted to the root account. If you delete the root account, which some security professionals may advocate, these changes will be permanently inaccessible. The following list highlights some of the more critically important privileges only available to root:

• Closing your cloud service provider account. This is particularly important if you plan to change providers, or the account is ephemeral for testing or development
• Changing many of your cloud service provider account settings, like the root email address (the root account should never be a person’s email address, but rather always a generic alias email account managed by the business)
• Changing your support plan and billing information (using a credit card or other method that will change due to an expiration date can cause issues if the root account is deleted)
• Enabling or disabling specific security controls, like MFA, to manage key runtime parameters, like deletion. (these settings should be implemented upfront and never be changed)

AWS Root User Best Practices

Regardless of the account type, the cloud represents unique challenges for all identities. Consider these AWS Root User best practices when managing cloud identities:

• Do not use your root user access key for anything except for those rare use cases where it is absolutely unavoidable. If the cloud provider allows for it, consider disabling root, or even deleting the root account, if you can overcome the potential issues listed above
• Enable MFA for all your root users, as well as for all IAM users. Single-factor authentication should never be used for cloud access
• Never share your root user or IAM user’s credentials with anyone for anything, at any time
• Create separate IAM users for anyone who needs access to an account. Accounts should never be shared—even for machine identities
• Implement least privilege access for your IAM users – always! Consider this identity “fully closed”, since most cloud service providers do not grant any privileges upon account creation.
• Have a robust password policy in place for all users and consider a privileged access management (PAM) solution to safeguard them and to perform management.

Broadly using highly privileged, superuser accounts like root or administrator, even with MFA enabled, can introduce unnecessary risk. Limiting privileged access exposure is critical to mitigating risks for all identities in the cloud.

Secure Cloud Identities with BeyondTrust

Identities in the cloud are different than identities on premise. On premise, we generally think of identities in the form of accounts. In the cloud, and for a mature cybersecurity practices, organizations should think of identities first. This allows the concept of identities to be applied to abstract cloud concepts like entitlements and principals, in addition to traditional security controls like privileges, permissions, and rights.

If you consider the identity first, all the controls needed for your security policies and management can be defined for an identity to ensure complete coverage. This not only includes the controls listed above, but also the workflow for a successful identity governance solution including the joiner, mover, leaver concepts.

BeyondTrust considers identities first in managing risks and policy in the cloud. With comprehensive cloud-based identity discovery and automation, BeyondTrust can help identify risks in the cloud based on identities and integrate with leading IGA solutions, such as by using SCIM, to complete identity management workflows in the cloud. This includes the management and discovery not only of root accounts, but also for any user or machine identity instantiated in the cloud. BeyondTrust also enables the enforcement of least privilege and zero trust security principles across your cloud, on-premise, and hybrid environment.

Cloud Security Begins with Protecting Identities

While the concepts around root and IAM identities and accounts in this paper were focused on AWS environments, similar concepts apply within both Microsoft Azure and Google Cloud. The primary concept to remember is to create and authenticate all identities according to the principle of least privilege.

All users and machine identities should have their own unique identities, when possible. Furthermore, these users and identities should be assigned the least amount of privilege needed to perform their mission. BeyondTrust can help you achieve this mission across cloud and hybrid environments with an integrated platform of Privileged Access Management and Cloud Infrastructure Entitlements Management (CIEM) solutions.

Morey J. Haber, Chief Security Officer, BeyondTrust

Morey J. Haber is the Chief Security Officer at BeyondTrust. He has more than 25 years of IT industry experience and has authored three books: Privileged Attack Vectors, Asset Attack Vectors, and Identity Attack Vectors. He is a founding member of the industry group Transparency in Cyber, and in 2020 was elected to the Identity Defined Security Alliance (IDSA) Executive Advisory Board. Morey currently oversees BeyondTrust security and governance for corporate and cloud based solutions and regularly consults for global periodicals and media. He originally joined BeyondTrust in 2012 as a part of the eEye Digital Security acquisition where he served as a Product Owner and Solutions Engineer since 2004. Prior to eEye, he was Beta Development Manager for Computer Associates, Inc. He began his career as Reliability and Maintainability Engineer for a government contractor building flight and training simulators. He earned a Bachelor of Science degree in Electrical Engineering from the State University of New York at Stony Brook.