【问题标题】:Which STS key was used to upload data to s3?哪个 STS 密钥用于将数据上传到 s3?
【发布时间】:2016-04-10 03:03:16
【问题描述】:

给定一个 S3 对象,我如何知道使用哪个 STS 密钥上传它?

解释我的用例场景(仅供参考): 在我的应用程序中,我允许我的用户使用 Javascript SDK 将数据上传到 s3。为了启动 SDK,我向我的用户提供了一个 STS token,有效期为 15 分钟。

用户应该使用该密钥一次上传恰好 1 个数据,我的应用程序稍后会处理这些数据。

问题是一旦我发出这个令牌并把它交给用户,一些恶意用户可能会尝试向我的存储桶上传许多随机的大数据。

由于只是看到一个对象,我无法将该数据与用户相关联,我不知道谁是罪魁祸首。如果通过某种 ma​​gic 方法我可以要求 aws 给我用于上传此数据的密钥,那么我可以交叉匹配我已将其发给的用户的密钥,从而找到我的罪魁祸首。

  1. 我不能使用metadata,因为恶意用户不会提供它。

【问题讨论】:

    标签: amazon-s3 aws-sdk


    【解决方案1】:

    启用AWS CloudTrail 和/或启用S3 server logs 应该为您提供适当的日志记录以跟踪此信息。

    【讨论】:

    • 感谢您的回复。根据这篇文章 (docs.aws.amazon.com/awscloudtrail/latest/userguide/…),只能记录 SAML 和 web-id-federation STS 密钥,但是,我使用 getSessionToken() 来获取我的令牌,这些令牌不属于这些类别。有什么建议吗?
    • @Rash 听起来您不应该使用 getSessionToken 而是应该使用假设角色,这将允许您提供一个策略语句来将使用临时凭据执行的操作限制为只有一个键单个存储桶,如果您愿意,甚至可以来自单个源 IP。公开会话令牌似乎可能会放弃太多特权。 “通常,如果您想使用 MFA 保护对特定 AWS API 的编程调用,则使用 GetSessionToken” docs.aws.amazon.com/STS/latest/APIReference/…
    • @Michael-sqlbot 我不太担心使用GetSessionToken(),因为生成这些令牌本身的 IAM 角色有权仅将对象上传到特定的存储桶和密钥,因此所有生成的临时信用也受到这些限制。 GetSessionToken 似乎是最基本的令牌形式,根本不赋予临时信用任何权力。另一方面,AssumedRole 在这一点上显得笨重且不必要。我喜欢 S3 日志的想法,但我看不到包含 STS 密钥的日志。
    • “笨重且不必要”会阻止您现在尝试查找并在事后​​解决的问题。奇怪的是,根据docs,您不应该能够使用实例角色获取会话令牌,因为这些凭据是使用假设角色获得的。奇怪的。 CloudTrail 应该有你正在寻找的东西。
    • @Michael-sqlbot 你完全正确。出于测试目的,我使用我的管理员帐户来生成 STS 令牌,认为稍后我将使用较低权限的帐户来生成令牌。我没有意识到该帐户首先需要AssumeRole 权限才能生成令牌。所以我今天继续使用AssumeRole 并相应地创建了用户。这也解决了您为什么能够使用实例角色获取会话令牌的谜团。感谢您的帮助:)
    猜你喜欢
    • 1970-01-01
    • 2023-01-25
    • 1970-01-01
    • 1970-01-01
    • 2014-07-10
    • 2017-09-11
    • 2012-08-08
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多