A Safer AWS Organizations Management Role

ACM.156 Altering the AWS Organizations Default Management Role to Reduce Risk

Part of my series on Automating Cybersecurity Metrics and IAM. The Code.

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

We figured out in our last post that we don’t want to leave the default AWS Organizations Role hanging around as it is a bit risky.

How could we modify that role to reduce the risk that it could be abused?

Let’s think through some scenarios.

Change the Role Name

Although we cannot change the permissions for the default management role, we can change the name:

At least by changing the name it will be harder for someone to guess the name because it was left as the default and try to abuse it somehow.

Root account credentials compromised

Let’s say our root account credentials are compromised. Our organization is pretty much toast, right? The root credentials are not subject to service control policies as I’ve mentioned a number of times, nor are any users or roles in the AWS management account.

The default AWS Organizations role references the account “root” principal. That principal applies to any administrator in the root account, not just the root user.

Until we create another principal in the root account, we can’t really change the principal in the trust policy to be more restrictive. We could create a new user in the root account.

I mentioned before that I was going to create an “IAMROOT” user to run our initial scripts. Perhaps we should do that now and deploy a new role in the governance account and delete the existing role. We can grant the IAMROOT user access to create a more specific policy. Then the IAMROOT user can delete the policy we don’t want.

Now I’m considering this IAMROOT user account to be a special user account only used under special circumstances. I could create a group and add multiple users. The problem that I might face is that a new user might somehow get added to the group and obtain access that only this special IAMROOT account should have.

Alternatively, I could create a specific process for how and when this particular account may be used and require multiple people to access it.

We can allow users to assume roles as described in this post on allowing groups to assume a role. In reality, I allowed users to assume a role in a trust policy, but I automated the creation of the trust policy by iterating the users in a group.

So the trust policy in the OrganizationAccountAccessRole could change like this for that particular scenario:

Compromise of the IAMROOT user that is allowed to assume the role

The most secure option is to limit the role to specific principals. However, what if those user’s credentials or session gets compromised?

AWS offers a number of additional controls we can add to our trust policy:

• Limiting by IP address is interesting and might be a good addition, but alone it does not protect against an attacker who has compromised a the machine where the principal is using the credentials that have been compromised. It will restrict an attacker from taking those credentials and using them from some other machine in a different network.
• Limiting to your own organization is a good idea, but this access could be too broad as it allows anyone in your organization to use the role. This would be a good addition but not a standalone control. It also would not block an attacker who has stolen valid credentials that work in your organization.
• Limiting based on tags is also interesting, but not if the people whom you are trying to restrict can or a malicious insider can change the tags. Consider the scenario where an attacker gets into the account and can modify the tags to give themselves access to the role. This again is a good addition but not a good stand-alone solution. Also, having dealt with tags before, it can be cumbersome and error prone. Test thoroughly if you use this approach.
• External IDs are really for use with third parties as explained in my post of the Confused Deputy problem. They also might help if you want to make sure someone has to know the external ID to use the role. However, anyone in the account that can see the policies and logs might be able to obtain access to the external ID. At least with this type of trust policy, an attacker cannot phish users so freely as they can with the AWS SSO CLI solution.

Probably a combination of the above controls would be helpful. However, an even better solution would be to require MFA as I wrote about in this post below and have been doing throughout this series.

That would limit this very powerful role to use by a specific user with an MFA device.

In upcoming posts we’ll continue considering how we want to architect our accounts to facilitate a more secure configuration for new AWS accounts.

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