Founder Security Fundamentals – Improved Security with Identity and Access Management

Authored By: Dave Barton, Principal Solutions Architect

At Amazon Web Services, we work with thousands of new startups every year, and we know how hard founders work to balance the demands on scarce time and resources. Often, a startup’s first goal is to build a minimum viable product, or MVP. This is a key milestone in their journey, where they can put their product into the hands of real users and start incorporating their feedback. Real users offer diverse experiences, reveal new use cases, and expose hidden bugs. And they also bring something very important: real user data. Users are trusting you with their information — which could be personal, financial, or medical in nature — and they expect you to treat it with care and respect.

When we speak to startups, we often talk about the concept of an MVSP, or minimum viable secure product. This doesn’t mean that a product must have every potential security risk mitigated at launch, just as it doesn’t need every feature implemented. By following AWS best practices, however, you can ensure that you’re building in a secure way and protecting your users and your business. While security is often seen as a blocker, putting the right guardrails in place can actually accelerate your development by allowing developers to deploy new features with confidence — reducing the amount of time they need to spend thinking about security and increasing the time they can dedicate to building features your customers will love.

Speaking of security guardrails, one of the first pieces of advice AWS gives to startups is, “Lock away your AWS account root user access keys.” In fact, that’s the very first item on our list of AWS Identity and Access Management security best practices — a sign of just how strongly we believe in this recommendation. Let’s start by understanding more about what the AWS account root user is and why you shouldn’t use it unless absolutely necessary.

So what is an AWS account root user?

From the official documentation, we can see that; “When you first create an Amazon Web Services (AWS) account, you begin with a single sign-in identity that has complete access to all AWS services and resources in the account. This identity is called the AWS account root user. You can sign in as the root user using the email address and password that you used to create the account.”

The root user is an integral component of an AWS account. There can only ever be one root user per account, and they have complete and unrestricted access to everything inside the account. The root user login is an email address, which must be unique across all AWS accounts in all regions. We strongly recommend that this email be an alias tied to a business domain, rather than a personal email address, and it should have a strong password and multi-factor authentication enabled. A handy tip here is to either use an email alias such as aws-production@yourdomain.com or, if your email provider supports it, you can use plus-addressing, which looks like aws+production@yourdomain.com.

There are two security fundamentals that highlight the differences between IAM users and root users in AWS:

• Identity and Attribution – every action taken within a system should be attributable to a specific user.
• Principle of Least Privilege – every user within a system should have the permissions to perform the tasks required of them and no more.

Looking at the AWS root account, you can clearly see that it fails both of these tests; if multiple individuals work using the root user, you cannot tell which individual performed which action, and the root user has full access to the account. This might feel fine when it’s just you building in your new account, but there’s a better way.

What is Amazon Identity and Access Management?

At its core, IAM is the AWS service that is used to manage access to all other AWS services. It is built around four foundational components:

• Principal – the user or service (identity) that is being granted or denied access.
• Action – the command(s) that are being allowed or denied. This could be very broad, such as full access to the Elastic Compute Cloud (Amazon EC2) service, or very tightly-scoped to a single command such as EC2:DescribeInstances.
• Resource – the target to which access is being granted or denied. Again, this could be as broad as any EC2 instance or scoped to a specific instance.
• Condition – an optional check that can be used to further limit permissions based on one or more criteria.

By combining these four elements, you can create an IAM policy that allows or denies access to AWS services using a consistent, logical, and readable syntax. If you want to learn more, we highly recommend watching this video by Becky Weiss, Senior Principal Engineer at AWS, where she dives deep on IAM and how to use it to protect your AWS environment effectively.

What is an IAM user, and why should you be using it instead?

Going back to the IAM documentation again, we can see that: “An AWS Identity and Access Management (IAM) user is an entity that you create in AWS to represent the person or application that uses it to interact with AWS. A user in AWS consists of a name and credentials.”

The key thing to note here is that an IAM user represents an individual or an identity. This allows actions taken by that user to be attributed to a specific person or application. Each IAM user can also have one or more IAM policies attached to them, which offers fine-grained control over the actions that user may take. In fact, those are the two key differences between the AWS account root user and an IAM user:

• An IAM user represents an individual person or application, whereas there can only ever be a single root user for each account.
• An IAM user only has the permissions granted to it by one or more IAM policies, whereas the root user has unlimited access, and there is no trivial mechanism for scoping down that access.

Let’s dive a bit deeper into the differences and similarities between the root user and an IAM user:

There are a few scenarios that make it clear why IAM users should be preferred, even in very small teams:

• Using shared root credentials – if someone leaves your team, the credentials must be rotated, and everyone will need to be given the new credentials. If the credentials are also being used by applications, they will also need to be updated.
• Root credentials leaked – while it’s possible to rotate the credentials of the root user, it’s disruptive (see above), and if the root credentials are leaked, the damage that can be done by an attacker is basically unlimited, including taking over or closing your account.
• User error – when all users are working with the root credentials, the risk that they could perform a highly destructive operation by mistake is greatly increased. This could include deleting production services or data.

When and how should I use the root user?

We strongly recommend that you do not use the root user for your everyday tasks, even administrative ones. Instead, adhere to the best practice of using the root user only to create your first IAM user. Then securely lock away the root user credentials and add multi-factor authentication. This can be done in a few ways:

• Hardware code generator or U2F token – this is a physical device that is required to gain access to the account to which it’s attached, and it is the most secure option for MFA. Once configured, the device can be stored in a safe or lockbox to offer additional security.
• A software-based authenticator – this is an app, usually running on a mobile device, that generates secure one-time codes, which are used as part of the sign-in process. These are considered less secure than physical tokens but are still a good option for most use cases.
• SMS-based MFA – this is considered insecure and is no longer supported for new users.

Some operations within your AWS account can only be performed by the root user. They are documented here, but the critical ones are:

• To create your first IAM user(s)
• To sign up for AWS Support
• To recover access to your AWS account if you lose access to your IAM user

With the above in mind, we recommend that you regularly (every month or so) check to make sure you can access the root user in your AWS account. Due to the high risk in using the root account, AWS Support has a high bar for evidence when it comes to recovering access. With this in mind, it’s a good idea to ensure that at least two people are able to access the root account, so that access is not lost if a single person is unavailable for any reason. You may also want to set up an alert so that you receive a notification when the root account is used, to ensure that it remains secure. Lastly, you should only use the root user via the AWS console, and you should not create access keys for the root user.

What’s next?

Now you have a solid understanding of what the AWS account root user is and why you should avoid using it for working in your AWS account. As a next step, go and see how the account root user is being used in your account today, and start working through our IAM security best practices. It might feel like a lot of work now, but doing it today while your team is small — and, ideally, before you have production workloads and real customer data in your account — can save you trouble, time, and money down the road. If you need help getting started, please reach out to your account manager or contact AWS Support.