防止跨服务混淆代理 - Amazon A EC2 uto Scaling

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

防止跨服务混淆代理

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

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

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

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

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

以下示例演示如何使用 Amazon EC2 Auto Scaling 中的 aws:SourceArnaws:SourceAccount 全局条件上下文键来防范混淆代理问题。

示例:使用 aws:SourceArnaws:SourceAccount 条件键

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

此示例信任策略使用条件语句,将服务角色的 AssumeRole 功能限制为只能执行影响指定账户中指定自动扩缩组的操作。aws:SourceArnaws: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" } } } }

在上述示例中:

  • Principal 元素指定服务的服务主体 (autoscaling.amazonaws.com)。

  • Action 元素指定 sts:AssumeRole 操作。

  • Condition 元素指定 aws:SourceArnaws:SourceAccount 全局条件键。源的 ARN 包含账户 ID,因此不必将 aws:SourceAccountaws:SourceArn 结合使用。

其他信息

有关更多信息,请参阅《IAM 用户指南》中的 AWS 全局条件上下文键混淆代理人问题以及修改角色信任策略(控制台)