Prerequisites

• Have established your AWS Organization with the Security OU and the SecurityAudit account.

• Have completed implementation of IAM Identity Center, and be able to log in with your Identity Center admin user.

The Lesson

Just this morning my wife gave me crap for the pile of unbuilt LEGO in the corner of my office. You see, I love LEGO, I just don’t have nearly as much time as I’d like to build them. It was a bit of a bad habit before we had kids, but now it’s worse. These are the sacrifices I make for you all — I hope they are appreciated!

Back in the early days of AWS we didn’t have Organizations and, as I probably mentioned, some of us realized very early that an AWS account makes a great security boundary. Things in one account can’t talk to things in another account without you making a deliberate connection. This is very powerful for limiting the damage of attacks, which we call the “blast radius”.

Accounts provide logical separation between functions, and enforce isolation. Have two applications that do different things, managed by different teams? Toss them into two separate accounts, and you don’t have to worry about one dev mucking up another dev’s environment.

There are a bunch of other benefits when you get into the weeds. One advantage is that service limits are enforced on a per-account level. What’s a service limit? AWS puts limits on all sorts of things, including the number of instances you can have, the number of IAM policies, and even the volume of API calls in a given period of time. These are all managed at the account level, and many of us have run into them, especially on larger projects. But kick something out into a separate account and now it has its own service limits — doubling capacity.

The more you cram into one account, the harder it is to manage granular security, and the more you need to rely on broad rules which might not work for everyone. Some of the biggest security messes I’ve seen occurred when a lot of different projects of different security levels were all crammed into a small number of accounts. This makes managing IAM least privilege policies especially hard.

So we get both security and operational benefits with multiple accounts. But the problem is organizing and managing these accounts (hello, LEGO analogy). This isn’t a topic we’ll get to stick a fork in today — this is just the start. And I want to be very clear that the organization structure in these labs is just one option that I personally like — it isn’t the only good way to do this.

My approach is a variation of the AWS Security Reference Architecture. It uses the some of the same base structure, but I add some Organizational Units and accounts. Again I want to thank Chris Farris, who sent me his recommendations when I double-checked some things with him. He has posted Terraform templates for creating OUs, and also recommended this re:Invent YouTube video from where he used to work.

There are multiple viable strategies for your overall account hierarchy, and all sorts of possible naming conventions. These guidelines can help, and we will be building out my opinionated version.

• At a minimum you want OUs for governance/security, infrastructure/operations, and workloads; as well as places to handle special cases such as incident response, mergers and acquisitions, and accounts you are deprovisioning.

  • Separation of functions. Always keep in mind who needs to use the account and what the account needs to do.

• When deciding what accounts to create and where, I try to use these guidelines:

  • One of the best security tools in our hierarchy is Service Control Policies (SCPs). For example if you want different ones for development vs. production environments, you should probably have dev and prod OUs.

  • If two things are in different security contexts — perhaps because one has a lot of compliance requirements, but the other is hosting pictures of your cats — move them into separate accounts.

  • If application stacks are managed by different teams, put them in different accounts. This makes IAM easier because you can restrict access to the relevant teams.

  • If two applications need to talk to each other and it’s a lot of data, then… wait until we get to that lab. This is the hardest decision point because, for cost reasons, you may need to put different workloads managed by different teams into the same account.

  • Separate accounts are also awesome for assigning to different cost centers. Much easier than trying to use tags.

For me SCPs, more than anything else, guide my top-line account hierarchy.

Today’s Lesson Points:

• AWS accounts are a powerful tool for enforcing security and operational rules.

• There are many different ways to organize accounts, but you usually want to at least separate security and infrastructure shared services from accounts running applications.

The Lab

Today we will add OUs and accounts. Then we will reorganize our SCPs. This will not be the entire organizational structure — we are focusing on the top level and security. Why? Because there is a lot more to discuss when we get into workloads than we have time for today.

Here is the structure and the reasoning.

• Security OU which we already established. Chris uses Governance as his name for most of what I put in here, which is also a good choice.

  • LogArchive which contains our logs. But wait, didn’t we set that up in SecurityAudit? We sure did, but Chris pointed out my mistake after I released that earlier lab. This was actually a weird brain fart on my part, so we will go in and change the name (a skill we needed to learn anyway) next week.

  • SecurityOperations where our main security tooling that can make changes will run.

  • SecurityAudit for assessment tooling. Some places put these tools in the SecurityOperations account, but I like to separate out read from read/write activity if I can. We won’t create this until next week, when we rename our existing one to LogArchive.

  • IAM for managing IAM Identity Center. I separate this one out because it’s so powerful. Some organizations have this under Infrastructure, but I think it really should be managed by security.

• Infrastructure OU for shared infrastructure services. We won’t add any accounts here today.

• Exceptions OU for accounts which need to operate temporarily outside the normal rules. We’ll use this today to temporarily disable our SCP which blocks use of the root account.

• Workloads OU where all our application accounts will go. This will be a single flat OU today, but it won’t stay that way long. We will quickly add Prod and Non-Prod to cover production applications and dev/test environments.

• Sandbox OU for accounts where we can give developers more freedom to play around with different services.

• Onboarding OU for new accounts we are adopting from another organization, like during a merger.

• Nursery OU for accounts created using automation. This lets you set them up here, before you move them into Workloads, where they will be locked down.

• Suspended OU for accounts we are preparing to deprovision. This will have a DenyAll SCP. You move an account here to see what breaks and who screams about it before you shut it down. We call this “WhineOps”, and it’s a very effective way to see who is using something but ignoring all the emails asking who owns it.

• IncidentResponse for accounts in an active incident where you need to change some of the ground rules to limit an attack. For example you might add an SCP denying actions an attacker could use to escalate privileges or add persistent access.

We will make more OUs later, especially under Workloads, but this is more than enough for today’s lab.

Video Walkthrough

Step-by-Step

New rule! Instead of the generic AWS console, this time log in using your SSO portal (Identity Center Sign In URL). You bookmarked it like I said, right? Mine looks like this:

Then pick your Management Account (mine is called CloudSLAW) and then AdministratorAccess.

Now go to Organizations. Then click Root in the hierarchy, since that’s where we want to create the next OU. Then click Actions and Create new.

This next part is so easy and obvious I’m embarrassed to even include a screenshot. But after teaching cloud security for over a decade, I know you people love screenshots. Name the OU and click Create organizational unit. Start with Infrastructure.

Now repeat those steps for the following list:

• Workloads

• Exceptions

• Sandbox

• Onboarding

• Nursery

• Suspended

• IncidentResponse

Go on, I’ll wait.

Now create two new AWS accounts. It’s the big orange button in the upper right corner that says, shocker, Add an AWS account.

Name the first one IAM, then use ‘+’ email addressing. I’m using +cloudslawIAM which is reasonably descriptive. Then click Create AWS account.

Repeat those steps for SecurityOperations. We’ll deal with the log archive issue next week.

We now have our accounts but they aren’t in the Security OU. If you don’t see them on the hierarchy page, click List then select the 2 new accounts, then Actions > Move.

Now Security, then Move AWS accounts. Then profit!

Actually don’t profit, but you’re done with the lab. See you next week!

-Rich