Setting 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 last 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.
Service control policies (SCPs)
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.
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 ot use a separate user from my ROOT user to deploy SCPs.
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.
Teri Radichel
If you liked this story ~ clap, follow, tip, buy me a coffee, or hire me 🙂
Medium: Teri Radichel
Email List: Teri Radichel
Twitter: @teriradichel
Twitter (company): @2ndSightLab
Mastodon: @[email protected]
Post: @teriradichel
Facebook: 2nd Sight Lab
Slideshare: Presentations by Teri Radichel
Speakerdeck: Presentations by Teri Radichel
Books: Teri Radichel on Amazon
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
Buy me a coffee: Teri Radichel
Company (Penetration Tests, Assessments, Training): 2nd Sight Lab
Request services via LinkedIn: Teri Radichel or IANS Research
© 2nd Sight Lab 2023
All the posts in this series:
Automating Cybersecurity Metrics (ACM)GitHub – tradichel/SecurityMetricsAutomation
____________________________________________
Author:
Cybersecurity for Executives in the Age of Cloud on Amazon
Need Cloud Security Training? 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.
Cybersecurity & Cloud Security Resources by Teri Radichel: Cybersecurity and Cloud security classes, articles, white papers, presentations, and podcasts
AWS Service Control Policies was originally published in Cloud Security on Medium, where people are continuing the conversation by highlighting and responding to this story.
