appdefensealliance / ASA-WG

36 stars 11 forks source link

Cloud Profile 2.7.3: excessively permissive #17

Open rdegraaf-ncc3 opened 5 months ago

rdegraaf-ncc3 commented 5 months ago

Cloud Profile rule 2.7.3 "Ensure IAM policies that allow full "*:*" administrative privileges are not attached" has the following exception:

Note that inline and AWS-manged policies are exempt from this requirement.

That exception was drawn from https://docs.aws.amazon.com/securityhub/latest/userguide/iam-controls.html#iam-1, which states

The control only checks the customer managed policies that you create. It does not check inline and AWS managed policies.

When we debated this rule a few months ago, I argued that use of the built-in AWS-managed permission policy "AdministratorAccess" should be permitted because nearly all accounts need some sort of administrator, even if only rarely. Without this exception, account operators will be required to do one of the following:

Allowing admin access to be granted only through the AWS-managed "AdministratorAccess" permission policy makes it very clear when a principal is intended to be an admin, which I feel is a good thing.

However, as written, we also allow admin permissions to be granted through inline permission policies. That largely neuters this rule since now operators can grant admin permissions however and wherever they want again. I think that AWS SecurityHub included this exception because their check works only at the level of Managed permission policies: inline permissions policies are different so their tool doesn't check them. I believe that they're documenting a limitation of their tool rather than something that they feel that account operators should do.

I propose removing "inline and" from the exception. Then we need steps to inspect inline permission policies for Users, Roles, and Groups:

  1. Run the following to get a list of IAM Users:

    aws iam list-users --query Users[].UserName
  2. For each User, use the following command to list attached inline permission policies:

    aws iam list-user-policies --user-name <user-name> --query PolicyNames[]
  3. For each permission policy, run the following command to list its contents:

    aws iam get-user-policy --user-name <user-name> --policy-name <policy-name>

    Review each permission policy to ensure that no statement has the Effect "Allow" with Action set to "*" and Resource set to "*".

  4. Run the following to get a list of IAM Roles:

    aws iam list-roles --query Roles[].RoleName
  5. For each User, use the following command to list attached inline permission policies:

    aws iam list-role-policies --role-name <role-name> --query PolicyNames[]
  6. For each permission policy, run the following command to list its contents:

    aws iam get-role-policy --role-name <role-name> --policy-name <policy-name>

    Review each permission policy to ensure that no statement has the Effect "Allow" with Action set to "*" and Resource set to "*".

  7. Run the following to get a list of IAM Groups:

    aws iam list-groups --query Groups[].GroupName
  8. For each Group, use the following command to list attached inline permission policies:

    aws iam list-group-policies --group-name <role-name> --query PolicyNames[]
  9. For each permission policy, run the following command to list its contents:

    aws iam get-group-policy --group-name <role-name> --policy-name <policy-name>

    Review each permission policy to ensure that no statement has the Effect "Allow" with Action set to "*" and Resource set to "*".

alex941115 commented 3 months ago

@rdegraaf-ncc3 do you view this as a blocker to finishing our v1.0 cloud standard? Or can this be considered a backlog item for discussion in the next round of updates?

rdegraaf commented 3 months ago

I wouldn't say that it's a blocker, just that it makes the rule kind of useless.