The Challenge of Multi-Account Management in Amazon Web Services (AWS)
AWS provides organizations with a powerful capability to build and scale with minimal overhead. An often-overlooked consideration when standing up these environments is developing a scalable way to securely manage identities and user access. Addressing this challenge early on will pay huge dividends in securing your environment and passing security audits as the environment grows. Fortunately, AWS provides a powerful managed service to help achieve this goal.
AWS Account Management
When first starting in AWS, it is important to understand how AWS structures their account hierarchy. It is common for companies to have multiple unique AWS accounts, each with a different purpose to segregate environments. For example, a different account for: Development, Staging, Production, Security, Administration, and so on. However, cloud administrators are often overwhelmed when attempting to manage each account individually. Maintaining each account, especially if services exist in multiple regions, isn’t scalable and introduces a large margin for error. This lack of visibility increases the risk of a cyber attack from both an insider and outsider threat perspective.
While an Identity and Access Management (IAM) identity can assume a role for access across specified accounts, this does not solve the problem of managing the entire AWS environment at scale. This is especially true for regional services. For example, Security Hub is a regional service that aggregates data from multiple security sources and provides a console to centrally manage alerts, benchmarks, and security posture in a particular region. Since it is a regional service, it is considered best practice to enable this service in every existing and future region utilized by a company. If an organization owns 3 AWS accounts with services in 5 regions, they have 15 individual instances of Security Hub. One can quickly see how this kind of architecture is difficult to scale, manage, and automate. Fortunately, AWS offers a solution that provides centralized cross account management, security, and governance that scales with the AWS environment: AWS Organizations. Deploying this service should be one of the first tasks for an operations team migrating to AWS.
AWS Organizations is an AWS global service designed to centrally manage and govern resources across AWS accounts. This service can be broken down into three parts:
- Accounts, Organizational Units (OUs), and Policies.
- Accounts: Individual AWS accounts
- Organizational Units: Logical grouping of AWS accounts. Accounts are linked to OUs
- Policies: Configurations that allow for management of accounts. Policies are linked to OUs
Managing AWS Accounts
As previously stated, managing each individual AWS account and the services within them does not scale. AWS Organizations provides a capability to centrally manage all accounts. As shown in the picture above, a dedicated management account should be created solely to manage other accounts. This account should not be used to host additional services or infrastructure. The only purpose this account serves is to manage the AWS Organizations service. Using this model, cloud administrators are relieved of having to log in to each account to manage individually. Security, workloads, and services can be quickly scaled and optimized resulting in immutable infrastructure. This applies to companies that are existing AWS customers as well as those looking to migrate to AWS. For existing customers, AWS Organizations allows them to add existing accounts to the master account with no need to re-create accounts or reverse engineer their AWS infrastructure. It is simple to add, invite, or remove member accounts for new or existing AWS customers.
It is considered best practice to initialize this service from the Management account. In the screenshot above, the star indicates this is the Management account. As other member accounts are added, they will populate with the Account name, Root email, Account ID, and Status displaying when that account was created. This provides a central view of all the AWS accounts associated within a company’s AWS environment.
Service Control Policies (SCPs), OUs, and Member Accounts
Now that all of the relevant member accounts have been created, added, or deleted in Organizations, it is time to explore how to manage them using Service Control Policies (SCPs) and Organizational Units. For those familiar with Active Directory, Group Policy Objects are synonymous to SCPs and OUs are synonymous to, well, OUs. The diagram on page 2 displays how SCPs are connected to OUs, which are connected to Accounts. It is important to note that SCPs cannot be attached directly to Accounts and by default AWS Organizations automatically creates a “Root” OU. By default, all member accounts will belong to the Root OU until other OUs are created and member accounts are moved under them.
Therefore, before creating SCPs, it is best to create OUs. Depending on an organization’s use cases, OUs will differ in both the number and naming schema for each company depending on the use case. However, many will remain similar from an operational perspective. AWS has a guide to Best Practices for Organization Units with AWS Organizations. Although the OUs mentioned in the article may not apply to every company, they do outline the importance of having all accounts applied to only one OU. It is important, however, to have an OU dedicated to Security. This OU should contain the AWS account that is responsible for owning all AWS Security related services, such as Security Hub and CloudTrail. Managing each of those regional services at the account level does not scale and will likely lead to a misconfiguration and manual overhead. These inevitably lead to breaches, such as exposing an S3 bucket with sensitive information to the world. Companies that are maintaining a product or service typically have an OU for Security, Development, Staging, and Production with associated accounts under each OU.
When enabling Service Control Policies, AWS populates the default policy “FullAWSAccess”. This policy grants ‘allow all access’ to every operation and is the default policy for every organization Root, OU, and account. It is also important to understand the inheritance of SCPs which is explained in Inheritance for service control policies.
A cloud administrator can utilize SCPs as a deny list or an allow list. Deny lists allow the administrator to specify which services and actions are not allowed. This is the most common strategy since the default SCP rule is to allow all access to every operation. The alternative method is to build an allow list. This method prohibits all actions by default and the administrator must specify which services and actions are allowed. Which strategy an organization chooses to implement depends on the use cases, operation knowledge, and time to implementation. There is no one size fits all. Since SCPs are attached to OUs, it is possible to utilize both deny and allow list strategies for different OUs. This, again, is dependent on the individual use cases of the organization.
SCPs are constructed in JSON format and can be written from scratch or by using the policy creator within AWS Organizations. There are also many examples of default policies in the official AWS documentation. The screenshot below displays an example of using the policy creator, with a policy named, “s3-deny-deletion” complete with a description. It is important to develop and adhere to a naming schema when naming SCPs for greater consistency and purpose. A common example is “<AWS Service>-<allow/deny>-<action>”.
Using the policy creator, a cloud administrator can select from one of the many AWS services and begin assigning actions. In the below example, S3 is the service and actions “DeleteBucket” and “DeleteObject” have been assigned to the SCP without having to manually write JSON. The policy creator will also check syntax upon creating a policy. Once the policy is created, it can be assigned to an OU or Member account. It is important to keep in mind how inheritance works when assigning SCPs in AWS Organizations.
AWS Organizations provides cloud administrators with the ability to centrally manage, govern, and scale an organization’s cloud environment. When it comes to scalability, security, reliability, and automation, the benefits of implementing AWS Organizations will have a positive impact on all aspects of the company’s cloud workflow.