RCP should deny cross-account role assumption from outside the Organization

iam

Description

A Resource Control Policy (RCP) should deny all cross-account role assumption methods from principals outside the AWS Organization. Without this control, IAM roles in member accounts can be assumed by any external AWS principal that satisfies the role’s trust policy, creating a lateral-movement risk and potential data exfiltration path.

This rule verifies that an RCP denies all three STS role assumption actions when aws:PrincipalOrgID does not match the organization ID:

  • sts:AssumeRole
  • sts:AssumeRoleWithSAML
  • sts:AssumeRoleWithWebIdentity

Alternatively, a wildcard action (sts:* or *) satisfies the requirement. Denying only sts:AssumeRole is insufficient — an attacker could still use SAML or Web Identity federation to assume roles from outside the organization.

The RCP must use a StringNotEquals or StringNotEqualsIfExists condition on aws:PrincipalOrgID to enforce the organization boundary.

Note: AWS service principals should be exempted using aws:PrincipalIsAWSService conditions to avoid disrupting AWS service integrations. Trusted third-party accounts can be exempted using aws:PrincipalAccount conditions.

Remediation

Create a Resource Control Policy that explicitly denies all three STS role assumption actions (sts:AssumeRole, sts:AssumeRoleWithSAML, sts:AssumeRoleWithWebIdentity) or sts:* using Action (not NotAction) from principals outside the organization and attach it to the organization root. The deny statement must include a StringNotEquals or StringNotEqualsIfExists condition on aws:PrincipalOrgID. Refer to the RCP syntax documentation and the AWS data perimeter best practices for guidance.