About the Customer
The Customer is a large Asset Management organization with trillions in Assets under Management (AUM). The customer is a complex global organization with multiple teams managing their core infrastructure including Business Units and an Enterprise IT Team.
Key Challenge/Problem Statement
The Customer needed to develop a strategy for providing AWS Accounts to a global organization. The company hierarchy of enterprise and business unit teams made the environment extremely complex. Additionally, due to the nature of the Customer’s business in financial services, there was a matrix of security guardrails and identity profiles that had to be deployed to AWS accounts depending on the applications that would be deployed onto them. The hierarchy complexity, security controls, and internal SLAs required the Customer’s Enterprise IT team to come up with an automated solution to provide AWS Accounts.
State of Customer’s Business Prior to Engagement
The AWS Account creation and customizing the accounts with the right network, logging and security features was mostly a manual process. There was some automation created with Terraform and GitLab to set up monitoring tools on existing accounts, but it was not comprehensive and required a lot of support from the Enterprise Cloud Platform Team. There was also minimal documentation around AWS security and operational best practices for design and support.
Proposed Solution & Architecture
The team worked with the Customer’s cloud platform, security, SRE, logging, and networking teams to design the AWS organizational unit structure and then to use Control Tower to handle the Core OU and to provide AWS accounts to the Customer’s Business Units through a self-service request model.
The team built out a secure Landing Zone with AWS’s Control Tower product that allowed the Enterprise IT team to launch an AWS account and have the matrix of security guardrails and identities automatically deployed. This enabled them to start onboarding Business Units to use AWS.
Control Tower has built-in security Guard Rails and automated account creation and configuration. Then provided guidance on industry best practices for security and operations to get the Customer to the point where a Business Unit could onboard to AWS to immediately start developing their applications.
Control Tower was implemented in a Master Account, where all of the AWS Services used to create and manage AWS Organizations and Accounts were located. Part of the default implementation of Control Tower is a Core Organization with Audit and Logging Accounts. Each of these receive the default Control Tower configurations including IAM Roles and VPC Resources.
Any AWS Organization or AWS Account under Control Tower can have Service Control Policies (SCPs) and AWS Config Rules assigned for security guardrails. Control Tower was used to deploy 22 base, 13 strongly recommended, and 18 custom SCPs and Config Rules to AWS Accounts.
AWS SSO was integrated with Duo Authentication Tool, which managed their AD and Multi-Factor Authentication. This allowed for easy integration between AWS and Customer’s AD for users to gain access to the proper accounts. AWS SSO was managed in the Master Account, and 12 User Roles were created to map directly to their defined user access patterns.
AWS Service Catalog was used in the actual creation of AWS Accounts under the Control Tower Domain. The account was placed under an Organization, such as the Sandbox Account in the Sandbox Organization, where the SCPs and Config Rules defined for the Organization would automatically be applied to that account. For an account that was created with Control Tower, the further configuration was done with CloudFormation and Terraform. CloudFormation was used where AWS already had provided a completed template with no additional coding requirements and the resource was not needed by developers Infrastructure as Code for Deployments. Terraform was used to create those resources that would be utilized by developers for Deployments, such as VPC resources where a Subnet or Security Group would need to be identified for a resource to be deployed. This method allowed for the Customer’s developer to continue to use their tool of choice for when it mattered to them, and to reuse AWS’s resources for times when it was irrelevant to their developers.
GitLab was used for automation orchestration. GitLab Jobs were used for the creation and management of resources, calling the AWS API to interact with Control Tower or individual accounts based on the need, below are some examples:
- A GitLab Job that would quarantine an EC2 instance in a given account by removing all access and controls, stopping the instance and copying a backup of the EBS Volumes to a quarantined VPC in the Audit Account.
- A GitLab Job to trigger Service Catalog to create a new account in a given organization.
- A GitLab Job that would create a privileged user for a given account in the event of a Break Glass scenario when someone needs immediate privileged access to an account.
In the end, the Customer had a way to create an AWS Organization / Account with proper Security guardrails in an automated method that could be controlled by a central enterprise team, while allowing the individual Business Units to manage their own environments.
AWS Services Used
- AWS Infrastructure Scripting – CloudFormation
- AWS Compute Services – Lambda
- AWS Storage Services – S3
- AWS Networking Services – VPC
- AWS Management and Governance Services – CloudWatch, Config, CloudTrail, Service Catalog, Organizations, Control Tower
- AWS Security, Identity, Compliance Services – IAM, Key Management Service, GuardDuty, AWS Single Sign-On
Third-party applications or solutions used
- GitLab
- Terraform
- Duo
Outcome Metrics
- ~10 minute process for requesting a business unit to request an AWS Account with required guardrails, entirely through self-service
- ~22 User identity types with permissions models were created and deployed to AWS accounts
- ~28 SCPs and 25 Config Rule guardrails deployed to AWS accounts
- ~10 Gitlab Jobs for executing operations activities through automation
Summary
By engaging AWS and Vertical Relevance, the Customer was able to build an AWS Account design that enabled them to scale for the future, along with streamlining their request to delivery speed for AWS Accounts. Security and compliance policies were enforced across all of their different AWS Accounts and business units. The Customer is now able to provide business units with their own AWS Accounts that have the right level of enterprise policies and standards in place.
