Jan 19
AWS Service Control Policies
Governance: Setting security controls at the organizational level
This is a continuation of my series on Automating Cybersecurity Metrics.
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.
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:
Teri Radichel | © 2nd Sight Lab 2023
If you liked this story ~ use the links below to show your support. Thanks!
Support:
Clap for this story or refer others to follow me.
Follow on Medium: Teri Radichel
Sign up for Email List: Teri Radichel
Follow on Twitter: @teriradichel
Follow on Mastodon: @teriradichel@infosec.exchange
Follow on Post: @teriradichel
Like on Facebook: 2nd Sight Lab
Buy a Book: Teri Radichel on Amazon
Buy me a coffee: Teri Radichel
Request services via LinkedIn: Teri Radichel or through IANS ResearchAbout:
Slideshare: Presentations by Teri Radichel
Speakerdeck: Presentations by Teri Radichel
Recognition: SANS Difference Makers Award, AWS Hero, IANS Faculty
Certifications: SANS
Education: BA Business, Master of Sofware Engineering, Master of Infosec
How I got into security: Woman in tech
Company (Penetration Tests, Assessments, Training): 2nd Sight LabCybersecurity for Executives in the Age of Cloud on Amazon
Cloud Security Training (virtual now available):
2nd Sight Lab Cloud Security Training
Is your cloud secure?
Hire 2nd Sight Lab for a penetration test or security assessment.
Have a Cybersecurity or Cloud Security Question?
Ask Teri Radichel by scheduling a call with IANS Research.
More by Teri Radichel:
Cybersecurity and Cloud security classes, articles, white papers, presentations, and podcasts
