AWS Identity and Access Management best practices

Require your human users to rely on temporary credentials when accessing AWS. You can use an identity provider for your human users to provide federated access to AWS accounts by assuming IAM roles, which provide temporary credentials. For centralized access management, we recommend that you use AWS IAM Identity Center to manage access to your accounts and permissions within those accounts. For more information, see the IAM Identity Center User Guide.

A workload is a collection of resources and code, such as an application or backend process, that requires an identity to make requests to AWS services. IAM roles have specific permissions and provide a way for workloads to access AWS by relying on temporary security credentials through an IAM role. For more information, see IAM roles.

We recommend using IAM roles for human users and workloads accessing your AWS resources so that they rely on temporary credentials. However, for scenarios in which you need IAM users or root users in your account, require MFA for additional security. Each user's credentials and device-generated response to an authentication challenge are required to complete the sign-in process. For more information, see Using multi-factor authentication in AWS.

Where possible, we recommend relying on temporary credentials instead of creating long-term credentials such as access keys. However, for scenarios in which you need IAM users with programmatic access and long-term credentials, use access key last used information to rotate and remove access keys regularly. For more information, see Rotating access keys.

When you create an AWS account, you establish a root user name and password to sign in to the AWS Management Console. Configure MFA to safeguard these credentials the same way you would protect other sensitive personal information. Also, use your root user to complete the tasks that can be performed only by the root user—and not for everyday tasks. For more information, see Best practices to protect your account's root user.

When you set permissions with IAM policies, grant only the specific permissions required to perform specific tasks, also known as least-privilege permissions. You might start with broad permissions while you explore the permissions that are required for your workloads or use cases. You then can reduce permissions to work toward least privilege. For more information, see Access management for AWS resources.

To get started granting permissions to your users and workloads, use the AWS managed policies that grant permissions for many common use cases and are available in your AWS account. Keep in mind that AWS managed policies might not grant least-privilege permissions for your specific use cases because they are available for use by all AWS customers. As a result, we recommend that you reduce permissions further by defining customer managed policies that are specific to your use cases. For more information, see AWS managed policies. For information about AWS managed policies that are designed for specific job functions, see AWS managed policies for job functions.

We recommend that you reduce permissions and remove unused users and roles with the goal of achieving least-privilege permissions. IAM provides last accessed information to help you identify the permissions that you no longer require, and you can use this information to refine your IAM policies to better adhere to least-privilege permissions. For more information, see Refining permissions in AWS using last accessed information.

You can specify conditions under which a permission is in effect. For example, you can write a policy condition to specify that all requests must be sent by using SSL. You can also use conditions to grant access to service actions, but only if they are used through a specific AWS service, such as AWS CloudFormation. For more information, see IAM JSON policy elements: Condition.

To grant only the permissions required to perform tasks, you can generate policies based on the access activity that is found in AWS CloudTrail. IAM Access Analyzer analyzes the services and actions that your IAM roles use, and then generates a least-privilege policy that you can use. For more information, see IAM Access Analyzer policy generation.

You can use IAM Access Analyzer to help you preview and analyze public and cross-account access for supported resource types by reviewing the findings that IAM Access Analyzer generates. These findings help you verify that your access controls grant the access that you expect. Additionally, as you update public and cross-account permissions, you can verify the effect of your changes before deploying new access controls to your resources. IAM Access Analyzer also monitors supported resource types continuously and generates a finding for resources that allow public or cross-account access. For more information, see Previewing access with IAM Access Analyzer APIs.

Use IAM Access Analyzer to validate the policies you create to ensure that they adhere to the IAM policy language (JSON) and IAM best practices. IAM Access Analyzer provides more than 100 policy checks and actionable recommendations to help you author secure and functional policies. As you author new policies or edit existing policies in the console, IAM Access Analyzer provides recommendations to help you refine and validate your policies before you save them. Additionally, we recommend that you review and validate all of your existing policies. For more information, see IAM Access Analyzer policy validation.

As you scale your workloads, separate them by using multiple accounts that are managed with AWS Organizations. We recommend that you use Organizations service control policies (SCPs) to establish permissions guardrails to control access for all IAM users and roles across your accounts. SCPs are a type of organization policy that you can use to manage permissions in your organization at the AWS organization, OU, or account level. However, SCPs alone are insufficient to grant permissions to the accounts in your organization. To do this, your administrator must attach identity-based or resource-based policies to IAM users, IAM roles, or the resources in your accounts. For more information, see AWS Organizations, accounts, and IAM guardrails.

In some scenarios, you might want to delegate permissions management within an account to others. For example, you might want to allow developers to create and manage roles for their workloads. When you delegate permissions to others, use permissions boundaries, which use a managed policy to set the maximum permissions that an identity-based policy can grant to an IAM role. A permissions boundary does not grant permissions on its own. For more information, see Permissions boundaries for IAM entities.