- Unlimited Leave
- Posts
- 🔐 Restrict access to CORE accounts 👀
🔐 Restrict access to CORE accounts 👀
If you've delegated AWS SSO / IC to a separate account, take a look at this.
Ross Wickman
November 11, 2022
Happy Friday. Unlimited Leave is the newsletter that reminds you - don't make any major changes before the weekend. Also, don't forget to thank a Vet today.
If you’re reading this week, there’s a very high probability you’ve arrived here from Corey Quinn’s Last Week In AWS Newsletter.
Welcome! I’m elated that you took the time to enter your coveted email address on my form. Even if you did use an `+` alias.
A huge thank you to Corey for the plug. If he saw enough potential in this newsletter to share it, maybe there's really something here.
Like a c-squad high school senior being let in the game for the last 2 minutes; I need to make sure I don't disappoint. This is my shot so...
Erratum:
In the last issue, I mentioned an issue I was having with Delegated CloudFormation StackSet Deployment. It looks like I neglected an API function of the `CallAs` property in the request. It was for a while CLI Only. Never noticed it on the resource documentation which is clearly documented here. I have not tested it yet but this looks like exactly what I need.
This week's topics
CIS Foundation Benchmarks v1.4.0 drops in the console
Protecting Core account(s) from delegated IAM IC
CloudFormation StackSet Execution Role Policy Update
Resource of the week: DevSecOps Git Repo
Still working on Multi-Org
Honorable Mention: Delegated ORG CloudTrail Administration
CIS Foundation Benchmarks v1.4.0 drops in the console
I was poking around the Security Hub console on Wednesday (Nov 9th) and noticed a new Benchmark without seeing an announcement. Later this announcement was released. But I'll still take this prime opportunity to show it in the console and flex a little bit that my accounts are pushing 98% compliance with no Disabled Checks.
I'll be curious to see what checks are missed in v1.4.0 since I'm pretty much maxed out.
After 24 hours of v1.4.0 being enabled, it looks like there are only 4 checks that need to be re-address for my current configuration.
Protect Core Accounts from delegated Identity Center
Delegating AWS SSO permissions to an account other than the Management Account is great. As a former reseller, giving unfettered access to manage permissions of an Organization in the Management Account was a complete nightmare.
Problem solved with the Delegation of AWS SSO / Identity Center. Maybe...
The Management Account is the boss for sure. But it's just one of the few (or many) accounts you don't want just anyone poking around in.
Not to mention that if you are using an external IDP and assign Groups to the Permissions Sets attached to your Management Account, anyone with access to manage Group Membership can give Management Account access to anyone.
First Note
Only assign permission sets for the Management Account to individual users and not groups. Permission Sets can be used on multiple accounts. Multiple groups and/or uses can be assigned multiple permission sets. Multiple permissions sets can be applied to any number of accounts. It all gets very messy very fast.
Protecting other accounts
What happens if you want to protect CORE accounts like the Control Tower deployed `Log Archive` or `Audit` accounts?
Out of the box, the delegated account and users are given the ability to manipulate any permissions to ALL other accounts in the organization.
So how do you protect this from happening?
A Service Control Policy is really the best bet. Add an explicit deny to the SSO:* action for all account resources ARNs you want to deny modification access to.
In this case, you never need to worry about the delegated account users manipulating user access and permissions sets for CORE and critical service accounts if they shouldn't be able to do so.
Link to SCP - https://github.com/rwickit/aws-service-control-policies/blob/main/account/scp-protect-core-accounts.json
Link to IAM IC Permission Set for Delegated SSO:* - https://github.com/rwickit/aws-ic-permission-sets/blob/main/operations/delegated-ops-ic.yml
Quick Video Tutorial - https://www.loom.com/share/ca1015e8577142399b67fc4e5dc9ba56
SIDE NOTE: this doesn't completely protect your accounts if the Identity Center and CloudFormation StackSet delegated accounts are the same account. With the correct permissions in the delegated IC account, a user could just deploy assumable roles into your CORE accounts through the use of a StackSet.
Didn't see that one coming did you?
CloudFormation StackSet Execution Role Policy Update
Do you ever take a peak into the AWS Health Dashboard? Every once in a while there will be a spicy little nugget of information that shows up that you might not come across in too many other places.
This last week AWS dropped in the PHD a short notice about the permissions on the `AWSCloudFormationStackSetExecutionRole` no longer needing `sns:*` attached as a prerequisite to deploying service_managed StackSets. That's something interesting that I never paid any attention to.
The change was made on October 31st and released on November 2nd. It doesn't look like the formal doc has been updated as of this issue.
Resource of the week: DevSecOps Git Repo
Do you ever `Star` a GitHub repo and then never go back to look at it or even search for it? I do. 279 times to be exact. However, a former compliance colleague shared this little gem with me this last weekend and it has been a Chrome tab chomping down memory ever since.
The DevSecOps Playbook is “a step-by-step guide to implementing a DevSecOps program for any size organization.”
It’s a very nice (working) write up.
What I like about it is it provides very simple concepts and tasks to 'shift left' a lot of core competencies of DevSecOps which is exactly what we are trying to accomplish with this newsletter.
What is found in this Git Repo is a very simple mapping of the basic Controls and the Framework(s) you're meeting by accounting for them.
Any time we can take one of these items on the list and take it out of the responsibility of the developer, we help baseline and harden application security and meet security framework requirements.
Still working on Multi-Org
I'm still working on that post I promised you about building for multi-org. I'm convinced that if not through this re:Invent season, soon after there will more discussions on when and why to use multiple AWS Organizations. There are already some posts out there that discuss having too many accounts in one Organization. I'm going to take it further.
Before the post is complete, start thinking of these items:
Does my organization have clear separation of products or services?
Are resources in child accounts siloed or do they need access to other accounts?
Who are the teams accessing the accounts?
Am I getting the right information for tracking costs across all accounts?
Delegated ORG CloudTrail Administration
🤔 W.T.H? 🤦♂️
This announcement and service feature obviously has something to do with changes being announced during the upcoming re:Invent conference. Aside from just simply management and access best practices, it looks and smells like yet another way to inadvertently increase the cost of your security architecture. As stated in a previous issue, Org CloudTrails are virtually worthless.
They:
burn up your one free trail per account
you can't attach or monitor any metrics through it in any child account because the log group / stream is in the Management account
only meet the most basic requirement of "are you logging api actions and access in all your accounts"
Multiple Org Trails still aren't going to help you close controls at the individual account level. AWS Config only watches for resources in the current account so, CloudTrail, CloudWatch, and SNS (all requirements for the above-mentioned Security Hub Checks) must be enabled in the account. Not just the Management Account.
All this service feature does is enables others to deploy ORG Trails from any delegated account (up to 3 accounts) which will just double, triple, or more, your cost. What are you going to get out of one Org Trail that you can't get out of the first worthless one?
I hope I'm missing something but I can't find it. Please let me know if I am.
Help us grow
Do you know someone else that could benefit from this content?Maybe they suck at AWS Architecture and you don't have the heart to tell them?
Forward them this email or tell them to subscribe 👇
It's not quite the same as sharing those wonderful family vacation photos, but they'll enjoy it a lot more.
