具有数据敏感对象名称的AWS S3对象

Question

我们使用雇员的生日来命名S3对象名称。这是愚蠢的。我们希望避免创建包含敏感数据的对象名称。使用S3用户定义的元数据存储敏感数据或添加拒绝操作S3:Getobject的S3存储桶策略是否安全。哪个行得通？

Answer 1

正如你所提到的；创建包含敏感数据的对象名称不是一个好主意；但它可以……也不算太糟..我将建议删除S3策略中的listAllObjects()权限。策略应该只允许getObject()，这意味着任何人只有在知道对象名称的情况下才能获取对象，即当调用接口时已经知道用户的道布。

有了listAllObjects()权限，调用者可以列出存储桶中的所有对象，并获取用户的道布。

Answer 2

对象键和用户元数据不应用于敏感数据。对象键背后的原因很明显，但元数据可能不那么明显；

每次获取对象时，HTTP元数据都会在

• 标头中返回。这是无法禁用的，但可以使用CloudFront和Lambda@Edge响应触发器解决此问题，这些触发器可用于在通过CloudFront下载对象时编辑元数据；但是，即使对象本身已加密，
• 元数据也不会加密存储在S3中。

Object标记也不适合敏感数据，因为它们也不是加密存储的。对象标记对于标记包含敏感数据的对象非常有用，因为可以在策略中使用标记来控制对对象的访问权限，但这仅在对象本身包含敏感数据时才相关。

在“敏感”意味着“专有”而不是“个人”的情况下，标签可以作为数据的可接受位置……这可能是从业务角度被认为是敏感的数据，但不需要加密存储，例如创建对象的特定软件版本的标识。(我使用这种策略是为了，如果后来确定某个版本的代码有bug，我可以确定哪些对象可能受到了影响，因为它们是由该版本生成的)。您可能希望将此信息保留为私有，但在此上下文中它不会是“敏感的”。

Answer 3

如果您的s3存储桶用于存储私有数据，并且您允许公众访问该存储桶，这始终是一个糟糕的想法-它基本上是模糊的安全性。

您可以将存储桶锁定到您的应用程序，然后通过cloudfront签名的urls提供数据，而不是更改现有的s3结构？

基本上，在当前注入s3 url的代码中，您可以调用aws api从s3 url和策略创建一个签名的url，并将这个新的url发送给最终用户。这将屏蔽s3 url，您还可以强制实施其他限制，如链接有效时间、强制要求特定报头或限制对特定ip的访问等。您还可以获得cdn边缘缓存和降低成本作为附带好处。

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/PrivateContent.html