AWS IAM: Security Best Practices

If you ask anyone to describe what's in their team or organization's AWS account, you'll probably get fairly consistent answers. Some S3 buckets, some EC2 instances, some RDS clusters. However, there is one critical service that everyone uses, but very few think to mention: AWS Identity and Access Management (IAM). Ask them to describe their IAM deployment, and you're likely to get a variety of answers. Some might shrug their shoulders, some might articulate well crafted, secure policies, and some probably just gave everything "**:**".

Sadly, IAM is often only given passing consideration when discussing AWS usage, despite it being a fundamental part of AWS cloud services. Sometimes, confusing and counterintuitive behavior leads to organizations having a complex, difficult to manage IAM infrastructure. This creates an obvious security risk to the entire company and its digital infrastructure. 

Fortunately, there are some simple steps engineering organizations can take to make sure their IAM architecture takes on a stronger security posture.

Your keys to a better career

Get started with ACG today to transform your career with courses and real hands-on labs in AWS, Microsoft Azure, Google Cloud, and beyond.

Before we dive into IAM security best practices, let’s get a quick refresh on what IAM actually is and how it fits into the constellation of AWS services. If you want to go more in-depth on the basics of IAM, this course provides a great introduction to IAM concepts.

Fundamentally, IAM is a Role Based Access Control (RBAC) system. Access and authorization to almost all AWS services is defined and issued via IAM. Like any RBAC, IAM grants access based on the concept of a role or identity. Roles are assigned permissions, via policies, to perform various tasks and access services. 

In IAM, roles take on three primary forms: users, roles, and groups. An IAM user is what a new AWS user will encounter first, so it makes sense to start our best practices there.

Securing IAM doesn't have to involve complicated security measures or elaborate monitoring systems. There are some basic steps you can take right away to significantly improve your IAM security posture. 

Building on the basic course mentioned above, you can take advantage of the intermediate IAM course to further your understanding of IAM and learn more advanced usage.

The IAM root user is one of the first things to focus on. Borrowing directly from AWS guidance:

We strongly recommend that you do not use the root user for your everyday tasks, even the 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 use them to perform only a few account and service management tasks.

The root user is the top-level identity in an AWS account or organization. Not only does it have full access to all services, it also controls billing and other administrative functions. Using it for regular tasks exposes it to a potential compromise, which would be catastrophic, and exponentially so in a multi-account deployment. 

If you're currently using the IAM root user, you should immediately:

1. Create a separate IAM user for administration and technical work.
2. Disable and delete any credential pairs the root user may have had.

Further logical separation of the root user from daily access can be achieved with multiple AWS accounts, AWS Organizations, and consolidated billing. AWS provides best practice guidance on the use of multiple accounts, but a simple first step is to create an AWS organization in your primary account, and create a second account to house the actual infrastructure and managed services that are being consumed. 

The first account will contain the root user that has access to the critical functions of billing and top level administration. However, it will contain no infrastructure or active service endpoints, vastly reducing the potential attack surface for compromise. 

The second account will contain the actual infrastructure, but in the event of a compromise, you will still retain top-level control of the organization, and can work with AWS support to resecure your resources.

Following the theme of reducing potential vectors for compromise, IAM users in any account should always have Multi-Factor Authentication (MFA) enabled. AWS works with both virtual and hardware MFA tokens, providing a critical extra layer of security for user access. Policies can be applied that prevent access to any resource without a valid MFA authentication in place, limiting the blast radius if an account is compromised.

So what are the potential risks if these measures aren't enacted? Not enforcing MFA on user accounts makes them more vulnerable to compromise. If one of these user accounts has admin-level permissions, the potential damage could be severe. 

Not taking steps to secure the root user account could possibly lead to an organization's entire AWS architecture being compromised, an event that would almost certainly wreak extreme financial and reputational damage.

Okay, we’ve got the basics covered. Now let’s evaluate some more advanced techniques for securing IAM. If you want to learn more, check out our advanced, deep-dive course on IAM.

If your organization still makes use of IAM users, IAM groups can provide a useful mechanism for simplifying policy creation and assignment. Streamlining permissions and access control for users can make effective security easier by simplifying management. Rather than assigning admin positions individually to each administrator, these permissions can be assigned to an "Administrators" group, and access can be granted and revoked simply by virtue of group membership.

IAM roles are one of the most powerful and flexible concepts within IAM. They are very similar to IAM users, with the critically important exception that a role can be assumed by multiple entities, even at the same time. This provides an excellent mechanism for issuing more temporary, ephemeral access grants without the concern of long-lived access credentials. 

If an identity such as an IAM user is granted permission as a Principal via a role's trust policy, it can assume that role. This enables access patterns that are more secure, such as keeping IAM users in an account with minimal permissions, and allowing them to assume roles for work in a separate account.

Some AWS resources, such as S3 buckets and SQS queues, have special policies called resource-based policies. In contrast to IAM policies, which are identity-based, resource-based policies focus on the underlying resources themselves. IAM will evaluate both identity and resource-based policies together, allowing for more fine-grained access control than might be offered by either one independently.

Inline policies are unique policies that are directly integrated with a given IAM identity. They can be useful to ensure that only a specific identity will ever have a given policy, but it’s likely that in most cases this will be an infrequent scenario. Widespread use of inline policies becomes difficult to manage, and prevents enforcing homogenous policy configuration and usage amongst a larger number of identities. 

A core tenet of managing complex, distributed systems effectively is being able to centralize change management and administration, which is made far easier by use of traditional managed policies attached to an identity.

One component of IAM policies is the Condition. A condition element can specify a condition (or conditions) under which a policy is active. At first glance it seems counterintuitive that someone would want to define situations where there is less of a security policy, but in the context of policy evaluation operating as "deny by default", it provides an effective mechanism for further controlling access. 

For instance, an IAM administrator could create a policy granting access to certain resources that would include a condition block that specifies the policy is only effective for the next seven days. At the end of the seven days, the policy would no longer apply, and IAM would render a denial of access to any resource that was not granted elsewhere. This provides a very effective tool for organizations that frequently work with contractors and third parties.

These guidelines focus on more advanced configurations that help streamline IAM administration and policy management. Using roles and role assumption significantly reduces the risk of hard-coded credentials with broad access being compromised. Not taking advantage of the other practices will eventually lead to a sprawling, unmanageable collection of IAM identities and policies, making for a much more difficult journey in keeping your AWS infrastructure secure.

By now you know that even basic steps can significantly improve your AWS security. With more and more organizations moving their software and data to cloud platforms like AWS, it's more important than ever to ensure proper security measures and hygiene are in place. Using this info will help sharpen your IAM skill set and improve your organization's AWS security.

About the author
Mike Vanbuskirk is a Lead DevOps engineer and technical content creator. He’s worked with some of the largest cloud, e-commerce, and CDN platforms in the world. His current focus is cloud-first architecture and serverless infrastructure.