Profile Applicability:
Level 1


Description:
This control ensures that IAM service roles include conditions that prevent cross-service confused deputy attacks. A confused deputy attack occurs when a service with broad permissions is tricked by another AWS service or account into performing unintended actions. To prevent this, IAM roles used by AWS services (such as Lambda, S3, or EC2) should restrict their trust policies with the aws:SourceArn or aws:SourceAccount condition keys to ensure that only authorized services or resources can assume them.

Rationale:
Without these restrictions, an attacker could exploit the role’s trust relationship by invoking a service that assumes the role on their behalf, gaining unintended permissions or accessing sensitive resources. Adding aws:SourceArn or aws:SourceAccount in the trust policy helps bind the role to specific resources or accounts, mitigating the risk of privilege escalation and unauthorized cross-service access. This is a fundamental AWS best practice aligned with CIS, SOC 2, ISO 27001, and NIST 800-53 security principles.

Impact:
Positive Impact: Protects AWS service roles from being exploited by other services or accounts, ensuring only legitimate and intended principals can assume the role.
Negative Impact: If conditions are overly restrictive or misconfigured, legitimate cross-service operations might fail until corrected.

Default Value:
By default, AWS service roles do not enforce aws:SourceArn or aws:SourceAccount conditions unless explicitly added to the trust policy.

Pre-Requisite:

  • IAM permissions required: iam:GetRole, iam:GetRolePolicy, iam:UpdateAssumeRolePolicy.

  • Knowledge of the specific AWS services or resources using the service role.

Test Plan 
Using AWS Console:

  1. Sign in to the AWS Management Console.

  2. Navigate to IAM → Roles.

  3. Select a role that is used by an AWS service (for example, AWS Lambda, CodeBuild, or EventBridge).

  4. Under the Trust relationships tab, review the trust policy.

  5. Verify that the policy includes condition keys 

  6. If the trust policy does not include aws:SourceAccount or aws:SourceArn, the service role is non-compliant.

Implementation Plan
Using AWS Console:

  1. Navigate to IAM → Roles.

  2. Select the target service role.

  3. Choose the Trust relationships tab → Edit trust policy.

  4. Add the appropriate condition keys depending on the service type:

    Example 1: AWS Lambda Execution Role

    { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "lambda.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "ArnLike": { "aws:SourceArn": "arn:aws:lambda:us-east-1:123456789012:function:*" }, "StringEquals": { "aws:SourceAccount": "123456789012" } } } ]
}


    Example 2: S3 Event-Triggered Role

  5. {  "Version": "2012-10-17",  "Statement": [    {      "Effect": "Allow",      "Principal": { "Service": "s3.amazonaws.com" },      "Action": "sts:AssumeRole",      "Condition": {        "StringEquals": {          "aws:SourceAccount": "123456789012"        },        "ArnLike": {          "aws:SourceArn": "arn:aws:s3:::my-secure-bucket"        }      }    }  ]
}


  6. Save changes to the trust policy.

  7. Validate that the role continues to function as expected by testing the associated AWS service or event trigger.

Backout Plan:

  1. If modifying the trust policy disrupts service functionality, revert to the previously saved version of the policy.

  2. Identify and correct overly strict conditions before reapplying.

  3. Re-test all workflows and triggers associated with the service role.

References: