Risk Associated With The Role Created In New AWS Organizations Accounts
ACM.155 Taking a look at the OrganizationAccountAccessRole
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
⚙️ Check out my series on Automating Cybersecurity Metrics. The Code.
🔒 Related Stories: Cloud Governance | IAM | AWS Security
💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In the last post we looked at the default Service-Linked roles in a new AWS account.
In this post we’ll explore that fourth role we saw in our new AWS Organizations account that was not an AWS Service-Linked role named OrganizationAccountAccessRole.
Trust policy for the OrganizationAccountAccessRole
As before let’s take a look at the trust policy associated with the OrganizationAccountAccessRole. I explained how to navigate to this trust policy and provided a link to trust policies in the last post.
When you take a look at this account you will see that this role allows any administrator in your management account to assume this role and take actions in your related AWS organizations account.
Here’s the recommendation on the AWS security blog regarding principals in AWS security policies:
Looks like AWS is not following their own recommended best practices in this case.
Well, if you set up a new account with AWS Organizations and AWS does not allow you at that time to specify who the principal should be in the trust policy then I presume the principal needs to be “root”. Now if someone forgets about this role and how it works they might add a new administrator in the management account and not realize that user now has full access to any AWS account in the organization because admin users in the management account can assume that rule created automatically in every account.
Additionally, if a management account administrator’s credentials get compromised, now the attacker has full access to any account in the organization with no MFA requirement or any other kind of restriction.
This role seems too risky as is and we are going to want to alter it. I really wish that AWS would allow customers to create and specify their own roles that should be deployed in new AWS accounts when deployed through AWS organizations. #awswishlist
For now, we will work around the problem.
Roles created by AWS SSO and Control Tower
Now that we’ve walked through the roles created by AWS for AWS Organizations, go back and take a look at the roles created by AWS when you use Control Tower and AWS SSO in your accounts. Consider if the roles created by those services pose any risk and how would you mitigate those risks. I’ll leave that as an exercise to the reader at this point.
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 LabNeed Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for PresentationFollow 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
