AWS Organizations and security invariants
Having recently moved the MFA on my AWS SSO configuration to use a YubiKey I was looking at the otter org which got me thinking. What do folks really need to care about when they build their org in the cloud? What do I think is important to think about when you do that. I’ll try to keep it short & actionable.
I’ll start with a brief caveat. Your environment, risk appetite, constraints and context will probably be different. That is ok and, in fact, expected. This are the principles that I fall back on when talking to people about what is important to focus on when they are starting out. Or when looking at where they are now. The subject of this is AWS Organizations and security invariants. I could just as easily called it ‘OUs, how many is enough?’.
What problem am I trying to solve
AWS Organizations (or Organizations depending on where you are standing) is the AWS service that allows you to create Organizational Units (OUs)and AWS Accounts.You can set policies that apply at different levels of the structure with lower level policies working in conjunction with policies higher up the structure. There are some other capabilities such as opting in to certain AWS regions, opting out of some AI related activities and setting some policies on tags.
I usually start with the AWS Well Architected Framework for getting guidance. One of the design principles is; separate workloads into different AWS Accounts. Orgs & OUs sit above that idea. This gets us to the problem. What is the thinking behind how many OUs to have and what should I use them for? After much thinking and going around in circles I’ve landed on the following conclusion.
Orgs & OU structures are there to get the common identity-based guardrails in place to mitigate the risk of the humans in your organization doing dumb stuff. It’s a way of shoving as much common identity stuff into SCPs and keeping them out of IAM policies attached to roles. The reason for this is that there are usually some pretty consistent configuration choices that apply to all AWS Accounts or groups of AWS Accounts. You also don’t want to implement configuration that you’ll need to change frequently.
The OUs and the associated security invariants should represent the common security baselines for collections of accounts. You have the opportunity to layer on additional capability in the [federated] user, network, data or application components.
What should I do?
It’s entirely possible the setup for this is going to be longer than the detail. This was design principles in a first draft but now includes some specifics.
- Don’t model your org structure, that way sucks lots of time.
- Use the least amount of OUs you can get away with.
- For OUs Prod, non-prod, common services, security & logging OUs cover most things
- Start with the org-wide stuff such as:
- Region restriction
- Prevent disabling of CloudTrail/GuardDuty/Security Hub/Config
- Block any services you are never going to use anywhere
- Denying the creation of IAM users.
- The IAM user thing is a personal thing, you might need them for edge cases. Generally speaking, federate all the users!
- Then at each OU add in things like:
- Allow lists for services (maybe prod is different from non-prod, or security teams get access to extra things)
- Conditional SCPs such as “only DNS admins get to make changes to Route53” See the AWS talk linked above
- Other useful conditional SCPs are "require permission boundary when creating IAM roles"
- Look here for examples
AWS Organizations is a really useful way to define common identity-based security configuration across a range of AWS Accounts. It also provides a way of grouping collections of similar AWS Accounts. When you look building your OU structure don’t make it too complex. Complexity will come as you grow but getting some sensible guardrails in place will make it easy to grow without wondering why you spun up a bunch of resources in a different region that you now have to unpick.