avatarTeri Radichel

Summary

The content outlines the process of analyzing AWS CloudTrail requests related to Service Control Policies (SCPs) to establish a delegated administrator for SCPs within AWS Organizations, with the aim of enhancing cloud governance and security.

Abstract

The author discusses the challenges and steps involved in creating a delegated administrator account for SCPs in AWS Organizations. They emphasize the importance of understanding the conditions and ARNs necessary for this setup, despite the documentation's lack of clarity. The author provides insights into the creation and testing of SCPs, the use of sample policies, and the need for a naming convention. They also highlight the importance of not blindly copying policies from the web and the potential impact of SCPs on service-linked roles. The article includes a detailed walkthrough of creating an SCP manually, troubleshooting common issues, and analyzing CloudTrail events to understand the requests related to SCP changes, which are logged in the us-east-1 region due to AWS Organizations being a global service. The author concludes by gathering the necessary elements to create a delegated administrator policy for SCP management.

Opinions

  • The author expresses that the current AWS documentation on creating a delegated admin account for SCPs is unclear and lacks necessary details.
  • They advocate for a cautious approach to implementing SCPs, suggesting that one should not blindly copy code from the web but rather analyze and test it thoroughly.
  • The author points out that AWS Service-Linked roles are unaffected by SCPs, which may not be immediately clear and should be considered when implementing governance policies.
  • They note the inconsistency in AWS's naming policies, particularly the restriction against using dashes in IAM Policy Statement Sids.
  • The author suggests that AWS could improve the user experience by providing an explicit list of roles not affected by SCPs.
  • They highlight the importance of a clear naming convention for SCPs, which could be organized by service or lines of business.
  • The author emphasizes the need to be explicit about the problem and check how roles are used in their accounts and what permissions they have.
  • They mention the age-old problem of region-specific logging, which can cause confusion when events are logged in a different region than expected.
  • The author expresses a desire for AWS to provide more detailed data in CloudTrail logs to aid in understanding actions taken.
  • They conclude by affirming that the necessary elements to create a delegated administrator policy for SCP management have been identified, with a hint at future exploration on this topic.

Analyzing CloudTrail Requests Related to SCPs

ACM.140 Trying to figure out conditions and ARNs to create a delegated administrator for SCPs

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

⚙️ 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

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

In my last post I wrote about how I wanted to create a delegated admin account for SCPs. I also noted that the documentation, at the time of this writing, is a bit unclear as to if this will even work, and it doesn’t provide all the necessary information to set it up.

I’m sure that will be updated at some point, but in the meantime let’s see if we can figure out what’s in a request in CloudTrail when you create an SCP. I’m going to create an SCP in my root AWS Organizations account and take a look.

You may recall that this all started when I was trying to protect my domain names. We can start with a global administration policy to restrict domain actions.

The documentation says that SCPs do not apply to the root management account, so any SCP we create won’t lock us out of our own resources, if true. The root management account should still have access, and can revert the SCP if needed. There are a number of other scenarios where SCPs do not apply listed here.

I had to revise my earlier blog post on Letting Governance Teams Govern after reading the documentation again. AWS Service-Linked roles are unaffected, and after reconsidering, it is not clear if the roles created by AWS Organizations and AWS Control Tower would fall into that category. Something to keep in mind and I’ll be exploring further later.

Sample Service Control Policies (SCPs)

AWS provides some Sample SCPs you can take a look at to get an idea what you can do with an SCP and how to write one. As I’ve said many times before, do not blindly copy and paste code off the web — even from a cloud vendor. Analyze it and test it to make sure it does what you want, and only what you want, securely.

Also note that some of these policies may already be in place if you are using AWS Control Tower or someone has created them in your account. To view Service Control Policies you can navigate to AWS Organizations, then Policies.

Click on Service Control Policies.

You can take a look at the policies to see what’s in them by clicking on any policy.

In this policy only the Control Tower Execution role is allowed to perform certain actions:

The role in the policy above is one of the roles I mentioned that may not be affected by our Service Control Policies. It would be nice if AWS could somehow provide a list of roles that will not be affected, just to be very explicit about the problem. Then customers could check to see how those roles are used in their accounts and what permissions they have.

Creating a Service Control Policy Manually

There’s the perfect way to do things and the get things done way. Ideally I want to automate creation of Service Control Policies. But to get immediate protection of my domain names across my organization, with the exceptions for roles not impacted as noted above, I’m going to manually create a Service Control Policy.

Click Create on the page listing all your service control policies.

Now, I could try to be super smart and only allow one particular role to manage my domains, but for right now, I just want to completely block that throughout my organization. I can always come back in and add the permission later.

In my case, there is little risk because I am the only one working in my account. In your case, you may be working in a large organization and I don’t recommend this approach! Who knows what functionality might break. Test first in a separate branch of your organization.

Mainly I just want to create an SCP and see the request in CloudTrail.

Enter a name. The input box nicely tells you the formats allowed. You might want to think about a naming convention here. Perhaps your convention is by service, or you have different SCPs for different lines of business. Since this SCP is applicable to my entire organization I’ll name it as such. We’ll see how this naming convention works out.

Here’s my policy:

At this point I get an error so I recreate my policy:

Inconsistent naming policies strikes again. Cannot have dashes in an IAM Policy Statement Sid.

I can see that my policy has been added. I can also see that the Control Tower policy descriptions are not very descriptive. They are all the same.

What does a request look like in CloudTrail?

Navigate to CloudTrail and try to find our actions. I tried to look up actions on the resource “ServiceControlPolicy” but it doesn’t exist in the list:

I just return to the default settings, clear true/false and hit enter to see all events. Well these create data key events with no user or resource are interesting.

Something to do with CloudTrail but would be nice if AWS would populate all the data.

I try searching by my user name. It says I performed a bunch of actions I don’t recall doing like accessing an S3 bucket and looking at DescribeConfigurationRecorderStatus which I guess is related to opening the CloudTrail page? Not sure how I triggered that. I don’t see anything related to my Service Control Policy change.

When I look up events by event source (organizations) I don’t see that here either:

Do you know what the problem is? Age-old problem that still got me for a minute. The events are logged in a different region. Even though I set up AWS Control Tower in one region and I was in that region, AWS organizations is a global service:

The events related to creating SCPs will be in us-east-1 as a result. I need to switch to that region and return to CloudTrail to see those events.

What we are looking for is the replacement for the the backup policy condition I wrote about yesterday:

I explained conditions in IAM policies here:

Ok now I can see my actions in CloudTrail where I created policies. I basically guessed this in my last post but it’s nice to know for certain. The policy type we need to use for our delegated administrator account policy is SERVICE_CONTROL_POLICY. Makes perfect sense!

I also notice here that there’s on organizations: PolicyType here. The fields for the condition are: policy > policySummary > SERVICE_CONTROL_POLICY.

There was one other thing I needed — an ARN. Perhaps. The last line of this portion of the sample delegated administrator policy refers to resources with backup_policy in the ARN.

We can get that ARN from our policy, actually. Take a look at any of your SCPs and they will have a similar ARN. The variables we want to abstract or extract if you prefer that will change from organization to organization are shown below. I want to have a way to deploy this that will work for any organization.

What is interesting in the example above, is that the backup_policy ARN in the example is structured differently. It does not include the organization ID. Perhaps backup policy ARNs are structured differently.

Well, it seems that we have what we need now to create our delegated administrator policy. I’ll try that out in the next post — probably. :) Unless I start doing that and hit another speed bump along the way.

Follow for updates.

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
Governance
Cloud Security
Cybersecurity
AWS
Service Control Policies
Recommended from ReadMedium
avatarAlexander Nguyen
The resume that got a software engineer a $300,000 job at Google.

1-page. Well-formatted.

4 min read
avatarRahul Sharma
I have Asked This SSH Question in Every AWS Interview — And Here’s the Catch

When I interview people, I always ask questions about problems that people face in the real world.

6 min read
avatarJoe Procopio
An Honest Recruiter Told Me Why Most Job Seekers Don’t Get Hired

If you want a great job, you need some tough love. Here it is.

5 min read
avatarJie Liau
Reverse Engineering to you Python binary

Reverse engineering is the critical part when doing malware analysis !!! Recently I did some self study and observed one malware…

3 min read
avatarVikas Taank
A Well Architected AWS Micro Services Architecture.

How to develop a highly resilient architecture in Cloud.

4 min read
avatarMike Cunningham
Measure, Maximize, & Mature Your Threat-Informed Defense

Written by Forrest Carver, Steve Luke, & Ivy Oeltjenbruns.

6 min read