How to Fix AWS IAM Identity Center

ACM.151 Simplifying adoption and improving security at the same time

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

⚙️ Check out my series on Automating Cybersecurity Metrics. The Code.

🔒 Related Stories: Cloud Governance | IAM | AWS Security

💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List

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

In my last post I wrote about AWS and SCIM.

AWS SCIM and AWS IAM Identity Center

I mentioned that I wish SCIM was available for AWS IAM. I don’t want to use AWS SSO (IAM Identity Center) which is something completely different. Why? I’ve written about that before.

The biggest problems are:

• The “magic roles” AWS SSO / IIC adds in your account with trust policies you cannot define or control.
• Because you cannot control the trust policies, you cannot enforce MFA to assume a role, external IDs, and add other conditions such as IP and ideally OU restrictions.
• You also cannot check the code for those roles into your own source control system, control and monitor deployments and drift [easily] as they are controlled by AWS.
• The requirement to use a browser to use the AWS CLI and the initiation of a CLI session from any source with no knowledge of the AWS account, user, or MFA device required.
• The ease for an attacker to switch roles on the AWS SSO dashboard if they gain access to a user’s workstation.
• An organization cannot create a user and restrict access to either the console or programmatic access the way you can with AWS IAM.
• Use of SAML seems like unnecessary complexity.
• The IIC / SSO dashboard is not administrator or security-friendly.
• On a related note, AWS Control Tower policies have issues. AWS SSO/IIC falls under AWS Control Tower, or at least it did before.
• Permission sets seem extraneous. They can be eliminated by my solution below and simply link accounts, users, and roles.

You can see the difference between AWS IAM and AWS IAM Identity Center when you log into the AWS Console. The AWS IAM screens are still there and separate from the AWS IAM Identity Center dashboard. You can get to the SSO / IIC dashboard when you log into the account you have defined as the management account if you are using AWS SSO/IIC.

AWS is trying to change all the IAM documentation to point to AWS IAM Identity Center which is frustrating because the two implementations are completely different. As I wrote about in the last post I don’t like the name change due to the confusion it creates.

What I want to write about in this post is how I would implement AWS SSO (IAM Identity Center). I think this solution might have cost AWS less to implement than the existing solution. I also think it is likely easier for customers to adopt, manage, and is more secure.

Now, I haven’t tested Okta yet, so I don’t know how this affects an external IdP (I will address that later) but as I mentioned in the last post, AWS IAM already supports IdPs. So I don’t see why this wouldn’t work for external IdPs as well. If I find any issues as I work through testing Okta integration I’ll address them at that point.

Here is how I would change AWS IAM Identity Center, if I could:

• Ditch SAML. It just adds complexity and potential security problems. AWS is not integrating with a third party to integrate with it’s own accounts. It controls the entire platform. No need for this.

• The existing login screen with the list of accounts and roles a user can assume is OK (though not very pretty). But allow organizations to enforce a policy to enforce MFA when switching roles to limit that blast radius if an attacker gets access to a user’s workstation.
• Ditch AWS CLI via the browser for reasons explained here.

• Leave everything (including how the AWS CLI works) about AWS IAM the same except the following.
• In the organization management account or delegated administrator account for IAM: the AWS IAM dashboard shows all IAM resources across the entire organization, not just the current account. Add the account ID to all resources and the ability to filter by account ID for resources deployed within a specific account.

• Make trust policies a separate entity with the ability to create trust policies stand alone in CloudFormation, AWS CLI, and the Console. Why? Read on…

• Add the ability to restrict the AWS trust policy actions separately from other IAM actions. This has many benefits including the ability to define organizational trust polices and the potential for improved separation of duties.

• Organization trust polices work exactly like existing trust policies with one exception. Add one new element to trust policies at the organizational level which we are all familiar with : RESOURCES. Resources in a trust policy are the accounts where the user can assume the role.

Here’s an existing trust policy:

{
 "Version": "2012-10-17",
 "Statement": [
  {
   "Effect": "Allow",
   "Principal": {
    "AWS": "arn:aws:iam::xxxxxxxxxxxx:root"
   },
   "Action": "sts:AssumeRole",
   "Condition": {
    "StringEquals": {
     "sts:ExternalId": "xxxxxxxxxxxx"
    },
    "Bool": {
     "aws:MultiFactorAuthPresent": "true"
    }
   }
  }
 ]
}

Here’s the new organization trust policy format that gets created in the management account — note the addition of Resources below.

{
 "Version": "2012-10-17",
 "Statement": [
  {
   "Effect": "Allow",
   "Principal": {
    "AWS": "arn:aws:iam::xxxxxxxxxxxx:root"
   },
   "Action": "sts:AssumeRole",
   "Resources" : [
      "111111111111",
      "222222222222",
      "333333333333"
   ],
   "Condition": {
    "StringEquals": {
     "sts:ExternalId": "xxxxxxxxxxxx"
    },
    "Bool": {
     "aws:MultiFactorAuthPresent": "true"
    }
   }
  }
 ]
}

• When an organizational trust policy gets deployed, the admin selects the appropriate regions (the same way the do currently in the console, on the command line, etc. when creating resources). The trust policy gets pushed out to the defined accounts, less the resource section.

• The role would need to be deployed to the accounts as well, but could be deployed independently of changes to the trust policy. Roles would have the name the customer defined with the region name appended for uniqueness.

In other words, a trust policy gets pushed to all the accounts defined in the organizational role and trust policy — and they work exactly as they do currently in AWS in the destination accounts. The customer can store the organizational trust policy in source control just like they do currently with trust policies for roles they create — unlike AWS SSO/IIC where the customer is at the mercy of what role and trust policy AWS pushes to the customer account, with “DO_NOT_DELETE” in the name. The customer can add conditions and control the principals in those trust policies and add external IDs if they need to.

That’s it. That’s my solution. #awswishlist

I hope that AWS will use this solution and pay me billions of dollars for it.

:-D

In fact, after writing this I started thinking about how I could implement it myself. Maybe more on that later when we create an AWS organization.

Why make trust policies a separate resource from roles and role policies?

Making trust policies a distinct entity with separate permissions might help solve the CreateUser escalation problem:

Backdoors and Privilege Escalation Via Cloud Account Users

An organization can separate duties between who can create a user and who can grant that user access to assume a role. An organization can also segregate duties between who can create a policy for a role and and who can define the principals that can use those permissions.

Mitigating CreateUser Privilege Escalation and Back Doors

A few other requests:

• Automate the above for those who simply want to click buttons, but use existing constructs and make sure customers can still own and control their infrastructure as code.
• Consider a way to allow an IAM administrator to create a user without getting access to the password.
• Add SCIM for AWS IAM.
• Separate billing from governance. The boundaries do not always align. OUs are for governance. Billing may need to tag things to show up on different bills but that do not align with the needs of governance teams.
• Consider a mechanism to deploy SCPs similar to how Azure Initiatives work for the Azure Security Benchmark, NIST Framework, etc.

Well, I’m sure that’s not going to happen any time soon, if ever, but #awswishlist. For now, back to my Okta testing with AWS IAM in upcoming posts. I’m also going to show you how to automate the setup of a new account structure once I get done with that.

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