AWS Identity and Access Management

I. Authentication and authorization

When you configure access to any account, two terms come up frequently: authentication and authorization. Although these terms might seem basic, you must fully understand them to properly configure access management on AWS.

Authentication

Authentication ensures that the user is who they say they are. User names and passwords are the most common types of authentication. But you might also work with other forms, such as token-based authentication or biometric data, like a fingerprint.

Authentication simply answers the question, “Are you who you say you are?”

Authorization

After you’re authenticated and in your AWS account, you might be curious about what actions you can take. This is where authorization comes in. Authorization is the process of giving users permission to access AWS resources and services. Authorization determines whether a user can perform certain actions, such as read, edit, delete, or create resources.

Authorization answers the question, “What actions can you perform?”

II. What is IAM?

AWS Identity and Access Management (IAM) is an AWS service that helps you manage access to your AWS account and resources.

It also provides a centralized view of who and what are allowed inside your AWS account (authentication), and who and what have permissions to use and work with your AWS resources (authorization).

With IAM, you can share access to an AWS account and resources without sharing your set of access keys or password. You can also provide granular access to those working in your account, so people and services only have permissions to the resources that they need.

For example, to provide a user of your AWS account with read-only access to a particular AWS service, you can granularly select which actions and which resources in that service that they can access.

III. IAM features

To help control access and manage identities in your AWS account, IAM offers many features to ensure security.

To learn more, expand each of the following six categories.

Global

IAM is global and not specific to any one Region. You can see and use your IAM configurations from any Region in the AWS Management Console.

Integrated with AWS services

IAM is integrated with many AWS services by default.

Shared access

You can grant other identities permission to administer and use resources in your AWS account without having to share your password and key.

Multi-factor authentication

IAM supports MFA. You can add MFA to your account and to individual users for extra security.

Identity federation

IAM supports identity federation, which allows users with passwords elsewhere—like your corporate network or internet identity provider—to get temporary access to your AWS account.

Free to use

Any AWS customer can use IAM; the service is offered at no additional charge.

IV. AWS Root User

When you first access AWS, you begin with a single sign-in identity known as the root user.

This root user has unrestricted access to everything in your account in most cases.

AWS root user credentials

The AWS root user has two sets of credentials associated with it:

• One set of credentials is the email address and password that were used to create the account. This allows you to access the AWS Management Console.
• The second set of credentials is called access keys, which allow you to make programmatic requests from the AWS Command Line Interface (AWS CLI) or AWS API.

Access keys consist of two parts:

• Access key ID: for example, A2lAl5EXAMPLE
• Secret access key: for example, wJalrFE/KbEKxE

Similar to a user name and password combination, you need both the access key ID and secret access key to authenticate your requests through the AWS CLI or AWS API. Access keys should be managed with the same security as an email address and password.

AWS root user best practices

• Choose a strong password for the root user.
• Enable multi-factor authentication (MFA) for the root user.
• Never share your root user password or access keys with anyone.
• Disable or delete the access keys associated with the root user.
• Create an Identity and Access Management (IAM) user for administrative tasks or everyday tasks.

Supported MFA devices

Device	Description	Supported Devices
Virtual MFA	A software app that runs on a phone or other device that provides a one-time passcode. These applications can run on unsecured mobile devices, and because of that, they might not provide the same level of security as hardware or FIDO security keys.	Twilio Authy Authenticator, Duo Mobile, LastPass Authenticator, Microsoft Authenticator, Google Authenticator, Symantec VIP
Hardware TOTP token	A hardware device, generally a key fob or display card device, that generates a one-time, six-digit numeric code based on the time-based one-time password (TOTP) algorithm.	Key fob, display card
FIDO security keys	FIDO-certified hardware security keys are provided by third-party providers such as Yubico. You can plug your FIDO security key into a USB port on your computer and enable it using the instructions that follow.	FIDO Certified products

V. IAM user

An IAM user represents a person or service that interacts with AWS. You define the user in your AWS account.

Any activity done by that user is billed to your account. When you create a user, that user can sign in to gain access to the AWS resources inside your account.

IAM user credentials

You can have up to 5000 users per AWS account. You should create individual IAM accounts for users (best practice not to share accounts).

Each user account has a friendly name and an ARN which uniquely identifies the user across AWS. A unique ID is also created which is returned only when you create the user using the API, Tools for Windows PowerShell, or the AWS CLI.

By default, users cannot access anything in your account. When you create an IAM user, you can grant permissions directly at the user level. This can seem like a good idea if you have only one or a few users. However, as the number of users increases, keeping up with permissions can become more complicated.

An IAM user consists of a name and a set of credentials. When you create a user, you can provide them with the following types of access:

• Access to the AWS Management Console with a user name and password
• Programmatic access to the AWS CLI and AWS API with a set of access keys (must be regenerated if lost)

A password policy can be defined for enforcing password length, complexity etc. (applies to all users). You can allow or disallow the ability to change passwords using an IAM policy. Access keys and passwords should be changed regularly.

IAM users can be created to represent applications, and these are known as “service accounts”.

VI. IAM groups

An IAM group is a collection of users. All users in the group inherit the permissions assigned to the group. This makes it possible to give permissions to multiple users at once. It’s a more convenient and scalable way of managing permissions for users in your AWS account. This is why using IAM groups is a best practice.

This provides a way to see who has what permissions in your organization. It also helps you scale when new people join, leave, and change roles in your organization.

!https://explore.skillbuilder.aws/files/a/w/aws_prod1_docebosaas_com/1729105200/v2l_QHcIYQAEkSzHQAySIw/tincan/9b7c5b541f30d708ac93c376cbcd26df5bc0c050/assets/IAM%20groups.png

Keep in mind the following features of groups:

• Groups can have many users.
• Users can belong to many groups.
• Groups cannot belong to groups.
• IAM Group is NOT truly an identity because it cannot be identified as a Principal in a resource-based or trust policy. It is only a way to attach policies to multiple users at one time.

Use the principle of least privilege when assigning permissions.

VII. IAM policies

To manage access and provide permissions to AWS services and resources, you create IAM policies and attach them to an IAM identity. Whenever an IAM identity makes a request, AWS evaluates the policies associated with them.

IAM policy examples

Most policies are stored in AWS as JSON documents with several policy elements. The most restrictive policy is applied.

The following examples provides admin access through an IAM identity-based policy.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "FirstStatement",
      "Effect": "Allow",
      "Action": ["iam:ChangePassword"],
      "Resource": "*"
    },
    {
      "Sid": "SecondStatement",
      "Effect": "Allow",
      "Action": "s3:ListAllMyBuckets",
      "Resource": "*"
    },
    {
      "Sid": "ThirdStatement",
      "Effect": "Allow",
      "Action": [
        "s3:List*",
        "s3:Get*"
      ],
      "Resource": [
        "arn:aws:s3:::amzn-s3-demo-bucket-confidential-data",
        "arn:aws:s3:::amzn-s3-demo-bucket-confidential-data/*"
      ],
      "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
    }
  ]
}

JSON policy document structure

As illustrated in the following figure, a JSON policy document includes these elements:

• Optional policy-wide information at the top of the document
• One or more individual statements

Each statement includes information about a single permission. If a policy includes multiple statements, AWS applies a logical OR across the statements when evaluating them. If multiple policies apply to a request, AWS applies a logical OR across all of those policies when evaluating them.

!https://docs.aws.amazon.com/images/IAM/latest/UserGuide/images/AccessPolicyLanguage_General_Policy_Structure.diagram.png

The information in a statement is contained within a series of elements.

• Version – Specify the version of the policy language that you want to use. We recommend that you use the latest 2012-10-17 version. For more information, see IAM JSON policy elements: Version
• Statement – Use this main policy element as a container for the following elements. You can include more than one statement in a policy.
  • Sid (Optional) – Include an optional statement ID to differentiate between your statements.
  • Effect – Use Allow or Deny to indicate whether the policy allows or denies access.
  • Principal (Required in only some circumstances) – If you create a resource-based policy, you must indicate the account, user, role, or federated user to which you would like to allow or deny access. If you are creating an IAM permissions policy to attach to a user or role, you cannot include this element. The principal is implied as that user or role.
  • Action – Include a list of actions that the policy allows or denies.
  • Resource (Required in only some circumstances) – If you create an IAM permissions policy, you must specify a list of resources to which the actions apply. If you create a resource-based policy, this element is optional. If you do not include this element, then the resource to which the action applies is the resource to which the policy is attached.
  • Condition (Optional) – Specify the circumstances under which the policy grants permission.

Policy Types

The following policy types, listed in order from most frequently used to less frequently used, are available for use in AWS. For more details, see the sections below for each policy type.

• Identity-based policies – Attach managed and inline policies to IAM identities (users, groups to which users belong, or roles). Identity-based policies grant permissions to an identity.
• Resource-based policies – Attach inline policies to resources. The most common examples of resource-based policies are Amazon S3 bucket policies and IAM role trust policies. Resource-based policies grant permissions to the principal that is specified in the policy. Principals can be in the same account as the resource or in other accounts.
• Permissions boundaries – Use a managed policy as the permissions boundary for an IAM entity (user or role). That policy defines the maximum permissions that the identity-based policies can grant to an entity, but does not grant permissions. Permissions boundaries do not define the maximum permissions that a resource-based policy can grant to an entity.
• Organizations SCPs – Use an AWS Organizations service control policy (SCP) to define the maximum permissions for account members of an organization or organizational unit (OU). SCPs limit permissions that identity-based policies or resource-based policies grant to entities (users or roles) within the account, but do not grant permissions.
• Access control lists (ACLs) – Use ACLs to control which principals in other accounts can access the resource to which the ACL is attached. ACLs are similar to resource-based policies, although they are the only policy type that does not use the JSON policy document structure. ACLs are cross-account permissions policies that grant permissions to the specified principal. ACLs cannot grant permissions to entities within the same account.
• Session policies – Pass advanced session policies when you use the AWS CLI or AWS API to assume a role or a federated user. Session policies limit the permissions that the role or user's identity-based policies grant to the session. Session policies limit permissions for a created session, but do not grant permissions. For more information, see Session Policies.

Grant least privilege

When you create IAM policies, follow the standard security advice of granting least privilege, or granting only the permissions required to perform a task. Determine what users and roles need to do and then craft policies that allow them to perform only those tasks.

As an alternative to least privilege, you can use AWS managed policies or policies with wildcard * permissions to get started with policies.

IAM provides several options to help you refine the permissions that you grant.

• Understand access level groupings – You can use access level groupings to understand the level of access that a policy grants. Policy actions are classified as List, Read, Write, Permissions management, or Tagging. To learn how to use policy summaries to understand access level permissions, see Access levels in policy summaries.
• Validate your policies – IAM Access Analyzer provides over 100 policy checks to validate your policies. To learn more about policy checks provided by IAM Access Analyzer, see IAM Access Analyzer policy validation.
• Generate a policy based on access activity – IAM Access Analyzer reviews your AWS CloudTrail logs and generates a policy template that contains the permissions that have been used by the entity in your specified time frame. You can use the template to create a managed policy with fine-grained permissions and then attach it to the IAM entity.To learn more, see IAM Access Analyzer policy generation.
• Use last accessed information – For more information, see Refine permissions in AWS using last accessed information.
• Review account events in AWS CloudTrail – To further reduce permissions, you can view your account's events in AWS CloudTrail Event history. CloudTrail event logs include detailed event information that you can use to reduce the policy's permissions. The logs include only the actions and resources that your IAM entities need. For more information, see Viewing CloudTrail Events in the CloudTrail Console in the AWS CloudTrail User Guide.

VIII. IAM roles

Roles are created and then “assumed” by trusted entities and define a set of permissions for making AWS service requests.

With IAM Roles you can delegate permissions to resources for users and services without using permanent credentials (e.g. user name and password).

IAM users or AWS services can assume a role to obtain temporary security credentials that can be used to make AWS API calls.

You can delegate using roles.

There are no credentials associated with a role (password or access keys).

IAM users can temporarily assume a role to take on permissions for a specific task.

A role can be assigned to a federated user who signs in using an external identity provider.

Temporary credentials are primarily used with IAM roles and automatically expire.

Roles can be assumed temporarily through the console or programmatically with the AWS CLI, Tools for Windows PowerShell, or the API.

IAM roles with EC2 instances:

• IAM roles can be used for granting applications running on EC2 instances permissions to AWS API requests using instance profiles.
• Only one role can be assigned to an EC2 instance at a time.
• A role can be assigned at the EC2 instance creation time or at any time afterwards.
• When using the AWS CLI or API instance profiles must be created manually (it’s automatic and transparent through the console).
• Applications retrieve temporary security credentials from the instance metadata.

Role Delegation:

• Create an IAM role with two policies:
  • Permissions policy – grants the user of the role the required permissions on a resource.
  • Trust policy – specifies the trusted accounts that are allowed to assume the role.
• Wildcards (*) cannot be specified as a principal.
• A permissions policy must also be attached to the user in the trusted account.

IX. AWS Security Token Service (AWS STS)

The AWS STS is a web service that enables you to request temporary, limited-privilege credentials for IAM users or for users that you authenticate (federated users).

Temporary security credentials work almost identically to long-term access key credentials that IAM users can use, with the following differences:

• Temporary security credentials are short-term.
• They can be configured to last anywhere from a few minutes to several hours.
• After the credentials expire, AWS no longer recognizes them or allows any kind of access to API requests made with them.
• Temporary security credentials are not stored with the user but are generated dynamically and provided to the user when requested.
• When (or even before) the temporary security credentials expire, the user can request new credentials, if the user requesting them still has permission to do so.

Advantages of STS are:

• You do not have to distribute or embed long-term AWS security credentials with an application.
• You can provide access to your AWS resources to users without having to define an AWS identity for them (temporary security credentials are the basis for IAM Roles and ID Federation).
• The temporary security credentials have a limited lifetime, so you do not have to rotate them or explicitly revoke them when they’re no longer needed.
• After temporary security credentials expire, they cannot be reused (you can specify how long the credentials are valid for, up to a maximum limit)

Users can come from three sources.

1. Federation (typically AD):
2. Uses SAML 2.0.
3. Grants temporary access based on the users AD credentials.
4. Does not need to be a user in IAM.
5. Single sign-on allows users to login to the AWS console without assigning IAM credentials.
6. Federation with Mobile Apps:
7. Use Facebook/Amazon/Google or other OpenID providers to login.
8. Cross Account Access:
9. Allows users from one AWS account access resources in another.
10. To make a request in a different account the resource in that account must have an attached resource-based policy with the permissions you need.
11. Or you must assume a role (identity-based policy) within that account with the permissions you need.

X. IAM best practices

Lock down the AWS root user

The root user is an all-powerful and all-knowing identity in your AWS account. If a malicious user were to gain control of root-user credentials, they would be able to access every resource in your account, including personal and billing information. To lock down the root user, you can do the following:

• Don’t share the credentials associated with the root user.
• Consider deleting the root user access keys.
• Activate MFA on the root account.

Follow the principle of least privilege

Least privilege is a standard security principle that advises you to grant only the necessary permissions to do a particular job and nothing more. To implement least privilege for access control, start with the minimum set of permissions in an IAM policy and then grant additional permissions as necessary for a user, group, or role.

Use IAM appropriately

IAM is used to secure access to your AWS account and resources. It provides a way to create and manage users, groups, and roles to access resources in a single AWS account. IAM is not used for website authentication and authorization, such as providing users of a website with sign-in and sign-up functionality. IAM also does not support security controls for protecting operating systems and networks.

Use IAM roles when possible

Maintaining roles is more efficient than maintaining users. When you assume a role, IAM dynamically provides temporary credentials that expire after a defined period of time, between 15 minutes and 36 hours. Users, on the other hand, have long-term credentials in the form of user name and password combinations or a set of access keys.

User access keys only expire when you or the account admin rotates the keys. User login credentials expire if you applied a password policy to your account that forces users to rotate their passwords.

Consider using an identity provider

If you decide to make your cat photo application into a business and begin to have more than a handful of people working on it, consider managing employee identity information through an identity provider (IdP). Using an IdP, whether it's with an AWS service such as AWS IAM Identity Center (successor to AWS Single Sign-On) or a third-party identity provider, provides a single source of truth for all identities in your organization.

You no longer have to create separate IAM users in AWS. You can instead use IAM roles to provide permissions to identities that are federated from your IdP. Being federated is a process that allows for the transfer of identity and authentication information across a set of networked systems.

For example, your employee Martha has access to multiple AWS accounts. Instead of creating and managing multiple IAM users named Martha in each of those AWS accounts, you could manage Martha in your company’s IdP. If Martha moves in the company or leaves the company, Martha can be updated in the IdP rather than in every AWS account in the company.

Regularly review and remove unused users, roles, and other credentials

You might have IAM users, roles, permissions, policies, or credentials that you are no longer using in your account. IAM provides last accessed information to help you identify irrelevant credentials that you no longer need so that you can remove them. This helps you reduce the number of users, roles, permissions, policies, and credentials that you have to monitor.