Select your cookie preferences

We use essential cookies and similar tools that are necessary to provide our site and services. We use performance cookies to collect anonymous statistics, so we can understand how customers use our site and make improvements. Essential cookies cannot be deactivated, but you can choose “Customize” or “Decline” to decline performance cookies.

If you agree, AWS and approved third parties will also use cookies to provide useful site features, remember your preferences, and display relevant content, including relevant advertising. To accept or decline all non-essential cookies, choose “Accept” or “Decline.” To make more detailed choices, choose “Customize.”

Cross-service confused deputy prevention in Incident Manager - Incident Manager

Cross-service confused deputy prevention in Incident Manager

The confused deputy problem is an information security issue that occurs when an entity without permission to perform an action calls a more-privileged entity to perform the action. This can allow malicious actors to run commands or modify resources they otherwise would not have permission to run or access.

In AWS, cross-service impersonation can lead to a confused deputy scenario. Cross-service impersonation is when one service (the calling service) calls another service (the called service). A malicious actor can use the calling service to alter resources in another service using permissions that they normally would not have.

AWS provides service principals with managed access to resources on your account to help you protect your resources' security. We recommend using the aws:SourceArn and aws:SourceAccount global condition context keys in your resource policies. These keys limit the permissions that AWS Systems Manager Incident Manager gives another service to that resource. If you use both global condition context keys, the aws:SourceAccount value and the account referenced in the aws:SourceArn value must use the same account ID when used in the same policy statement.

The value of aws:SourceArn must be the ARN of the affected incident record. If you don't know the full ARN of the resource, or if you are specifying multiple resources, use the aws:SourceArn global context condition key with the * wildcard for the unknown portions of the ARN. For example, you can set aws:SourceArn to arn:aws:ssm-incidents::111122223333:*.

In the following trust policy example, we use the aws:SourceArn condition key to restrict access to the service role based on the incident record's ARN. Only incident records created from the response plan myresponseplan are able to use this role.

{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Principal": { "Service": "ssm-incidents.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "ArnLike": { "aws:SourceArn": "arn:aws:ssm-incidents:*:111122223333:incident-record/myresponseplan/*" } } } }
PrivacySite termsCookie preferences
© 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved.