防止跨服务混淆代理

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

混淆代理问题是一个安全性问题，即不具有某操作执行权限的实体可能会迫使具有更高权限的实体执行该操作。

在中 AWS，跨服务模仿可能会导致混乱的副手问题。一个服务（呼叫服务）调用另一项服务（所谓的服务）时，可能会发生跨服务模拟。可以操纵调用服务以使用其权限对另一个客户的资源进行操作，否则该服务不应有访问权限。

为了防止这种情况，我们 AWS 提供了一些工具，帮助您保护所有服务的数据，这些服务委托人已被授予对您账户中资源的访问权限。我们建议在 Amazon A EC2 uto Scaling 服务角色的信任策略中使用aws:SourceArn和aws:SourceAccount全局条件上下文密钥。这些密钥限制了 Amazon A EC2 uto Scaling 向该资源提供的其他服务的权限。

SourceArn和SourceAccount字段的值是在 Amazon A EC2 uto Scaling 使用 AWS Security Token Service (AWS STS) 代表您担任角色时设置的。

要使用aws:SourceArn或aws:SourceAccount全局条件键，请将该值设置为 Amazon A EC2 uto Scaling 存储的亚马逊资源名称 (ARN) 或资源账户。请尽可能使用更具体的 aws:SourceArn。将值设置为 ARN 或带通配符 (*) 的 ARN 模式，用于 ARN 的未知部分。如果您不知道资源的 ARN，请改用 aws:SourceAccount。

以下示例显示了如何在 Amazon A EC2 uto Scaling 中使用aws:SourceArn和aws:SourceAccount全局条件上下文键来防止出现混淆的副手问题。

示例：使用 aws:SourceArn 和 aws:SourceAccount 条件键

由一项服务担任、代表您执行操作的角色称为服务角色。如果您想创建生命周期挂钩以向亚马逊以外的任何地方发送通知 EventBridge，则必须创建一个服务角色以允许 Amazon A EC2 uto Scaling 代表您向亚马逊 SNS 主题或 Amazon SQS 队列发送通知。如果您只希望将一个自动扩缩组与跨服务访问相关联，则可以指定服务角色的信任策略，如下所示。

此示例信任策略使用条件语句，将服务角色的 AssumeRole 功能限制为只能执行影响指定账户中指定自动扩缩组的操作。aws:SourceArn 和 aws:SourceAccount 条件会得到独立评估。使用服务角色的任何请求都必须满足这两个条件。

在使用此策略之前，请将区域、账户 ID、UUID 和组名称替换为您账户中的有效值。

{
  "Version": "2012-10-17",
  "Statement": {
    "Sid": "ConfusedDeputyPreventionExamplePolicy",
    "Effect": "Allow",
    "Principal": {
      "Service": "autoscaling.amazonaws.com"
    },
    "Action": "sts:AssumeRole",
    "Condition": {
      "ArnLike": {
        "aws:SourceArn": "arn:aws:autoscaling:region:account_id:autoScalingGroup:uuid:autoScalingGroupName/my-asg"
      },
      "StringEquals": {
        "aws:SourceAccount": "account_id"
      }
    }
  }
}

在上述示例中：

其他信息

有关更多信息，请参阅 IAM 用户指南中的AWS 全局条件上下文密钥、混乱的代理问题和更新角色信任策略。