Naming Conventions That Minimize Complexity for Policies and Roles

ACM.416 Revisiting the names of AWS Organizational Units, Accounts, and Roles

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

⚙️ Check out my series on Automating Cybersecurity Metrics | Code.

🔒 Related Stories: AWS Organizations | IAM | Deploying a Static Website

💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In the last post I documented the process for changing an email in an AWS Organizations account because it’s kind of painful that you can’t rename a role or change an email address easily, and if you don’t change the email before you close an account you can’t rename it.

In this post I want to explain why I’m renaming things and how I’m going to rename my OUs and accounts to try to make policy and role management easier (I think — to be tested.)

I was thinking about all the different roles I need for different administrators. But do I really need all those roles? Some administrators can administer a single account and specific kinds of resources. Some administrators need to be able to manage entire environments if something goes wrong. Yet ideally if things are breaking in the non-prod environment due to a developer action, hopefully that’s not affecting your production environment and an administrative scope to fix the problem can be limited to nonprod.

I started thinking I could just use the organization role for all administrators — now that I sorted out how to enforce MFA without modifying the role itself in this post:

Instead of creating new roles for every type of administrator I think it will be possible to use the AWS Organizations role with an SCP to limit what each administrator can do with it.

I can also give the organizational role a different name in each environment. That way when I grant permissions, I can limit an administrator to assume the AWS Organizations role only in specific environments using the [env]-* construct in the ARN as I’ve demonstrated before for limiting access to CloudFormation stacks.

AWS has some constructs for allowing permissions in particular OUs as well but I have had problems with the implementation in the past. I’ll probably revisit that but the naming convention feels easier to implement and use.

The one thing I have to figure out is adding administrators to the AWS Organization Role trust policy. Can I do that? If not I still may need to add one role to every account to allow administrator access with a controlling SCP.

It may cause some issues if we need to iterate through every single account — the code will need to account for different organizational roles — so we’ll minimize the number of environments while maintaining the major trust boundaries and minimizing risk to a reasonable degree. In my case, it’s root, org, prod and nonprod but you may have a more granular breakdown in a larger environment with different stages of SDLC and different lines of business.

As mentioned in prior posts, I will have completely separate administrators for backup and domain name management.

My OUs can include the environment name like this. If the OU doesn’t have a dash in it then the OU name is the environment name.

This makes my code a bit easier to write.

env=$(echo $name | cut -d '-' -f1)

That works whether the OU or account has a dash in it or not.

I use the org-admin user in the root-org account to build out the organization using the cross-account role: root-adminrole.

The organizational environment has the following OUs:

Accounts for the org-governance OU:

Note that I was going to try to have the billing administrator create the accounts but that proved to be challenging for various reasons.

The org-security and org-backup OUs:

Accounts in the org-deploy OU:

The org-deploy account processes can move code between environments and validate code integrity in the process.

Sample nonprod accounts:

Note that I am separating non-prod, prod, and org backups.

So now that I’ve thought that out, I can redeploy all my OUs and accounts using the method for doing so in parallel that I wrote about in this post.

Follow for updates.

Teri Radichel | © 2nd Sight Lab 2023

About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight Lab

Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation

Follow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab