Which of the following are recommended best practices for AWS IAM service?

AWS Identity and Access Management (IAM) enables you to manage users and permission levels for staff and third parties requiring access to your AWS account. This service provides centralized access to manage access keys, security credentials, and permission levels. This service is particularly useful for organisations with complex workloads on AWS.

Trend Micro Cloud One™ – Conformity monitors AWS Identity and Access Management (IAM) with the following rules:

1. Use Amazon Inspector to monitor for compliance
5. Use AWS Lambda to scan log files

• Amazon Inspector is an automated security assessment service that helps improve the security and compliance of applications deployed on AWS. Amazon Inspector automatically assesses applications for exposure, vulnerabilities, and deviations from best practices
• You can use AWS Lambda, Amazon EMR, the Amazon Elasticsearch Service, or third- party tools from the AWS Marketplace to scan logs to detect things like unused permissions, overuse of privileged accounts, usage of keys, anomalous logins, policy violations, and system abuse
• CloudWatch is used for performance monitoring whereas CloudTrail is used for logging API calls
• AWS IAM is not used for storage of log files

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.

Start a Free Trial

Table of contents

What is IAM?

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.

IAM security best practices – Basic 

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.

IAM root user

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.

Enforce MFA

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.

What’s the worst-case scenario?

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.

IAM security best practices – Advanced 

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.

Utilize IAM groups

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.

Make use of roles and role assumption

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.

Implement resource-based policies

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.

Avoid 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.

Configure policies with conditional values

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.

What’s the worst-case scenario?

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.

Securing IAM is critical to AWS security

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.

Which of the following are recommended best practices for AWS IAM service select two?

Which of the following are IAM best practices choose 3 answers?

Which of the following are AWS IAM best practices for AWS select three?

What is the best practices for managing AWS IAM access keys?