Prerequisites

• Completed the CloudTrail and IAM Identity Center labs

The Lesson

In security we toss around the term “least privilege” like “don’t forget to floss”. It’s up there with “defense in depth” and “insider threat” as generic guidance that’s so broad yet ill-defined that you can make it mean almost anything you want.

Yeah, I probably just pissed off some security pros.

All those are important general concepts, but the devil is always in the details. And sometimes trying to get to true least privilege or defense in depth isn’t actually the best choice. It’s kind of a Safety Third situation. Our job is to manage and reduce risks to whatever level our organization decides it needs, while minimizing friction. It’s a balance.

That said, sometimes we need to out our foot down and prevent our org from shooting said foot/feet. Root user account security is one battle we’ve largely won (sorry you Azure folk dealing with Global Admin… you’ll get there). Our next crucible is locking down the Organization’s management account. To be fair, AWS didn’t really provide what we needed to minimize usage until relatively recently, and this is still an area where they have room to grow.

As you’ve seen, we need the management account (we called ours CloudSLAW) to enable and manage all the nifty org features like SCPs, IAM Identity Center, and CloudTrail. It makes sense to run all those from the top, but the problem is that anyone who works in the management account has very broad abilities to mess with all the other accounts. For example they could use OrganizationAccountAccessRole to gain admin access to any account in the org (which has it, but that’s the default). Or they could use a CloudFormation StackSet to give themselves access to any account. There’s simply, a lot that a bad actor can do from the management account.

For a long time our only recourse was to be very good with IAM, but we still needed to support a lot of direct access — for everything from managing Identity Center to checking billing. This meant a lot of people logging into the management account on a day-to-day basis, and constant worry that if someone gets those credentials it’s kind of game over.

Delegated Administration

To help with this, AWS added a Delegated Administration capability for multiple Organizations services. Delegated admin is quite simple: you initially set up a service in the management account, then you delegate a different account (or sometimes multiple accounts) as administrators for that service.

Users/roles in a delegated account can administer the service. Each service is a bit different in terms of how much is delegated. For example Identity Center doesn’t let the delegated admin change any permission sets that were created directly in the management account, which helps prevent a delegated admin from making themselves an admin in the management account itself. But nearly all other capabilities are fair game.

My recommendation is to create dedicated accounts for any delegated administration. This is why we created an IAM account, and why we have our SecurityAudit account.

We will use delegated administration a lot as we progress through this training. It’s a simple concept and easy to set up, but you want to be smart about your planning. For example I almost had a lab where we created Identity Center permission sets in the management account first, but then we wouldn’t be able to modify them from our delegated IAM account.

Delegated administration is your friend, so let’s go meet our new friend.

Lesson Key Points

• The Organizations management account is incredibly powerful, but also hard to secure. You can’t, for example, use SCPs.

• To minimize use of the management account we can use delegated administration to enable other accounts to manage certain Organizations services.

• This helps enforce least privilege without adding much friction.

• Using multiple dedicated administration accounts for different services helps improve our use of least privilege, while also reducing the blast radius in case an account is compromised.

The Lab

Today we will enable delegated administration for Identity Center and CloudTrail.

Identity Center will delegate admin to the IAM account we recently created. CloudTrail will delegate to the SecurityAudit account. Why SecurityAudit instead of LogArchive? Because SecurityAudit is where we will centrally manage all security monitoring. LogArchive is a great place to keep the logs, which enables us to let operations teams also access those logs without giving them access to enable/disable/modify the CloudTrail configuration.

Video Walkthrough

Step-by-Step

Sign into your Identity Center portal, then go to CloudSLAW > AdministratorAccess:

Make sure your are in the Oregon region. Then go to IAM Identity Center > Settings:

Now click the Management tab. You might need to scroll down a bit to see it:

Now click Register account under Delegated administrator:

On the next page scroll down and expand your Security OU, select the IAM account, and click Register account:

Success!

Now let’s do the same thing in CloudTrail. This will look a bit different. The first big difference is that you need to know the account ID — you can’t just pick it from a list, like we can with Identity Center. To get the ID we need to go into Organizations, expand our Security OU, and copy the account ID for our SecurityAudit account. I recommend right-clicking and opening Organizations into a new tab:

LogArchive is where our logs are stored, but the SecurityAudit account is where we manage security monitoring from.

Now go to CloudTrail:

Go to Settings > Register administrator. Notice that this time there are spots for multiple delegated administrators, unlike Identity Center. If you think about it, there might be legitimate reasons to split this up and allow, say, both security and operations to modify CloudTrail settings. I think the limit is 3 but I’m entirely too lazy to look it up, and ChatGPT is in the corner conspiring with my cat.

Paste in the account ID and then Register administrator:

You should get a green success message and see your new administrator like this:

And that’s it! Now you can manage Identity Center from the IAM account and CloudTrail from the SecurityAudit account (assuming you have the right permissions in those accounts).

Lab Key Points

• We delegated administration for Identity Center to our IAM account.

• We delegated administration of CloudTrail to our SecurityAudit account.

-Rich