# Ensure IAM Service Roles Prevent Against a Cross-Service Confused Deputy Attack - Source: https://support.icompaas.com/support/solutions/articles/62000233833-ensure-iam-service-roles-prevent-against-a-cross-service-confused-deputy-attack - Section: [Solutions](https://support.icompaas.com/support/solutions) › [AWS Checks New Version](https://support.icompaas.com/support/solutions/62000112673) › [AWS New Checks](https://support.icompaas.com/support/solutions/folders/62000169206) - Last updated: 2026-05-29 - Publisher: iCompaas, Inc. (https://www.icompaas.com) **Profile Applicability:** - **Level 2** **Description:**A confused deputy attack occurs when a service with permissions inadvertently performs actions on behalf of an unauthorized entity. In AWS, cross-service confused deputy attacks can happen when a service role is used improperly, allowing unintended access to AWS resources. To mitigate this risk, IAM policies should explicitly limit which services can assume a role using the aws:SourceArn or aws:SourceAccount condition keys. **Rationale:** Mitigating confused deputy attacks ensures that IAM service roles are only used by authorized AWS services with defined permissions. This prevents unintended privilege escalation and unauthorized access, helping to enforce the principle of least privilege. By implementing condition-based access controls, organizations can prevent malicious or unintended use of IAM roles across AWS services. **Impact: Pros:** - Prevents unauthorized access through misconfigured or overly permissive IAM roles. - Reduces the risk of privilege escalation by restricting role assumptions. - Ensures compliance with security best practices and regulatory requirements. **Cons:** - Requires careful management of IAM policies and conditions. - Can cause access issues if incorrectly configured, requiring additional troubleshooting. **Default Value:** By default, IAM roles do not enforce conditions preventing cross-service confused deputy attacks. AWS recommends explicitly defining service role permissions using condition keys. **Pre-requisites:** - AWS IAM permissions: - iam:UpdateRolePolicy - iam:GetRolePolicy - iam:ListRoles - AWS CLI installed and configured. - Access to IAM role configurations and permission management. **Remediation:** **Test Plan: Using AWS Console:** 1. Sign in to the AWS Management Console. 2. Navigate to IAM and select Roles. 3. Identify IAM roles used for cross-service access. 4. Check the Trust Relationship section to ensure condition keys (aws:SourceArn or aws:SourceAccount) are used. 5. If missing, update the trust policy to restrict access to specific AWS services and accounts. **Using AWS CLI:** 1. List IAM roles: aws iam list-roles --query 'Roles\[\*\].RoleName' 2. Check trust relationships for a specific role: aws iam get-role --role-name --query 'Role.AssumeRolePolicyDocument' 3. If the policy does not contain aws:SourceArn or aws:SourceAccount, update it: aws iam update-assume-role-policy --role-name --policy-document file://trust-policy.json Ensure the trust-policy.json file includes conditions to restrict access. **Implementation Plan: Using AWS Console:** 1. Open the AWS Management Console and navigate to IAM. 2. Select Roles and choose the role that needs restriction. Edit the Trust Relationship and add conditions like: "Condition": { "StringEquals": { "aws:SourceAccount": "123456789012" }, "ArnLike": { "aws:SourceArn": "arn:aws:s3:::my-secure-bucket" } } 3. Save the changes and verify restricted access. **Using AWS CLI:** 1. Update the assume role policy with proper conditions: aws iam update-assume-role-policy --role-name --policy-document file://trust-policy.json 2. Validate the policy changes by checking the role’s trust relationship: aws iam get-role --role-name --query 'Role.AssumeRolePolicyDocument' **Backout Plan: Using AWS Console:** 1. Sign in to the AWS Management Console and navigate to IAM. 2. Select Roles and locate the affected role. 3. Edit the Trust Relationship to remove the restrictive conditions or revert to a previous version. 4. Save the changes and verify that the role functions as expected. **Using AWS CLI:** 1. Identify affected roles and review logs for permission errors. 2. Restore the previous policy version using the following command: aws iam update-assume-role-policy --role-name --policy-document file://previous-policy.json 3. Verify that authorized services can assume the role while blocking unauthorized ones. 4. Document changes and implement troubleshooting steps for future reference. **Reference:** - AWS IAM: [Understanding Trust Policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies.html) - AWS CLI: [update-assume-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/update-assume-role-policy.html) **CIS Controls:**

Version

Control ID

Control Description

7.1

4.3

Ensure IAM role trust policies enforce least privilege and limit cross-service access.

7.1

14.4

Monitor and review IAM policies to prevent privilege escalation risks.

## Related compliance guidance - [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them. - [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.