用于只读和一次写入访问的 Amazon S3 ACL答案

【问题标题】：Amazon S3 ACL for read-only and write-once access用于只读和一次写入访问的 Amazon S3 ACL
【发布时间】：2012-05-22 11:32:47
【问题描述】：

我正在开发一个 Web 应用程序，我目前已将以下 ACL 分配给它用于访问其数据的 AWS 账户：

{
  "Statement": [
    {
      "Sid": "xxxxxxxxx", // don't know if this is supposed to be confidential
      "Action": [
        "s3:*"
      ],
      "Effect": "Allow",
      "Resource": [
        "arn:aws:s3:::cdn.crayze.com/*"
      ]
    }
  ]
}

不过，我想让这更具限制性，这样如果我们的 AWS 凭证被泄露，攻击者就无法破坏任何数据。

从文档来看，我似乎只想允许以下操作：s3:GetObject 和 s3:PutObject，但我特别希望该帐户只能创建尚不存在的对象 - 即 PUT应拒绝对现有对象的请求。这可能吗？

【问题讨论】：

不知道语言标签！这些在哪里列出？
我认为它不支持这一点的原因是 S3 是一种最终一致的，因此没有权威的“对象不存在”语义。

标签： amazon-s3 acl

【解决方案1】：

这在Amazon S3 中是不可能的，就像你想象的那样；但是，您可以通过Using Versioning 解决此限制，这是一种将对象的多个变体保存在同一个存储桶中的方法，并且在开发时考虑了这样的用例：

您可以启用版本控制以防止对象被删除或被错误覆盖，或存档对象，以便您可以检索以前的版本。

还有一些相关的常见问题解答，例如：

What is Versioning? - 版本控制允许您保留、检索和恢复存储在 Amazon S3 存储桶中的每个对象的每个版本。为存储桶启用版本控制后，只要您对现有对象执行 PUT、POST、COPY 或 DELETE 操作，Amazon S3 就会保留它们。默认情况下，GET 请求将检索最近写入的版本。可以通过在请求中指定版本来检索被覆盖或删除的对象的旧版本。
Why should I use Versioning? - Amazon S3 为客户提供高度耐用的存储基础设施。版本控制通过在客户意外覆盖或删除对象时提供一种恢复方式来提供额外的保护。 这使您可以轻松地从意外的用户操作和应用程序故障中恢复。您还可以使用版本控制来保留和归档数据。 [强调我的]
How does Versioning protect me from accidental deletion of my objects? - 当用户对对象执行 DELETE 操作时，后续默认请求将不再检索该对象。但是，该对象的所有版本将继续保留在您的 Amazon S3 存储桶中，并且可以检索或恢复。 只有 Amazon S3 存储桶的所有者才能永久删除版本。 [强调我的]

如果您对存储桶所有者的 AWS 凭证非常重视（当然，他们可能不同于访问用户），您甚至可以更进一步，请参阅 How can I ensure maximum protection of my preserved versions?：

使用multi-factor authentication 的版本控制的 MFA 删除功能可用于提供额外的一层安全。 [...] 如果您使用 MFA Delete 启用版本控制在您的 Amazon S3 存储桶上，需要两种形式的身份验证永久删除对象的一个版本：您的 AWS 账户凭证和有效的六位数代码和序列号您实际拥有的身份验证设备。 [...]

【讨论】：

不幸的是，这是唯一可用于非常常见且明显的备份需求（“只写新的”）的解决方案。如果您使用 S3 版本控制，则无法使用 S3 的生命周期管理策略。因此，现在您不得不在拥有可靠的备份安全性或拥有删除旧备份的便捷方式之间做出选择。我认为两者都不要太期待。
我经常在需要的地方同时使用同一个存储桶中的版本控制和生命周期系统——使用一个并不排除另一个。来自 s3 接口中版本控制的描述：You can use Lifecycle rules to manage all versions of your objects as well as their associated costs. Lifecycle rules enable you to automatically archive your objects to the Glacier Storage Class and/or remove them after a specified time period.
听起来不错。攻击者是否可以禁用版本控制？还是没关系，因为他们无论如何都无法删除已经版本化的对象？
“攻击者是否可以禁用版本控制”。如果攻击者拥有“PutBucketVersioning”权限，他们可以禁用版本控制，这会停止继续创建版本，但不会删除以前创建的版本。但是任何对存储桶具有只写访问权限的东西可能不应该具有“PutBucketVersioning”访问权限

【解决方案2】：

如果这是您试图避免的意外覆盖，并且您的业务需求允许在短时间内出现不一致，您可以在 Lambda 函数中执行回滚：

制定“禁止新对象同名”的策略。大多数时候它不会发生。强制执行：
在AWS Lambda function 中侦听 S3:PutObject 事件。
触发事件时，检查是否存在多个版本。
如果存在多个版本，请删除除最新版本之外的所有版本。
通知上传者发生了什么（将原始上传者放在对象的x-amz-meta-* 中很有用。更多信息here）。

【讨论】：

如果你想防止覆盖，#4不应该是“删除所有最旧的”吗？

【解决方案3】：

您现在可以使用 S3 对象锁定来锁定对象的版本。这是按桶设置的，允许您放置两种 WORM 锁中的一种。

“保留期” - 无法更改
“合法保留” - 存储桶所有者可以随时更改

https://docs.aws.amazon.com/AmazonS3/latest/dev/object-lock.html

正如下面@Kijana Woodard 所述，这不会阻止创建新版本的对象。

【讨论】：

这是解决 S3 经常需要的功能的绝佳解决方案。
您仍然可以创建新版本。 "对对象设置保留期或合法保留仅保护请求中指定的版本，不会阻止创建对象的新版本。"

【解决方案4】：

编辑：如果您来自此question，则适用。

对象锁仅适用于版本化存储桶。如果您可以不为您的存储桶启用版本控制，但可以容忍短暂的不一致，即假定文件存在而 DELETE 仍在进行中（S3 只是最终一致）可能导致 PUT -after-DELETE 如果在紧密循环中使用会间歇性地失败，或者相反，连续的 PUT 会间歇性地错误地成功，那么以下解决方案可能是合适的。

给定对象路径，读取对象的 Content-Length 标头（来自元数据，HeadObject 请求）。仅在请求成功时写入对象，并且在适用的情况下，如果长度大于zero。

【讨论】：