Introduction

When customers get started on AWS Cloud in order deploy their workloads by consuming AWS Cloud services, the first step for them is to create an AWS Account. An AWS Account is a dedicated container in which customers launch and manage their workloads and services. An AWS Account provides customers necessary security isolation and resource independence for their workloads along with the administrative capabilities to manage them in a self-service model. Customers pay for their usage of AWS Services on a pay-per-usage model through the Billing Console on their AWS Account.

As customers scale their usage on the AWS platform, they need multiple environments each with its own security boundaries, user access, billing console and administrative controls. The multi-environment model is necessary for customers to segregate workloads, provide access to various functional teams, track resource usage and support various lines of business within the organization. Customers then deploy the environment-specific workloads into these segregated AWS accounts and provide access to required users based on their team and persona. For example, customers create AWS accounts based on environments such as Dev account/ Prod account etc. or based on lines of business such as Marketing account/sales account etc.

A multi-account setup on AWS cloud needs well managed security controls, governance and user management. Manually setting up a multi-account environment on AWS cloud is time consuming, prone to errors and increases cost.

In order to build multi-account setup, AWS recommends a best practices framework called the ‘AWS Landing zone’ that provides customers an opinionated, secure and scalable construct. AWS Landing zone is a best-practices based, well-architected, multi-account environment that helps customers jump start their AWS cloud journey. AWS recommends the landing zone as the starting point for customers as they scale forward in their cloud journey.

This intent of this blog post is to serve as a security starter kit for our customers on their cloud journey covering the best practices, security guardrails, root user security and other aspects of multi-account model. The intended audiences for this blog post are AWS Cloud architects, AWS cloud administrators, AWS security architects and AWS Cloud developers.

Objective

The key objectives of this blog are to discuss in detail the following aspects -

  • Automated way for multi-account landing zone setup done through AWS Control tower
  • AWS account access model
  • Recommended security guardrails for the multi-account environment.
  • Core security configurations post account setup.
  • Various AWS security monitoring services for the multi-account environment.

Drivers and Motivation for Security of multi-account setup

The key considerations for customers on their AWS multi-account setup are given below -

  • Create a secure, scalable, well-architected, best-practices based and extensible construct to manage workloads in AWS.
  • Create security guardrails to ensure compliance to regulatory guidelines and organization policies.
  • Ensure compliance to regulatory and organizational requirements.
  • Enable agility to respond to evolving changes.
  • Share the common resources across various workloads.
  • Centralize the log management, identity and access management.
  • Integrate with existing on-prem systems and services.
  • Continuously monitor and evaluate the workloads and accounts against security best practices and remediate any deviations.

The solution framework to cover the above considerations is discussed in the next section.

Solution

The proposed solution framework comprises of a five-step process that provides customers a path to building the landing zone environment with comprehensive security and monitoring controls. The five-step process as depicted in Fig 1 will cover the core security guardrails, security configurations post account setup and the key security monitoring services.

Tech blog resized images
Figure 1 Solution framework for secured multi-account setup

In step 1, we setup the landing zone using AWS control tower to securely setup the account hierarchy. In step 2, we setup the appropriate account access defining the account customers and their access. We then define the preventive and detective security guardrails in step 3. In step 4, we configure the advanced security configurations. Finally, in step 5, we configure continuous real-time security monitoring setup to identify and handle the security incidents.

Table 1 provides the brief details of all the AWS services that we will use as part of the solution.

Tech blog resized images
Table 1 AWS Services used in the solution

Let us now look into each of these steps in detail in the following sections.

Step -1: Landing zone setup using AWS Control Tower

In order to build the landing zone manually, customers create the organization hierarchy and multiple AWS accounts by providing the appropriate access controls. The manual process for building the multiple account setup is time consuming and error prone. Hence customers require an AWS managed service to automate the landing zone setup activities.

AWS Control Tower is the AWS service that automates the multi-account environment setup. AWS recommends using the AWS Control Tower to deploy the Landing Zone.

AWS Control Tower is used to setup the core AWS accounts (log archive, audit, security) and custom AWS accounts (such as Production account, UAT account, dev account etc.) and also setup the preventive and detective guardrails for the accounts. AWS Control Tower helps customers create the AWS accounts as part of the AWS organization.

Given below are the key benefits of using AWS Control Tower for the landing zone setup:

  • Automate the creation of account hierarchy and extending it to suit the organization needs.
  • Enable the customers with best-practices’ based blueprint and security guardrails.
  • Enable customers to create centralized log archival account and centralized identity and access management.
  • Provide features to clearly define the security boundaries for each of the accounts and share the commonly used services across accounts.
  • Enables customers to establish security baseline and configuration baseline that can be continuously monitored.

A typical landing zone with multi-account structure is depicted in Figure 2:

Tech Blog-resized image
Figure 2 Sample Landing Zone

The details of the AWS accounts that are created using AWS Control Tower are as given below -

  • Management account: Customers start their Landing Zone setup with this Account and use the Management Account to setup the AWS Organizations and Organization units (OU) using the AWS Control Tower. First step is to create core OU and Custom OU. For seamless multi-account access, AWS recommends customers to setup the AWS IAM Identity center (Successor to AWS SSO) along with users and permission sets provisioned for the various AWS Accounts created via Control Tower. The Management account is also used for centralized bill payment across all the AWS accounts.
  • Log archive account: The Log archive account holds the centralized S3 bucket for managing all the logs generated from AWS CloudTrail, Amazon CloudWatch and other services.
  • Audit Account: The Audit account contains services such as AWS Config and Amazon GuardDuty that will be required for auditing and compliance purposes. The Audit account receives the notifications related to configuration changes, security events and drifts across various other AWS accounts in the Landing Zone.
  • Shared Services account: All the services that are shared across various accounts is provisioned in this account. In this account, customers provision services such as Microsoft Active Directory, cross-account IAM Roles, Custom Firewalls/IDS/IPS Services, Monitoring Services and various other tools that they bring into AWS.
  • Workload accounts: Customers also create various project specific or environment specific accounts where they can provision the workloads. Separate accounts for Development, UAT and Production are typically created.

Log archive, shared services and audit accounts are created under core organization unit (OU) and workload accounts are created under custom organization unit (OU).

Step – 2: Setup Appropriate Account Access

Setting up Users, Roles and Access into these various AWS accounts created as part of step 1 is a critical process. Access to an AWS account should be implemented on the principle of least privilege by providing only the required access on required resources for the right users. This step details the account access details across various accounts in the multi-account setup.

It is recommended to use AWS IAM Identity center (successor to AWS SSO) for centralized access management. For access management we use AWS IAM policy that defines a permission of an AWS resource (such as user, user group, AWS service or role) to which it is associated with. A permission set is a collection of IAM policies that eases the management of permissions assigned to a user of the AWS organization.

Grouping users into user groups helps in efficient governance. AWS IAM policies are applied to various user groups for each of the accounts. Table 2 defines the user groups including administrators (group of users who are involved in system administration), operations (group of users who handle incidents), security (group of users who verify and setup the security configuration), developers (group of users who develop the applications and services).

Table 2 details the recommended account access permissions for various user groups.

Tech blog resized images
Table 2 User Access to Accounts

Step – 3: Enable Security Guardrails

Security guardrails provide managed rules for security, operations and compliance that can be applied to organizations and accounts. For instance, administrators should define a security guardrail to ensure that all data uploaded to AWS S3 bucket to be encrypted. The guardrails ensures the data-at-rest encryption-related organization policy.

The security guardrails are initially assigned by the administrator during the landing zone setup. Customers should also enhance and fine tune the guardrails later based on the organization policies and regulatory and compliance requirements.

It is recommended to enable preventative and detective guardrails to ensure compliance, resource governance, monitoring and effective cost management.

Preventative guardrails
Preventative guardrails restrict the actions based on the defined rules. Preventative Guardrails are enabled through AWS Service Control Policy (SCP) which is a rule that defines the policy for managing the permissions for an AWS organization. Customers should attach the SCP at the organization unit (OU) level or at an AWS account level.

Detective Guardrails
Detective guardrails monitor and detect the configuration violations against the baseline configurations. Detective guardrails are enabled through AWS Config as defined in Table 1 AWS Services used in the solution.

Recommended Guard rails across services

We have provided various security guardrails that can be enabled across AWS services. The list given below specifies the guidance type (elective, mandatory or strongly recommended), the organization unit (core or custom) and behavior (Prevention or detection). It is recommended to implement the mandatory and strongly recommended guardrails and implement elective guardrails as needed. The list given below serves as a good starting point and customers can further create custom guardrails based on their requirements.

Elective Guardrails

Mandatory Guardrails

Strongly Recommended Guardrails

Step - 4: Security configurations post account setup

Once the AWS accounts are setup with the security guardrails, customers should strengthen the AWS cloud security posture to meet organization’s security and compliance needs.

Customers should configure additional security controls post account setup. Customers should setup security event monitoring, threat intelligence monitoring, encryption controls, compliance monitoring and other necessary security controls.

Table 3 provides the recommended security configurations and corresponding AWS services and best practices that needs to be enabled once we setup the account. The additional security controls in table 3 enhances the security posture of the AWS account.

Tech blog resized images
Table 3 - Recommended Security Configurations Post-Account Setup
Tech blog resized images
Continuation of Table 3 - Recommended Security Configurations Post-Account Setup

We have given the core security guidelines and recommendation in Appendix 1 for reference.

Step – 5: Continuous Security Monitoring

Continuous security monitoring is required to detect and mitigate the security incidents in real time. Customers should monitor the security events (such as login events, password change events, failed login attempts), network traffic, compliance violations and audit the API calls. Customers should enable continuous and real time security monitoring controls in AWS cloud as depicted in Figure 3.

Tech blog resized images
Figure 3 Continuous Security Monitoring Services

Logging: All the logs are stored centrally in the S3 bucket of the log archive account. We recommend leveraging native monitoring tools including Amazon CloudWatch and AWS CloudTrail and Amazon CloudWatch Events. Customers should use Amazon CloudWatch for collecting resource metrics and for triggering alarms. Amazon CloudWatch events monitor the real-time resource changes. We can configure rules for watching events of interest (such as Amazon EC2 launches or EC2 status changes) and sending out notifications. Additionally, it is also recommended to enable VPC Flowlogs for VPC traffic monitoring.

Auditing: Customers should enable AWS CloudTrail to audit the API call details. This helps customers to understand and analyze the account activity and identify any suspicious activities. Customers should use AWS CloudTrail to fulfil the auditing, governance and compliance requirements.

Threat Intelligence: Customers should use Amazon GuardDuty to continuously monitor the workloads and AWS accounts and to provide the security findings. Amazon GuardDuty leverages VPC flow logs, CloudTrail logs and DNS query logs to identity the threats based on Machine Learning Models.

Continuous compliance and Governance : Customers should use AWS Config to ensure compliance against standards such as ISO, SOC, PCI-DSS and others. Customers should use AWS Control Tower dashboard to monitor the compliance of organization units (OU) against the defined guardrails.

Continuous cloud security posture management: Customers should use AWS Foundational Security Best Practices standard of AWS Security Hub to continuously evaluate and detect the deviation of accounts and workloads from the security best practice. Use AWS Foundation Security Checks in Security Hub to identify security issues. Leverage AWS Security Hub to build incident response system for auto remediation.

Continuous near-real time monitoring: Customers should use cloud native tools such as Amazon CloudWatch events, Amazon OpenSearch for log analytics and events and Amazon CloudWatch alarms to trigger alarms and notifications to the system administrators.

Conclusion

This blog post discussed in detail a comprehensive solution to build a multi-account setup with all the required security controls and best-practices based configurations.

We discussed about how customers can use AWS Control Tower to build an automated multi-account setup, the key activities and account governance. We also discussed the recommended preventative and detective guardrails to ensure compliance to the defined standards. In order to build a robust security posture, we recommended customers should also use additional security controls such as Threat intelligence, Security Event monitoring, Encryption and key management), compliance monitoring (, Vulnerability and patch management , optimal access privileges , resource inventory and cost management. Finally, we discussed on a path to Sustaining the security posture as a continuous journey.

For further reading, we recommend to check out the document links in the reference section of this blog post

Appendix – 1 – Security Checklist

Tech blog resized images

References