Security control recommendations for managing identity and access - AWS Prescriptive Guidance
Root user activityAccess keys for the root userMFA for the root userIAM best practicesLeast privilegeGuardrails at workload level Rotate IAM access keysExternally shared resources

Security control recommendations for managing identity and access

You can create identities in AWS, or you can connect an external identity source. Through AWS Identity and Access Management (IAM) policies, you grant users the necessary permissions so that they can access or manage AWS resources and integrated applications. Effective identity and access management helps validate that the right people and machines have access to the right resources under the right conditions. The AWS Well-Architected Framework provides best practices for managing identities and their permissions. Examples of best practices include relying on a centralized identity provider and using strong sign-in mechanisms, such as multi-factor authentication (MFA). The security controls in this section can help you implement these best practices.

Monitor and configure notifications for root user activity

When you first create an AWS account, you begin with a single sign-in identity called the root user. By default, the root user has full access to all AWS services and resources in the account. You should tightly control and monitor the root user, and you should use it only for tasks that require root user credentials.

For more information, see the following resources:

Don't create access keys for the root user

The root user is the most privileged user in an AWS account. Disabling programmatic access to the root user helps reduce the risk of inadvertent exposure of the user credentials and subsequent compromise of the cloud environment. We recommend that you create and use IAM roles as temporary credentials for accessing your AWS accounts and resources.

For more information, see the following resources:

Enable MFA for the root user

We recommend that you enable multiple multi-factor authentication (MFA) devices for the AWS account root user and IAM users. This raises the security bar in AWS accounts and can simplify access management. Because a root user is a highly privileged user that can perform privileged actions, it's crucial to require MFA for the root user. You can use a hardware MFA device that generates a numeric code based on the time-based one-time password (TOTP) algorithm, a FIDO hardware security key, or a virtual authenticator application.

In 2024, MFA will be required to access the root user of any AWS account. For more information, see Secure by Design: AWS to enhance MFA requirements in 2024 in the AWS Security Blog. We strongly encourage you to extend this security practice and require MFA for all user types in your AWS environments.

If possible, we recommended that you use a hardware MFA device for the root user. Virtual MFA might not provide the same level of security as hardware MFA devices. You can use virtual MFA while waiting for hardware purchase approval or delivery.

In situations where you manage hundreds of accounts in AWS Organizations, depending on your organization's risk tolerance, it might not be scalable to use hardware-based MFA for the root user of each account in an organizational unit (OU). In this case, you can choose one account in the OU that acts as an OU management account, and then disable the root user for the other accounts in that OU. By default, the OU management account doesn't have access to the other accounts. By setting up cross-account access in advance, you can access the other accounts from the OU management account in an emergency. To set up cross-account access, you create an IAM role in the member account, and you define policies so that only the root user in the OU management account can assume this role. For more information, see Tutorial: Delegate access across AWS accounts using IAM roles in the IAM documentation.

We recommend that you enable multiple MFA devices for your root user credentials. You can register up to eight MFA devices of any combination.

For more information, see the following resources:

Follow the security best practices for IAM

The IAM documentation includes a list of best practices that are designed to help you secure your AWS accounts and resources. It includes recommendations for configuring access and permissions according to the principle of least privilege. Examples of IAM security best practices include configuring identity federation, requiring MFA, and using temporary credentials.

For more information, see the following resources:

Grant least-privilege permissions

Least privilege is the practice of grant only the permissions required to perform a task. You do this by defining the actions that can be taken on specific resources under specific conditions.

Attribute-based access control (ABAC) is an authorization strategy that defines permissions based on attributes, such as their tags. You can use group, identity, and resource attributes to dynamically define permissions at scale, rather than defining permissions for individual users. For example, you can use ABAC to allow a group of developers to access only resources that have a specific tag associated with their project.

For more information, see the following resources:

Define permission guardrails at the workload level

It's best practice to use a multi-account strategy because it provides flexibility to define guardrails at the workload level. The AWS Security Reference Architecture offers prescriptive guidance about how to structure your accounts. These accounts are managed as an organization in AWS Organizations, and the accounts are grouped into organizational units (OUs).

AWS services, such as AWS Control Tower, can help you centrally manage controls across an organization. We recommend that you define a clear purpose for each account or OU within the organization, and apply controls according to that purpose. AWS Control Tower implements preventive, detective, and proactive controls that help you govern the resources and monitor compliance. A preventive control is designed to prevent an event from occurring. A detective control is designed to detect, log, and alert after an event has occurred. A proactive control is designed to prevent the deployment of noncompliant resources by scanning resources before they are provisioned.

For more information, see the following resources:

Rotate IAM access keys at a regular interval

It's a best practice to update access keys for use cases that require long-term credentials. We recommend rotating access keys every 90 days or less. Rotating access keys reduces the risk that an access key that is associated with a compromised or terminated account is used. It also prevents access by using an old key that might have been lost, compromised, or stolen. Always update applications after rotating the access keys.

For more information, see the following resources:

Identify resources that are shared with an external entity

An external entity is a resource, application, service, or user that is outside of your AWS organization, such as another AWS accounts, a root user, an IAM user or role, a federated user, an AWS service, or an anonymous (or unauthenticated) user. It is a security best practice to use IAM Access Analyzer to identify the resources in your organization and accounts, such as Amazon Simple Storage Service (Amazon S3) buckets or IAM roles, that are shared with an external entity. This helps you identify unintended access to resources and data, which is a security risk.

For more information, see the following resources: