# Securing your account
Controls and recommendations in this section help keep your AWS account secure. They cover using AWS Identity and Access Management (IAM) users and roles (also known as *principals*) for both human and machine access, restricting the use of the root user, and requiring multi-factor authentication. In this section, you confirm that AWS has the contact information necessary to reach you regarding your account activity and status. You also set up monitoring services, such as AWS Trusted Advisor, AWS Identity and Access Management Access Analyzer, and AWS Budgets, so that you are notified of account activity and can respond if unauthorized or unexpected activity occurs.
**This section contains the following topics:**
+ [ACCT.01 Set account-level contacts to valid email distribution lists](acct-01.md)
+ [ACCT.02 Restrict use of the root user](acct-02.md)
+ [ACCT.03 Configure console access for each user](acct-03.md)
+ [ACCT.04 Assign permissions](acct-04.md)
+ [ACCT.05 Require multi-factor authentication to log in](acct-05.md)
+ [ACCT.06 Enforce a password policy](acct-06.md)
+ [ACCT.07 Deliver CloudTrail logs to a protected Amazon S3 bucket](acct-07.md)
+ [ACCT.08 Prevent public access to private Amazon S3 buckets](acct-08.md)
+ [ACCT.09 Delete unused VPCs, subnets, and security groups](acct-09.md)
+ [ACCT.10 Configure AWS Budgets to monitor your spending](acct-10.md)
+ [ACCT.11 Enable IAM Access Analyzer](acct-11.md)
+ [ACCT.12 Resolve AWS Trusted Advisor high-risk items](acct-12.md)
+ [ACCT.13 Use short-lived credentials for access to your AWS resources](acct-13.md)
# ACCT.01 Set account-level contacts to valid email distribution lists
When setting up primary and alternate contacts for your AWS account, use an email distribution list instead of an individual's email address. Using an email distribution list makes sure that ownership and reachability are preserved as individuals in your organization come and go. Set alternate contacts for billing, operations, and security notifications, and use appropriate email distribution lists accordingly. AWS uses these email addresses to contact you. Make sure that you retain access to them.
**To update your account name, root user password, or root user email address**
1. Sign in to the [AWS Management Console](https://console.aws.amazon.com/)
1. Choose your account name or number, and then choose **Account**.
1. On the [Account](https://console.aws.amazon.com/billing/home?#/account) page, next to **Account details**, choose **Actions**, and then choose the action you want to take.
1. Next to the field you want to update, choose **Edit**.
1. After you have entered your changes, choose **Save changes**.
1. If you are updating the root user password or email address, follow the verification steps that AWS displays.
**To edit your contact information**
1. On the [Account](https://console.aws.amazon.com/billing/home?#/account) page, under **Contact information**, choose **Edit**.
1. For the fields you want to change, enter your updated information, and then choose **Update**.
**To add, update, or remove alternate contacts**
1. On the [Account](https://console.aws.amazon.com/billing/home?#/account) page, under **Alternate Contacts**, choose **Edit**.
1. For the fields you want to change, enter your updated information, and then choose **Update**.
If you have an organization in AWS Organizations enabled, you can also programmatically manage the alternate contacts on your accounts through the AWS Command Line Interface (AWS CLI). For more information, see [Programmatically managing alternate contacts on member accounts with AWS Organizations](https://aws.amazon.com/blogs/mt/programmatically-managing-alternate-contacts-on-member-accounts-with-aws-organizations/) on the AWS Cloud Operations Blog*.*
# ACCT.02 Restrict use of the root user
The AWS account root user is created when you sign up for an AWS account, and this user has full ownership privileges and permissions over the account that cannot be changed. Use the root user exclusively for tasks that require root user credentials. For more information, see [Tasks that require root user credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/root-user-tasks.html) in the IAM documentation. Perform all other actions in your account by using other types of IAM identities, such as federated users with IAM roles. For more information, see [AWS security credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/security-creds.html) in the IAM documentation.
**To restrict use of the root user**
1. Require multi-factor authentication (MFA) for the root user. For more information, see [ACCT.05 Require multi-factor authentication (MFA) to log in](acct-05.md).
1. Create an administrative user so that you don't use the root user for everyday tasks. For more information about configuring user access, see [ACCT.03 Configure console access for each user](acct-03.md).
# ACCT.03 Configure console access for each user
AWS recommends using temporary credentials to grant access to AWS accounts and resources. *Temporary credentials* have a limited lifetime, so you do not have to rotate them or explicitly revoke them when they're no longer needed. For more information, see [Temporary security credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) in the IAM documentation.
For human users, AWS recommends using federated identities from a centralized identity provider (IdP), such as AWS IAM Identity Center, Okta, Active Directory, or Ping Identity. Federating users allows you to define identities in a single, central location, and users can securely authenticate to multiple applications and websites, including AWS, by using a single set of credentials. For more information, see [Identity federation in AWS](https://aws.amazon.com/identity/federation/) and [IAM Identity Center](https://aws.amazon.com/single-sign-on/).
**Note**
Identity federation can complicate the transition from a single-account architecture to a multi-account architecture. It is common for startups to delay implementing identity federation until they have established a multi-account architecture managed in AWS Organizations.
**To set up identity federation using IAM Identity Center**
1. See [Getting started](https://docs.aws.amazon.com/singlesignon/latest/userguide/getting-started.html) in the IAM Identity Center documentation.
1. Make sure that your IdP enforces multi-factor authentication (MFA).
1. Apply permissions according to [ACCT.04 Assign permissions](acct-04.md).
If you are using an external or third-party IdP, see [Identity providers and federation](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) in the IAM documentation.
If your startup is not yet ready to configure identity federation, you can create IAM users directly as a starting point. Creating IAM users with long-term credentials is not a security best practice. Long-term credentials do not expire automatically, which increases the risk of credential exposure if they are not rotated regularly. When your startup is ready to transition to a multi-account architecture managed in AWS Organizations, migrating from IAM users to federated identities will require additional planning.
As a baseline, create an IAM user with a username, password, and multi-factor authentication (MFA) for each human operator. Do not share credentials across users, and rotate long-term credentials on a regular schedule.
**To create an IAM user**
1. Follow the steps in [Create an IAM user in your AWS account](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html#id_users_create_console) in the IAM documentation.
1. Apply permissions according to [ACCT.04 Assign permissions](acct-04.md).
**Warning**
IAM users have long-term credentials, which presents a security risk. To help mitigate this risk, provide these users with only the permissions they require to perform their tasks and remove these users when they are no longer needed. Avoid creating long-lived access keys for IAM users. Instead, use temporary credentials through `aws login` to access the AWS CLI and SDKs, even when using IAM user credentials. This provides the same secure authentication while eliminating the risks associated with long-lived credentials. For more information about CLI and SDK access methods, see [ACCT.13 Use short-lived credentials for access to your AWS resources](acct-13.md).
# ACCT.04 Assign permissions
Configure user permissions by attaching [AWS managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) to IAM roles. *AWS managed policies* are standalone policies designed by AWS to provide permissions for many common use cases. If you customize permissions, follow the security best practice of [granting least privilege](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege). *Least privilege* is the practice of granting the minimum set of permissions that each user needs to perform their tasks. Examples of roles for early-stage startups include administrator, developer, contractor, and finance team member. Create specialized roles as specific job functions are identified.
If you are using federated identities, users access the account by assuming an IAM role through the external identity provider. The IAM role defines the actions that users authenticated by your organization's IdP can perform. Apply custom or AWS managed policies to this role to configure permissions.
**To assign permissions for federated identities using IAM Identity Center**
1. See [Use IAM policies in permission sets](https://docs.aws.amazon.com/singlesignon/latest/userguide/howtocmp.html) in the IAM Identity Center documentation.
1. If you are using an external or third-party IdP, see [Adding IAM identity permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html#add-policies-console) in the IAM documentation.
If you are using IAM users, configure IAM roles for the work your users perform, and have users assume those roles rather than attaching policies directly to individual IAM users. When an IAM user assumes a role, they receive temporary credentials that automatically expire. This reduces the risk of credential exposure compared to policies attached directly to IAM users, which remain in effect until explicitly removed.
# ACCT.05 Require multi-factor authentication to log in
With multi-factor authentication (MFA), users have a device that generates a response to an authentication challenge. Each user's credentials and device-generated response are required to complete the sign-in process. Enable MFA for AWS account access, especially for long-term credentials such as the account root user and IAM users.
**To set up MFA for the root user**
1. Sign in to the [AWS Management Console](https://console.aws.amazon.com/).
1. Choose your account name, and then choose **Security credentials**.
1. On the **Security credentials** page, under **Multi-factor authentication (MFA)**, choose **Assign MFA device**.
1. Follow the steps to configure your MFA device. For more information, see [Multi-factor authentication for AWS account root user](https://docs.aws.amazon.com/IAM/latest/UserGuide/enable-mfa-for-root.html) in the IAM documentation.
**To set up MFA in IAM Identity Center**
1. See [Enable MFA](https://docs.aws.amazon.com/singlesignon/latest/userguide/enable-mfa.html) in the IAM Identity Center documentation.
**To set up MFA for your own IAM user**
1. Sign in to the [IAM console](https://console.aws.amazon.com/iam).
1. Choose your user name, and then choose **Security credentials**.
1. On the **Security credentials** tab, under **Multi-factor authentication (MFA)**, choose **Assign MFA device**.
1. Follow the steps to configure your MFA device. For more information, see [AWS Multi-Factor Authentication in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html) in the IAM documentation.
**To set up MFA for other IAM users**
1. Sign in to the [IAM console](https://console.aws.amazon.com/iam).
1. In the navigation pane, choose **Users**.
1. Choose the name of the user for whom you want to enable MFA, and then choose the **Security credentials** tab.
1. Under **Multi-factor authentication (MFA)**, choose **Assign MFA device**.
1. Follow the steps to configure the MFA device. For more information, see [AWS Multi-Factor Authentication in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html) in the IAM documentation.
# ACCT.06 Enforce a password policy
Users sign in to the AWS Management Console by providing sign-in credentials. AWS recommends requiring MFA for all users. Require that passwords adhere to a strong password policy to help prevent discovery through brute force or social engineering. For more information about password policy recommendations, see the [Password policy guide](https://www.cisecurity.org/insights/white-papers/cis-password-policy-guide) on the Center for Internet Security (CIS) website.
**Note**
For a benchmark-aligned minimum password length, see [AWS Security Hub control IAM.15](https://docs.aws.amazon.com/securityhub/latest/userguide/iam-controls.html#iam-15), which references the CIS AWS Foundations Benchmark recommendation.
For IAM users, configure password requirements by creating a custom IAM password policy. For more information, see [Set an account password policy for IAM users](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html) in the IAM documentation.
**To create a custom password policy**
1. Open the [IAM console](https://console.aws.amazon.com/iam/).
1. In the navigation pane, choose **Account settings**.
1. In the **Password policy** section, choose **Edit**.
1. Choose **Custom** to use a custom password policy.
1. Select the options that you want to apply to your password policy and choose **Save changes**.
1. Confirm that you want to set a custom password policy by choosing **Set custom**.
# ACCT.07 Deliver CloudTrail logs to a protected Amazon S3 bucket
Actions taken by users, roles, and services in your AWS account are recorded as events in AWS CloudTrail. CloudTrail is enabled by default, and in the CloudTrail console, you can access 90 days of event history information. To view, search, download, archive, analyze, and respond to account activity across your AWS infrastructure, see [Viewing events with CloudTrail event history](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html) in theCloudTrail documentation.
To retain CloudTrail history beyond 90 days, create a trail that delivers log files to an Amazon Simple Storage Service (Amazon S3) bucket for all event types. When you create a trail in the CloudTrail console, you create a multi-Region trail.
**To create a trail that delivers logs for all AWS Regions to an Amazon S3 bucket**
1. Open the [CloudTrail console](https://console.aws.amazon.com/cloudtrail/).
1. Follow the steps in [Creating a trail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html) in the CloudTrail documentation. On the **Choose log events **page, do the following:
1. For **API activity**, select both **Read** and **Write**.
1. For the **Exclude AWS KMS events **option, use the following guidance:
+ For preproduction environments, select **Exclude AWS KMS events **to exclude all AWS Key Management Service (AWS KMS) events from your trail. AWS KMS read actions such as `Encrypt`, `Decrypt`, and `GenerateDataKey` can generate a large volume of events.
+ For production environments, select **Write** for management events, and clear the **Read **and **Exclude AWS KMS events **check boxes. This excludes high-volume AWS KMS read events but still logs relevant AWS KMS actions, such as `Disable`, `Delete`, and `ScheduleKey`.
1. If you do not plan to use the Amazon Relational Database Service (Amazon RDS) Data API and want to use CloudTrail for troubleshooting and data access auditing purposes, select **Exclude Amazon RDS Data API events**. The Data API can generate a high volume of CloudTrail events.
After you create the trail, it appears on the **Trails** page. CloudTrail begins publishing log files to the Amazon S3 bucket you specified within approximately 15 minutes.
**Note**
As a cost consideration, you can deliver one copy of your ongoing management events to your Amazon S3 bucket at no charge from CloudTrail by creating a trail. Amazon S3 storage charges apply. For information about Amazon S3 pricing, see [Amazon S3 pricing](https://aws.amazon.com/s3/pricing/).
**To help secure the Amazon S3 buckets where you store CloudTrail log files**
1. Review the [Amazon S3 bucket policy](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/create-s3-bucket-policy-for-cloudtrail.html) in the CloudTrail documentation for each bucket where you store log files, and adjust it as needed to remove unnecessary access.
1. Make sure to add an `aws:SourceArn` condition key to the bucket policy. For more information, see [Create or update an Amazon S3 bucket for an organization trail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-an-organizational-trail-by-using-the-aws-cli.html) in the CloudTrail documentation.
1. To add an additional layer of protection against accidental or unauthorized deletion of log files, see [Configuring MFA delete](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiFactorAuthenticationDelete.html) in the Amazon S3 documentation.
# ACCT.08 Prevent public access to private Amazon S3 buckets
By default, the root user of the AWS account and the IAM principal that created the bucket have permissions to read and write to Amazon S3 buckets. Additional IAM principals are granted access by using identity-based policies, and access conditions can be enforced by using a bucket policy. You can create bucket policies that grant the general public access to the bucket, creating a *public *bucket.
Buckets created on or after April 28, 2023 have the **Block Public Access** setting enabled by default. For buckets created before this date, a misconfigured bucket policy can unintentionally grant public access. You can help prevent this by enabling the **Block Public Access** setting for each bucket. If you have no current or future use cases for a public Amazon S3 bucket, enable this setting at the AWS account level.
**To prevent public access to Amazon S3 buckets**
1. Follow the steps in [Configure block public access settings for your Amazon S3 buckets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/configuring-block-public-access-bucket.html) in the Amazon S3 documentation.
AWS Trusted Advisor generates a yellow finding for Amazon S3 buckets that allow list or read access to the public and generates a red finding for buckets that allow public uploads or deletes. Follow [ACCT.12 Monitor for and resolve AWS Trusted Advisor high-risk items](acct-12.md) to identify and correct misconfigured buckets. In the Amazon S3 console, you can see if your bucket is publicly accessible from the **Buckets** list.
# ACCT.09 Delete unused VPCs, subnets, and security groups
To reduce the opportunity for security issues, delete resources that are not being used. In a new AWS account, by default, a virtual private cloud (VPC) is created automatically in every AWS Region. This enables you to assign public IP addresses in public subnets. If these VPCs are not needed, this introduces risk of unintended exposure of resources.
If they are not in use, delete the default VPCs in each Region, including Regions where you do not plan to deploy workloads. Before you can delete a VPC, you must first delete its dependent resources in the order of their dependencies. For example, delete Amazon Elastic Compute Cloud (Amazon EC2) instances before their subnets, and delete NAT gateways and internet gateways before the VPC. Subnets and security groups are deleted when the VPC is deleted. Attempting to delete a resource that has dependent resources will result in an error.
**Note**
You can view your Regions and VPCs on the [Amazon EC2 Global View console](https://console.aws.amazon.com/ec2globalview/home). For more information, see [List and filter resources across Regions using Amazon EC2 Global View](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Filtering.html#global-view) in the Amazon EC2 documentation.
**To delete a default VPC and its associated resources**
1. See [Delete your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/delete-vpc.html) in the Amazon Virtual Private Cloud (Amazon VPC) documentation.
1. Repeat this process for each Region where default VPCs exist.
# ACCT.10 Configure AWS Budgets to monitor your spending
AWS Budgets enables monitoring of monthly costs and usage with notifications when costs are forecast to exceed target thresholds. Cost forecast notifications can indicate unexpected activity, which adds a layer of monitoring alongside other services, such as Trusted Advisor. Monitoring your AWS costs helps you detect unexpected usage and avoid unplanned charges.
**To set up a budget**
1. See [Create a cost budget](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-create.html) in the AWS Billing and Cost Management documentation.
**Note**
AWS Budgets provides two budgets per account at no charge. For information about the cost of additional budgets, see [AWS Budgets pricing](https://aws.amazon.com/aws-cost-management/pricing/).
# ACCT.11 Enable IAM Access Analyzer
Enable IAM Access Analyzer in each AWS Region you use. Because IAM Access Analyzer operates on a per-Region basis, you must enable it separately in each Region to gain visibility into resource sharing across your AWS footprint. This helps prevent accidental public or cross-account access to resources, such as Amazon S3 buckets, IAM roles, and AWS KMS keys.
**To enable IAM Access Analyzer**
1. Open the [IAM console](https://console.aws.amazon.com/iam/).
1. In the left navigation pane, choose **Access Analyzer**.
1. Choose **Create analyzer**.
1. Enter a name for your analyzer.
1. For the analyzer scope, choose **Account** for a single account, or choose **Organization** if you are using AWS Organizations.
1. Choose **Create analyzer**.
Review the findings in the **Access Analyzer **console and update resource policies to remove unintended external access. For more information, see [Reviewing findings for IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-findings.html) in the IAM documentation. Prioritize high-impact findings, such as public Amazon S3 buckets or IAM roles that are shared outside of your AWS account.
**Note**
IAM Access Analyzer pricing depends on the analyzer type and features you use. An external access analyzer is available at no additional charge. Early-stage startups should start with an external access analyzer. For more information about pricing, see [IAM Access Analyzer pricing](https://aws.amazon.com/iam/access-analyzer/pricing/).
# ACCT.12 Monitor for and resolve AWS Trusted Advisor high-risk items
AWS Trusted Advisor scans your AWS infrastructure for high-risk or high-impact issues related to security, performance, cost, and reliability. It provides detailed information about affected resources and remediation recommendations. For more information about checks and descriptions, see [AWS Trusted Advisor check reference](https://docs.aws.amazon.com/awssupport/latest/user/trusted-advisor-check-reference.html) in the AWS Support documentation. Access to Trusted Advisor checks varies by AWS Support plan.
Basic Support provides access to the following:
+ Checks in the Service Limits category
+ Selected checks in the Security and Fault Tolerance categories, including:
+ Amazon Elastic Block Store (Amazon EBS) public snapshots
+ Amazon Relational Database Service (Amazon RDS) public snapshots
+ Amazon S3 bucket permissions
+ MFA for the root user
+ Security groups that have specific ports unrestricted
+ AWS Security Token Service (AWS STS) global endpoint usage across AWS Regions
Full access to all Trusted Advisor checks requires one of the following paid support plans**:**
+ AWS Business Support\$1
+ AWS Enterprise Support
+ AWS Unified Operations
Review Trusted Advisor findings regularly and remediate issues as they are identified. If you have AWS Business Support\$1, AWS Enterprise Support, or AWS Unified Operations, you can subscribe to a weekly findings email. For more information, [Set up notification preferences](https://docs.aws.amazon.com/awssupport/latest/user/get-started-with-aws-trusted-advisor.html#notification-preferences) in the AWS Support documentation.
**To view Trusted Advisor findings**
1. See [View check categories](https://docs.aws.amazon.com/awssupport/latest/user/get-started-with-aws-trusted-advisor.html) in the AWS Support documentation.
1. Start by reviewing *action recommended* issues, which are marked in red*.*
# ACCT.13 Use short-lived credentials for access to your AWS resources
Determine how your developers access AWS services and resources through the [AWS Command Line Interface (AWS CLI)](https://aws.amazon.com/cli/). To reduce security risk, avoid using IAM users with long-lived access keys for authentication when developing software or working with production data. Short-lived credentials expire automatically, which reduces the risk of credential exposure.
**Choose the approach that matches your current AWS access pattern**
+ [Sign in with console credentials (Recommended)](https://docs.aws.amazon.com/signin/latest/userguide/command-line-sign-in.html#command-line-sign-in-local-development) – If you use root, IAM users, or federation with IAM for AWS account access, use `aws login` to obtain temporary credentials for AWS CLI or AWS SDK access.
+ [Sign in with IAM Identity Center credentials](https://docs.aws.amazon.com/signin/latest/userguide/command-line-sign-in.html#command-line-sign-in-sso) – If you use IAM Identity Center for AWS account access, this approach provides centralized identity management and automatic credential rotation.
+ **Federated access through your corporate identity provider** – Use your organization's existing identity provider, such as Okta, Active Directory, or Ping Identity, with MFA enforcement.
**To obtain temporary AWS CLI credentials using the **`aws`** login**
1. Install or update the AWS CLI. For more information, see [Installing or updating to the latest version of the AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) in the AWS CLI documentation.
1. Enter `aws login` and follow the authentication prompts.
1. Authenticate using your IAM user credentials and MFA.
After you authenticate, the AWS CLI manages temporary credentials for your session. When your session expires, enter `aws login` again to re-authenticate. For information about session duration settings, see [IAM role session duration](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use.html) in the IAM documentation.
For AWS Partner integrations and third-party solutions, use short-lived credentials where possible. [IAM temporary delegation for AWS Partners](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-temporary-delegation-partner-guide.html) allows you integrate AWS Partner products by using short-lived credentials instead of long-lived access keys. [IAM Outbound Identity Federation](https://aws.amazon.com/blogs/aws/simplify-access-to-external-services-using-aws-iam-outbound-identity-federation/) allows AWS workloads to authenticate to external solutions by using short-lived tokens instead of long-lived API keys.