# Security best practices and use cases in AWS Identity and Access Management AWS Identity and Access Management (IAM) offers several security features to consider as you develop and implement your own security policies. The following best practices are general guidelines and don't represent a complete security solution. These best practices may not be appropriate or sufficient for your specific environment. Therefore, treat them as helpful considerations rather than requirements. To get the most out of IAM, take the time to learn the recommended best practices. One effective way to do this is to see how IAM is used in real-world scenarios to work with other AWS services. **Topics** + [ # Security best practices in IAM ](best-practices.md) + [ # Root user best practices for your AWS account ](root-user-best-practices.md) + [ # Business use cases for IAM ](business-use-cases.md) # Security best practices in IAM To help secure your AWS resources, follow these best practices for AWS Identity and Access Management (IAM). **Topics** + [ ## Require human users to use federation with an identity provider to access AWS using temporary credentials ](#bp-users-federation-idp) + [ ## Require workloads to use temporary credentials with IAM roles to access AWS ](#bp-workloads-use-roles) + [ ## Require multi-factor authentication (MFA) ](#enable-mfa-for-privileged-users) + [ ## Update access keys when needed for use cases that require long-term credentials ](#update-access-keys) + [ ## Follow best practices to protect your root user credentials ](#lock-away-credentials) + [ ## Apply least-privilege permissions ](#grant-least-privilege) + [ ## Get started with AWS managed policies and move toward least-privilege permissions ](#bp-use-aws-defined-policies) + [ ## Use IAM Access Analyzer to generate least-privilege policies based on access activity ](#bp-gen-least-privilege-policies) + [ ## Regularly review and remove unused users, roles, permissions, policies, and credentials ](#remove-credentials) + [ ## Use conditions in IAM policies to further restrict access ](#use-policy-conditions) + [ ## Verify public and cross-account access to resources with IAM Access Analyzer ](#bp-preview-access) + [ ## Use IAM Access Analyzer to validate your IAM policies to ensure secure and functional permissions ](#best-practice-policy-validation) + [ ## Establish permissions guardrails across multiple accounts ](#bp-permissions-guardrails) + [ ## Use permissions boundaries to delegate permissions management within an account ](#bp-permissions-boundaries) ## Require human users to use federation with an identity provider to access AWS using temporary credentials Human users, also known as *human identities,* are the people, administrators, developers, operators, and consumers of your applications. They must have an identity to access your AWS environments and applications. Human users that are members of your organization are also known as *workforce identities.* Human users can also be external users with whom you collaborate, and who interact with your AWS resources. They can do this via a web browser, client application, mobile app, or interactive command-line tools. Require your human users to use temporary credentials when accessing AWS. You can use an identity provider for your human users to provide federated access to AWS accounts by assuming roles, which provide temporary credentials. For centralized access management, we recommend that you use [AWS IAM Identity Center (IAM Identity Center)](https://docs.aws.amazon.com/singlesignon/latest/userguide/getting-started.html) to manage access to your accounts and permissions within those accounts. You can manage your user identities with IAM Identity Center, or manage access permissions for user identities in IAM Identity Center from an external identity provider. For more information, see [What is AWS IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) in the *AWS IAM Identity Center User Guide*. For more information about roles, see [Roles terms and concepts](id_roles.md#id_roles_terms-and-concepts). ## Require workloads to use temporary credentials with IAM roles to access AWS A *workload* is a collection of resources and code that delivers business value, such as an application or backend process. Your workload can have applications, operational tools, and components that require credentials to make requests to AWS services, such as requests to read data from Amazon S3. When you're building on an AWS compute service, such as Amazon EC2 or Lambda, AWS delivers the temporary credentials of an IAM role to that compute resource. Applications written using an AWS SDK will discover and use these temporary credentials to access AWS resources, and there is no need to distribute long lived credentials for an IAM user to your workloads running on AWS. Workloads that run on outside of AWS, such as your on-premises servers, servers from other cloud providers, or managed continuous integration and continuous delivery (CI/CD) platforms, can still use temporary credentials. However, you'll need to deliver these temporary credentials to your workload. The following are ways you can deliver temporary credentials to your workloads: + You can use IAM Roles Anywhere to request temporary AWS credentials for your workload using an X.509 Certificate from your public key infrastructure (PKI). + You can call the AWS AWS STS`AssumeRoleWithSAML` API to request temporary AWS credentials for your workload using a SAML assertion from an external identity provider (IdP) that is configured within your AWS account. + You can call the AWS AWS STS `AssumeRoleWithWebIdentity` API to request temporary AWS credentials for your workload using a JSON web token (JWT) from an IdP that is configured within your AWS account. + You can request temporary AWS credentials from your IoT device using Mutual Transport Layer Security (MTLS) authentication using AWS IoT Core. Some AWS services also support integrations to deliver temporary credentials to your workloads running outside of AWS: + [Amazon Elastic Container Service (Amazon ECS) Anywhere](https://aws.amazon.com/ecs/anywhere/) lets you run Amazon ECS tasks on your own compute resources, and delivers temporary AWS credentials to your Amazon ECS tasks running on those compute resources. + [Amazon Elastic Kubernetes Service Hybrid Nodes](https://docs.aws.amazon.com/eks/latest/userguide/hybrid-nodes-overview.html) lets you join your compute resources running outside of AWS as nodes to an Amazon EKS cluster. Amazon EKS can deliver temporary credentials to the Amazon EKS pods running on your compute resources. + [AWS Systems ManagerHybrid Activations](https://docs.aws.amazon.com/systems-manager/latest/userguide/activations.html) lets you manage your compute resources running outside of AWS using SSM, and delivers temporary AWS credentials to the SSM agent running on your compute resources. ## Require multi-factor authentication (MFA) We recommend using IAM roles for human users and workloads that access your AWS resources so that they use temporary credentials. However, for scenarios in which you need an IAM user or root user in your account, require MFA for additional security. With 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. For more information, see [AWS Multi-factor authentication in IAM](id_credentials_mfa.md). We recommend that you use phishing-resistant MFA such as passkeys and security keys wherever possible. For more information, see [Assign a passkey or security key in the AWS Management Console](id_credentials_mfa_enable_fido.md). If you use IAM Identity Center for centralized access management for human users, you can use the IAM Identity Center MFA capabilities when your identity source is configured with the IAM Identity Center identity store, AWS Managed Microsoft AD, or AD Connector. For more information about MFA in IAM Identity Center see [Multi-factor authentication](https://docs.aws.amazon.com/singlesignon/latest/userguide/enable-mfa.html) in the *AWS IAM Identity Center User Guide*. ## Update access keys when needed for use cases that require long-term credentials 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, we recommend that you update the access keys when needed, such as when an employee leaves your company. We recommend that you use *IAM access last used information* to update and remove access keys safely. For more information, see [Update access keys](id-credentials-access-keys-update.md). There are specific use cases that require long-term credentials with IAM users in AWS. Some of the use cases include the following: + **Workloads that cannot use IAM roles** – You might run a workload from a location that needs to access AWS. In some situations, you can't use IAM roles to provide temporary credentials, such as for WordPress plugins. In these situations, use IAM user long-term access keys for that workload to authenticate to AWS. + **Third-party AWS clients** – If you are using tools that don’t support access with IAM Identity Center, such as third-party AWS clients or vendors that are not hosted on AWS, use IAM user long-term access keys. + **AWS CodeCommit access** – If you are using CodeCommit to store your code, you can use an IAM user with either SSH keys or service-specific credentials for CodeCommit to authenticate to your repositories. We recommend that you do this in addition to using a user in IAM Identity Center for normal authentication. Users in IAM Identity Center are the people in your workforce who need access to your AWS accounts or to your cloud applications. To give users access to your CodeCommit repositories without configuring IAM users, you can configure the **git-remote-codecommit** utility. For more information about IAM and CodeCommit, see [IAM credentials for CodeCommit: Git credentials, SSH keys, and AWS access keys](id_credentials_ssh-keys.md). For more information about configuring the **git-remote-codecommit** utility, see [Connecting to AWS CodeCommit repositories with rotating credentials](https://docs.aws.amazon.com/codecommit/latest/userguide/temporary-access.html#temporary-access-configure-credentials) in the *AWS CodeCommit User Guide*. + **Amazon Keyspaces (for Apache Cassandra) access** – In a situation where you are unable to use users in IAM Identity Center, such as for testing purposes for Cassandra compatibility, you can use an IAM user with service-specific credentials to authenticate with Amazon Keyspaces. Users in IAM Identity Center are the people in your workforce who need access to your AWS accounts or to your cloud applications. You can also connect to Amazon Keyspaces using temporary credentials. For more information, see [Using temporary credentials to connect to Amazon Keyspaces using an IAM role and the SigV4 plugin](https://docs.aws.amazon.com/keyspaces/latest/devguide/access.credentials.html#temporary.credentials.IAM) in the *Amazon Keyspaces (for Apache Cassandra) Developer Guide*. ## Follow best practices to protect your root user credentials When you create an AWS account, you establish root user credentials to sign in to the AWS Management Console. Safeguard your root user credentials the same way you would protect other sensitive personal information. To better understand how to secure and scale your root user processes, see [Root user best practices for your AWS account](root-user-best-practices.md). ## Apply least-privilege permissions When you set permissions with IAM policies, 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, also known as *least-privilege permissions*. You might start with broad permissions while you explore the permissions that are required for your workload or use case. As your use case matures, you can work to reduce the permissions that you grant to work toward least privilege. For more information about using IAM to apply permissions, see [Policies and permissions in AWS Identity and Access Management](access_policies.md). ## Get started with AWS managed policies and move toward least-privilege permissions To get started granting permissions to your users and workloads, use the *AWS managed policies* that grant permissions for many common use cases. They 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) that are specific to your use cases. For more information, see [AWS managed policies](access_policies_managed-vs-inline.md#aws-managed-policies). For more information about AWS managed policies that are designed for specific job functions, see [AWS managed policies for job functions](access_policies_job-functions.md). ## Use IAM Access Analyzer to generate least-privilege policies based on access activity To grant only the permissions required to perform a task, you can generate policies based on your access activity that is logged in AWS CloudTrail. [IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) analyzes the services and actions that your IAM roles use, and then generates a fine-grained policy that you can use. After you test each generated policy, you can deploy the policy to your production environment. This ensures that you grant only the required permissions to your workloads. For more information about policy generation, see [IAM Access Analyzer policy generation](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html). ## Regularly review and remove unused users, roles, permissions, policies, and credentials You might have IAM users, roles, permissions, policies, or credentials that you no longer need in your AWS account. IAM provides *last accessed information* to help you identify the users, roles, permissions, policies, and 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. You can also use this information to refine your IAM policies to better adhere to least-privilege permissions. For more information, see [Refine permissions in AWS using last accessed information](access_policies_last-accessed.md). ## Use conditions in IAM policies to further restrict access You can specify conditions under which a policy statement is in effect. That way, you can grant access to actions and resources, but only if the access request meets specific conditions. For example, you can write a policy condition to specify that all requests must be sent using TLS. You can also use conditions to grant access to service actions, but only if they are used through a specific AWS service, such as CloudFormation. For more information, see [IAM JSON policy elements: Condition](reference_policies_elements_condition.md). ## Verify public and cross-account access to resources with IAM Access Analyzer Before you grant permissions for public or cross-account access in AWS, we recommend that you verify if such access is required. You can use IAM Access Analyzer to help you preview and analyze public and cross-account access for supported resource types. You do this by reviewing the [findings](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-findings.html) that IAM Access Analyzer generates. These findings help you verify that your resource 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-preview-access-apis.html). ## Use IAM Access Analyzer to validate your IAM policies to ensure secure and functional permissions Validate the policies you create to ensure that they adhere to the [IAM policy language](access_policies.md#access_policies-json) (JSON) and IAM best practices. You can validate your policies by using IAM Access Analyzer policy validation. 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html). For more information about policy checks provided by IAM Access Analyzer, see [IAM Access Analyzer policy check reference](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-reference-policy-checks.html). ## Establish permissions guardrails across multiple accounts As you scale your workloads, separate them by using multiple accounts that are managed with AWS Organizations. We recommend that you use AWS Organizations [service control policies](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) (SCPs) to establish permissions guardrails to control access for all principals (IAM roles and users) across your accounts. We recommend that you use AWS Organizations [resource control policies](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) (RCPs) to establish permissions guardrails to control access for AWS resources across your organization. SCPs and RCPs are types of organization policies that you can use to manage permissions in your organization at the AWS organization, organizational unit (OU), or account level. However, SCPs and RCPs alone are insufficient to grant permissions to principals and resources in your organization. No permissions are granted by SCPs and RCPs. To grant permissions, you must attach [identity-based or resource-based policies](access_policies_identity-vs-resource.md) to IAM users, IAM roles, or the resources in your accounts. For more information, see [SRA building blocks — AWS Organizations, accounts, and guardrails](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/organizations.html). ## Use permissions boundaries to delegate permissions management within an account In some scenarios, you might want to delegate permissions management within an account to others. For example, you could allow developers to create and manage roles for their workloads. When you delegate permissions to others, use *permissions boundaries* to set the maximum permissions that you delegate. A permissions boundary is an advanced feature for using 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](access_policies_boundaries.md). # Root user best practices for your AWS account When you first create an AWS account, you begin with a default set of credentials with complete access to all AWS resources in your account. This identity is called the [AWS account root user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html). We strongly recommend you don’t access the AWS account root user unless you have a [task that requires root user credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/root-user-tasks.html#root-user-tasks). You need to secure your root user credentials and your account recovery mechanisms to help ensure you don’t expose your highly privileged credentials for unauthorized use. For multiple AWS accounts managed through AWS Organizations, we recommend removing root user credentials from member accounts to help prevent unauthorized use. You can remove the root user password, access keys, signing certificates, and deactivate and delete multi-factor authentication (MFA). Member accounts can't sign in to their root user or perform password recovery for their root user. For more information, see [Centrally manage root access for member accounts](id_root-user.md#id_root-user-access-management). Instead of accessing the root user, create an administrative user for everyday tasks. + If you have a new AWS account, see [Setting up your AWS account](getting-started-account-iam.md). + For multiple AWS accounts managed through AWS Organizations, see [Set up AWS account access for an IAM Identity Center administrative user](https://docs.aws.amazon.com/singlesignon/latest/userguide/get-started-assign-account-access-admin-user.html). With your administrative user, you can then create additional identities for users that need access to resources in your AWS account. We strongly recommend you require users to authenticate with temporary credentials when accessing AWS. + For a single, standalone AWS account, use [IAM roles](id_roles.md) to create identities in your account with specific permissions. Roles are intended to be assumable by anyone who needs it. Also, a role does not have standard long-term credentials, such as a password or access keys, associated with it. Instead, when you assume a role, it provides you with temporary security credentials for your role session. Unlike IAM roles, [IAM users](id_users.md) have long-term credentials such as passwords and access keys. Where possible, [best practices](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices-use-cases.html) recommend relying on temporary credentials instead of creating IAM users who have long-term credentials such as passwords and access keys. + For multiple AWS accounts managed through AWS Organizations, use IAM Identity Center workforce users. With IAM Identity Center, you can centrally manage users across your AWS accounts and permissions within those accounts. Manage your user identities with IAM Identity Center or from an external identity provider. For more information, see [What is AWS IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) in the *AWS IAM Identity Center User Guide*. **Topics** + [ ## Secure your root user credentials to prevent unauthorized use ](#ru-bp-secure) + [ ## Use a strong root user password to help protect access ](#ru-bp-password) + [ ## Secure your root user sign-in with multi-factor authentication (MFA) ](#ru-bp-mfa) + [ ## Don't create access keys for the root user ](#ru-bp-access) + [ ## Use multi-person approval for root user sign-in wherever possible ](#ru-bp-multi) + [ ## Use a group email address for root user credentials ](#ru-bp-group) + [ ## Restrict access to account recovery mechanisms ](#ru-bp-recovery) + [ ## Secure your AWS Organizations account root user credentials ](#ru-bp-organizations) + [ ## Monitor access and usage ](#ru-bp-monitor) ## Secure your root user credentials to prevent unauthorized use Secure your root user credentials and use them for only [the tasks that require them](https://docs.aws.amazon.com/IAM/latest/UserGuide/root-user-tasks.html). To help prevent unauthorized use, don’t share your root user password, MFA, access keys, CloudFront key pairs, or signing certificates with anyone, except those that have a strict business need to access the root user. Don't store the root user password with tools that depend on AWS services in an account that is accessed using that same password. If you lose or forget your root user password, you will not be able to access these tools. We recommend that you prioritize resiliency and consider requiring two or more people to authorize access to the storage location. Access to the password or its storage location should be logged and monitored. ## Use a strong root user password to help protect access We recommend that you use a password that is strong and unique. Tools such as password managers with strong password generation algorithms can help you achieve these goals. AWS requires that your password meet the following conditions: + It must have a minimum of 8 characters and a maximum of 128 characters. + It must include a minimum of three of the following mix of character types: uppercase, lowercase, numbers, and \$1 @ \$1 \$1 % ^ & \$1 () <> [] \$1\$1 \$1 \$1\$1-= symbols. + It must not be identical to your AWS account name or email address. For more information, see [Change the password for the AWS account root user](root-user-password.md). ## Secure your root user sign-in with multi-factor authentication (MFA) Because a root user can perform privileged actions, it's crucial to add MFA for the root user as a second authentication factor in addition to the email address and password as sign-in credentials. You can register up to eight MFA devices of any combination of the currently supported MFA types with your AWS account root user. We strongly recommend enabling multiple MFA devices for your root user credentials to provide additional flexibility and resiliency in your security strategy. All AWS account types (standalone, management, and member accounts) require MFA to be configured for their root user. Users must register MFA within 35 days of their first sign-in attempt to access the AWS Management Console if MFA is not already enabled. + FIDO Certified hardware security keys are provided by third-party providers. For more information, see [Enable a FIDO security key for the AWS account root user](https://docs.aws.amazon.com/IAM/latest/UserGuide/enable-fido-mfa-for-root.html). + A hardware device that generates a six-digit numeric code based on the time-based one-time password (TOTP) algorithm. For more information, see [Enable a hardware TOTP token for the AWS account root user](https://docs.aws.amazon.com/IAM/latest/UserGuide/enable-hw-mfa-for-root.html). + A virtual authenticator application that runs on a phone or other device and emulates a physical device. For more information, see [Enable a virtual MFA device for your AWS account root user](https://docs.aws.amazon.com/IAM/latest/UserGuide/enable-virt-mfa-for-root.html). ## Don't create access keys for the root user Access keys let you run commands in the AWS Command Line Interface (AWS CLI) or use API operations from one of the AWS SDKs. We strongly recommend that you do not create access keys for your root user because the root user has full access to all AWS services and resources in the account, including billing information. Since only a few tasks require the root user and you typically perform those tasks infrequently, we recommend signing in to the AWS Management Console to perform root user tasks. For programmatic access, instead of creating access keys for the root user, use the `aws login` command with your root credentials to authenticate to the AWS CLI and SDKs. This approach provides temporary, automatically rotated credentials that enhance your security posture while eliminating the need to manage long-term access keys. Before creating access keys, review the [Alternatives to long-term access keys](security-creds-programmatic-access.md#security-creds-alternatives-to-long-term-access-keys). ## Use multi-person approval for root user sign-in wherever possible Consider using multi-person approval to ensure that no one person can access both MFA and password for the root user. Some companies add an additional layer of security by setting up one group of administrators with access to the password, and another group of administrators with access to MFA. One member from each group must come together to sign in as the root user. ## Use a group email address for root user credentials Use an email address that is managed by your business and forwards received messages directly to a group of users. If AWS must contact the owner of the account, this approach reduces the risk of delays in responding, even if individuals are on vacation, out sick, or have left the business. The email address used for the root user should not be used for other purposes. ## Restrict access to account recovery mechanisms Ensure you develop a process to manage root user credential recovery mechanisms in case you need access to it during emergency such as takeover of your administrative account. + Ensure you have access to your root user email inbox so that you can [reset a lost or forgotten root user password](https://docs.aws.amazon.com/IAM/latest/UserGuide/reset-root-password.html). + If MFA for your AWS account root user is lost, damaged, or not working, you can sign in using another MFA registered to the same root user credentials. If you lost access to all your MFAs, you need both the phone number and the email used to register your account, to be up to date and accessible to recover your MFA. For details, see [Recovering a root user MFA device](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_lost-or-broken.html#root-mfa-lost-or-broken). + If you choose not to store your root user password and MFA, then the phone number registered in your account can be used as an alternate way to recover root user credentials. Ensure you have access to the contact phone number, keep the phone number updated, and limit who has access to manage the phone number. No one person should have access to both the email inbox and phone number since both are verification channels to recover your root user password. It is important to have two groups of individuals managing these channels. One group having access to your primary email address and another group having access to the primary phone number to recover access to your account as root user. ## Secure your AWS Organizations account root user credentials As you move to a multi-account strategy with AWS Organizations, each of your AWS accounts has its own root user credentials that you need to secure. The account you use to create your organization is the **management account** and the rest of the accounts in your organization are **member accounts**. ### Secure root user credentials for the management account AWS requires that you register MFA for the root user of your organization's management account. MFA registration must be completed during the first sign-in attempt or within the 35-day grace period. If MFA is not enabled within this time, registration will be required before you can access the AWS Management Console. For more information, see [Multi-factor authentication for AWS account root user](enable-mfa-for-root.md). ### Secure root user credentials for member accounts If you use AWS Organizations to manage multiple accounts, there are two strategies that you can take to secure root user access in your AWS Organizations. + Centralize root access and remove root user credentials from member accounts. Remove the root user credentials, access keys, signing certificates, and deactivate and delete multi-factor authentication (MFA). When this strategy is used, member accounts can't sign in to their root user or perform password recovery for their root user. For more information, see [Centrally manage root access for member accounts](id_root-user.md#id_root-user-access-management). + Secure root user credentials of your AWS Organizations accounts with MFA to enhance account security. For more information, see [Multi-factor authentication for AWS account root user](enable-mfa-for-root.md). For details, see [Accessing member accounts in your organization](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_access.html) in the *AWS Organizations User Guide*. ### Set preventative security controls in AWS Organizations using a service control policy (SCP) If the member accounts in your organization have root user credentials enabled, you can apply an SCP to restrict access to member account root user. Denying all root user actions in your member accounts, except for certain root-only actions, helps prevent unauthorized access. For details, see [Use an SCP to restrict what the root user in your member accounts can do](https://docs.aws.amazon.com/organizations/latest/userguide/best-practices_member-acct.html#bp_member-acct_use-scp). ## Monitor access and usage We recommend you use your current tracking mechanisms to monitor, alert, and report the sign in and use of root user credentials, including alerts that announce root user sign-in and usage. The following services can help to ensure that root user credential usage is tracked and perform security checks that can help prevent unauthorized use. **Note** CloudTrail logs different sign-in events for the root user and privileged root user sessions. These privileged sessions allow tasks that require root user credentials to be performed in member accounts in your organization. You can use the sign-in event to identify the actions taken by the management account or a delegated administrator using [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoot.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoot.html). For more information, see [Track privileged tasks in CloudTrail](cloudtrail-track-privileged-tasks.md). + If you want to be notified about root user sign-in activity in your account, you can leverage Amazon CloudWatch to create an Events rule that detects when root user credentials are used and triggers a notification to your security administrator. For details, see [Monitor and notify on AWS account root user activity](https://aws.amazon.com/blogs/mt/monitor-and-notify-on-aws-account-root-user-activity/). + If you want to set up notifications to alert you of approved root user actions, you can leverage Amazon EventBridge along with Amazon SNS to write an EventBridge rule to track root user usage for the specific action and notify you using an Amazon SNS topic. For an example, see [Send a notification when an Amazon S3 object is created](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-s3-object-created-tutorial.html). + If you already using GuardDuty as your threat detection service, you can [extend its capability](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html#policy-iam-rootcredentialusage) to notify you when root user credentials are being used in your account. Alerts should include, but not be limited to, the email address for the root user. Have procedures in place for how to respond to alerts so that personnel who receive a root user access alert understand how to validate that root user access is expected, and how to escalate if they believe that a security incident is in progress. For an example of how to configure alerts, see [Monitor and notify on AWS account root user activity](https://aws.amazon.com/blogs/mt/monitor-and-notify-on-aws-account-root-user-activity/). ### Evaluate root user MFA compliance The following services can help evaluate MFA compliance for root user credentials. **MFA-related rules return noncompliant if you follow the best practice of removing root user credentials.** We recommend removing root user credentials from member accounts in your organization to help prevent unauthorized use. After you remove root user credentials, including MFA, these member accounts are evaluated as **not applicable**. + AWS Config provides rules to monitor compliance with root user best practices. You can use AWS Config managed rules to help you [enforce MFA for root user credentials](https://docs.aws.amazon.com/config/latest/developerguide/root-account-mfa-enabled.html). AWS Config can also [identify access keys for the root user](https://docs.aws.amazon.com/config/latest/developerguide/iam-root-access-key-check.html). + Security Hub CSPM provides you with a comprehensive view of your security state in AWS and helps you assess your AWS environment against security industry standards and best practices, such as having MFA on the root user and not having root user access keys. For details on the rules available, see [AWS Identity and Access Management controls](https://docs.aws.amazon.com/securityhub/latest/userguide/iam-controls.html#iam-4) in the *Security Hub CSPM User Guide*. + Trusted Advisor provides a security check so you know if MFA isn't enabled on the root user account. For more information, see [MFA on Root Account](https://docs.aws.amazon.com/awssupport/latest/user/security-checks.html#mfa-root-account) in the *AWS Support User Guide*. If you need to report a security issue on your account, see [Report Suspicious Emails](https://aws.amazon.com/security/report-suspicious-emails/) or [Vulnerability Reporting](https://aws.amazon.com/security/vulnerability-reporting/). Alternatively, you can [Contact AWS](https://aws.amazon.com/contact-us/) for assistance and additional guidance. # Business use cases for IAM A simple business use case for IAM can help you understand basic ways you might implement the service to control the AWS access that your users have. The use case is described in general terms, without the mechanics of how you'd use the IAM API to achieve the results you want. This use case looks at two typical ways a fictional company called Example Corp might use IAM. The first scenario considers Amazon Elastic Compute Cloud (Amazon EC2). The second considers Amazon Simple Storage Service (Amazon S3). For more information about using IAM with other services from AWS, see [AWS services that work with IAM](reference_aws-services-that-work-with-iam.md). **Topics** + [ ## Initial setup of example corp ](#InitSetupExampleCorp_IAM) + [ ## Use case for IAM with Amazon EC2 ](#UseCase_EC2) + [ ## Use case for IAM with Amazon S3 ](#UseCase_S3) ## Initial setup of example corp Nikki Wolf and Mateo Jackson are the founders of Example Corp. Upon starting the company, they create an AWS account and set up AWS IAM Identity Center (IAM Identity Center) to create administrative accounts to use with their AWS resources. When you set up account access for the administrative user, IAM Identity Center creates a corresponding IAM role. This role, which is controlled by IAM Identity Center, is created in the relevant AWS account, and the policies specified in the **AdministratorAccess** permission set are attached to the role. Since they now have administrator accounts, Nikki and Mateo no longer need to use their root user to access their AWS account. They plan to only use the root user to complete the tasks that only the root user can perform. After reviewing the security best practices they configure multi-factor authentication (MFA) for their root user credentials and decide how to safeguard their root user credentials. As their company grows, they hire employees to work as developers, admins, testers, managers, and system administrators. Nikki is in charge of operations, while Mateo manages the engineering teams. They set up an Active Directory Domain Server to manage the employees accounts and manage access to internal company resources. To give their employees access to AWS resources, they use IAM Identity Center to connect their company's Active Directory to their AWS account. Because they connected Active Directory to IAM Identity Center, the users, group, and group membership are synchronized and defined. They must assign permission sets and roles to the different groups to give the users the correct level of access to AWS resources. They use [AWS managed policies for job functions](access_policies_job-functions.md) in the AWS Management Console to create these permissions sets: + *Administrator* + *Billing* + *Developers* + *Network administrators* + *Database administrators* + *System administrators* + *Support users* Then they assign these permissions sets to the roles assigned to their Active Directory groups. For a step-by-step guide describing the initial configuration of IAM Identity Center, see [Getting started](https://docs.aws.amazon.com/singlesignon/latest/userguide/get-started-assign-account-access-admin-user.html) in the *AWS IAM Identity Center User Guide*. For more information about provisioning IAM Identity Center user access, see [Single sign-on access to AWS accounts](https://docs.aws.amazon.com/singlesignon/latest/userguide/useracces.html) in the *AWS IAM Identity Center User Guide*. ## Use case for IAM with Amazon EC2 A company like Example Corp typically uses IAM to interact with services like Amazon EC2. To understand this part of the use case, you need a basic understanding of Amazon EC2. For more information about Amazon EC2, go to the [Amazon EC2 User Guide](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/). ### Amazon EC2 permissions for the user groups To provide "perimeter" control, Nikki attaches a policy to the AllUsers user group. This policy denies any AWS request from a user if the originating IP address is outside Example Corp's corporate network. At Example Corp, different IAM groups require different permissions: + **System administrators** – Need permission to create and manage AMIs, instances, snapshots, volumes, security groups, and so on. Nikki attaches the `AmazonEC2FullAccess` AWS managed policy to the SysAdmins user group that gives members of the group permission to use all the Amazon EC2 actions. + **Developers** – Need the ability to work with instances only. Mateo therefore creates and attaches a policy to the Developers user group that allows developers to call `DescribeInstances`, `RunInstances`, `StopInstances`, `StartInstances`, and `TerminateInstances`. **Note** Amazon EC2 uses SSH keys, Windows passwords, and security groups to control who has access to the operating system of specific Amazon EC2 instances. There's no method in the IAM system to allow or deny access to the operating system of a specific instance. + **Support users** – Should not be able to perform any Amazon EC2 actions except listing the Amazon EC2 resources currently available. Therefore, Nikki creates and attaches a policy to the Support users group that only lets them call Amazon EC2 "Describe" API operations. For examples of what these policies might look like, see [Example IAM identity-based policies](access_policies_examples.md) and [Using AWS Identity and Access Management](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/index.html?UsingIAM.html) in the *Amazon EC2 User Guide*. ### User's job function change At some point, one of the developers, Paulo Santos, changes job functions and becomes a manager. As a manager, Paulo becomes part of the Support users group so that he can open support cases for his developers. Mateo moves Paulo from the Developers user group to the Support users group. As a result of this move, his ability to interact with Amazon EC2 instances is limited. He can't launch or start instances. He also can't stop or terminate existing instances, even if he was the user who launched or started the instance. He can list only the instances that Example Corp users have launched. ## Use case for IAM with Amazon S3 Companies like Example Corp would also typically use IAM with Amazon S3. John has created an Amazon S3 bucket for the company called *amzn-s3-demo-bucket*. ### Creation of other users and user groups As employees, Zhang Wei and Mary Major each need to be able to create their own data in the company's bucket. They also need to read and write shared data that all developers work on. To enable this, Mateo logically arranges the data in amzn-s3-demo-bucket using an Amazon S3 key prefix scheme as shown in the following figure. ``` /amzn-s3-demo-bucket /home /zhang /major /share /developers /managers ``` Mateo divides the `/amzn-s3-demo-bucket` into a set of home directories for each employee, and a shared area for groups of developers and managers. Now Mateo creates a set of policies to assign permissions to the users and user groups: + **Home directory access for Zhang** – Mateo attaches a policy to Wei that lets him read, write, and list any objects with the Amazon S3 key prefix `/amzn-s3-demo-bucket/home/zhang/` + **Home directory access for Major** – Mateo attaches a policy to Mary that lets her read, write, and list any objects with the Amazon S3 key prefix `/amzn-s3-demo-bucket/home/major/` + **Shared directory access for the developers user group** – Mateo attaches a policy to the user group that lets developers read, write, and list any objects in `/amzn-s3-demo-bucket/share/developers/` + **Shared directory access for the managers user group** – Mateo attaches a policy to the user group that lets managers read, write, and list objects in `/amzn-s3-demo-bucket/share/managers/` **Note** Amazon S3 doesn't automatically give a user who creates a bucket or object permission to perform other actions on that bucket or object. Therefore, in your IAM policies, you must explicitly give users permission to use the Amazon S3 resources they create. For examples of what these policies might look like, see [Access Control](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingAuthAccess.html) in the *Amazon Simple Storage Service User Guide*. For information on how policies are evaluated at runtime, see [Policy evaluation logic](reference_policies_evaluation-logic.md). ### User's job function change At some point, one of the developers, Zhang Wei, changes job functions and becomes a manager. We assume that he no longer needs access to the documents in the `share/developers` directory. Mateo, as an admin, moves Wei to the `Managers` user group and out of the `Developers` user group. With just that simple reassignment, Wei automatically gets all permissions granted to the `Managers` user group, but can no longer access data in the `share/developers` directory. ### Integration with a third-party business Organizations often work with partner companies, consultants, and contractors. Example Corp has a partner called the Widget Company, and a Widget Company employee named Shirley Rodriguez needs to put data into a bucket for Example Corp's use. Nikki creates a user group called *WidgetCo* and a user named `Shirley` and adds Shirley to the WidgetCo user group. Nikki also creates a special bucket called *amzn-s3-demo-bucket1* for Shirley to use. Nikki updates existing policies or adds new ones to accommodate the partner Widget Company. For example, Nikki can create a new policy that denies members of the WidgetCo user group the ability to use any actions other than write. This policy would be necessary only if there's a broad policy that gives all users access to a wide set of Amazon S3 actions.