Guidance for Identity Management & Access Control on AWS

Implementation Resources

• Represent and organize identities and roles in the environment

  • Scenario
  • Overview
  • Implementation

  • Scenario
  • Represent and organize identities and roles in the environment

    • Define roles to manage the environment
    • Provide access to third parties/partner/vendors/auditors
    • Define an Identity framework for operational tooling
  • Overview

  • When establishing your environment, it is important to establish a common set of functional user roles in your environment. These roles will allow you to manage your overall infrastructure. The following list provides roles which should be deployed across your environment:

    • The Environment administrator manages the overall environment, creates isolated group of resources, sets guardrails, and delegates the administration of different services to the appropriate isolated group of resources and teams.
    • The Network administrator manages the network. They will have access to create and configure network topologies, DNS, VPNs, and build network security across your environment. Network administrators are responsible to secure the network and distribute resources workloads can be provisioned.
    • The Directory Services administrator manages access to the environment. This function creates, updates, deletes, assigns, and removes access from different users to the environment.
    • The Security administrator manages security services and tools across your environment, ensuring all your services and workloads are running on a secured infrastructure, and they have access to the environment to remediate any possible security threat.
    • The Billing administrator manages the spend of your environment and creates budgets and alerts based on the forecasting of your expenses. They are also responsible to pay the invoice for your environment.
    • The Read Only Security this function is used monitor the environment. Security administrators can use this role to oversee the environment in real time and interact with the different security tools, without having explicit access to the environment
    • The Security Audit is an exclusively read only role intended to grant access to external or internal auditors that need to examine the environment.
    • The Log Storage administrator manages the log storage in your environment. This function creates or updates the resources needed to security and immutably store your logs, and manages the environment when changes need to be applied.
    • The Shared Services administrator manages all the shared services across the environment. For example, this function is used to set up a central DNS or a central template management function.
    • The Support role has access to read only permissions for the infrastructure and not data within each of the isolated group of resources in the environment. This will allow the cloud team to help troubleshoot the environment, and the workload infrastructure when deployed, helping the team solve any issues with their environment or internal workflows. When necessary, this role can be used to escalate and find a resolution with your cloud service provider.

    These functions with the appropriate permissions and boundaries should be assigned to the user groups which job family needs to perform tasks related to the roles above. This will allow them to access, monitor, operate, update, and secure the environment as needed to meet your business requirements. These functions represent responsibilities within your cloud environment, and multiple functions can be assumed by the same team or person.

    To achieve this, you need to build isolation boundaries to limit the access from each group to the services and tools needed to build, deploy, and operate. In some cases, these groups will need to work together to establish a connection to consume services between the boundaries isolating the resources, to create a cohesive environment that is secure and scalable, and provide access to these services to workloads or other foundational services within the environment.
    

  • Implementation

  • It is important to define and document the standard roles that will be used to manage the environment.

    We recommend that you develop a standard naming convention for the functional roles and document the required roles. These functional roles will be used to create the IAM Identity Center Groups to grant appropriate access to users. Below is a list of recommended functions and group names.

    • Support-Users - This function can authenticate into the AWS Management account and have cross-account access to support all the AWS Organizations member accounts to troubleshoot, offer solutions, and escalate to AWS Support.
    • MA-Billing-Administrators - This functional role can access the AWS Management account and manage billing details for the AWS Cost Explorer and Billing services. The group has permissions to the Cost and Usage Report S3 buckets that allow AWS Cost and Usage Reports to be generated.
    • MA-Billing-ReadOnly-Users - This functional role allows members to access the AWS Management account and view billing details for the AWS Cost Explorer and Billing service.
    • Organization-Administrators - This functional role allows members to access the AWS Management account and have full privileges to manage AWS Organization service.
    • Organization-ReadOnly-Users - This functional role allows members to access the AWS Management account with Organization read-only access to view the AWS Organization service configurations.
    • Security-Auditors - This functional role allows members to have access to all AWS accounts in the AWS Organization for the security auditor and read-only group within the environment.
    • SecurityTooling-Administrators - This functional role allows members to access the AWS Security Tooling account with administrative access.
    • SecurityTooling-ReadOnly-Users - This functional role allows members to access the AWS Security Tooling account with read-only access. All SecurityTooling-Administrators should be a part of this group.
    • IAMIdentityCenter-Administrators - This functional role allows members to manage AWS Organizations member accounts and cloud applications within IAM Identity Center console in the AWS Management account.
    • IAMIdentityCenter-ReadOnly-Users - This functional role has read-only access to IAM Identity Center service in the AWS Management account. All IAM Identity Center-Administrators should be a part of this group.

• Enable preventative access controls across the environment

  • Scenario
  • Overview
  • Implementation

  • Scenario
  • Enable preventative access controls across the environment

    • Deploy preventative controls to protect isolated group of resources in the core infrastructure
    • Deploy preventative controls on groups of resources based on security and operational needs
  • Overview

  • Only granting permissions does not guarantee that the environment is fully secured. To ensure that only the intended services or functions are permitted by the assigned roles, you need to limit what actions can be performed in your overall environment. For example, it is important to limit the modification of the logs that are being stored in your log storage.

    To prevent anyone from deleting or modifying these logs by mistake, you need to enable preventative controls to restrict the deletion on the logs in your log storage. In AWS, this can be accomplished by applying service control policies (SCPs) to your AWS accounts. These policies allow you to limit certain actions within a specific account, but you can also use them to prevent access to services completely, or limit the actions in your environment in specific regions that are not approved for use in your environment.

  • Implementation

  • Service control policies are a type of organization policy that you can use to manage permissions in your organization. SCPs offer central control over the maximum available permissions for all accounts in your organization. SCPs help to ensure that your accounts stay within your organization’s access control guidelines.

    No permissions are granted by an SCP. SCPs allow you to centrally control the maximum available permissions for all accounts in your organization. The administrator must still attach identity-based or resource-based policies to Identity and Access Management (IAM) users or roles to grant permissions. The effective permissions are the logical intersection between what is allowed by the SCP and what is allowed by the IAM and resource-based policies.

    To start using service control policies, all AWS Organization features must be enabled. Once enabled, you can create the SCPs you need to set controls across your environment. Service control policies can be attached to the root of the Organization, to the Organizational unit construct, or to the individual account(s).

    When a service control policy is attached to the root of the organization, the policy is inherited by all member accounts (all accounts except for the Management account). When attached to an organizational unit (OU), only the member accounts under the OU will inherit the controls. SCPs can also be attached directly to an account to limit permissions for only that account.

    To learn more about effects and limitations of SCPs, refer to the AWS Organizations SCP Documentation page.

    Create service control policies for your environment

    If you are planning on implementing new SCPs into your existing environment, we recommend that you test the policies before applying them to your production accounts to avoid unintended impact. SCPs can be tested in a dedicated OU (Policy Staging OU), or on test accounts where you can verify that they will not cause any unintended impact. Review the different use cases on the Policy Staging OU section in the Organizing Your AWS Environment Using Multiple Accounts whitepaper.

    Example Service Control Policies

    The SCPs in the following table are intended to be samples that can be modified to meet your specific requirements. For example, you can restrict specific actions from Root, or require tags on creation for specific services. Additionally, these policies can be combined into one service control policy document, to work within your service quotas.

    SCP Name	Description	SCP Target	SCP Boundary	Level	Sample
    DenyAccessToRegion	This SCP limits access to specific Regions or allow only specific Regions within your environment.	Root / Workload OU	Account	100	Link
    PreventMemberLeaveOrg	This SCP prevents accounts to leave the Organization.	Root	Account	100	Link
    PreventBillingModifications	This SCP prevents modifications to billing within the accounts.	Root	Account	100	Link
    PreventRootActions	This SCP prevents the root user in the member accounts in your organization to perform certain actions.	Root	Identity	100	Link
    PreventRootAccessKeys	This SCP prevents the Root user in the member accounts to create, modify, or delete access keys.	Root	Identity	100	Link
    PreventDeletionModification IAMroles	This SCP prevents the modification or deletion of IAM Roles across the environment, unless the infrastructure or any allowed roles are specified.	Root	Identity	100	Link
    PreventUpdateAssumeRole PolicyOnSpecificIAMRoles	This SCP prevents updating the Assume Role policy across the environment.	Root	Identity	100	Link
    PreventIAMSpecificActions	This SCP prevents specific IAM actions across the environment or in specific accounts, like Create Users. The allowed roles need to be specified within the policy.	Root	Identity	100	Link
    PreventDeletionModificationLog ArchiveResources	This SCP prevents the modification of the Log Archive account resources, to create a tamper resistant environment for customers to store their logs.	Log Archive Account	Detection	200	Link
    PreventDeletionModificationOrg CloudTrail	This SCP prevents the modification of the Organizational trail used across the environment to log access to AWS resources.	Root	Detection	200	Link
    PreventDeletionCloudWatch LogGroups	This SCP prevents the deletion of AWS Cloud Watch Logs.	Root	Detection	200	Link
    PreventEnableDisableAWSConfig	This SCP prevents the enablement or disablement of AWS Config across the environment. Only allowing the specified role within the policy to do so.	Root	Detection	200	Link
    PreventModificationTagged AWSConfigRules	This SCP prevents the modification of AWS Config rules that include a specific tag.	Root	Detection	200	Link
    PreventDisablingDefaultEBS Encryption	This SCP prevents disabling the default Amazon Elastic Block Store (AmazonEBS). Encryption across the environment.	Root	Data	300	Link
    PreventModificaitonTo SpecificCloudFormationResources	This SCP prevents the modification of AWS CloudFormation resources.	Root	Infrastructure Protection	400	Link
    PreventCreatingDefaultVPCand Subnet	This SCP prevents the creation of a default Amazon VPC.	Root	Infrastructure Protection	400	Link
    PreventGlacierDeletion	This SCP prevents the deletion of Amazon S3 Glacier objects.	Root	Data	300	Link
    PreventDisableAndModifyingGuardDuty	This SCP prevents users from modifying or disabling Amazon GuardDuty across the environment.	Root	Data	200	Link
    RequireTagOnCreation	This SCP enforces tagging across the environment, and rejecting the creation of resources when tags are not enabled.	Root	Infrastructure Protection	400	Link
    PreventKMSKeyDeletion	This SCP prevents the deletion of KMS keys across the environment.	Root	Infrastructure	400	Link
    PreventModificationsToSpecific LambdaFunctions	This SCP protects infrastructure automation solutions deploy Lambda functions that need protection	Root	Infrastructure Protection	400	Link
    PreventResourceSharingOutsideOrganization	This SCP prevents the sharing resources outside of the AWS Organization, and helps customers establish data boundaries.	Root	Data	300	Link
    PreventDisablingS3AccountPublic AccessBlock	This SCP prevents users from disabling the Public Access Block when set up on S3 buckets. It can be applied across the organization, for specific resources, or to a specific account.	Root	Data	300	Link
    PreventS3UnencryptedObject Uploads	This SCP enforces encryption of the objects when they are uploaded to specific S3 buckets.	Root	Data	300	Link
    PreventS3PublicObjectAccess	This SCP prevents users from enabling public access to objects stored in the S3 bucket.	Root	Data	300	Link
    PreventSpecificS3BucketsFrom Deletion	This SCP helps customers protect S3 buckets from deletion.	Root	Infrastructure	400	Link
    PreventAccessToSpecificS3Buckets	This SCP helps customer protect specific S3 buckets from general access across their environment.	Root	Data	300	Link
    PreventModificationToSpecificSNSTopics	This SCP helps customers to prevent the modification of specific Amazon SNS topics in their environment. These SNS topics are typically used to create alerts, and activate remediations to security incidents and non-compliant resources.	Root/Data	Infrastructure	400	Link
    PreventDeletionModification SecurityServices	This SCP protects the delegated administration set up in the Security Tooling account, along with the resources deployed and configured within the account.	Security Tooling Account	Data	400	Link

    SCP Boundary Definitions

    • Account: An SCP that applies permission boundaries to AWS account(s) within an organization
    • Identity: An SCP that applies permission boundaries to the IAM user, group, or role in an AWS account
    • Data: An SCP that applies permission boundaries to the data contained in an AWS account
    • Infrastructure Protection: An SCP that applies permission boundaries to the configured AWS services

    SCP Level Definitions

    • Level 100: Identity and Access Management: Account and Administrator Security
    • Level 200: Detection: Log and Audit Security
    • Level 300: Data Protection: Securing organizational Data
    • Level 400: Infrastructure Protection: Control methodologies for ongoing operations in the cloud
      

• Establish a single point of management for access and authorization for the cloud environment

  • Scenario
  • Overview
  • Implementation

  • Scenario
  • Establish a single point of management for access and authorization for the Cloud environment

    • Establish programmatic access for users and/or applications
    • Implement Attribute Based Access Control (ABAC) with your federated access
  • Overview

  • Federated access grants you the ability to efficiently manage the access to the environment and should be established and operated centrally. The benefits of managing your identities and controlling access to your environment centrally, helps you quickly create, update, and delete the permissions and policies you need to meet your business requirements. From granting or revoking permissions to specific users or roles, or by establishing preventative controls on your overall environment, your security teams can manage access to the environment from one place.

    The permissions to perform certain actions of the environment need to be separated. Granting permissions to perform only the necessary actions to specific roles that require them, helps you achieve a least privileged access model. We recommend that you group different users by their job family to access different tools within a different set of permissions. Regardless of the user, there may be some preventative controls that need to be set centrally to prevent access or modification to certain resources and areas of your environment.

    Previously, we recommended that you establish MFA for every role that has access to your environment, as a minimum requirement for administrator roles. This adds an extra layer of protection on top of your username and password. Additionally, it is very important that every root user has MFA enabled. For access to your organizational account, the root user MFA needs to be enabled, and the access key and password should be stored separately.

    Delegating the administration of different services

    As your environment grows, the complexity of managing your environment will increase with the amount of resources you have. To effectively manage your environment, you need to have a level of automation that matches the complexity of your environment.

    Each team in your organization will assume different roles to manage different aspects of the environment. Delegating the administration of the services that the team will be managing in your environment will allow them to establish boundaries for data and security separately. The teams can build or deploy the necessary automation needed to operate and oversee the environment without affecting other teams or environments. For example, we recommend delegating the management of security services to your security team, delegating the infrastructure deployments, and template management to your Operations and Central IT teams, and delegating the management of your identity to your Identity or Security team.

  • Implementation
  • Setting up IAM Identity Center

    IAM Identity Center is where you create or connect your workforce identities in AWS once and manage access centrally across your AWS Organization. You can create user identities directly in the IAM Identity Center, or you can bring them from your current user directory or a standards-based identity provider, such as Okta Universal Directory or OneLogin.

    Once your AWS Organization has been created, you can enable IAM Identity Center in the desired AWS Region.

    Note: If you are an AWS Control Tower user, IAM Identity Center is deployed during the AWS Control Tower set up in your home Region.
    

    To maintain a secure posture in your environment, enable Attribute Based Access Control, MFA, and set your user portal URL (optional) within the IAM Identity Center web console settings tab.

    Note: The IAM Identity Center user portal URL can only be changed once. If you need to change it again, you need to delete your IAM Identity Center instance, and start over.
    

    Creating IAM Identity Center User Groups

    IAM Identity Center Groups are a logical combination of users that you define. You can create groups and add users to the groups. Groups are useful when assigning access to AWS accounts and applications. The following groups reflect the functions we described earlier. We will assign permission through IAM policies to groups according to the group’s role in the AWS Organization. A policy, per the Policies and Permissions in IAM User Guide, is an object in AWS that, when associated with an identity or resource, defines their permissions.

    Note: When using IAM Identity Center delegated administrator account, we do not recommend using groups in IAM Identity Center for managing access to your AWS Management account. The design of IAM Identity Center delegation is to mitigate risk of unintended management account access. IAM Identity Center delegation allows for management of all member accounts assignments as well as all group membership. If a group is used to manage access to the management account, the IAM Identity Center delegated admin account is still able to add members to the group. To best isolate your management account, only create assignments using users.

    Create a group for each of the required functions that you have previously defined and documented. You can create the following groups and add additional groups as additional requirements arise.

    Support-Users: Can authenticate into the AWS Management Account and have cross-account access to support to all the AWS Organization’s member accounts to troubleshoot, offer solutions and escalate to AWS Support.

    MA-Billing-Administrators: Access the AWS Management Account and manage billing details for the AWS Cost Explorer and Billing service. The group will have permissions to the specific S3 buckets that allow Cost and Usage Reports to be generated.

    MA-Billing-ReadOnly-Users: Members access the AWS Management Account and can view billing details for the AWS Cost Explorer and Billing service.

    Organization-Administrators (OA): Members access the AWS Management Account and have full privileges to manage AWS Organization services.

    Organization-ReadOnly-Users: Members access the AWS Management Account with Organization read-only access to view AWS Organization service configurations. All OAs should also be members in this group.

    Security-Auditors: Members have access to all AWS Accounts in the AWS Organization for fulfillment of the Auditor and Read Only role within the environment.

    SecurityTooling-Administrators: Members access the AWS Security Tooling account with Administrative access.

    SecurityTooling-ReadOnly-Users: Members access the AWS Security Tooling account with Read Only Access. All SecurityTooling-Administrators should be a part of this group.

    IAMIdentityCenter-Administrators: Members Manage AWS Organizations member accounts and cloud application within IAM Identity Center in the Management Account.

    IAMIdentityCenter-ReadOnly-Users: Members have read-only access to IAM Identity Center service in the Management Account. All IAM Identity Center-Administrators should also be a part of this group.

    Creating Workload IAM Identity Center User Groups

    You also need to create another set of groups for managing your workloads (projects) and your individual sandbox accounts. Although there might be AWS accounts that are accessed and managed only by an individual, we recommend you leverage groups to manage access to your accounts. This will allow you to add more users later to help manage the account or to grant temporary access. The following are some examples on how to leverage user groups:

    For your workload accounts, we recommend you create the [Workload]-Administrators and [Workload]-ReadOnly-Users groups. A read-only group should be created for each workload, to allow the review of configurations and logs without concern of configuration change. All members of the [Workload]-Administrators should be added to the corresponding [Workload]-ReadOnly-Users group.

    For a sandbox environment, you need to grant access to the user that owns the sandbox account, and for the administrators that will have access to manage the environment. This can be done by adding the users with access to the environment to the administrator group, or by deploying access through the organization management group into this account. In addition, the owner of the environment will have access to the read-only role, along with the security team members to monitor the environment. The groups you need to create are Sandbox-[UserName]-Administrators and Sandbox-[UserName]-ReadOnly-Users.

    You can create these IAM Identity Center Groups in the IAM Identity Center console or you can use the IAM Identity Center-admin API to create and manage your groups.

    Creating IAM Identity Center Permission Sets

    IAM Identity Center Permission Sets are a collection of permissions that can be attached to an IAM Identity Center User or Group, granting them permissions on the accounts where they are assigned.

    Create the IAM permission sets based on the required functions and groups that you have created. Below is a list of example permission sets that align with the example IAM Identity Center groups previously provided.

    Example Permission Sets

    MA-Administrator
    The MA-Administrator role is setup to have full admin access to the management account. The assignment to this permission set is intended to be heavily restricted and secure, being assigned to a minimal number of individuals. Since the permission set will be assigned to the management account it can only be edited in the management IAM Identity Center console.

    This permission set will use the arn:aws:iam::aws:policy/AdministratorAccess policy.
    

    MA-Operator
    This permission set is very similar to the MA-Administrator, but it does not have access to modify user access or IAM Identity Center permissions. The corresponding role is designed to be assumed by the environment administrators to perform configuration updates, and managing the environment. Since the permission set will be assigned to the management account it can only be edited in the management IAM Identity Center console.

    This permission set will use the arn:aws:iam::aws:policy/job-function/PowerUserAccess policy.

    MA-ReadOnly
    This permission set is used by the environment administrators to oversee and monitor the environment when no action is necessary. The corresponding role is a read only role to ensure that things are set up and working as expected. Since the permission set will be assigned to the management account it can only be edited in the management IAM Identity Center console.

    This permission set will use the arn:aws:iam::aws:policy/ReadOnlyAccess policy.

    MA-Billing-Administrator
    This permission set is used to view billing information, set up payments, and authorize payments. The user can monitor the costs accumulated for the entire AWS service. The permissions grant grants full permissions for managing billing, costs, payment methods, budgets, and reports. The corresponding role is leveraged to take action within the management account. Since the permission set will be assigned to the management account it can only be edited in the management IAM Identity Center console.

    This permission set will use the arn:aws:iam::aws:policy/job-function/Billing policy.

    MA-Billing-ReadOnly
    This permission set allows users to view bills in the AWS Billing console. The corresponding role should be given to the financial team members who require viewing of the cost reporting and access to the “Cost and Usage Report” data. Since the permission set will be assigned to the management account it can only be edited in the management IAM Identity Center console.

    This permission set will use the arn:aws:iam::aws:policy/AWSBillingReadOnlyAccess
    policy.

    MA-Support-User
    This is a permission set created to grant access to the internal support team to the resources in your environment in order to troubleshoot and help with configuration issues before escalating to AWS Support. Since the permission set and role will be assigned to the management account it can only be edited in the management IAM Identity Center console.

    This permission set will use the arn:aws:iam::aws:policy/job-function/SupportUser policy.

    Support-User
    This ipermission set is created to grant access to the internal support team to the resources in your environment in order to troubleshoot and help with configuration issues before escalating to AWS Support.

    This permission set will use the arn:aws:iam::aws:policy/job-function/SupportUser policy.

    SecurityTooling-Administrator
    This permission set grants access to read security configuration metadata within an AWS account. It is useful for software that audits the configuration of an AWS account. The corresponding role should be leveraged by the security team and delivered to all AWS accounts in your AWS Organization.

    This permission set will use the arn:aws:iam::aws:policy/job-function/PowerUserAccess policy.

    SecurityTooling-ReadOnly
    This permission set grants access to read access within the Security Tooling account. The corresponding role should be leveraged by the security team and delivered to all AWS accounts in your AWS Organization.

    This permission set will use the arn:aws:iam::aws:policy/ReadOnlyAccess policy.

    MA-Organization-Administrator
    This role provides full access to AWS Organizations service in the Management Account. Functionality of the role includes:

    • Creating/deleting AWS Organizations
    • Enabling, editing, linking and deleting Organization policies
    • Creating and closing AWS accounts within Organizations
    • Creating AWS Organizational Units within Organizations
    • Enabling and delegating AWS Organization Integrated Services

    Since the permission set will be assigned to the management account it can only be edited in the management IAM Identity Center console.

    This permission set will use the arn:aws:iam::aws:policy/AWSOrganizationsFullAccess policy.

    MA-IAMIdentityCenter-Administrator
    This permission set can be used to enable and edit the IAM Identity Center configurations within the IAM Identity Center Service. The corresponding role is only deployed to the Management Account. The functionality of the role includes the following:

    • Create/enable/delete the IAM Identity Center
    • Configure IAM Identity Center Settings
    • Configure AWS Directory Settings for IAM Identity Center
    • Create Users, Groups, and Permissions Sets
    • Apply Permission Sets to AWS accounts

    Since the permission set will be assigned to the management account it can only be edited in the management IAM Identity Center console.

    This permission set will use the arn:aws:iam::aws:policy/AWSSSOMasterAccountAdministrator policy.

    IAMIdentityCenter-Administrator
    This permission set can be used to enable and edit the IAM Identity Center configurations within the IAM Identity Center Service. The corresponding role is only deployed to the IAM Identity Center Delegated Administrator account. The functionality of the role includes the following:

    • Configure IAM Identity Center Settings
    • Configure AWS Directory Settings for IAM Identity Center
    • Create Users, Groups, and Permissions Sets
    • Apply Permission Sets to AWS Member Accounts

    For more information on what IAM Identity Center Delegated Administrator account can do, refer to What tasks can be performed in the delegated administrator account within the IAM Identity Center documentation.

    This permission set will use the arn:aws:iam::aws:policy/AWSSSOMasterAccountAdministrator policy.

    IAMIdentityCenter-ReadOnly
    This permission set provides read only access to IAM Identity Center configurations. For any review or checks of IAM Identity Center configuration or audits, the corresponding functional role should be leveraged. Members of the IAMIdentityCenter-DirectoryAdmin and IAM Identity Center-Administrator should be granted access to this role.

    LogArchive-Administrator
    This permission set grants the administrator access to the Log Archive account. The access allows all actions to all services within the Log Archive account.

    This permission set will use the arn:aws:iam::aws:policy/AWSSSOMasterAccountAdministrator policy.

    LogArchive-ReadOnly
    This permission set supports read-only functionality into the Log Archive account. Any activities that the Log Archive support team take which do not require action, but only review would use the corresponding role. The purpose of this permission set is to promote safe operations, and ensuring no actions can be made within the session.

    This permission set will use the arn:aws:iam::aws:policy/ReadOnlyAccess policy.

    [Workload]-Administrator
    This permission set grants administrator access to a specific Workload type AWS account.

    This permission set will use the arn:aws:iam::aws:policy/AdministratorAccess policy

    [Workload]-ReadOnly
    This is read only permission set will grant read-only access for specific Workload type AWS accounts.
    

    This permission set will use the arn:aws:iam::aws:policy/ReadOnlyAccess policy.

    Sandbox-[UserName]-Administrator
    Sandbox environments are meant for users to experiment and try new services and build new solutions. This role should be assigned to the owner of the sandbox environment.

    This permission set will use the arn:aws:iam::aws:policy/AdministratorAccess policy

    Sandbox-[UserName]-ReadOnly
    This permission set should be granted to the sandbox account members who need access to their account to conduct read-only operations into the environment to ensure that everything is running according to policy.

    This permission set will use the arn:aws:iam::aws:policy/ReadOnlyAccess policy.

    Creating IAM Identity Center Users

    IAM Identity Center allows you to create user accounts and a user represents an individual that will have access to one or more accounts or applications. Each user will have access to an independent portal to the permissions they have been assigned to each account. This allows you to identify who is using what role, in which account, because these actions are logged through AWS CloudTrail into your centralized logs. (Review the Log Storage capability for instructions on how to set up a central log storage).

    Each user created in IAM Identity Center should belong to one-to-many groups. Groups allows you to manage permissions quickly by the function assigned to each group, and abstracts the need for keeping track of what permission sets are assigned to a user, allowing you to more efficiently audit and control the permissions in your environment.

    When needed, you can also attach a permission set to a user. If you assign permission sets to individual user, establish a policy to review periodically these permissions. You can use IAM Access Analyzer to evaluate the permissions that are not being used, and remove them from the policy (whether it is a group or an individual user) to keep the least privilege permissions the user needs in your environment.

    Create as many users as the number of people who need access to your environment. These users will be assigned a set of permissions so they can access the resources, accounts, and workloads they need in your AWS environment. For each user you create, you will need the following information:

    1. Username
    2. Email address
    3. First name
    4. Last name
    5. Display name

    IAM Identity Center allows you to generate a random one-time password. This password can be shared with the customer manually, or sent via the email used to register on IAM Identity Center. If you decide to send the password through the email, make sure the account is verified by the owner of the email before assigning any permission sets.

    After entering the required information, you can assign the user to the groups the user will belong to, and grant access automatically through the permission sets assigned in the groups to the environment.

    Assigning Permission Sets to Users and User Groups

    Now that the groups and the permission sets have been created, you can assign the appropriate permission sets to the groups, and grant access to their functionality.

    Note: Assignments to the Management account need to be managed from the Management account by the IAM Identity Center Administrator. Any permission set assigned to the Management Account cannot be edited or used in any other account in the organization. Additionally, we recommend using individual users for the Management Account assignments, because groups managed outside of the Management Account can be a security risk.

    You can assign a permission set to a group through the IAM Identity Center web console, or through the IAM Identity Center admin CLI. To complete via the IAM Identity Center web console follow these steps:

    1. In the console, navigate to the AWS accounts tab, and select the accounts you want to grant access.
    2. Once you have selected all the accounts, click Assign Users, click the Groups tab, and select the group that should have access to the account(s).
    3. Click next, and in the pop-up window select the permission set(s) that will be assigned to this group for the specified accounts.
    4. Repeat this process to grant access through your groups to as many accounts that need console/CLI access for users.

    An example of a user that you may want to deploy to all accounts is the Support User. The Support User allows access to troubleshoot accounts and contact AWS Support from that account, if needed.

    Accounts that do not require human access don’t need to be assigned an IAM Identity Center group. A role can be deployed to these accounts using infrastructure as code (IaC), allowing the deployment, operation, and governing of resources in the account the resources in the account externally.

    Note: For access to the Management Account, we do not recommend using groups with your Identity Provider (IdP), because the management of these groups can happen externally. You should ensure that only individuals that require access to the Management Account. The Management Account should be a controlled environment, this allows you to create a secure perimeter account.
    

    Refer to the following table for the most up to date recommendation mapping between accounts, permissions sets, and groups.

    IAM Identity Center Group	IAM Identity Center Permission Set	Accounts
    Direct user assignment (no group)	MA-AdministratorAccess	Management Account
    Direct user assignment (no group)	MA-PowerUserAccess	Management Account
    MA-ReadOnly	MA-ReadOnlyAccess	Management Account
    Direct user assignment (no group)	MA-Billing-Administrator	Management Account
    MA-Billing-ReadOnly	Custom policy allowing only read access to billing	Management Account
    Direct user assignment (no group)	MA-Support-User	Management Account
    Support-User	SupportUser	All Accounts
    SecurityTooling-Administrator	PowerUserAccess	Security Tooling Account
    SecurityTooling-ReadOnly	ReadOnlyAccess	Security Tooling Account
    Direct user assignment (no group)	MA-Organization-Administrator Custom policy granting permission for organizations	Management Account
    Direct user assignment (no group)	MA-IAM Identity Center-Administrator Custom Policy granting permissions only for IAM Identity Center Admin	Management Account
    IAM Identity Center-Administrator	Custom Policy granting permissions only for IAM Identity Center Admin	Shared Services Account
    IAM Identity Center-ReadOnly	Custom Policy granting permissions to read IAM Identity Center	Shared Services Account
    LogArchive-Administrator	PowerUserAccess	Log Archive Account
    LogArchive-ReadOnly	ReadOnlyAccess	Log Archive Account
    Security-Auditor-ViewOnly	Custom policy to manage Audit Manager	All accounts
    Security-Auditor-Admin	Custom Policy to allow read-only to AWS Audit Manager	All accounts
    [Workload]-Administrator	PowerUserAccess	This group is created for a specific account, only used to assign user access to that account.
    [Workload]-ReadOnly	ReadOnlyAccess	This group is created for a specific account, only used to assign user access to that account.
    Sandbox-[UserName]-Administrator	AdministratorAccess	This group is created for a specific account, only used to assign user access to that account.
    Sandbox-[UserName]-ReadOnly	ReadOnlyAccess	This group is created for a specific account, only used to assign user access to that account.

    With the help of SCPs, at the AWS Organization level, you can limit which users have access to certain actions by adding certain conditions.

• Manage the lifecycle of identities

  • Scenario
  • Overview
  • Implementation

  • Scenario
  • Manage the lifecycle of identities

    • Audit for unused roles or users
  • Overview

  • As environments scale, it is common to have unnecessary or unused roles that were never deleted or never used. When provisioning users or roles within your environment, it’s important to have a process or mechanism that removes permissions or roles that have not been used for a period of time.

  • Implementation

  • IAM access advisor provides you with role-last-used information for your organization in the Management Account IAM console, using APIs, or using the AWS CLI (generate-organizations-access-report). These reports display the number of days that have passed since each role made an AWS service request. AWS records last-used information for the trailing 400 days. This is referred to as the tracking period. You can sort the column to identify the roles your team has not used recently.

• Enforce multi-factor authentication (MFA)

  • Scenario
  • Overview
  • Implementation

  • Scenario
  • Enforce multi-factor authentication (MFA)

    • Enforce MFA on initial sign-in
    • Prohibit API calls without MFA
    • Detect users without MFA enabled
  • Overview

  • We recommend that you establish MFA for every role that has access to your environment. MFA adds extra security because it requires users to provide unique authentication from an AWS supported MFA mechanism in addition to their regular sign-in credentials when they access AWS websites or services: It is very important that every AWS account root user has MFA enabled. For access to your organizational account, the root user MFA needs to be enabled, and the access key and password should be stored separately.

  • Implementation
  • IAM Identity Center MFA

    MFA is enabled from the IAM Identity Center console. You can also configure MFA enforcement which will not allow users to log in for the first time until they configure an MFA device. Follow the IAM Identity Center User Guide to configure MFA device enforcement.

    Using SCPs to require MFA

    Additionally, SCPs can be used to require MFA to allow API calls. The following is an example SCP that requires MFA to stop or decommission instances.

    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Sid": "DenyStopAndTerminateWhenMFAIsNotPresent",
          "Effect": "Deny",
          "Action": [
          "ec2:StopInstances",
          "ec2:TerminateInstances"
       ],
       "Resource": "*",
       "Condition": {"BoolIfExists": {"aws:MultiFactorAuthPresent":       false}}
        }
      ]
    }

    Code snippet copied

    Copy

    Using AWS Config to check for Multi-Factor Authentication for IAM users

    We recommend that if you do IAM users in your environment, each user should have MFA enabled. You can achieve this by leveraging an AWS managed Config rule (iam-user-mfa-enabled), which can be used with AWS Config to verify whether the IAM users have MFA enabled.
    

• Implement data perimeter

  • Scenario
  • Overview
  • Implementation

  • Scenario
  • Implement data perimeter

    • Delegate and isolate administrative functions in your environment
  • Overview

  • Simply granting permissions does not guarantee that your environment is fully secured. To ensure that only the services that are intended to be used by the assigned roles are used by those roles, you can limit access to the environment by establishing a delegated administration function from an isolated environment. This provides individual boundaries to perform specific functions, aggregate information, and centralize operations and security across your organization. For example, this could involve creating an isolated boundary for managing your identities, your security, or your operational tooling.
    

  • Implementation
  • Delegate and isolate administrative functions in your environment

    Delegating administration of AWS services
    AWS recommends that access to the management account should be limited. Avoid running workloads in the management account, and deploy the services that manage your organization to separate accounts.

    AWS services used to manage your environment security should be delegated to the Security Tooling account. For a deep dive on these security services, review the Security Reference Architecture.

    Delegated administration is a feature offered by AWS Organizations. This allows you to grant organizational administrator rights over a service to a specific account. You can register one or more delegated administrators for a service. Review the list of services that support delegated administration in the AWS Organizations documentation.

    You can register delegated administrators from the services’ consoles, or you can use the AWS Organizations API to register these services centrally. The following table shows the current recommendations for delegating the administration of services to member accounts in your organization.
    

    AWS Service	AWS Account	Delegation or Account Isolation
    AWS Security Hub	Security Tooling	Delegation
    Amazon GuardDuty	Security Tooling	Delegation
    AWS Config	Security Tooling	Delegation
    Amazon Macie	Security Tooling	Delegation
    AWS IAM Access Analyzer	Security Tooling	Delegation
    AWS Firewall Manager	Security Tooling	Delegation
    Amazon EventBridge	Security Tooling	Delegation
    Amazon Detective	Security Tooling	Delegation
    Route 53	Shared Services	Delegation and isolation within the account.
    VPC Transit Gateway	Networking	Delegation
    Service Catalog	Shared Services	Delegation and isolation within the account.
    CloudFormation	Operations Tooling	Delegation and isolation within the account.
    CloudTrail	Management	Isolation of permissions within the management account. Alarms and alerts to be set up.
    IAM Identity Center	Management	Isolation of permissions within the management account. Alarms and alerts to be set up.
    AWS Systems Manager	Operations Tooling	Delegation and isolation within the account.
    AWS License Manager	Shared Services	Delegation and isolation within the account.
    Amazon S3 Storage Lens	Log Archive	Delegation and isolation within the account.
    Amazon VPC IP Address Manager (IPAM)	Networking	Delegation
    Key Management Service	Security Tooling	Delegation
    IAM Identity Center Delegated	Shared Services	Delegation and isolation within the account.
    AWS Account Management
    AWS Audit Manager	Security Tooling Account	If an external auditor requires access, a specific Role within IAM Identity Center. The security team should manage this account: Security-Auditor-ViewOnly

    Delegate IAM Identity Center
    To complete the initial setup of the Identity Management and Access Control capability, delegate the management of IAM Identity Center to its own isolated account (or in your Shared Services account) to reduce the access needed to the management account in your organization.

    Regardless of delegation, access to the management account through IAM Identity Center should be managed from the management account itself. The delegated account cannot manage or update groups of users who have access to the management account itself.

    Access to the management account should be restricted to those who strictly need to perform management actions within this account, and the roles of those who need access should be monitored closely.

    Note: This recommendation includes the delegation for administering these services outside the management account. The setup and operations for these services will be given within the guidance of additional foundational capabilities.