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:
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.
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
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.
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:
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.
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.
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, 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 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.
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 will focus on security measures and drift management.