Confused deputy prevention
The confused deputy problem occurs when an entity that doesn't have permission to perform an action can coerce a more-privileged entity to perform the action. AWS provides tools that help you protect your account if you provide third-parties (called cross-account) or other AWS services (called cross-service) access to resources in your account.
Cross-service confused deputy problem can occur when one service (the calling service) calls another service (the called service). The calling service can be manipulated to use its permissions to act on another customer's resources in a way it should not otherwise have permission to access. To prevent this, you can create policies that help you protect your data for all services with service principals that have been given access to your service's resources.
Amazon Fraud Detector supports using service roles
in your permission policies to allow a service to access another service’s resources on your behalf. A role requires two policies: a role trust policy that specifies the principal
that is allowed to assume the role and a permissions policy that specifies what can be done with the role. When a service assumes a
role on your behalf, the service principal must be allowed to perform the sts:AssumeRole
action in the role trust policy.
When a service calls sts:AssumeRole
, AWS STS returns a set of temporary security credentials that the service principal
uses to access the resources that are permitted by the role’s permissions policy.
To prevent cross-service confused deputy problem, Amazon Fraud Detector recommends using the aws:SourceArn
and aws:SourceAccount
global condition context keys in your role trust policy to limit access to the
role to only those requests that are generated by expected resources.
The aws:SourceAccount
specifies the Account ID and the aws:SourceArn
specifies the ARN of the resource associated with
cross-service access. The aws:SourceArn
must be specified using the ARN format.
Ensure that both aws:SourceAccount
and aws:SourceArn
are using the same Account ID when used in the same policy statement.
The most effective way to protect against the confused deputy problem is to use the
aws:SourceArn
global condition context key with the full ARN of the
resource. 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 a wildcard
(*
) for the unknown portions of the ARN. For example,
arn:aws:
. For information about
Amazon Fraud Detector resources and actions you can use in your permission policies, see Actions, resources, and condition keys for Amazon Fraud Detector.servicename
:*:123456789012
:*
The following role trust policy example uses wildcard(*) in the aws:SourceArn
condition key to allow Amazon Fraud Detector access to multiple
resources associated with the Account Id.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "frauddetector.amazonaws.com" ] }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:SourceAccount": "123456789012" }, "StringLike": { "aws:SourceArn": "arn:aws:frauddetector:us-west-2:123456789012:*" } } } ] }
The following role trust policy allows Amazon Fraud Detector access to only external-model
resource. Notice the aws:SourceArn
param in Condition block.
The resource qualifier is built using the model endpoint that is provided for making the PutExternalModel
API call.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "frauddetector.amazonaws.com" ] }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:SourceAccount": "123456789012" }, "StringLike": { "aws:SourceArn": "arn:aws:frauddetector:us-west-2:123456789012:external-model/MyExternalModeldoNotDelete-ReadOnly" } } } ] }