Guidance for Establishing an Initial Foundation Using AWS Organizations

Implementation Resources

• Planning for foundational deployment

  • Scenario
  • Overview
  • Implementation

  • Scenario

  • Planning for foundational deployment 

    • Document conventions and basic governance
  • Overview

  • Effective governance rules permit consistency and control over your cloud environment while maintaining agility. It's a good idea to establish governance early on so that it is embedded throughout your environment as your cloud foundation matures.
    

    Supporting Cloud Foundations capability:

    • Governance
  • Implementation
  • Document conventions and basic governance

    Before you start creating an environment, you need to establish basic governance. Established naming conventions are one of the most visible core governance procedures, and they allow for planning at scale. By identifying a method to name your AWS accounts, you can effectively identify ownership or type of AWS account operating within your environment. Additionally, identifying where your AWS management control plane and operational workloads are located will help you ensure your accounts are not inconsistently sprawled across AWS.
    

    In this section, you will create a documented email convention for new accounts, identify and document your home AWS Region, and identify and document your operational AWS Regions. The documentation will help you drive the creation of a well-planned and consistent environment.
    

    Create AWS account email naming convention

    When creating new AWS accounts, you will need to use an email address that is associated with the root user of the account. To better manage your AWS environment as it scales, it is recommended to establish a naming convention for the account alias and the corresponding root account email address. We recommend using the same name for the email as for the AWS account alias.
    

    An example is: “aws-management-account-primary@example.com” which is given to the management account of your AWS Organization. Consider that over time you may become responsible for more than one AWS Organization and that you will need to differentiate those environments. All AWS accounts require a unique email address and can never be leveraged twice. The following are examples of getting started with a naming convention:
    

    Account Alias	Root email	Email Example	Description
    aws-management-account-[org-identifier]	aws-management-account-[org-identifier]@example.com	aws-management-account-primary@example.com	Name given to the alias and email address for the management account. Org-identifier is used to specify the AWS organization. This can be the function of the organization or a number (example: 1)
    [workload]-[environment]-[org-identifier]	aws-[workload]-[environment]-[org-identifier]@example.com	aws-[workload]-[environment]-primary@example.com	Convention used for your workload accounts. Org-identifier is used to specify the AWS organization. This can be the function of the organization or a number (example: 1)
    [sandbox]-[username]-[org-identifier]	aws-[sandbox]-[username]-[org-identifier]@example.com	aws-[sandbox]-[username]-primary@example.com	Convention used for creating AWS sandbox accounts for specific user. Org-identifier is used to specify the AWS organization. This can be the function of the organization or a number (example: 1)

    Note: Do not simply give your AWS management account the name aws-management-account. Within AWS, you can potentially have more than one AWS management account and Organization. We recommend using an additional descriptor to ensure that if you scale your environment to multiple AWS Organizations, you can identify the different environments.
    

    Determine home Region

    Within AWS, select a home Region where you deploy your AWS Organization management and orchestration tools, such as AWS CloudTrail and IAM Identity Center. The home Region does not need to be the same as the operational Regions (where your workloads are deployed). If you do not have specific compliance requirements, keep your home Region in a Region that supports the necessary AWS services such as IAM Identity Center and aligns with one of your operational Regions.
    

    Home Region considerations

    1. The home Region does not have to be one of your operational Regions (the Regions where workload data and resources will be hosted)
    2. A home Region could be your operational Region

    Determine operational Regions

    Within AWS, your operational Regions are AWS Regions where you will allow workloads to operate in. Operational Regions can be thought of as the AWS Regions where your end-user data is stored. All other AWS Regions should have controls put in place to restrict operational access. Your operational Region(s) can be the same as your home Region, but can also include other Regions.
    

    For a list of AWS Regions, reference Regions and Availability Zones.

    For more information to help you identify your operational Regions, read the AWS architecture blog: What to Consider when Selecting a Region for your Workloads.

• Creating and configuring your management account

  • Scenario
  • Overview
  • Implementation

  • Scenario

  • Creating and configuring your management account 

    • Create management account
    • Configure management account
  • Overview

  • The management account (sometimes referred to as the payer account or AWS organization management account) is the AWS account that defines and manages your AWS Organization. It can create new AWS accounts and invite existing AWS accounts into its AWS Organization. Your AWS management account will be used to:

    1. Centralize a billing entity for all member AWS accounts
    2. Manage AWS Organization services across all member accounts
    3. Enable and delegate AWS Services at the organization level to member accounts
    4. Define management and security policies across the environment
    5. Create, remove, and invite other AWS accounts into the organization

     

    Due to the high level of permissions associated with the management account, it is important to setup and secure the management account early in the process.

     

    Supporting Cloud Foundations capabilities: 

    • Identity Management & Access Control
    • Support
  • Implementation
  • Create management account

    The management account is your first AWS account when onboarding is initiated. The initial setup requires information to create the account that is used during sign up. Once the AWS account is created, it is important to start with security in mind. 
    

    In this section, you will create a new management account with a secure root user. 
    

    Set up management account email address

    When creating the new AWS account, you will need to supply an email address that has never been used for an AWS account. We recommend you set up a distribution group email and give it a title following the convention of: “aws-management-account-primary@example.com,” which maps the email address to the functionality. This allows the members of the distribution list to recover access to the environment, and if an individual leaves your company or organization, they can be removed from the distribution list. Only add a small number of members to the group email, as this email address is for the management account root administrative user.

    Document all email addresses you create for AWS accounts, as each email address can be used only once for account creation.

    Create AWS management account

    Visit Create an AWS Account and enter the required information on the following page.
    

    Field	Description	Tips
    Email address	A unique email address that identifies the AWS account and is the name of the AWS account root user.	Use the management AWS account root user email address that you already established. Be very careful that you enter the correct email address and that you have access to the email account.
    Password	A password for the AWS account root user.	Ensure that you secure this value. In a later step, you'll have the option to enable Multi-factor Authentication (MFA) - a highly recommended approach to help secure your AWS account.
    AWS account name	A brief identifier for the AWS account.	For example: aws-management-account-[org-identifier]. This value does not have to be unique and can be modified later on.

    As you sign up, set your account to either personal or professional. Both types of accounts have the same functionality and features. Enter your personal or professional information and then read and accept the AWS Customer Agreement.

    Note: Professional accounts are accounts that are created for a business or at an enterprise level, whereas Personal accounts are created for learning and experimenting with AWS services. 
    

    Secure management account root user

    Once you have completed signing up, you will be logged in as the root administrative user of the account. It is important to secure the root user and follow the Best practices to protect your account's root user. Ensure you set AWS multi-factor authentication (MFA) on your AWS account root user account, as outlined here: Enable MFA on the AWS account root user. For more information, see Using multi-factor authentication (MFA) in AWS in the IAM User Guide.

    Note: AWS supports Hardware, Virtual, and FIDO security key MFA devices. Compliance or the support team location may dictate what type of MFA device is leveraged for the root user. AWS foundational security best practices states to use a hardware-based MFA solution (reference FSBP-IAM-6).
    

    Configure management account

    The AWS management account root user has specific activities it can only complete within the account. After securing the root user account, it is important to complete the tasks that follow.

    In this section, you will complete all the necessary root user tasks in the management account to set up billing and support.

    Allow AWS Identity and Access Management (IAM) role access to billing

    Requires: root user

    By default, AWS does not provide access to any other IAM users or roles, regardless of the permissions you give them. To enable access to billing data for IAM users, or roles, outside the AWS root administrator account, follow the steps in the AWS Identity and Access Management User Guide. Once completed within the AWS management account, all AWS member accounts will inherit this setting.
    

    Set management account alternate contacts for operations, security, billing

    Requires: root user

    To keep the right people in the loop, you can add an alternate contact for Billing, Operations, and Security communications for the AWS account.

    To set these contacts in your management account, login as a root user and update the alternate contacts following the Update standalone AWS account alternate contacts documentation. You should provide email distribution groups for Billing, Operations, and Security.
    

    Configure billing and tax information

    Requires: root user or IAM billing enabled for IAM users and roles

    The AWS management account acts as the centralized billing entity, allowing you to receive a single invoice for all the AWS accounts within the organization. You will need to review and make any necessary changes to the billing console for the following details:

    1. Updating and deleting tax registration numbers
    2. Turning on tax setting inheritance
    3. Managing US tax exemptions
    4. Designate a payment method - pay by credit card or invoice
    5. Edit contact information
       

    Select AWS support tier

    Requires: root user

    Review the different AWS Support Plans. By default, all AWS accounts receive Basic support. If you would like to choose a higher level of support than Basic, follow the Changing AWS Support Plans steps in the AWS Support User Guide. If your intent is to have enterprise support, we recommend setting the support plan now instead of changing it later on.
    

• Deploying identity management

  • Scenario
  • Overview
  • Implementation

  • Scenario

  • Deploying identity management
    

    • Deploy AWS IAM Identity Center
    • Create IAM Identity Center standard assignments
    • Configure IAM Identity Center
    • Discontinue use of management account root user
  • Overview

  • Federated identity management grants you the ability to efficiently manage the access to the environment, and should be established and operated centrally. By managing your identities and controlling access to your environment centrally, you can 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.
    

    Supporting Cloud Foundations capability:
    

    • Identity Management & Access Control
  • Implementation
  • Deploy AWS IAM Identity Center

    IAM Identity Center (successor to AWS Single Sign-On) enables a robust, federated identity management services into your AWS environment. We recommend that you do not use AWS root user accounts except for activities that require it (reference AWS documentation for Root User Tasks). With IAM Identity Center, you create users and permission sets that you can assign to all AWS accounts within your environment.

    In this section, you will establish your AWS Organization, enable IAM Identity Center, create an administrator that will be used instead of the AWS account root user, and create a read-only user.
    

    Enable IAM Identity Center

    Within your identified home Region follow the instructions to Enable IAM Identity Center.
    

    Create IAM Identity Center standard assignments

    IAM Identity Center needs to be configured to create user assignments to access resources and applications in your environment. You will need to set up standard permissions and roles that will facilitate role-based accessed.

    In this section, you will set up a management account administrator assignment and a read-only assignment that your team can use to run your management account.

    Create management account for IAM Identity Center admin users

    From the management account in the IAM Identity Center console, you will need to add or create your additional management account administrators. The management account administrator team should be a small number of individuals that will have admin access to the management account.
    

    Follow the Add user instructions from the IAM Identity Center documentation to add your management account admin users, creating a minimum of one new admin user for you.
    

    Create management account for IAM Identity Center permission sets

    Follow the Cloud Foundations template guide for details in deploying permission sets in the management account.  

    Create management account for IAM Identity Center assignments

    From the management account in the IAM Identity Center console, you will need to assign your users to a permission set and to the management account. It is a best practice to assign only users and not groups to the management account administrator assignment. Groups can be updated in the IAM Identity Center delegated admin account and could give unauthorized access to the management account.
    

    Follow the Cloud Foundations template guide for details in deploying permission sets in the management account.  

    Configure IAM Identity Center

    IAM Identity Center (IdC) stores administrative permission settings that specify the amount of access granted to users and groups for an AWS account. After enabling IAM Identity Center and creating a permission set, the identity provider must be configured to support best practices.

    In this section, you will configure IAM Identity Center to require users to set up multi-factor authentication (MFA), enable Attribute Based Access Control (ABAC), and you will create a customized IdC URL for your team to easily remember and access.  

    Set MFA in IAM Identity Center

    Enable MFA for IAM Identity Center users. This is enabled from the IAM Identity Center console by setting the option to Configure multi-factor authentication, 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 this setting using the below settings:

    Setting	Recommendation
    Prompt users for MFA	Only when their sign-in context changes (context-aware)
    Users can authenticate with these MFA types	Check the boxes: Security keys and built-in authenticators and Authenticator apps
    If user does not yet have a registered device	Require them to register an MFA device at sign in

    Enable Attribute-based access control in IAM Identity Center

    Attribute-based access control (ABAC) is an authorization strategy that defines permissions based on attributes. Enable ABAC in IAM Identity Center by following the user guide to Enable and configure attributes for access control.

    Configure IdC URL in IAM Identity Center

    To make accessing your AWS environment easier for your users, you can set a customized portal URL. Follow the Identity Center documentation Customizing the AWS access portal URL to configure your customized portal URL.
    

    Note: If you are not sure what the custom URL will be, you can come back and complete this step later.
    

    Discontinue use of management account root user

    Your management account root user is used to configure your environment; however, now that IAM Identity Center is set up, it is recommended to discontinue use of the root user account. Your root user will not be needed except for tasks that are defined in the AWS security credentials documentation.

    In this section, you will stop using the management account root user and login as the IAM Identity Center management account administrator.
    

    Login with your IAM Identity Center user account

    Using your IdC user account you created and the custom URL for your Identity Center, log in and start accessing the management account using the MA-Administrator role.
    

• Building foundational Organizational Unit structure and accounts

  • Scenario
  • Overview
  • Implementation

  • Scenario

  • Building a foundational Organizational Unit (OU) Structure and Accounts
    

    • Create Security OU
    • Create Infrastructure OU
    • Create Workloads OU
    • Create Exceptions OU
    • Create Sandbox OU
    • Create Log Archive Account
    • Create IAM Identity Center Log Archive Administrator role
    • Create Security Tooling Account
    • Create IAM Identity Center Security Tooling Administrator role
  • Overview

  • An Organizational Unit (OU) is a virtual container used by AWS Organizations to classify and organize AWS accounts and administer them as a single unit.  For example, you can attach a policy-based control to an OU, and all accounts within the OU will automatically inherit the policy. 
    

    By starting with a subset of the AWS Multi-Account Strategy Recommended OUs, you will have an organizational structure that allows you to start building out your environment and workloads. Create additional recommended OUs as they are needed.
    

    Supporting Cloud Foundations capability:
    

    • Workload Isolation
  • Implementation
  • Create Security OU from AWS Organizations

    The Security Organizational Unit (OU) is intended for security services. It is used to hold AWS accounts containing AWS security resources that are shared or utilized by the rest of the organization. No application accounts or application workloads are intended to exist within this OU.  

    In this section, you will deploy the Security OU from AWS Organizations.

    Template Resource: If you deployed the sample CloudFormation template solution foundational-organizational-unit-structure, you will have completed this implementation.
    

    Create Security OU from AWS Organizations
    

    Follow the Managing organization units (OUs) user guide to create and enroll a top-level OU (from the Root OU) named Security.
    

    Create Infrastructure OU from AWS Organizations

    The Infrastructure Organizational Unit is intended for shared infrastructure services. It is used to hold AWS accounts containing AWS infrastructure resources that are shared or utilized by the rest of the organization. No application accounts or application workloads are intended to exist within this OU.

    In this section, you will deploy the Infrastructure OU from AWS Organizations.
    

    Template Resource: If you deployed the sample CloudFormation template solution foundational-organizational-unit-structure, you will have completed this implementation.
    

    Create Infrastructure OU from AWS Organizations

    Follow the AWS Organizations User Guide to create and enroll a top-level OU (from the Root OU) named Infrastructure.
    

    Create Workloads OU from AWS Organizations

    The Workloads Organizational Unit is intended to hold your business-specific workloads, including both production and non-production environments. To maintain a clear separation between production and non-production workloads, create a Production and one or more Non-production OUs within the Workload OU. Reference the Organizing Workload-oriented OUs section of the AWS multi-account strategy whitepaper for more information.

    In this section, you will deploy the Workload OU from AWS Organizations.

    Template Resource: If you deployed the sample CloudFormation template solution foundational-organizational-unit-structure, you will have completed this implementation. Otherwise, follow the tasks listed below to complete.  

    Create Workloads OU from AWS Organizations

    Follow the AWS Organizations User Guide to create and enroll a top-level OU (from the Root OU) named Workloads.
    

    Create Exceptions OU from AWS Organizations

    The Exceptions Organizational Unit is designed to be a service control policy (SCP) exception OU. SCPs should be attached directly to the accounts within this OU to provide the flexibility to manage different types of exceptions. 

    In this section, you will deploy the Exceptions OU from AWS Organizations.
    

    Template Resource: If you deployed the sample CloudFormation template solution foundational-organizational-unit-structure, you will have completed this implementation. Otherwise, follow the tasks listed below to complete.  

    Create Exceptions OU from AWS Organizations

    Follow the AWS Organizations User Guide to create and enroll a top-level OU (from the Root OU) named Exceptions.
    

    Create Sandbox OU from AWS Organizations

    The Sandbox OU contains accounts in which your builders are generally free to explore and experiment with AWS services and other tools and services subject to your acceptable use policies. These environments are typically disconnected from your internal networks and internal services. Sandbox accounts should not be promoted to any other type of account or environment within the Workloads OU.

    In this section, you will deploy the Sandbox OU from AWS Organizations.
    

    Template Resource: If you deployed the sample CloudFormation template solution foundational-organizational-unit-structure, you will have completed this implementation. Otherwise, follow the tasks listed below to complete.  

    Create Sandbox OU from AWS Organizations

    Follow the AWS Organizations User Guide to create and enroll a top-level OU (from the Root OU) named Sandbox.
    

    Create Log Archive Account from AWS Organizations

    The log archive is an account that acts as a consolidation point for log data that is gathered from all the accounts in the organization and primarily used by your security, operations, audit, and compliance teams. This account will contain a centralized storage location for copies of every account’s audit, configuration compliance, and operational logs. It also provides a storage location for any other audit and compliance logs, as well as application and operating system logs.
    

    Template Resource: If you deployed the sample CloudFormation template solution foundational-organizational-unit-structure, you will have completed this implementation. Otherwise, follow the tasks listed below to complete.  

    Create Log Archive account

    Follow the AWS Organizations guide to create an account named Log Archive, and follow the email convention to identify the account quickly, such as: aws-log-archive-[org-identifier]@example.com.
    

    Move Log Archive account to Security OU
    

    1. Select the account you want to move on the AWS accounts console
       
    2. Choose the checkbox ✓ next to the name of each account you want to move
       
    3. On the Actions menu, under AWS account, choose Move
    4. In the Move AWS account dialog box, navigate to and then choose Security OU
    5. Choose Move AWS Account
       

    To move accounts to or between OUs, follow the AWS Organizations' guide Moving accounts to an OU or between the root and OUs.
    

    Create an IAM Identity Center Log Archive Administrator role

    To configure and set up services, you will need to create an administrator role to access the Log Archive account.
    

    Create Log Archive Admins IAM Identity Center Group

    Follow the IAM Identity Center guide to Add groups for your Log Archive Administrator. Use a name that can easily help you identify the purpose of the group later. For example, Log Archive Administrators.
    

    Assign users to IAM Identity Center Group

    Add the IAM Identity center users that will be managing this account to the created group, following the IAM Identity Center steps to Add users to groups.
    

    Create Permission Set for your Log Archive Admins Group

    Follow the IAM Identity Center guide to Create a permission set using the AdministratorAccess Policy. Name this permission set in a way that allows you to identify it easily and reuse it on another account, where the same group can be assigned. For example, LogArchiveAdminAccess.
    

    Grant Access to Log Archive account

    Follow the IAM Identity Center guide to Assign user access to AWS accounts, to assign the Log Archive Administrators user group to your Log Archive account using the LogArchiveAdminAccess permission set.
    

    Create Security Tooling account from AWS Organizations

    We recommend the use of a security tooling account to contain broadly applicable security-oriented workloads in the form of security services, tools, and supporting data.

    In the context of native AWS services, this account is used to provide centralized delegated admin access to AWS security tooling and consoles, as well as provide view-only access for investigative purposes into all accounts in the organization. The security tooling account should be restricted to authorized security and compliance personnel and related security.
    

    Template Resource: If you deployed the sample CloudFormation template solution foundational-organizational-unit-structure, you will have completed this implementation. Otherwise, follow the tasks listed below to complete.  

    Create Security Tooling account

    Follow the AWS Organizations guide Creating an AWS account that is part of your organization named Security Tooling, and follow the email convention to identify the account quickly. For example, aws-security-tooling-[org-identifier]@example.com.
    

    Move Security Tooling account to Security OU

    1. Select the account you want to move on the AWS accounts console
       
    2. Choose the checkbox ✓ next to the name of each account you want to move
       
    3. On the Actions menu, under AWS account, choose Move
    4. In the Move AWS account dialog box, navigate to and then choose Security OU
    5. Choose Move AWS Account
       

    To move accounts to or between OUs, follow the AWS Organizations' guide Moving accounts to an OU or between the root and OUs.
    

    Create an IAM Identity Center Security Administrator role

    To configure and set up services in the Security Tooling account, you will need to create an administrator role to access the security tooling account(s).
    

    Create Security Admins IAM Identity Center Group

    Follow the IAM Identity Center guide to Add groups for your Security Administrator. Use a name that can easily help you identify the purpose of the group later. For example, Security Administrators.
    

    Assign users to IAM Identity Center Group

    Add the IAM Identity center users that will be managing this account to the created group, following the IAM Identity Center steps to Add users to groups.
    

    Create Permission Set for the Security Admins Group

    Follow the IAM Identity Center guide to Create a permission set using the AdministratorAccess Policy. Name this permission set in a way that allows you to identify it easily and reuse it on another account, where the same group can be assigned. For example, SecurityAdminAccess.
    

    Grant Access to Security Tooling account

    Follow the IAM Identity Center guide to Assign user access to AWS accounts, to assign the Security Administrators user group to your Log Archive account using the SecurityAdminAccess permission set.
    

• Deploying and configuring AWS CloudTrail

  • Scenario
  • Overview
  • Implementation

  • Scenario

  • Deploying and configuring AWS CloudTrail

    • Create an Amazon Simple Storage Service (Amazon S3) bucket for CloudTrail events
    • Create an AWS Key Management Service (AWS KMS) encryption key for CloudTrail in production Security Tooling account
    • Create organization management event trail in management account
  • Overview

  • AWS CloudTrail is an AWS service that helps you conduct operational and risk auditing, governance, and compliance of your AWS account. Actions taken by a user, role, or an AWS service are recorded as events in CloudTrail. Events include actions taken in the AWS Management Console, AWS Command Line Interface, and AWS SDKs and APIs.
    CloudTrail is enabled on your AWS account when you create it. When activity occurs in your AWS account, that activity is recorded in a CloudTrail event. You can easily view recent events in the CloudTrail console by going to Event history. For an ongoing record of activity and events in your AWS account, follow the procedures for Creating a trail.

    An organization CloudTrail trail allows you to capture CloudTrail events from all accounts within the AWS organization.

    Supporting Cloud Foundations capabilities:
    

    • Identity Management & Access Control
    • Log Storage
    • Observability
  • Implementation
  • Create Amazon S3 bucket for CloudTrail events

    An AWS CloudTrail trail delivers log files to an S3 bucket. The S3 bucket should be located in a log archive account, which is dedicated to storing and protecting log files.
    

    Template Resource: The CloudTrail S3 Bucket can be deployed with our open-sourced CloudFormation template centralized-logging-cloudtrail-s3-bucket. Otherwise, follow the tasks listed below to complete.

    Document CloudTrail bucket name

    Create and document a CloudTrail trail S3 bucket name.
    

    Log type	S3 Bucket naming convention recommendation	Recommendation Example
    CloudTrail	aws-logs-cloudtrail-[log archive account id]-[home-Region]	aws-logs-cloudtrail-123456789000-us-east-1

    Create S3 bucket in Log Archive account for CloudTrail logs

    Follow the Amazon S3 user guide for Creating a bucket. Create an S3 bucket in the home Region of your Log Archive account using your documented CloudTrail S3 bucket name.
    

    Configure S3 bucket to allow writes from CloudTrail

    Follow the CloudTrail user guide to create an Amazon S3 bucket policy for CloudTrail and apply a bucket policy to the CloudTrail S3 bucket. Reference the CloudTrail documentation to Create or update an Amazon S3 bucket to store the log files. A reference S3 Bucket policy can be found at the Cloud Foundations open-source template library.
    

    Create AWS KMS encryption key for CloudTrail in production Security Tooling account

    By default, the log files delivered by CloudTrail to your bucket are encrypted by Amazon server-side encryption with Amazon S3-managed encryption keys (SSE-S3). To provide a security layer that is directly manageable, we recommend that you use SSE-KMS for your CloudTrail log files.
    

    Create AWS KMS encryption key for CloudTrail in Security-Tooling-prod account

    In the home Region of your Security Tooling account (same Region that CloudTrail will be deployed), create an AWS KMS key following the AWS KMS guide on Creating keys.

    The AWS KMS key configuration can be referenced or deployed with our open-sourced template.
    

    Record the ARN of the AWS KMS key

    Record the AWS KMS Amazon Resource Name (ARN) of the created key, as it is needed during the creation of the CloudTrail trail.
    

    Create organization management event trail in the management account

    A CloudTrail organization trail is created in every AWS account that belongs to your organization. Users with CloudTrail permissions in member accounts can see this trail when they log into the CloudTrail console from their AWS accounts, or when they run AWS command-line interface (CLI) commands such as describe-trail. However, users in member accounts do not have sufficient permissions to delete the organization trail, turn logging on or off, change what types of events are logged, or otherwise change the organization trail in any way.
    

    Enable Trusted Access for CloudTrail

    Navigate to the AWS Organization console from the management account and enable Trusted Access for CloudTrail in the Services section. If you are deploying an Organization CloudTrail from the console, you don’t need to do this step since Trusted Access will automatically be enabled for you.

    Create Management event CloudTrail in management account

    Log into the home Region of the management account using the management account Administrator role and create a management event organization trail following the CloudTrail user guide for Creating a trail for an organization.
    

    Template Resource: The CloudTrail configuration can be referenced or deployed with our open-sourced template example.

• Deploying and configuring AWS Config

  • Scenario
  • Overview
  • Implementation

  • Scenario

  • Deploying and configuring AWS Config
    

    • Create AWS KMS encryption key for AWS Config in production Security Tooling account
    • Create Amazon S3 bucket for AWS Config in Log Archive Account
    • Create CloudFormation StackSet roles in management account
    • Deploy AWS Config in management account
    • Deploy AWS Config to all allowed Regions in member accounts
    • Enable AWS Config Aggregator in production Security Tooling account
  • Overview

  • AWS Config is a fully managed service that provides you with an AWS resource inventory, configuration history, and configuration change notifications. With AWS Config, you can discover existing AWS resources, export a complete inventory of your AWS resources with all configuration details, and determine how a resource was configured at any point in time.

    Supporting Cloud Foundations capabilities:
    

    • Resource Inventory Management
    • Log Storage
    • Observability
  • Implementation
  • Create AWS KMS encryption key for AWS Config in production Security Tooling account

    By default, the log files delivered by AWS Config to your bucket are encrypted by Amazon server-side encryption with Amazon S3-managed encryption keys (SSE-S3). To provide a security layer that is directly manageable, we recommend that you use SSE-KMS for your AWS Config log files.
    

    Create AWS KMS encryption key for AWS Config in Security-Tooling-prod account

    In the home Region of your Security Tooling account (same Region where the AWS Config S3 bucket will be located), create an AWS KMS key following the AWS KMS guide on Creating keys.

    Template Resource: The AWS KMS configuration can be referenced or deployed with our open-sourced template.

    Record the ARN of the KMS key

    Record the AWS KMS key ARN of the created key, as it is needed during the creation of AWS Config logs.
    

    Create S3 Bucket for AWS Config in Log Archive Account

    An S3 Bucket needs to be configured to allow for AWS Config to centrally log all AWS Config details across your environment. The S3 Bucket will serve as a central point for aggregating AWS Config logs for persistent storage, which can be later queried.

    In this section, you will create the S3 bucket and configure it to allow AWS Config to deliver logs to it.
    

    Template Resource: Leverage the Cloud Foundations CloudFormation template in the open-source GitHub repository to quickly deploy S3 Bucket for Centralized AWS Config logging.

    Create S3 bucket in Log Archive account for AWS Config logs

    In the Log Archive account, create an S3 Bucket that will centrally store all AWS Config logs generated from the AWS Config Recorder.
    
    

    1. Log in to your Log Archive account from the AWS Management Console and navigate to the Amazon S3 service under your Home Region.
    2. Locate and choose Create bucket to create a new bucket.
    3. Give your bucket a unique name and select the Region where you want to create the bucket. It's important to choose the Region where you want to centralize your AWS Config logging.
    4. In the Set permissions section, you can choose to configure the bucket's public access settings. Since this bucket will be used for logging, it's recommended to keep public access blocked.
    5. Choose the Create button to create the bucket.
    6. Once the bucket is created, choose the bucket name to open it.

    Configure S3 buckets to allow writes from AWS Config

    Follow the developer guide Granting AWS Config access to the Amazon S3 Bucket to create an S3 bucket policy for AWS Config, and apply a bucket policy to the AWS Config S3 bucket.

    Template Resource: Leverage our sample S3 Bucket policy for AWS Config to quickly configure an AWS Config S3 bucket policy.

    Create CloudFormation StackSet roles in management account

    AWS CloudFormation is a service that helps you model and set up your AWS resources. This allows you to spend less time managing those resources and more time focusing on your applications that run in AWS using Infrastructure as Code (IaC).  AWS CloudFormation StackSets enable you to create, update, or delete CloudFormation stacks across multiple accounts and AWS Regions with a single operation.

    To use StackSets to deploy and configure AWS resources in the management account in multiple Regions, CloudFormation StackSet roles are required.

    In this section, you will create CloudFormation StackSet Administration and CloudFormation StackSet Initiation roles.
    

    Create AWS CloudFormation StackSet Administration role

    In the CloudFormation console of the management account, create a CloudFormation Stack and use the below Amazon S3 URL as the Template Source. This will create a CloudFormation StackSet Administration role.
    

    Setting	Recommendation
    Template Source URL	https://s3.amazonaws.com/cloudformation-stackset-sample-templates-us-east-1/AWSCloudFormationStackSetAdministrationRole.yml *For home Regions not in us-east-1, change the Region in the URL to match your home Region
    Stack Name	CloudFormationStackSetAdministrationRole

    Create AWS CloudFormation StackSet Initiation role

    In the CloudFormation console of the management account, create a CloudFormation Stack and use the below Amazon S3 URL as the Template Source. This will create a CloudFormation StackSet Initiation role.
    

    Setting	Recommendation
    Template Source URL	https://s3.amazonaws.com/cloudformation-stackset-sample-templates-us-east-1/AWSCloudFormationStackSetInitiationRole.yml *For home Regions not in us-east-1, change the Region in the URL to match your home Region
    Stack Name	CloudFormationStackSetInitiationRole
    Stack Parameter: AdministratorAccountId	Enter the Account ID of the management account

    Deploy AWS Config in management account

    Due to the critical nature of the management account, we recommend deploying AWS Config in each Region of the management account to track resources and allow alerting on those resources. You can follow the manual steps below or use automation to deploy AWS Config in all Regions of the management account.
    

    Note: If you use automation, ensure that you configure your home Region to include global resources and configure the other Regions to not include global resources.
    

    In this section, you will deploy AWS Config to all enabled Regions of the management account with a delivery channel that sends the AWS Config history and snapshots to the centralized AWS Config logging bucket in the Log Archive account.
    

    Deploy AWS Config in the home Region of the management account

    In the CloudFormation console in the home Region of the management account, create a CloudFormation Stack and use the below Template Source URL and parameters (for parameters not in the table, you can leave the default values). This will deploy AWS Config in the home Region of the management account, with a delivery channel configured to send the configuration snapshots and configuration history files to the S3 bucket in the Log Archive account.
    

    Setting	Setting Type	Recommendation
    Template Source URL	Stack Setting	https://cloudformation-stackset-sample-templates-us-east-1.s3.us-east-1.amazonaws.com/EnableAWSConfigForOrganizations.yml *For home Regions not in us-east-1, change the Region in the URL to match your home Region
    Support all resource types	Stack Parameter	TRUE
    Include global resource types	Stack Parameter	TRUE
    Central S3 bucket	Stack Parameter	Enter the AWS Config Log S3 bucket. (example: aws-controltower-logs-[Log Archive Account number]-[Home Region])
    Prefix for the specified Amazon S3 bucket	Stack Parameter	The Organization ID. (example: o-v1234563). This can be found in the Settings section of the AWS Organization console in the management account.

    Deploy AWS Config in all non-home enabled Regions of the management account

    In the CloudFormation console in the home Region of the management account, create a CloudFormation StackSet and use the below parameters (for parameters not in the table, you can leave the default values). This will deploy AWS Config in all enabled Regions except for the home Region of the management account. It is deployed with a delivery channel that is configured to send the configuration snapshots and configuration history files to the S3 bucket in the Log Archive account.
    

    Setting	Setting Type	Recommendation
    Permissions	Permission Type	Self-service permissions *By default, CloudFormation will use the CloudFormation Roles created in previous steps.
    Template Source URL	StackSet details	https://cloudformation-stackset-sample-templates-us-east-1.s3.us-east-1.amazonaws.com/EnableAWSConfigForOrganizations.yml *For home Regions not in us-east-1, change the Region in the URL to match your home Region
    StackSet Name	StackSet details	ConfigNonHomeRegions
    Support all resource types	StackSet Parameter	TRUE
    Include global resource types	StackSet Parameter	TRUE
    Central S3 bucket	StackSet Parameter	Enter the AWS Config Log S3 bucket. (example: aws-controltower-logs-[Log Archive Account number]-[Home Region])
    Prefix for the specified Amazon S3 bucket	StackSet Parameter	The Organization ID. (example: o-v1234563). This can be found in the Settings section of the AWS Organization console in the management account.
    Account Numbers	Set Deployment Options	Enter the management account ID.
    Specify Regions	Set Deployment Options	Enter in All enabled Regions except for the home Region.   *Note: you can check which Regions are enabled by clicking on the Region in the top right of the console. The enabled Regions are not grayed out.

    Deploy AWS Config in member accounts

    Follow the CloudFormation user guide to Enable trusted access with AWS Organizations.
    

    Enable trusted access for CloudFormation within your AWS Organization

    Follow the CloudFormation user guide to Enable trusted access with AWS Organizations.
    

    Deploy AWS Config to the Organization using CloudFormation StackSet with AWS Organizations

    In the CloudFormation console in the home Region of the management account, create a CloudFormation StackSet and use the below parameters (for parameters not in the table, you can leave the default values). This will deploy AWS Config in all member accounts and the Regions you select.
    

    Setting	Setting Type	Recommendation
    Permissions	Permission Type	Service Managed permissions
    Template Source URL	StackSet details	https://cloudformation-stackset-sample-templates-us-east-1.s3.us-east-1.amazonaws.com/EnableAWSConfigForOrganizations.yml *For home Regions not in us-east-1, change the Region in the URL to match your home Region
    StackSet Name	StackSet details	ConfigMemberAccounts
    Support all resource types	StackSet Parameter	TRUE
    Include global resource types	StackSet Parameter	TRUE
    Central S3 bucket	StackSet Parameter	Enter the AWS Config Log S3 bucket. (example: aws-controltower-logs-[Log Archive Account number]-[Home Region])
    Prefix for the specified Amazon S3 bucket	StackSet Parameter	The Organization ID. (example: o-v1234563). This can be found in the Settings section of the AWS Organization console in the management account.
    Deploy to Organization	Set Deployment Options	Enter the management account ID.
    Specify Regions	Set Deployment Options	Enter in All enabled Regions except for the home Region.   *Note: you can check which Regions are enabled by clicking on the Region in the top right of the console. The enabled Regions are not grayed out.

    Enable AWS Config Aggregator in production security tooling account

    By setting up an AWS Config Aggregator, you can effortlessly gather AWS Config configuration and compliance data from multiple accounts within your organization. This provides you with a comprehensive view of all the resources, configuration details, and compliance data across your organization, allowing you to easily query and analyze the information.

    In this section, you will delegate the management of AWS Config for your Organization to the Security Tooling account and set up an AWS Config Aggregator to collect the AWS Config data across your environment.
    

    Delegate AWS Config management to production security tooling account

    Leveraging AWS CLI, run the following command from your AWS management account. For a simplified setup, use AWS CloudShell inside your management account with an administrator role to have the necessary permissions to complete the CLI operations.
    

    Note: From your management account, delegate AWS Config to the production Security Tooling account.
    

    Command:
    

    aws organizations enable-aws-service-access --service-principal=config.amazonaws.com
    aws organizations register-delegated-administrator --account-id <SecurityToolingProdAccountId> --service-principal config.amazonaws.com

    Code snippet copied

    Copy

    Create AWS Config Aggregator in production security tooling account

    Leveraging AWS CLI, run the following command from your AWS security tooling account. For a simplified setup, use the AWS CloudShell inside your security tooling using an administrator role to have the necessary permissions to complete the CLI operations.
    

    Note: Log into your Security Tooling account to configure the next step.
    

    1. Create an IAM role, so AWS Config can aggregate the data:
    

    aws iam create-role --role-name OrgConfigRole --assume-role-policy-document "{\"Version\":\"2012-10-17\",\"Statement\":[{\"Sid\":\"\",\"Effect\":\"Allow\",\"Principal\":{\"Service\":\"config.amazonaws.com\"},\"Action\":\"sts:AssumeRole\"}]}" --description "Role for organizational Config aggregator"

    Code snippet copied

    Copy

    2. Copy the outputted ARN of the role
    

    3. Attach the AWSConfigRoleForOrganizations to the role we just created:
    

    aws iam attach-role-policy --role-name OrgConfigRole --policy-arn arn:aws:iam::aws:policy/service-role/AWSConfigRoleForOrganizations

    Code snippet copied

    Copy

    This policy allows the OrgConfigRole to call the following AWS Organizations APIs: DescribeOrganizations, ListAWSServiceAccessForOrganizations, and ListAccounts.
    

• Enabling foundational cost observability

  • Scenario
  • Overview
  • Implementation

  • Scenario

  • Enabling foundational cost observability 
    

    • Enable AWS Cost Explorer
    • Setup Cost and Usage Reports
  • Overview

  • Set up the right mechanisms and tools to monitor your resources. These tools allow you to create reports, dashboards, and anomaly detection of the cloud spend of your budget. These also help you plan for cost optimization to avoid or reduce unnecessary costs.

    Supporting Cloud Foundations capability:
    

    • Cloud Financial Management
  • Implementation

  • Enable Cost Explorer

    AWS Cost Explorer is a tool that enables you to view and analyze your AWS costs and usage. Enabling Cost Explorer in the management account allows you to analyze AWS cost and usage for your entire AWS Organization. To use Cost Explorer, it must be enabled. Note that Cost Explorer will take approximately 24 hours to generate the current month’s costs. The trailing 12-month costs and 12-month forecast will be available a few days later. Also note that Cost Explorer can only be enabled through the console.

    In this section, you will enable Cost Explorer for your AWS environment.

    Enable Cost Explorer

    You can Enable Cost Explorer for your account by opening Cost Explorer for the first time in the AWS Cost Management console.

    Setup Cost and Usage Reports

    The AWS Cost and Use Reports (AWS CUR) provide the most detailed cost and usage statistics available. You may utilize AWS CUR to publish your AWS billing reports to a bucket owned by you on Amazon S3. To find out more about AWS CUR, refer to What are AWS Cost and Usage Reports user guide.

    In this section, you will set up Cost and Usage Reports for your AWS environment.

    Create Amazon S3 Bucket for Cost and Usage Reports

    You will need to create an Amazon S3 bucket to use as a destination for AWS CUR. You can create this S3 bucket in the console as you create the Cost and Usage report, or follow the instructions for Setting up an Amazon S3 bucket for Cost and Usage Reports.
    

    Enable Cost and Usage Reports

    Create and configure Cost and Usage reports (CURs) following the AWS Cost and Usage Reports User Guide.

    Below is a suggested configuration for your first Cost and Usage report:
    

    Parameter	Description	Recommendation
    Report Name	The name for this Cost and Usage report	cur-hourly
    S3 Bucket	The S3 bucket that will be used to receive and store your Cost and Usage reports.	You can create this bucket in the console as you create your Cost and Usage report.
    Report path prefix	A prefix that will be prepended to the name of your report.	cur-hourly
    Time Granularity	The time granularity on which report data are measured and displayed.	hourly
    Enable report data integration for	Determines the data format to allow integration with Amazon Athena, Amazon Redshift, or Amazon QuickSight.	Amazon Athena

    The Cost and Usage report will take up to 24 hours. For how to view and understand your report, see the Managing your Cost and Usage Reports user guide.
    

    Querying Cost and Usage Reports using Amazon Athena

    Amazon Athena is a serverless query service that you can use to analyze the data from your Cost and Usage Reports in Amazon S3 using standard SQL. Follow the Setting up Athena using AWS CloudFormation templates documentation to set up Athena for your queries.
    

    Create Cost visualization dashboard

    To visualize your Cost and Usage Reports data, you can deploy Cost Intelligence Dashboards (CIDs). Follow the Cloud Intelligence Dashboards Deployment Command Line Interface tool to create dashboards from AWS Cost and Usage Reports.
    

• Establishing tagging

  • Scenario
  • Overview
  • Implementation

  • Scenario

  • Establishing tagging 
    

    • Create a tagging dictionary
    • Enable Cost Allocation Tags
  • Overview

  • Tags are a key and value pair applied to a resource to hold metadata about that resource. Each tag is a label consisting of a key and an optional value. Not all services and resource types currently support tags (see Services that support the Resource Groups Tagging API). 

    It is essential to define a strategy to tag your resources as soon as possible during your cloud journey. As your overall environment expands and matures, this allows you to identify resources or groups of resources quickly. When defining your tagging strategy, you need to determine the right tags that will help you gather all the information across your environment.
    

    Supporting Cloud Foundations capability:
    

    • Tagging
  • Implementation
  • Create a tagging dictionary

    It is important to use a consistent approach to tagging your AWS resources. A tagging dictionary helps you achieve this consistency by maintaining and publishing:
    

    • A documented set of mandatory and optional tags
    • Definitions or purpose of each tag
    • Allowed tag values for each tag key (where applicable)
    • Proper case format of tag keys and values (tags are case-sensitive)

    In this section, you will build a tagging dictionary for your foundational environment.
    

    Define initial tagging dictionary

    As part of your tagging dictionary, you should define certain tags that can be used to access specific resources based on the tags attached to a role at a certain time. These tags can be used for a temporary escalation of privileges, or for deploying changes through infrastructure as code that other identities may not have access to.

    Below is a suggested set of mandatory tags that would be applied to all supported resources:

    Tag Key	Tag Purpose	Sample Tag Values	Observations
    Owner	This tag is used to indicate the owner of the resource.	SecurityLead, SecOps, Workload-1-Development-team	This value should represent a team or a title, given that humans come and go, but the function would remain within your environment.
    BusinessUnit	This tag indicates the business unit for the resource.	Finance, Retail, API-1, DevOps
    Environment	This Tag is used to indicate the lifecycle stage for the resource	Sandbox, Dev, PreProd, QA, Prod, Testing
    CostCenter	This Tag is used to indicate the cost center associated with the resource.	FIN123,Retail-123,Sales-248,HR-333
    FinancialOwner	This tag is used to indicate the Financial Owner associated with the resource.	HR, SecurityLead, DevOps-3, Workload-1-Development-team	This value should represent a team or a title, given that humans come and go, but the function would remain within your environment.
    Compliance	This tag is used to indicate if the resource is subject to any compliance requirement.	FN/A, NIST, HIPAA, GDPR

    Publish tagging dictionary

    The tagging dictionary needs to be made available to builders and stakeholders. This helps ensure that tags are applied consistently across the environment. Once an initial tagging dictionary is defined, publish it internally in a shared location. 
    

    Note: It is not necessary to publish the tagging dictionary to development teams yet. However, it is beneficial to publish this tagging dictionary to the engineers who are building out the environment so that the foundational resources can be tagged in accordance with the mandatory tags.
    

    Enable Cost Allocation Tags

    Cost allocation tags allow you to track your AWS costs on a detailed level. After you activate cost allocation tags, AWS uses the cost allocation tags to organize your resource costs on your cost allocation report to make it easier for you to categorize and track your AWS costs. AWS provides two types of cost allocation tags: AWS generated tags and user-defined tags.
    

    AWS-generated cost allocation tags

    The AWS generated tags createdBy is an AWS-generated cost allocation tag that AWS defines and applies to supported AWS resources for cost allocation purposes.

    To use the AWS generated tags, a management account owner must activate it in the Billing and Cost Management console. Management account owners can activate the AWS generated tags in the Billing and Cost Management console, which activates this tag for all member accounts. This tag is visible only in the Billing and Cost Management console and reports.
    

    User defined cost allocation tags

    User-defined cost allocation tags are tags that you define, create, and apply to resources. After you have created and applied the user-defined tags, you can activate by using the Billing and Cost Management console for cost allocation tracking. 

    In this section, you will enable Cost Allocation tags.
    

    Enable Cost Allocation tags

    Activate the AWS-generated cost allocation tags in the management account following the AWS Billing User guide.
    

    Note: Cost allocation tags can take up to 24 hours to populate. If you don’t see any AWS-generated cost allocation tags in the AWS Billing console, return after 24 hours.
    

• Foundational hardening

  • Scenario
  • Overview
  • Implementation

  • Scenario

  • Foundational hardening 
    

    • Enable AWS account management
    • Delegate IAM Identity Center
    • Harden member accounts
    • Delete default network resources in Management Account
    • Configure management account alerting
    • Configure Identity and Access Management (IAM) password policy in management account
    • Set Amazon S3 public block access in accounts
    • Enable baseline AWS Config rules for Organization
    • Create and attach organization hardening SCPs
  • Overview

  • After deploying your basic foundational environment, we recommend you enhance the security of your environment by following a few hardening best practices. The foundational hardening actions will promote the overall security of your new environment and implement a least-privilege access model. The actions do this by isolating the management account, setting monitoring and alerting mechanisms in all your AWS accounts, and removing unnecessary resources.
    

    Supporting Cloud Foundations capabilities:
    

    • Identity Management & Access Control
    • Workload Isolation
  • Implementation
  • Enable AWS Account Management

    Manage the contact details for your member AWS accounts to help deliver timely information to the appropriate audience. These alternate contacts are used for messaging and alerting for the specific member AWS account activity. Every AWS account will have the following alternate account contacts:
    

    • Billing – The alternate billing contact will receive billing-related notifications, such as invoice availability notifications.
    • Operations – The alternate operations contact will receive operations-related notifications.
    • Security – The alternate security contact will receive security-related notifications, including notifications from the AWS Abuse Team.

    In this section, you will set up the ability to manage these member AWS account alternate contacts across your entire AWS Organization, and then update all member account alternate contacts.
    

    Enabling trusted access for AWS Account Management

    To enable the management account in your organization to call the AWS Account Management API operations for other member accounts in the organization, follow the steps on the Enabling trusted access for AWS Account Management.
    

    Set member account alternate contacts for operations, security, billing

    To ensure the right people are notified, add an alternate contact for Billing, Operations, and Security communications for the AWS account.
    

    To set these contacts in your member accounts, log in to your management account using a role with AWS Organizations administrator and update the alternate contacts following the AWS. Update member AWS account alternate contacts documentation. You should provide email distribution groups for Billing, Operations, and Security for any newly created AWS account. 

    The example convention below helps map your distribution emails to the proper accounts.

    Alternate contact email	Email Example
    [account-alias]-billing@example.com	workload1-prod-primary-billing@example.com
    [account-alias]-operations@example.com	workload1-prod-primary-operations@example.com
    [account-alias]-security@example.com	workload1-prod-primary-security@example.com

    Delegate AWS IAM Identity Center

    Delegated administration provides a convenient way for assigned users in a registered member account to perform most IAM Identity Center administrative tasks. Even though your IAM Identity Center instance must always reside in the management account, you can choose to delegate administration of IAM Identity Center to a member account in AWS Organizations. This extends the ability to manage IAM Identity Center from outside the management account.
    
    In this section, you will create an AWS account and delegate IAM Identity Center management operations to the new account.

    Create IAM Identity Center Account and move to Infrastructure OU

    Follow the AWS Organizations guide to create an account for IAM Identity Center delegation. And, follow the email convention to identify the account quickly and move the account to the Infrastructure OU. For example, aws-idc-[org-identifier]@example.com.
    

    Note: The account does not manage any IAM Identity Center assignments for the management account, nor can any permission set leveraged in an assignment to the management account be managed from the IAM Identity Center account.
    

    Delegate IAM Identity Center

    While logged into the AWS management account, follow the instructions to Register a member account for delegating AWS Identity Center administration to the Identity Center AWS account
    

    Harden member accounts

    Any AWS account created through the AWS Organizations console will set up a new AWS account root user. By default, the password is not yet set for the account; however, the email address used to create the account can undergo the process of recovering the password to initially set the password.

    In this section, you will configure the password and enable MFA for the root user of the member account.

    Secure member account root users

    Follow the instructions for resetting lost or forgotten AWS password to set the password for your newly created AWS account root user.

    Once the password is set for the AWS account root user, you should enable MFA for the AWS account root user.
    

    To enable MFA for the root user:

    1. Sign in to the AWS Management Console.
       
    2. On the right side of the navigation bar, choose your account name, and then choose My Security Credentials.
    3. If necessary, choose Continue to Security Credentials.
    4. Expand the Multi-Factor Authentication (MFA) section.
    5. Choose Activate MFA.
    6. Follow the wizard instructions to configure your MFA devices accordingly. For more information, see Enabling MFA devices for users in AWS (IAM documentation).
       

    Delete default network resources in Management Account

    When you create a new account, a default virtual private cloud (VPC) is available in each AWS Region. A default VPC comes with a public subnet in each Availability Zone, an internet gateway, and settings to enable DNS resolution. We recommend that you delete the default VPCs in all accounts.

    In this section, you will remove the default VPC resources in your management account.
    

    Template Resource: Leverage the Cloud Foundations script resource Network Default VPC Deletion to quickly complete the tasks.
    

    Delete default VPCs in each Region of the management account

    Follow the below steps to delete the default VPCs in each Region of the management account:

    1. In the AWS Management Console, change to the Region you plan to work in. This Region selection is in the upper right-hand drop-down menu.
    2. In the AWS Management Console, choose Services, then select VPC.
    3. From the left-hand menu, select Your VPCs.
    4. In the main panel, the checkbox next to the default VPC should be highlighted. You can verify this is the default VPC by scrolling to the right. The Default VPC column will be marked with Yes.
    5. With our default VPC checked, locate and select the Actions dropdown, and select Delete VPC.
       
    6. In the Delete VPC Panel, check the box 'I Acknowledge that I want to delete my default VPC' and select the Delete VPC button in the bottom right.
       
    7. Confirm deletion by typing “delete default VPC” in the confirm deletion field.
       
    8. You should get a green highlighted dialog stating 'The VPC was deleted' and you can select Close. If it is red, then likely something is deployed into this VPC and you will have to remove those resources (items such as EC2 instances, NAT Gateway, VPC, and endpoints all prevent your VPC from deleting). You could also consider another Region from the list above.

    Configure management account alerting

    Your CloudTrail is configured to send CloudTrail events to an Amazon CloudWatch Log group in the management account. This allows you to create a CloudWatch alarm based on log patterns in a CloudTrail CloudWatch Log group. Because Service Control Policies do not apply to the management account, it is important to configure alerting in the management account on unwanted events.

    In this section, you will create an alert and notification for root user login events.
    

    Create a metric filter

    In the home Region of your management account, follow the steps for Creating a metric filter in CloudWatch from the CloudWatch User Guide to create a metric filter. This metric filter will identify root user activity using the CloudTrail log group. You will create this metric filter for the log group ‘aws-controltower/CloudTrailLogs’ using the below parameters. 
    

    Note: Make sure you tag your metric filter with the correct values that you decided on during the creation of your tagging dictionary.
    

    Parameter	Description	Recommendation
    Filter Pattern	The pattern that will be used to match terms in log events.	{$.userIdentity.type="Root" && $.userIdentity.invokedBy NOT EXISTS && $.eventType !="AwsServiceEvent"}
    Filter name	Name to identify the metric filter.	RootUserActivityFilter
    Metric namespace	The metric namespace is a container for CloudWatch metrics. The metric filter will create a CloudWatch metric within this namespace. This namespace should be used for all management account CloudTrail based metric filters.	LogMetrics
    Metric name	The CloudWatch metric name for this metric. It must be unique within the namespace.	RootUserActivity
    Metric value	Metric value is the value published to the metric name when a Filter Pattern match occurs.	1
    Default value	The default value is published to the metric when the pattern does not match. If you leave this blank, no value is published when there is no match.	(leave blank/default)

    Create alarm

    Create the CloudWatch Alarm for the metric filter that you have created.

    1. Go to the ‘aws-controltower/CloudTrailLogs’ CloudWatch Log Group in the home Region of the management account
       
    2. Select Metric filters
       
    3. Select the check box for the Metric filter that you have created (example: ‘RootUserLogin’)
       
    4. Select Create alarm
       
    5. Create the alarm using the below parameters:

    Parameter	Description	Type	Recommendation
    Statistic	The statistic for the metric specified in MetricName.	Metric and conditions	Sum (default)
    Period	The length, in seconds, used each time the metric specified in Met- ricName is evaluated. Valid values are 10, 30, and any multiple of 60.	Metric and conditions	5 minutes (default)
    Threshold type	The type of threshold for the alarm (Static or Anomaly Detection).	Metric and conditions	Static (default)
    Alarm Condition	The condition that will cause the alarm to invoke.	Metric and conditions	Greater/Equal
    Threshold value	The value that defines the threshold where the alarm will invoke.	Metric and conditions	1
    Alarm State Trigger	The alarm state that will invoke a defined action. In this example, it will invoke, sending a notification to the Amazon Simple Notification Service (Amazon SNS) topic.	Notification	In Alarm
    SNS Topic	The SNS topic where the alarm notification will be sent when the alarm is "in alarm" state.	Notification	Create new topic
    New Topic name	Unique name of new SNS topic name	SNS configuration	ManagementAccountCloudWatchAlarm For future management account alarms in the home Region, we recommend using the same SNS topic.
    Email endpoints	Email endpoints that will receive the notification of alarm.	SNS configuration	Use an email(s) that you want to receive the alerts. You must Confirm the subscription from the email after you configure alarm.
    Alarm Name	Name for the CloudWatch Alarm	Name and Description	RootUserActivityAlarm

    Configure IAM password policy in management account

    You can set a custom password policy on your AWS account to specify complexity requirements and mandatory rotation periods for your IAM users' passwords. If you don't set a custom password policy, the default AWS password policy will be used. For more information, see Setting an account password policy for IAM users in the AWS IAM documentation.

    In this section, you will set the IAM password policy for security and compliance.

    Configure password policy to company standard in management account

    Create a custom password policy to enhance your security posture:

    • Sign in to the IAM dashboard from the AWS Management Console.
      
    • In the navigation pane, choose Account settings.
      
    • In the Password policy section, choose Change password policy.
      
    • Select the options that you want to apply to your password policy, and then choose Save changes.

    Set Amazon S3 public block access in accounts

    By default, new Amazon S3 buckets and objects don't allow public access. However, users can modify bucket policies or object permissions to allow public access. Amazon S3 Block Public Access provides settings for access points, buckets, and accounts to help you manage public access to Amazon S3 resources. 

    Due to their function and criticality, your Foundational accounts should not contain S3 buckets that allow public access. By configuring S3 block public access at the account level, you can ensure that data is not exposed publicly due to a misconfigured bucket.

    In this section, you will configure security controls for S3 public access.
    

    Configure Amazon S3 block public access in the management account

    From the management account, follow the Amazon S3 documentation for Configuring block public access settings for your account.
    

    Configure Amazon S3 block public access in member accounts

    In each member account (all accounts except for the management account), follow the Amazon S3 documentation for Configuring block public access settings for your account.
    

    Note: If you have already created an S3 bucket that is providing public access, setting S3 block public access at the account level will stop this access. If public access to the S3 bucket is required, we recommend moving the S3 bucket to a Workload OU account that is dedicated to serving public S3 data. You would not enable S3 block public access on that account.
    

    Enable Baseline AWS Config rules for the Organization

    AWS Config provides AWS managed rules, which are predefined, customizable rules that AWS Config uses to evaluate whether your AWS resources comply with common best practices.

    In this section, you will enable baseline hardening AWS Config rules for all accounts in the organization.

    Enable AWS Config rules for all accounts

    Enable the below AWS Config rules in each account and operational Region in your organization.

    AWS Config Rule	Rule Description	Behavior
    ROOT_ACCOUNT_MFA_ENABLED	Detect whether MFA for the root user is enabled	Detective
    S3_BUCKET_PUBLIC_READ_PROHIBITED	Detect whether public read access to Amazon S3 buckets is allowed	Detective
    S3_BUCKET_PUBLIC_WRITE_PROHIBITED	Detect whether public write access to Amazon S3 buckets is allowed	Detective
    MFA_ENABLED_FOR_IAM_CONSOLE_ACCESS	Detect whether MFA is enabled for AWS IAM users of the AWS Console	Detective
    IAM_USER_MFA_ENABLED	Detect whether MFA is enabled for AWS IAM users	Detective

    You can deploy these AWS Config rules as Organization Config rules from the Management or Delegated AWS Config Administrator account.   

    Create and attach organization hardening SCPs

    Service control policies (SCPs) 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 you to ensure your accounts stay within your organization’s access control guidelines.

    We recommend that you create and attach the following SCPs from the AWS Organizations console to help strengthen your organization’s foundation.

    In this section, you will create and attach AWS organization SCPs.
    

    Create and attach SCPs using AWS Organizations

    Create and attach the SCP in the below example, following the AWS Organizations user guide for creating and attaching SCPs.
    

    SCP	SCP Target	SID
    Prevent Member from leaving the organization	All top level OUs except for Exceptions.	PreventMemberLeaveOrg
    Prevent resource sharing outside the organization	All top level OUs except for Exceptions.	PreventResourceSharingOutsideOrg
    Prevent root user from performing any actions.	All top level OUs except for Exceptions.	PreventRootUserFromPerformingAnyActions

    Reference Template: Review the example SCP policy statements from the above table in the Service Control Policy.
    

    You can reference additional example SCPs provided in the AWS Organizations user guide.
    

    Note: We recommend that you do not attach SCPs to the root of the organization because those policies will apply to all member accounts in the organization. Instead, for policies that you want to apply to the entire organization, we recommend attaching them to all top level OUs except for the Exceptions OU.
    

    Remove unnecessary IAM users

    To strengthen the security of your AWS account, delete any unnecessary IAM user credentials (passwords and access keys). We strongly recommend that your management account should not have any IAM users, and that you use AWS Identity Center users for standard use. There are exceptions to having IAM users in your management account which include Break-Glass access which is not covered in this Guidance. All standard user web console and API access should be conducted through IAM Identity Center.

    In this section, you will delete any unneeded IAM users in your management account.

    Delete IAM users

    Log into the management account using the IAM Identity Center administrator user role and delete any unnecessary IAM users following the Deleting IAM users section of the IAM user guide.