AWS Service Control Policies
ACM.136b Governance: Setting security controls at the organizational level
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
⚙️ Part of my series on Automating Cybersecurity Metrics. The Code.
🔒 Related Stories: Cloud Governance | AWS Security
💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
As a reminder I’ve recently been considering how to protect domain names migrated to a single AWS account in an organization that is dedicated for that purpose. I’ve considered the pros and cons of using various IAM functions and how someone might escalate privileges to get to the resources in that account.
In the last post, I reiterated The Dry Principle (Don’t Repeat Yourself). I’ve written about it a few times but decided to summarize it in a single post:
That concept is applicable to one more AWS construct we can use in our IAM architecture to help protect our resources and provide governance across our organization. We cloud disallow access to Route 53 domain management functions in each account for each user, group, or role. But we have another option that allows us to implement this policy in one place, one time, globally.
AWS Service Control Policies (SCPs) provide the ability to create a policy at the organizational level that applies across all your AWS accounts. Well, almost all — they don’t apply to the root management account. I’ll also explain some other caveats in upcoming posts related to Service-Linked roles.
Instead of writing code over and over to restrict access, we can write a policy that applies across the organization to limit actions across the board with a few minor exceptions.
Deny all but one role to perform certain actions
AWS provides the following example of an SCP that denies particular actions to all but a single Administrative role.
We can enforce MFA to assume the role.
We can leverage the concepts in this example policy to require MFA to assume the role.
Deny account root user from taking unauthorized actions
We can also deny access to the root user of the AWS account:
Prevent removal of account from organization
The other thing someone could try to do to get around restrictions would be to remove the account from the organization. We can prevent that as well.
Avoid using frequently active sessions to perform sensitive actions
We need to decide is who, exactly, is going to be allowed to manage domain names. We want to write an SCP that allows anyone except that specific role from accessing the account or managing domain names.
I’m going to set up a different user and role to manage domain names and disable the automation keys when not in use.
The same is true for the user account that manages SCPs.
Limiting who can change SCPs
We have the same complication with SCPs that we have with other IAM permissions. Anyone who has permission to change the policies can change or remove them to suit their own needs. I’m going to use a separate user from my ROOT user to deploy SCPs.
If we use an SCP to prevent an IAM user from transfering a domain name, but the IAM Administrator can change the SCPs, then we’ve kind of defeated the purpose of the SCP.
Perhaps we need to separate user management from organizational policy management. Perhaps organizational policy falls into the category of governance.
Automated deployment of SCPs through CloudFormation
It seems like some of the documentation I referenced earlier is incorrect because I found a CloudFormation resource that appears to create an SCP:
Next steps
It seems like these are the next steps (if these are all possible):
- Create or choose a principal that is allowed to deploy SCPs.
- Create or choose a principal that is allowed to manage domain names (transfers, register, deregister).
- Create an SCP that denies all but our SCP admin to create, modify or delete SCPs.
- Create an SCP to require MFA for all role assumptions for users.
- Create an SCP that denies all but our domain administrator principal perform the Route 53 domain actions and only in the domains account.
- Create an SCP to deny PassRole to any user because as noted we currently don’t need that permission and it poses a risk. (We are using roles with the CLI and requiring MFA.) We can restore this permission if and when we need it later.
- Create a PermissionBoundary that only allows users to change their own password, manage their own MFA keys, or add their own developer keys. *
- Create an SCP to Deny anyone but our IAM Admin from using the CreateUser permission and can only add a user with the specified PermissionBoundary.
- Limit root account actions.
- Prevent the account from being removed from the organization to circumvent the rules.
* We may have an issue with this one in relation to our automation accounts but we’ll cross that bridge when we come to it.
Well, that’s the idea, but we’ll have to see how that works out when we attempt to implement it. Which I started to do here and continue to do in other posts in this series:
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