Why Is Cloud Security So Hard? (Hint: It’s Not)
Securing a new environment without knowing the rules of the road can be hard. Take the time to learn the rules and avoid speedbumps.
A HOW-TO on how to set up your AWS Organization properly to allow you to deploy services and controls across your AWS Accounts.
In a previous post, I went over the importance of setting up AWS Service Control Policies. However, there is a lot of pre-work involved before doing that, namely setting up AWS Organization. This article is a HOW-TO for setting up your AWS Organization properly, allowing you to deploy services and controls across your AWS Accounts.
If you think your company will never grow past one AWS Account, think again. In fact, if you have only one account, you are lucky! Nine times out of ten, when I walk into a new AWS environment, there are already tens of accounts, yet AWS Organizations is not being taken advantage of.
AWS Organizations allows you the following benefits:
As mentioned earlier, you will more than likely require multiple AWS Accounts as your company grows, so best to start now. In any case, creating a new account will not add any additional cost, and once you have a consolidated billing setup, it should be quite easy.
Below is a summary of AWS Accounts needed for a sound security strategy:
This will be the root of your AWS Organization. It’s an account that must be empty of resources. Nine times out of ten, the existing master account is the first AWS Account your company created (where all your production resources are). Take the time to create a new AWS Account and migrate your billing to that account (see step by step below).
This is an essential account, even before the security account. This is where all your logs will be stored, including your organization trail (CloudTrail enabled at the organization level). This account should have extra security controls and minimal access to ensure the logs’ integrity is maintained. In the future, other system logs may end up here, thus, the need for a dedicated logging account. Other teams and tools may request access to these logs, which is fine.
This is also an essential account. This AWS Account is where your security tooling will be run from. Your AWS security toolset will consist of both AWS Security Tooling—such as GuardDuty, IAM Access Analyzer, AWS Firewall Manager, AWS Security Hub, AWS Macie, and Open Source tooling—as well as CloudMapper, ScoutSuite, and other Open Source Tools (check out here and here).
I may not know much about your product offerings or workflow, but I can guarantee you that you will more than likely have at least one service that is shared by multiple development teams. It may be your CI/CD tooling, container repository, automation, image building, or another tooling that may not be a SaaS-based service. For example, you may have golden AMIs for other teams to use, in which case, you would publish them from this account. Or maybe you have a Service Catalog that you publish; in that case, you would do that from this account as a delegated administrator account.
Here is where it gets a little tough. And I will forgive you if you don’t do this right away, but I recommend that you have separate AWS Accounts per environment, per application. There are multiple reasons why, but here are a few:
Now, you may ask, “Can’t I just do this all in one account with multiple VPCs, one per environment?” My answer: YES! However, in order to ensure the right permissions and segmentation, you will likely need to use IAM permissions boundaries to ensure that certain groups don’t have access to certain resources. For example, only admins should have direct access to production, although no one really should since all access should be deployed programmatically via Terraform/Github or another means.
This guide assumes you have production resources in your existing Master account and that “emptying” this account will be a large undertaking. Embarking on the steps below will be less work 99% of the time than the work involved in actually migrating resources out of an existing Master account.
The next step is to logically separate your AWS Accounts into Organizational Units. Creating OUs and moving AWS Accounts into them will have no impact at all, assuming you have not created any SCPs yet, of course. You also have the option of nesting OUs as needed. SCPs applied at any level will be applied in any sub-OUs.
Here are multiple OU layouts to choose from. Choose the one that best suits your environment and work style:
This organizational unit is for production AWS Accounts. Any account that has production services belongs here. The strictest security will generally be applied here.
This organizational unit is for staging AWS Accounts. These are typically environments that mimic production in 1:1 fashion, except for staged pushes.
This organizational unit is for staging AWS Accounts. More relaxed AWS Accounts where developers have a lot of creative freedom to test, experiment, and, well… develop!
This organizational unit is typically for companies that don’t have a mature multi-staging workflow, and so everything is either Prod or Non-Prod. “Non-Prod” may or may not have a clean staging environment, and the dev environment is usually a mess. Feel free here to create sub-OUs here as needed.
This organizational unit is for testing or maybe triaging AWS Accounts into the organization. SCPs may not be applied here or, or maybe a lighter complement of SCPs. The reason is to verify any impact SCPs may have on an AWS Account as they are applied instantly if they exist.
This organizational unit can be for subsidiaries in your organization that you might not have full control over. For example, you might be a large international company, and so you have a consolidated billing account to get the biggest discount. This also means that all your AWS Accounts are in your AWS Organization as well. However, you might not have direct access to the account or even the security authority/responsibility of the account, so you are not in a position to apply SCPs to them.
This where this OU comes in: it’s a way to organize the AWS Accounts so they’re not under root nor outside of billing. This is common in large companies with a federated model towards security.
If you followed the above, you now have a clean AWS organization! This will save you lots of time and effort as your company grows. It’s one of the first things I recommend for any company to do, and it really applies to companies of all sizes, whether you have one AWS Account or one-hundred! Having a well-organized AWS Organization with no resources running in the root AWS Account is essential for applying Service Control Policies safely and effectively.
If this article was helpful to you, consider subscribing to my weekly newsletter, where I share my latest commentary as a vCISO for high growth startups.
Check out how we help startups accelerate and level up their security programs through vCISO (CISO As A Service).