This article is in continuation with AWS Control Tower Simplified.
This article was originally published as a blogpost at FAIR CG’s website.
Introduction
The previous post of this blog series discussed the benefits, functionalities and potential scope of the AWS Control Tower. In this article, we will delve into details of how an organisation can deploy AWS Control Tower effectively to ensure secure and agile operations.
At the heart of any well-governed AWS multi-account architecture is decentralisation. It is decentralisation and delegation of responsibility that enables organisations to compartmentalise certain security issues and help in balancing safety and agility. AWS Control Tower, right from the start, focuses on decentralisation and accelerates the process by generating a few accounts and roles related to various operations, such as logging, auditing and provisioning of accounts. This serves as a road map for how to divide responsibilities across users.
The features defined in this blog use AWS Control Tower’s promise to provide a multi-account setup that enables organisations to build, move fast and stay secure, and will help the reader understand — and possibly implement — a well-architected landing zone.
While setting up guidelines for management, the Two-Person Rule is recommended to be followed. It says that the person who grants access to a service should not be the one using it.
Imagine an organisation using an AWS account that has the entire storage backup. Ideally, there should be one set of employees that can access that account and another set of employees that can enable access to that account.
A well-architected multi-account setup should provide the following:
- Flexible Security Controls — Compliance with well-known security standards such as HIPAA/PCI DSS. An account is a unit of security protection. Potential risks and security threats should be contained within an account, without affecting others.
- Rapid Innovation Across Multiple Teams — Ability to provision accounts for different users on a need basis. Account provisioning and setup should be rapid so that operations by multiple teams do not overlap.
- Simplified Billing — Ability to provide separate billing for individual accounts.
- Quota/Service Allocation — Ability to set up quotas for certain services and limits for expenditure on accounts.
- Data and Responsibility Isolation — Data isolation is critical and setting up separate accounts can make it possible. However, there are certain compliance standards. For example, data isolation helps support compliance with the General Data Protection Regulation (GDPR).
Recommended Organizational Units (OUs):
For organisations that are willing to set up a multi-account setup by using Control Tower, it is essential to look into their organisational structure and needs before laying out OUs. The following categories are common for most mid-to-large size organisations and can be used as a guide while creating OUs.
Read our previous blog for more details on OUs.
Foundational OUs
Both Security and Infrastructure OUs are classified as Foundational OUs by AWS. They contain AWS resources, include accounts and workloads, that provide security and infrastructure capabilities.
Source: AWS
Infrastructure
This OU contains deployments and test accounts for the various networking and IT services that are used in the organisations, such as mailing servers, chat application deployments and other management and/or productivity tools.
Security
The Security OU is intended for holding accounts that are related to security configurations and their related services.
The following accounts are recommended inside this OU:
- Log Archive: It will keep all the access and audit logs generated by the landing zone.
- Security ReadOnlyAccess: It will allow security team members to get ReadOnlyAccess to other accounts in the landing zone for various monitoring and auditing purposes.
- Security Break Glass: It should be used in case of an emergency and it will allow extensive temporary write access to all the accounts in the landing zone. Special permission should be granted before allowing access to this account.
- Security Tooling: It should be used for hosting security-related services such as AWS GuardDuty and AWS Security Hub, minimal human access should be allowed.
Business-Oriented OUs
Source: AWS
Sandbox
Sandbox OU is for individual developers who want to develop and experiment with various AWS offerings. This OU provides a playground for developers and also enables organisations to set limits where necessary.
Workloads
Client solutions and their SDLC accounts live in this OU. It is recommended to create Workload accounts to isolate software services instead of mapping them to the teams. It becomes much easier to assign team members to certain accounts than moving entire software artefacts from one account to another in case of organisational changes.
None of the SDLC accounts should have any dependencies on each other.
Additional OUs
- Policy Staging: For testing any changes in regards to policies when rolling out new changes to the OU structure.
- Suspended: For keeping all the suspended accounts. All the rights should be revoked from these accounts and details should be logged just in case these accounts have to be brought back up at some point.
- Business Users: Limited Access accounts for non-technical business users.
- Exceptions: For cases when certain projects are exceptions to certain audit and/or security conditions that are applied to OU:Workloads
- Transitional: For accounts that are yet to be formally integrated or categorised into an OU
- Deployments: For organisations that have different processes/teams for deployment processes
Recommended Guardrails
- In the previous blog post of this series, we also discussed preventive and detective guardrails provided by AWS Control Tower that can be applied to OUs. A subset of these predefined guardrails are mandatory and are already applied whenever a landing zone is created using Control Tower.
- Guardrails help in establishing a firm base for the multi-account setup by enforcing certain rules that limit users from crossing boundaries that would violate the structure of the landing zone. One rule that should be kept in mind while applying preventive guardrails is that the Service Control Policies (SCPs) should always be applied to an OU and not to an individual account.
In AWS Control Tower, guardrails are divided into two categories,
- Preventive Guardrails
- Detective Guardrails
Preventive Guardrails
Preventive guardrails, as the name might suggest, prevent an undesirable action from happening. Preventive guardrails are applied using the SCPs in AWS Organizations. In simple words, they are rules that are enforced on the OUs and the accounts beneath OUs, much like IAM policies.
To exemplify a rule that needs to be enforced, one may imagine an SCP that prevents any account created by AWS Control Tower from leaving AWS Organizations. The exhaustive list of mandatory preventive guardrails provided by AWS can be found here.
Apart from the mandatory guardrails, there are other guardrails that an organisation might want to enforce in their landing zone. This would vary from business to business and, like any other process implementation, would require proper thought and consideration. For instance, an organisation might want to disable access to certain services in their sandbox OU, or, an example that might be fit for a lot of businesses, is denying the ability to the accounts in the landing zone to opt-out of centralised logging. The needs and possibilities can vary from scenario to scenario.
Detective Guardrails
Detective guardrails can be thought of as measures that ensure compliance with certain standards. Organisations may need to ensure that their cloud-based solutions comply with industry-relevant standards or they just want to ensure that their teams are using best security and infrastructure practices while using AWS.
Detective guardrails are applied via AWS Config and they monitor all the accounts in the landing zone and consolidate their compliance status in a single dashboard which makes it easy for the organisation to check compliance and take action if needed.
AWS provides ready-to-use best-practice blueprints called conformance packs that cover a wide range of use cases.
Conclusion
This article explains how organisations can effectively deploy AWS Control Tower for quick and secure operations. Resources like OUs and guardrails offer businesses the opportunity to effectively compartmentalise and manage data while also ensuring security.
The next and last part of this series: AWS Control Tower Deep Dive: Part 2 focuses on security measures and drift management.
