Building a Landing zone with AWS Control Tower (part 2)
In the previous post, I explained what a Landing Zone is, what the preconditions for a Landing Zone to appear, and why and when you should consider creating a Landing Zone. I explained a bit about the AWS Control Tower and what a Landing Zone looks like from the organizational unit perspective, as well as a little about Controls (a.k.a. Guardrails).
In this and the following posts, I will explain the content of different accounts and Organizational Units in detail. Here, we start with the foundational AWS accounts (Management, Log Archive, and Audit).
Let’s get back to the following schema from the previous post and check the first three items separately:
Foundational (shared) accounts
By default, Management, Log Archive, and Audit accounts are present in every Landing Zone created by AWS Control Tower.
As a best practice for a well-architected multi-account environment, AWS Control Tower sets up accounts that offer isolated environments for specialized roles in your organization. These accounts are the dedicated hubs for management, log archival, and security auditing.
Let’s look at what those accounts have:
In the Management account tab, we can see the Baseline configuration, deployed by CloudFormation and Directory type for SSO:
Baseline configuration creates an organizational CloudTrail
CloudTrail will be automatically enabled in all member accounts, logs will be shipped to the S3 bucket in the Log Archive account
SSO configuration
The default SSO identity source will be the AWS Identity Center directory:
But later, you can configure and use AWS Managed Microsoft AD or any other external identity providers configured via SAML, such as Azure AD, Okta, JumpCloud, Onelogin, Google Workspaces, etc.
There are many useful options like MFA, Session duration, and Attribute-based access control (ABAC) available in the IAM Identity Center (a.k.a. AWS SSO)
Moreover, you can use it not only for access to AWS accounts but also for other applications (Grafana, Opensearch, ArgoCD, OpenVPN, etc.) configured via SAML.
I wrote a separate post on how to configure such access via SSO.
Log Archive account
This account contains a central Amazon S3 bucket for storing a copy of all AWS CloudTrail and AWS Config log files for all other accounts in your landing zone. As a best practice, we recommend restricting log archive account access to teams responsible for compliance and investigations, and their related security or audit tools.
In the Log Archive account tab, we can see the Baseline configuration, deployed by CloudFormation and S3 bucket for logs (Cloudtrail and AWS Config logs):
The S3 bucket is part of the initial baseline, deployed by CloudFormation StackSet, to the Control Tower Home region in the Log Archive account:
In general, the centralized logging would look like this:
We can have an S3 bucket for different AWS Services and applications. All member accounts can store logs in the Log Archive account. If just storing logs is not enough, we can configure the SIEM system to read logs and analyze (visualize) them.
One of SIEM solutions, based on AWS services (OpenSearch, Lambda, etc.) is available on GitHub.
SIEM on Amazon OpenSearch Service is a solution for collecting multiple types of logs from multiple AWS accounts, correlating and visualizing the logs to help investigate security incidents.
Here is a high-level diagram of the solution, but for a detailed demonstration we would need s separate article:
How the log visualization may look like:
SIEM systems are not for all companies due to the extra effort and costs, but they may be very useful during security event investigations.
Audit account
The audit account is a restricted account that’s designed to give your security and compliance teams read and write access to all accounts in your landing zone. From the audit account, you have programmatic access to review accounts, by means of a role that is granted to Lambda functions only. The audit account does not allow you to log in to other accounts manually.
In the Audit account tab, we can see the Baseline configuration, deployed by CloudFormation and IAM roles:
The AWS Config Aggregator is part of the initial baseline, deployed by CloudFormation StackSet, to the Control Tower Home region in the Audit account:
Two IAM roles are also created as a part of the initial baseline.
The audit account should be restricted to security and compliance teams with auditor (read-only) and administrator (full-access) cross-account roles to all accounts in the landing zone. These roles are intended to be used by security and compliance teams to:
- Perform audits through AWS mechanisms, such as hosting custom AWS Config rule Lambda functions
- Perform automated security operations, such as remediation actions
Audit accounts can be a delegated administrator for different security services (Security Hub, GuardDuty, Inspector, Macie, etc.)
We recommend that you enable Security Hub on the Control Tower Management account, and delegate the Audit account as the Security Hub delegated administrator account in all governed regions. On the Audit account, the “Auto-enabled” option should be selected, so that new accounts that are governed by Control Tower will be managed by the delegated account automatically.
Delegated Administrator can be configured from the Management account:
Next, you can aggregate findings from all Security services from all covered AWS regions in one place — Security Hub in the Audit account:
Integrate with Slack or Microsoft Teams via AWS Chatbot and get a quick and simple notification mechanism:
Conclusion
This is the second post about the Landing zone, where I demonstrated three foundational AWS accounts (Management, Log Archive, and Audit), baseline resources, and possible customizations, which are frequently implemented on projects. In the next part, we will look at the Infrastructure Organizational Unit and possible use cases for it.
