AWS Organizations SCPs — Redundant and Extraneous Policies

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

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

🔒 Related Stories: Bugs | AWS Security | Secure Code

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

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

The design of AWS Organizations is such that accounts and OUs end up having repetitive and redundant FullAWSAccess policies.

It seems like you should be able to remove one of the redundant policies. They both do exactly the same thing so attaching one at every level is unnecessary (from a logical standpoint).

When you try to detach he policy on this particular OU or account like the one above which already has the default FullAWSAccess policy from a parent, you get the following warning:

This warning makes it sound like removing the SCP will remove the ability to perform any action. However, the way the documentation is written, AWS SCPs do not grant permission, they only take permission away. So the above statement makes no sense in that context.

From the documentation:

SCPs alone are not sufficient to granting permissions to the accounts in your organization. No permissions are granted by an SCP.

SCPs act as guardrails, limiting actions the customers doesn’t want to allow users in an account to perform.

Therefore, the full access SCP should not be a requirement at all, nor should a requirement exist to attach an SCP to every single account and OU. Every OU and account in the hierarchy should have full access by default.

However, if you try to remove the default AllowAllAccess SCP assigned to an OU or account in the hierarchy that does not have any other SCP directly assigned, you get an error saying that you can’t remove it because every object must have an SCP assigned. Why? SCPs do not *grant* permission they take permission away per the documentation (and the way it should work if these truly are guardrails.)

This seems like a logic flaw or implementation issue because the documentation makes perfect sense. The implementation and warning messages do not, from a security policy or logic perspective. It just ends up creating a lot of unnecessary, redundant policies in customer accounts.

I haven’t tested this yet, but what if I add a policy to every object that says deny IAM unless the principal is the IAM administrator role. The policy does not grant any permission. It only denies IAM to any role except the IAM administrator.

Would that work? It should. All actions in accounts except IAM should still work if this is implemented as guardrail and SCPs do not grant permission, only take it away.

Then you’d have the same scenario — a whole bunch of redundant policies for no reason. They all do the same thing an the single policy a the root should be inherited to all the other accounts.

I don’t have time to test this right now I just hope this gets fixed.

If SCPs by default do not grant any permissions but instead only create guardrails as the above documentation states, no SCP should be required at all at any level to obtain full access to all actions.

The implementation is problematic because:

1. There is a limit of 5 SCPs at each level. The FullAccess SCP unnecessarily uses up part of that quota.
2. The quota seems low.
3. The creation of the same SCP across every account and OU is redundant.
4. Customers want to store their policies as code. They have no control over the default SCPs so they have to create a new SCP on every single object in the hierarchy, and then delete the default SCPs to manage their own policies in source control.
5. This implementation is also error prone and doesn’t follow best programming practices of reducing logic to it’s simplest, correct form.

The fix for this problem:

I would prefer if AWS would remove all the default SCPs and the restriction that requires an SCP at every level. Allow customers to add their own SCPs as they see fit, which they store in their own code repository.

Also needed — Provide templates (like Azure initiatives) for common policies customers may want to use to align with NIST, PCI, etc. that they can apply to any level within their organization including a single OU, a parent or root OU, or a single account.

#awswishlist

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