Forem: ColWillis

Productionize multi AWS Accounts (org-formation Landing Zone)

ColWillis — Tue, 17 Aug 2021 11:59:12 +0000

Following-on from the 'Landing Zones, Organizations, OUs and Multi-Account Environments blog', I decided to "practice what I preach" with my personal AWS Accounts!

Currently I have 5-10 Accounts for different workloads (spikes, storage of personal data, web app hosting etc); I have had these accounts for many years and I manually used AWS Organizations via the Console to create & manage them

NO guardrails or SCPs have been implemented, I have probably deployed & configured some AWS services wrong and I have probably created IAM users with broad (*) permissions

The purpose of this blog is to address the above concerns; To refactor my accounts into a Landing Zone that follows the AWS best practices.

My Accounts - Current Account Architecture

The below Diagram shows my current Account structure

org-formation - Overview

Taken from github org-formation; AWS Organization Formation is an Infrastructure as Code (IaC) tool for AWS Organizations.

org-formation orchestrates CloudFormation and AWS Organizations for account creation and resource provisioning

Tasks / Features

Tasks files can be added to enable a variety of Automated features such as:

OrganizationAccountAccessRole restrictions (SCPs)
Budget Alarms
AWS Access Key Rotation checks
Enabling CloudTrail
Centralising and Enabling Guard Duty
Many IAM Configurations (Password Policy, force MFA)
Many S3 Configurations (Prohibit Read & Write, Enable encryption)
VPC Security Groups conform to (user-defined) ALLOW list

This feature list is what I intend to implement on my Accounts.
For the full list of available org-formation features, please refer to the 40mb pdf

FYI on Tooling Decision

Control Tower? Terraform? CloudFormation? org-formation? CDK?...

It is not the purpose of this post to go into the detailed comparisons of these tools.

I am an AWS Architect at Version 1, I have experienced all of the above tools used to produce Landing Zones for Clients.

org-formation (DAPx)

One of the Version 1 DAPx Landing Zone Accelerators is built upon org-formation, I have used this for my Landing Zone.

It is not the purpose of this post to sell DAPx, please message me if you would like to know more about DAPx,

My Accounts - Target Accounts Architecture Design

The below diagram shows the Target Account structure that is aligned to the best practices & architecture detailed in the 'LZs, Organizations, OUs and Multi-Account Environments blog'

Development Summary

org-formation is a highly flexible and powerful toolkit, to prevent content bloat I will provide only a few code/console snippets for key important featues.

IAM Role - Account/OU Access

Secure Defaults

Budget Alarms

GuardDuty

AWS Config

Centralised AWS Config in the Master Account, AWS Config has access to all member/child accounts.
The LogArchive Bucket is in the LogArchive Account, this has Access Restrictions and Cleardown Policies by-default
AWS Config Findings Alerts (inc SNS Topic by-default), All AWS Config Managed Rules are available to use

CloudTrail

SCPs

The End Result

The below diagram shows the final Account Structure & AWS Services that have now been implemented

Cleanup on isle "Config Findings"

These Config Rule Alerts include:

access-keys-rotated
iam-password-policy
root-account-mfa-enabled
s3-bucket-server-side-encryption-enabled
vpc-sg-open-only-to-authorized-ports

Once I have remediated these I will feel a lot better about the security of my AWS accounts!

Thank you for reading, constructive feedback is welcomed.

Landing Zones, Organizations, OUs and Multi-Account Environments

ColWillis — Wed, 21 Jul 2021 16:33:54 +0000

This Post is a notes-summary of AWS Best Practices for:

Governance, risk, and compliance when establishing your cloud presence (AWS Blog Page)
Organizational Units with AWS Organizations (AWS Blog Page)
Managing the multi-account environment using AWS Organizations and AWS Control Tower (AWS Blog Page)

PART 1. Best Practices for... Governance, risk, and compliance when establishing your cloud presence

AWS Blog Page

Check the Management and Governance Lens (A Well-Architected Lens extension) This is built up from years of migrations and best practices learned along the way

Introducing a Landing Zone

Separation of concerns get more important and also difficult as companies grow in AWS
Separate costs for budgets and billing
Security enforcement, resource isolation

A Landing Zone is a...Well-architected multi-account AWS environment that is stable and secure

It is:

The starting point for your cloud journey
Built on AWS Organization w/ multiple accounts

Landing Zone Framework

Foundational OUs

Shared Services OU is for things like log archival, networking - Usually the responsibility of central teams

Infrastructure - Shared IT Services & Networking
Security - Log Archival, security tools, break-glass / forensics

Additional OUs

Sandbox OU to allow developers to have their own accountsa to spike/experiment
Workloads OU to isolate and tightly control production/app services
etc - These are a guide, pick which fits the company the best

Landing Zone Automation

2 Tools to assist here...

AWS Control Tower - AWS Managed Service to setup and govern multi-account env ** It uses AWS Organizations and a number of other services to automate the orchestration ** Easier option, minimal customisations; Still allows your to centrally manage governance and has preconfigured best practices
AWS Organizations - Use this directly, high levels of customisation Personal Note: Check out org-formation or Terraform

PART 2. Best Practices for... Organizational Units with AWS Organizations

AWS Blog Page

Apply SCPs at an OU Level
SDLC OUs - Think of having SCPs at each stage of the lifecycle of the application

e.g Different Policies in different Stages/Environments (Dev vs Test)
Deployments OU - If you have different governance and operational models for CICD compared to accounts in Workloads OU (Prod / SDLC)
** Reduces dependency on shared CI/CD environments
** Pipelines and CICD should match the operational model of the software service it builds and deploys
Infra OU may looks like this:
Security OU for hosting security-related services, should be managed by Security team(s)
Log Archive - Audits
ReadOnlyAccess - Humans for Read-Only permission, cross-account role from here
Breakglass - Humans in rare scenarios/security incidents, special authorisation would be required, all access to this logged in detail
Tooling - MINIMAL Humans, Master Account for Guard Duty, Security Hub and Amazon Detective...Human Access for Admin purposes only, infrequent
** IaC should be heavily used
Sandbox OU for individuals wanting to play, should limit internet access if possible
** Individuals Accounts created in here e.g ColinWillisAccount
Workloads OUs
Suspended OU - Accounts that are to be deleted from the Organisation
** Apply an SCP to deny all actions, add Tags for traceability if they need to be restored
** Accounts are permanent deleted after 90 days
Exceptions OU - Accounts that warrant exceptions to Security or Auditing conditions
** SCP may be applied directly to the accounts here

Think Top-Secret Project Account; it may have MORE scrutiny than standard accounts

PART 3. Best Practices for... Managing the multi-account environment using AWS Organizations and AWS Control Tower

AWS Blog Page

Permissions Management

Once Organization is created, enable AWS SSO
AWS SSO can recognize existing users and groups who need access
Prebuild in AWS or use External Identity store (like Azure AD or Okta)
SCP can restrict boundaries e.g Which AZ a user can work in
https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html is good to reference

** Preventative guardrails are SCPs that limit actions based on your policies.

** Detection guardrails are AWS Config rules paired with AWS Lambda

*** These detect noncompliant resources and alert you through the Control Tower dashboard for remediation

Security

AWS offers a feature called Delegated Administration, which allows you to designate an account (such as via Security Tooling Account) ** Use this to then manage the following AWS security and audit services on behalf of the entire organization

AWS Audit Manager - automates the continuous collection of evidence to help you audit your use of cloud services.
AWS Config - detects and provides mitigation recommendations for incorrectly configured resources.
Amazon GuardDuty - detects unexpected and potentially unauthorized and malicious activity in your AWS environment.
Amazon Macie - continuously evaluates your content to identify business-critical or potentially confidential data.
AWS Trusted Advisor - identifies opportunities to improve stability, save money, or help close security gaps.
IAM Access Analyzer - helps you identify any resources or data in your AWS environment that are shared with external entities.
AWS Security Hub - provides you with security checks and recommendations across your organization.

Security users can then centrally view and manage security events
NOTE: You may need to enable certain Security Services at the management/organizational account level

Account Management

After initial Organization setup, new or invited Accounts can be assigned to OUs
Integrated into AWS Organizations, these help you get accounts ready to use:

** AWS Resource Access Manager - Make resources available cross-account e.g EC2 Capacity Reservation, VPC Endpoints

** AWS CloudFormation StackSets - Share Stacks cross account e.g Automatically delete or create resources when an Account joins or leaves the Organization