When using AWS Identity and Access Management What is the recommended best practice with your root user access keys?

Keeping your Amazon account secure is a major concern for every AWS user and admin. Here are the top five AWS root user account best practices every organization should follow:

  1. Never share AWS root account credentials
  2. Delete any and all of root’s programmatic access keys
  3. Enable multi-factor authentication (MFA) on the root account
  4. Update the AWS password policy to rotate credentials every 90 days
  5. Perform all administrative functions with non-root accounts

Let’s break these down one by one.

Credentials for the AWS root account should be shared only with a select group of individuals on the IT team. Don’t share the AWS root account with the CEO, or with an auditor or compliance officer. Only as small number of individuals should know where the root credentials are stored. Create rules about how to access that credential, and what steps to follow when the root account password is updated.

If you must assign elevated rights to a user temporarily, create a time-boxed role for that individual. But never share AWS root account credentials.

Another AWS root account best practice is to delete any programmatic access keys associated with the root user.  If a PEM file or DER certificate exists for the root account, that doubles the root account’s attack surface. Delete those keys immediately.

In rare instances, an administrator might perform an administrative function as a root user. There are no reasons why a piece of software should programmatically log in as root with user’s access keys.

When using AWS Identity and Access Management What is the recommended best practice with your root user access keys?

By default, AWS accounts are only protected by a username and password. The best practice here is to enable MFA.

With a password, you prove who you are with a piece of information that only you know. MFA ups the ante by requiring not only what you know but also what you have. In addition to a password the user must also provide a token or code, generated on a device that is not the device on which the user is attempting to log in as the AWS root.

Many Gmail or Facebook users are familiar with using SMS messages with MFA. AWS is much stricter — an SMS message to a mobile device is not a valid MFA option. For AWS, the only valid MFA options are:

  • A virtual MFA device
  • Universal 2nd factor security key
  • Hardware MFA key fob
  • Hardware display card
  • GovCloud approved MFA device

Securing access to the root AWS account is a crucial best practice. If your organization uses any of the devices listed above, include them in an MFA routine.

When using AWS Identity and Access Management What is the recommended best practice with your root user access keys?

MFA is a commonly accepted best practice for root AWS account security.

There is no default password rotation for the AWS root account. Once the AWS root password is set, there are no rules that require regular password updates.

However, admins can easily create a setup to regularly rotate passwords by updating the password policy attached to the account.

A general AWS root user best practice is to set the password rotation period to at least 90 days. For even more security, set it to 60 days.

For day-to-day administration of the AWS console, create an administrative group and add trusted users who need elevated rights.

The root AWS account can never be deleted, and the rights associated with the root account cannot be revoked. Admins can, however, remove a user from the administrative group or suspend a user’s account altogether.

Furthermore, with administrative access provisioned on a per-account basis, admins can monitor the actions of a specific user to identify any peculiar activity that warrant investigation. If the root account is shared by multiple users, there is no way to identify which user performed which administrative tasks.

A core tenet of server-side security is to respect the principle of least privilege.

When using AWS Identity and Access Management What is the recommended best practice with your root user access keys?

An AWS root account best practice is to always respect the principle of least privilege.

An admin should assign to users only the minimal rights to perform their required tasks. Furthermore, don’t add users to the administrative group every time they perform a one-off administrative function — use AWS roles instead.

Also, regularly monitor exactly who is included in your account’s administrative group. If a user moves on to a non-administrative role, do not allow that user to perform management functions in AWS.

Follow these AWS root account best practices, and you’ll ensure that nefarious cyber-criminals never gain access to your cloud-computing credentials.

There are different types of users in AWS. For example, there is the account owner (root user) and AWS Identity and Access Management (IAM) users. When you create an AWS account, we create the account root user. The root user or an IAM administrator for the account can create IAM users. All AWS users have security credentials.

Root user credentials

The credentials of the account owner allow full access to all resources in the account. You can't use IAM policies to deny the root user access to resources explicitly. You can only use an AWS Organizations service control policy (SCP) to limit the permissions of the root user. Because of this, we recommend that you create an IAM user with administrator permissions for everyday AWS tasks, and lock away the credentials for the root user.

There are specific tasks that are restricted to the AWS account root user. For example, only the root user can close your account. If you must perform a task that requires the root user, sign in to the AWS Management Console with the email address and password of the root user. For more information, see Tasks that require root user credentials in the AWS Account Management Reference Guide.

Considerations

  • Be sure to save the following in a secure location: the email address associated with your AWS account, the AWS account ID, the root user password, and your account access keys. If you forget or lose your root user password, you must have access to the email address associated with your account in order to reset it. If you lose your access keys, you must sign into your account to create new ones.

  • We strongly recommend that you do not use the root user for your everyday tasks. Safeguard your root user credentials and use them to perform the tasks that only the root user can perform. For the complete list of tasks that require you to sign in as the root user, see Tasks that require root user credentials.

  • Security credentials are account-specific. If you have access to multiple AWS accounts, you have separate credentials for each account.

  • Never share your AWS account root user password or access keys with anyone.

IAM credentials

With IAM, you can securely control access to AWS services and resources for users in your AWS account. For example, if you require administrator-level permissions, you can create an IAM user, grant that user full access, and then use those credentials to interact with AWS. If you must modify or revoke your permissions, you can delete or modify the policies that are associated with that IAM user.

If you have multiple users who require access to your AWS account, you can create unique credentials for each user and define who has access to which resources. You don't need to share credentials. For example, you can create IAM users with read-only access to resources in your AWS account and distribute those credentials to users.

For more information, see IAM identities in the IAM User Guide.

When you use AWS programmatically, you provide your AWS access keys so that AWS can verify your identity in programmatic calls. Your access keys consist of an access key ID (for example, AKIAIOSFODNN7EXAMPLE) and a secret access key (for example, wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY).

Anyone who has your access keys has the same level of access to your AWS resources that you do. Consequently, AWS goes to significant lengths to protect your access keys, and, in keeping with our shared-responsibility model, you should as well.

The steps that follow can help you protect your access keys. For background information, see Creating and deleting access keys for the AWS account root user.

Your organization may have different security requirements and policies than those described in this topic. The suggestions provided here are intended as general guidelines.

Remove (or don't generate) an account access key

You must use your access keys to sign requests that you make using the AWS Command Line Tools, the AWS SDKs, or direct API calls. Anyone who has the access keys for your AWS account root user has unrestricted access to all the resources in your account, including billing information. You can't restrict the permissions for your AWS account root user.

One of the best ways to protect your account is to not have access keys for your AWS account root user. Unless you must have root user access keys (which is rare), it is best not to generate them. Instead, the recommended best practice is to create one or more AWS Identity and Access Management (IAM) users. Grant those IAM users the necessary permissions, and use them for everyday interaction with AWS.

If you already have access keys for your account, we recommend the following: Find places in your applications where you are currently using access keys (if any), and replace the root user access keys with IAM user access keys. Then disable and remove the root user access keys. For more information about how to substitute one access key for another, see How to Rotate Access Keys for IAM Users on the AWS Security Blog.

By default, AWS doesn't generate access keys for new accounts.

For information about how to create an IAM user with administrative permissions, see Creating Your First IAM Admin User and Group in the IAM User Guide.

Use temporary security credentials (IAM roles) instead of long-term access keys

In many scenarios, you don't need long-term access keys that never expire (as you have with an IAM user). Instead, you can create IAM roles and generate temporary security credentials. Temporary security credentials consist of an access key ID and a secret access key, but they also include a security token that indicates when the credentials expire.

Long-term access keys, such as those associated with IAM users and AWS account root users, remain valid until you manually revoke them. However, temporary security credentials obtained through IAM roles and other features of the AWS Security Token Service expire after a short period of time. Use temporary security credentials to help reduce your risk in case credentials are accidentally exposed.

Use an IAM role and temporary security credentials in these scenarios:

  • You have an application or AWS CLI scripts running on an Amazon EC2 instance. Don't use access keys directly in your application. Don't pass access keys to the application, embed them in the application, or let the application read access keys from any source. Instead, define an IAM role that has appropriate permissions for your application and launch the Amazon Elastic Compute Cloud (Amazon EC2) instance with roles for EC2. Doing this associates an IAM role with the Amazon EC2 instance. This practice also enables the application to get temporary security credentials that it can in turn use to make programmatic calls to AWS. The AWS SDKs and the AWS Command Line Interface (AWS CLI) can get temporary credentials from the role automatically.

  • You need to grant cross-account access. Use an IAM role to establish trust between accounts, and then grant users in one account limited permissions to access the trusted account. For more information, see Tutorial: Delegate access across AWS accounts using IAM roles in the IAM User Guide.

  • You have a mobile app. Don't embed access keys with the app, even in encrypted storage. Instead, use Amazon Cognito to manage user identities in your app. This service lets you authenticate users using Login with Amazon, Facebook, Google, or any OpenID Connect (OIDC)–compatible identity provider. You can then use the Amazon Cognito credentials provider to manage credentials that your app uses to make requests to AWS. For more information, see Using the Amazon Cognito Credentials Provider on the AWS Mobile Blog.

  • You want to federate into AWS and your organization supports SAML 2.0. If you work for an organization that has an identity provider that supports SAML 2.0, configure the provider to use SAML. You can use SAML to exchange authentication information with AWS and get back a set of temporary security credentials. For more information, see About SAML 2.0-based Federation in the IAM User Guide.

  • You want to federate into AWS and your organization has an on-premises identity store. If users can authenticate inside your organization, you can write an application that can issue them temporary security credentials for access to AWS resources. For more information, see Enabling custom identity broker access to the AWS Management Console in the IAM User Guide.

Manage IAM user access keys properly

If you must create access keys for programmatic access to AWS, create them for IAM users, granting the users only the permissions they require. For more information, see Managing access keys for IAM users in the IAM User Guide.

Are you using an Amazon EC2 instance with an application that requires programmatic access to AWS resources? If so, use IAM roles for EC2.

Observe these precautions when using access keys:

  • Don't embed access keys directly into code. The AWS SDKs and the AWS Command Line Tools enable you to put access keys in known locations so that you don't have to keep them in code.

    Put access keys in one of the following locations:

    • The AWS credentials file. The AWS SDKs and AWS CLI automatically use the credentials that you store in the AWS credentials file.

      For information about using the AWS credentials file, see the documentation for your SDK. Examples include Set AWS Credentials and Region in the AWS SDK for Java Developer Guide and Configuration and credential files in the AWS Command Line Interface User Guide.

      To store credentials for the AWS SDK for .NET and the AWS Tools for Windows PowerShell, we recommend that you use the SDK Store. For more information, see Using the SDK Store in the AWS SDK for .NET Developer Guide.

    • Environment variables. On a multitenant system, choose user environment variables, not system environment variables.

      For more information about using environment variables to store credentials, see Environment Variables in the AWS Command Line Interface User Guide.

  • Use different access keys for different applications. Do this so that you can isolate the permissions and revoke the access keys for individual applications if they are exposed. Having separate access keys for different applications also generates distinct entries in AWS CloudTrail log files. This configuration makes it easier for you to determine which application performed specific actions.

  • Rotate access keys periodically. Change access keys on a regular basis. For details, see Rotating access keys (AWS CLI, Tools for Windows PowerShell, and AWS API) in the IAM User Guide and How to Rotate Access Keys for IAM Users on the AWS Security Blog.

  • Remove unused access keys. If a user leaves your organization, remove the corresponding IAM user so that the user can no longer access your resources. To find out when an access key was last used, use the GetAccessKeyLastUsed API (AWS CLI command: aws iam get-access-key-last-used).

  • Configure multi-factor authentication for your most sensitive operations. For more information, see Using Multi-Factor Authentication (MFA) in AWS in the IAM User Guide.

Access the mobile app using AWS access keys

You can access a limited set of AWS services and features using the AWS mobile app. The mobile app helps you support incident response while on the go. For more information and to download the app, see AWS Console Mobile Application.

You can sign in to the mobile app using your console password or your access keys. As a best practice, do not use root user access keys. Instead, we strongly recommend that in addition to using a password or biometric lock on your mobile device, you create an IAM user to manage AWS resources. If you lose your mobile device, you can remove the IAM user's access. For more information about generating access keys for an IAM user, see Managing access keys for IAM users in the IAM User Guide.

To sign in using access keys (mobile app)

  1. Open the app on your mobile device.

  2. If this is the first time that you're adding an identity to the device, choose Add an identity and then choose Access keys.

    If you have already signed in using another identity, choose the menu icon and choose Switch identity. Then choose Sign in as a different identity and then Access keys.

  3. On the Access keys page, enter your information:

    • Access key ID – Enter your access key ID.

    • Secret access key – Enter your secret access key.

    • Identity name – Enter the name of the identity that will appear in the mobile app. This does not need to match your IAM user name.

    • Identity PIN – Create a personal identification number (PIN) that you will use for future sign-ins.

      If you enable biometrics for the AWS mobile app, you will be prompted to use your fingerprint or facial recognition for verification instead of the PIN. If the biometrics fail, you might be prompted for the PIN instead.

  4. Choose Verify and add keys.

    You can now access a select set of your resources using the mobile app.

Learn more

For more information about best practices for keeping your AWS account secure, see the following resources: