How does Control Tower Operate? – Designing a Multi-Account AWS Environment for Complex Organizations – SAP-C02 Study Guide

How does Control Tower Operate?

Upon setup, Control Tower deploys a certain number of resources in your organization. It leverages CloudFormation templates through stacks and stacksets to deploy and manage these resources. The following steps will further explain the process:

• First, Control Tower will create a root for your new organization or reuse your existing organization root, depending on your specific case.
• It will then create two OUs, security (always) and sandbox (optional) under that root structure. Within the Security OU, Control Tower will create two accounts—a log archive account and an audit account. The log archive account is meant to serve as a central repository for the CloudTrail and CloudWatch logs delivered from the various accounts inside your landing zone, to track API activities and resource configurations. The audit account is a restricted access account dedicated to your security and audit teams (think compliance here) to review the accounts in your landing zone.
• Control Tower will then set up AWS SSO with a user directory, preconfigured groups, and SSO access. These preconfigured groups can then be used to organize the users who, depending on their roles, will need to perform specific tasks in your landing zone accounts. If you already have a third-party identity provider (IdP) such as Okta in place, you can also integrate that IdP with AWS SSO and synchronize your users between the two, using System for Cross-domain Identity Management (SCIM), for instance. Integration with Microsoft Active Directory (MS AD) is slightly different in the sense that, in that case, Control Tower will not manage the SSO directory.
• Eventually, Control Tower will apply a number of preventive guardrails to enforce best practices. Preventive guardrails are meant to block unauthorized actions that could lead to policy violations from happening.
• Control Tower will also apply some mandatory detective guardrails to detect configuration violations. Note that preventive guardrails apply in all AWS regions, while detective guardrails only apply in those AWS regions where Control Tower is supported. Note also that mandatory guardrails are enabled by default; while strongly recommended, elective guardrails are not enabled by default, so it’s for you to decide whether to activate them.

Preventive guardrails are implemented using SCPs, while detective guardrails are implemented using AWS Config rules and AWS Lambda functions.

The following is an example of a mandatory preventive guardrail implemented by Control Tower using SCPs, which prevents any change to CloudTrail settings by Control Tower itself:

{

  “Version”: “2012-10-17”,

  “Statement”: [

    {

      “Sid”: “GRCLOUDTRAILENABLED”,

      “Effect”: “Deny”,

      “Action”: [

        “cloudtrail:DeleteTrail”,

        “cloudtrail:PutEventSelectors”,

        “cloudtrail:StopLogging”,

        “cloudtrail:UpdateTrail”

      ],

      “Resource”: [“arn:aws:cloudtrail:*:*:trail/awscontroltower-*”],

      “Condition”: {

        “ArnNotLike”: {

        “aws:PrincipalARN”:”arn:aws:iam::*:role/

          AWSControlTowerExecution”

        }

      }

    }

  ]

}

The example below illustrates detective guardrails. It configures a mandatory guardrail implemented by Control Tower on the Security OU that detects whether public read access is enabled on the S3 buckets within the accounts belonging to that OU:

AWSTemplateFormatVersion: 2010-09-09

Description: Configure AWS Config rules to check that your S3

buckets do not allow public access

Parameters:

  ConfigRuleName:

    Type: ‘String’

    Description: ‘Name for the Config rule’

Resources:

  CheckForS3PublicRead:

    Type: AWS::Config::ConfigRule

    Properties:

      ConfigRuleName: !Sub ${ConfigRuleName}

      Description: Checks that your S3 buckets do not allow public read access.

If an S3 bucket policy or bucket ACL allows public read access, the bucket is noncompliant.

      Source:

        Owner: AWS

        SourceIdentifier: S3_BUCKET_PUBLIC_READ_PROHIBITED

      Scope:

        ComplianceResourceTypes:

          – AWS::S3::Bucket

In the preceding example, the intention is to report any S3 bucket with public read access enabled in the log archive and audit accounts.