This article is a continuation of AWS Control Tower Deep Dive: Part 1
This article was originally published as a blogpost at FAIR CG’s website.
Introduction
The previous blog posts in this series focused on the features of the AWS Control Tower and how it can be deployed effectively so that organisations can work efficiently and stay secure. This article, the last of this series, will revolve around the security measures offered by AWS Control Tower as well as drift management.
Recommended Security Measures
AWS lays heavy emphasis on providing security to its cloud customers. Source: AWS
Security is one of AWS’ highest priorities in all of its cloud service offerings. As a result, we as customers, benefit from an ecosystem that is built around the most resilient and well-known security standards.
Due to the nature of the service offerings and their use cases, the implementation of these security measures is shared between AWS and the customers. AWS calls it the shared responsibility model, under which:
- security of the cloud is the responsibility of AWS and is regularly tested and verified by third-party vendors;
- security in the cloud is the responsibility of the customer and is determined by the services that the customer uses. The organisational requirements, applicable laws and standards and users’ data safety all come under the responsibility of the customer.
AWS recommends a set of landing zone services for the overall safety and monitoring of the accounts. These services are also vital in case there is a need for an audit by a third party or a certain security standard is to be met.
What is AWS GuardDuty?
AWS GuardDuty is, simply put, an antivirus for an AWS account. It is a threat detection service that continuously monitors for malicious activity and unauthorised behaviour to protect your AWS accounts, workloads and data.
AWS Control Tower creates an audit account in Security OU for security administration and tooling. It is recommended that AWS GuardDuty should be set up in the audit account that is created by AWS Control Tower so that it can be managed by the security team. Using the delegated administrator feature in AWS Organization, an audit account can be made an administrator of AWS GuardDuty, which allows managing multiple accounts with AWS Organizations to monitor threats. AWS GuardDuty supports managing and monitoring up to 5000 accounts.
Luckily, AWS provides a CloudFormation stack that can be used to deploy GuardDuty in the audit account quite easily by following the steps mentioned here.
AWS SecurityHub
AWS Security Hub monitors security loopholes in an AWS account by validating the usage of services against best practices, aggregating alerts and providing a unified view of the entire service landscape. It also provides automated remediation of certain security loopholes.
AWS Security Hub can also be used along with AWS Organizations and it should be deployed in the audit account of Security OU using the delegated administrator feature of AWS Organizations, like AWS GuardDuty.
AWS IAM Access Analyzer
Identity and Access Management (IAM) Access Analyzer, as the name suggests, analyses the resources in an account that are shared with external entities. External entities can be another AWS account, an IAM user or an IAM role for a federated user.
IAM Access Analyzer can also be deployed in AWS Organizations with delegated administrator features in the audit account, which enables access to details of all landing zone resources on a single portal.
When the Access Analyzer is enabled, it creates a zone of trust within the organisation that it is a part of and it also creates an analyser. All resources in the organisation are monitored periodically and, in case access to an external entity is detected, the analyser generates a finding and evaluates it against the policies of the resource to assess if the access was intended or not so that the administrator can take appropriate action.
Recommended Budget Management
AWS Budgets
Billing alerts and thresholding is an important aspect of a landing zone’s governance. It is no news that cost estimation in the cloud has always been a matter of concern and is without proper measures, almost unavoidable. A well-architected multi-account AWS setup demands that costs should be controlled and managed on a centralised level.
AWS Budgets helps with these concerns. It is a service that is used for monitoring and alerting the cost that is incurred by an AWS account. Alerts and actions can be set when a certain real or speculative threshold is crossed.
Budget management in a landing zone can be centralised or decentralised, depending on the needs and the requirements. Centralised budget management acts on the consolidated bill of all the accounts and can be used in setting up alerts and logging expenditure trends. Decentralised budget management focuses on cases where certain actions need to be taken on particular OUs when and if they reach certain limits.
One of the interesting cases in decentralised budget management is where an organisation wants to set a limit on the expenditure of sandbox accounts. For instance, an organisation decides to allow 50 USD a month per sandbox account. If an account exceeds the amount, all the services running in that account should be halted. This can be realised by using the budget actions feature in AWS Budgets. A hard limit can be set in AWS budgets and once an account surpasses the limit, that account can be moved to a Quarantine OU. The Quarantine OU should have a Service Control Policy (SCP) that revokes all access from the accounts added to it. Once the account is moved to this OU, all the services inside the account will halt. This article elaborates on this approach and provides a CloudFormation stack.
Drift Management
Drift Notifications
Changes in a landing zone are inevitable and it is very important that these changes are addressed and tested promptly. It is very much possible that the POC account for client X is now approved and developers have decided to move the entire account to Workloads OU to avoid starting from scratch. The first potential problem that may arise in situations like these is the lack of communication. It may happen that the person responsible for performing cleanup tasks and testing SCPs after such a change is not notified in time, which can result in future risks and uncertainties.
To resolve this problem, AWS provides a stack that notifies whenever a drift or a Control Tower lifecycle event is detected in a landing zone. Relevant actions can be taken in response to the drift. It is recommended that this approach is implemented in the landing zone so that no changes in the landing zone go unnoticed. Since the approach uses a single notification service (SNS), there is also a possibility of firing custom events to respond to changes rather than just getting a notification.
Automated Resources and SCP Deployment
The default method of resource creation in AWS is done via the management console or Command Line Interface (CLI). This manual process can be time-intense and is not even required in a landing zone as there might be several policies that need to be attached to a resource or an account after it is created. Besides, manually creating and deleting resources in a landing zone that has many accounts can be a cumbersome task.
Another example of this management chaos is preventive guardrails that are implemented via SCPs in AWS Organizations. Imagine a scenario where a considerable number of guardrails are applied to multiple OUs and there is a requirement where X number of guardrails need to be removed from Y number of OUs. Going through this process manually will become laborious and prone to human error. Aside from the manual effort, the administrators will have a hard time figuring out when and why a certain SCP was removed from an organisation.
AWS provides Customizations for Control Tower (CfCT) to address this problem and recommends that it should be used for resource creation and management in the landing zone. CfCT enables administrators to manage their accounts by using CloudFormation templates. It wires up various services in a way where a simple git commit not only creates the resources but also applies all the policies to the newly created resource.
Customizations for Control Tower is in itself a vast topic and its applications are many. This white paper will help with understanding and deploying it.
An overview of AWS account structure and services.
Conclusion
By this point, it is perhaps evident that setting up and governing a landing zone is a task that requires constant effort, training and upskilling. Multi-account governance is an area that has gone through a lot of changes during the past five years and it is still prone to change and experimentation by AWS, which is why, like with most cloud-based services, it is necessary to investigate and make necessary changes when due.