跨服务混淆了副手的预防 AWS IoT Events - AWS IoT Events

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

跨服务混淆了副手的预防 AWS IoT Events

注意

  • 该 AWS IoT Events 服务仅允许您使用角色在创建资源的同一个账户中启动操作。这有助于防止出现混乱的副手攻击 AWS IoT Events。

  • 此页面可作为参考，以了解混乱的副手问题是如何运作的，如果 AWS IoT Events 服务中允许使用跨账户资源，则可以避免。

混淆代理问题是一个安全性问题，即不具有某操作执行权限的实体可能会迫使具有更高权限的实体执行该操作。在中 AWS，跨服务模仿可能会导致混乱的副手问题。

一个服务（呼叫服务）调用另一项服务（所谓的服务）时，可能会发生跨服务模拟。可以操纵调用服务以使用其权限对另一个客户的资源进行操作，否则该服务不应有访问权限。为了防止这种情况，我们 AWS 提供了一些工具，帮助您保护所有服务的数据，这些服务委托人已被授予访问您账户中资源的权限。

我们建议在资源策略中使用aws:SourceArn和aws:SourceAccount全局条件上下文密钥来限制为资源 AWS IoT Events 提供其他服务的权限。如果 aws:SourceArn 值不包含账户 ID，例如 Amazon S3 存储桶 ARN，您必须使用两个全局条件上下文密钥来限制权限。如果同时使用全局条件上下文密钥和包含账户 ID 的 aws:SourceArn 值，则 aws:SourceAccount 值和 aws:SourceArn 值中的账户在同一策略语句中使用时，必须使用相同的账户 ID。

如果您只希望将一个资源与跨服务访问相关联，请使用 aws:SourceArn。如果您想允许该账户中的任何资源与跨服务使用操作相关联，请使用 aws:SourceAccount。aws:SourceArn值必须是与sts:AssumeRole请求关联的探测器模型或警报模型。

防范混淆代理问题最有效的方法是使用 aws:SourceArn 全局条件上下文键和资源的完整 ARN。如果不知道资源的完整 ARN，或者正在指定多个资源，请针对 ARN 未知部分使用带有通配符 (*) 的 aws:SourceArn 全局上下文条件键。例如，arn:aws:iotevents:*:123456789012:*。

以下示例说明了如何使用中的aws:SourceArn和aws:SourceAccount全局条件上下文键 AWS IoT Events 来防止出现混淆的副手问题。

主题