AWS Security Landing Zone through AWS Control Tower Service using Terraform automation

Introduction

The article gives an insight on the strategies and functionalities adopted for deployment of Landing zone on Amazon web services. It also enlists the services adopted as per best practices followed across industry and recommended by Amazon web services.

As per the best practices the decisions made as a part of application onboarding will be discussed with their benefits and the scalability of future will be laid emphasis on in the document.

This solution will deploy landing zone setup using Terraform infrastructure as a code (IaaC) along with surrounding security services.

Need of Building a Landing Zone/Control Tower – Enterprise Challenges

?

1.???????Multiple Design Decisions – As per the introduction of new projects and new team or third-party vendor solutions, Enterprises always have had the challenge of streamlining access, data classification with multiple design decisions to integrate the new projects and solutions into existing setup.

2.???????Management and Team collaboration Challenges– Different teams involved into application deployment makes it a challenge in maintaining a bridge between all for running or new upcoming tasks. Being on cloud everything is centralized, and use of Landing zone structure defines specific touch points to reduce operation issues.

3.???????Segregation of Duties/Multiple Accounts – Since separate teams wish to have controls on specific section with cloud management. Multi Account structure in Landing zone will provide access dedicatedly to the team member designated for the role. Example: Security team will have access only the Transit account

4.???????Compliance and Risk Management/Multiple Accounts – Separate AWS account for compliance management where all the logs are stored and becomes a central point and single source of truth for data and compliance management.

5.???????Centralized Policy management and Auditing – Baseline policies managed centrally for all the applications and services deployed across the Customer Amazon Web services structure.

About Landing Zone

1.????Security & Compliance

????????Enforce security at the global, OU and account level.

????????Consistent architecture for concerns like threat etc.

2.????Standardized Tenancy and Governance

????????Framework for creating and baselining a multi-account

????????Regulatory Concerns

3.????Identity and Access Management

????????Principle of least privilege by defining roles and access policies

4.????Networking

????????Designing and implementing highly available, resilient, and scalable network

5.????Operations

????????Centralized logging from various accounts leveraging different services

Cloudxchange.io’s Approach / Proposed Solution for Customer LZ with Control Tower

??Landing Zone solution deployed for Customer has three core accounts namely:

?

1.???????Transit/Network Account – Security Account with NGFW Gateway virtual machines deployed for security with active-active mode within a single cluster across Availability Zones. NXFW, F5, Proxy, WAF, DDOS & other required.

2.???????Log Archival Account – All the network flow logs, user activity logs, security logs will flow to a centralized account where the compliance and audit team can have access and view even the historical data relevant to the audit standards.

3.???????Security/Audit Account – Centralized management of alerts and potential threats at the platform level managed by AWS service called Guard Duty (VPC flow log analysis, DNS log analysis and IAM log analysis)

?

The surrounding accounts currently in functioning as depicted in the diagram

?

1.???????NON-Production Accounts – Development and UAT workloads are deployed and in phase of transitioning to the production account post active testing phase.

2.???????Production Account – Transition to the production.

3.???????Organization Account – AWS Master account for Organization management and Service control policies, SSO, Service Catalog etc.

4.???????Shared services - The Shared Services account is a reference for creating infrastructure shared services such as directory services, monitoring services, RODS DNS server etc.

??????????????????????????????????????

The accounts have specific projects deployed for now and in future they will have additional projects added to them based on the criteria specified in the below section.

Overview of the Architecture

Considering the best practices, following architectural considerations are recommended:

1)????The architecture build based on best practices and considering security parameter

2)????Automates the creation and management of AWS accounts from Master account OU

3)????Consolidated billing can be enabled at Master account

4)????Active Directory Controller server will deploy for AWS SSO integration and connect with AWS services to centrally manage identities

5)????Can enforce the policies across the AWS accounts for compliance (using SCP)

6)????Manages the access privileges for multiple accounts without custom scripts

7)????A configured, secure, scalable, multi-account AWS environment based on AWS best practices

8)????AWS CloudTrail to create a searchable log of all cloud activity from the organization level

9)????Different 2 VPC will be create for Intranet (MPLS) and Internet traffic inspection

a.?????MPLS VPC – On-premises traffic through DX connection

b.????INTERNET VPC – Incoming and outgoing traffic from Internet

c.?????MPLS traffic will filter and inspect using NGFW and F5 WAF

d.????Internet Inbound traffic will filter and inspect using NXFW and F5 WAF

e.?????Internet Outbound traffic will filter and inspect NGFW.

10) Transit gateway to communicate VPC to each other and connecting on-premises network

11) Direct connect to communicate from data center to AWS cloud servers via TGW and NXFW for network inspection

12) CloudTrail - User activity log monitoring?

13) AWS KMS - AWS key management service for data encryption at rest with our own encryption using third party solution.

14) Config - CMDB management database with auto change tracking and records

15) An Internet gateway allows communication between instances in your VPC and the Internet.

16) Use an Application Load Balancer to distribute web traffic to the NXFW firewall for inspection and then it will terminate on primary servers via transit gateway

17) Use and Gateway Load balancer to distribute network traffic for F5 WAF

18)Own Encryption mechanism using third party tools

19) SIEM solution for end to end logging and monitoring

Prerequisites:

? Terraform to be installed on the control machine

? Terraform with version ~< 1.4.x.

? Git to be installed on the control machine (laptop of delivery team member).

? High-level understanding of Terraform and AWS.

? AWS Account access key and secrete key with admin access.

? AWS Control Tower Setup.

Sample Code for multiples modules:

1.AWS Accounts Creation Detailed Steps:

terraform { required_providers {

aws = {

version = "~> 5.0.1" source = "hashicorp/aws"

}

}

}

provider "aws" { alias = "main" #profile = "network"

region = "ap-south-1" access_key = "xxxxxxxxxxxxxxx"

secret_key = "xxxxxxxxxxxxx"

2. Password Policy Module:

module "passwd_policy" {

source = "../../terraform-aws-LZ-modules/modules/account_hardening" #version = "1.1.1"

?

##### password policy ############ create_passwd_policy = {

passwd_policy = { minimum_password_length????= 8

password_reuse_prevention??= 5

max_password_age????????????= 90

require_numbers???????????????????????????= true require_lowercase_characters = true require_uppercase_characters = true require_symbols???????????????????????????= true

hard_expiry????????????????= true

}

}

?

}

3. Service Control Policy Module:

module "scp" {

source = "../../terraform-aws-LZ-modules/modules/Policies"

enable_ram_sharing_with_org = true

# If enabled, RAM sharing with Org SCP policy will be created ############### SCP ######################

enable_scp_policy = true ou_target = ({

name = "test"??// scp policy will be created by this name

})

# require ebs encrypted force_encryption_on_ebs = true

# require rds encrypted force_encryption_on_rds = true

# require s3 objects be encrypted require_s3_encryption = false

# Tagging Policy on EC2 , volume and RDS snapshot tagging_policy_tags = {

Name = "true" Environment = "true"

}

# don't allow all accounts to be able to leave the org deny_leaving_orgs????????????= true

# applies to accounts that are not managing IAM users deny_creating_iam_users????????????????????????????= true

# don't allow deleting KMS keys deny_deleting_kms_keys????????????????????????????= false # don't allow deleting Route53 zones deny_deleting_route53_zones????????????????????????????= false # don't allow deleting CloudWatch logs deny_deleting_cloudwatch_logs = false # don't allow access to the root user deny_root_account????????????????????????????= true

protect_s3_buckets????????????????????????????= false # protect terraform statefile bucket protect_s3_bucket_resources????????????????????????????= [

"arn:aws:s3:::prod-terraform-state-us-west-2/*

? "]

# only execute if protect_s3_buckets is set to true.

?

# don't allow public access to bucket deny_s3_buckets_public_access = false deny_s3_bucket_public_access_resources = [

"arn:aws:s3:::*"

]

# only execute if deny_s3_buckets_public_access is set to true.

protect_iam_roles????????????= false

# - protect OrganizationAccountAccessRole protect_iam_role_resources?????????????????????????????= [

"arn:aws:iam::*:role/OrganizationAccountAccessRole"

]

# only execute if protect_iam_role_resources is set to true.

?

# restrict EC2 instance types limit_ec2_instance_types?????????????????????????= false allowed_ec2_instance_types = ["t2.medium"]

?

# restrict region-specific operations to us-west-2 limit_regions???????????????= true

# - restrict region-specific operations to us-west-2 allowed_regions???????????????????????????= ["ap-south-1"]

?

# SCP policy tags ou_tags = {

Name = "Test-SCP",

Application = "AWS Security Landing Zone", Environment = "Production"

}

}

4. GuardDuty

guarduty_kubernetes_protection_enabled = false

guarduty_malware_protection_enabled???= true enable_delegate_user?????????????????= true

guardduty_delegated_admin_account_id??= XXXXXXXXXX #Audit account id

Key Decision Parameters for Multi Account Structure

?

1.???????AWS business support will only be used for production accounts and transit accounts.

2.???????Benefits in Decision and architecture – Secure backbone for the application deployment and addition of upcoming project in the predefined structure.

3.???????Segregation of Duties – All the accounts are specific to enterprise teams and only relevant teams will have access to the services needed as per least privileges.

4.???????Centralized compliance and risk management – For audit and compliance all the logs are moved to specific account and external audit teams can have access to logs at a centralized place.

Summary:

In the AWS Landing Zone Control Tower service provides a robust and centralized solution for managing and governing multi-account AWS environments. It streamlines the process of setting up and configuring a well-architected and secure foundation while offering granular control over accounts, policies, and compliance. With Control Tower, organizations can ensure consistent best practices, enforce security measures, and facilitate efficient resource management across their AWS landscape.

cloudxchange.io #security #aws @ControlTower