针对单个存储桶的读写权限的AWS S3 IAM策略

Question

在Michael Hartl的Rails教程的第11.4.4章“Image upload in production”中，建议使用Amazon Web Services S3作为云存储服务。在页面底部的注释中，作者自己将书的这一部分定义为“具有挑战性的”，并建议“可以跳过它而不会失去连续性”。

事实上，本节最具挑战性的部分之一是找到一个合适的IAM策略，该策略可以附加到AWS的IAM用户，以便授予IAM用户对S3存储桶的读写权限。

我发现在Stackoverflow上这是一个常见的问题:例如，参见'Trying to set up Amazon's S3 bucket: 403 Forbidden error & setting permissions‘。

实际上，需要单个S3存储桶上的读写权限的应用程序的Amazon Web Services's solution不起作用，并且尝试上传图像的用户从Heroku的AWS服务器收到403禁止状态。

预定义的“AmazonS3FullAccess”策略确实有效，但是它不应该被视为最终的解决方案，因为不需要向IAM用户授予太多权限，因此也不需要向应用程序授予太多权限，而且我认为这也可能是一个安全缺陷。

那么，正确的IAM策略是什么？

Answer 1

如果“AmazonS3FullAccess”策略有效，那么肯定会有一些对应用程序的工作至关重要的操作。

除了ListBucket、PutObject、GetObject和DeleteObject这些看似合乎逻辑的操作之外，我发现PutObjectAcl也是必要的。

来自亚马逊网络服务的Access Control List (ACL) Overview

“通过亚马逊S3访问控制列表( ACL )，您可以管理对存储桶和对象的访问。每个存储桶和对象都有一个作为子资源附加到其上的访问控制列表。它定义了哪些S3帐户或组被授予访问权限以及访问类型。收到针对资源的请求时，亚马逊S3会检查相应的访问控制列表，以验证请求者是否具有必要的访问权限。当您创建存储桶或对象时，Amazon S3会创建一个默认访问控制列表，该默认访问控制列表将授予资源所有者对资源的完全控制权限。”

此外，从documentation on 'PutObjectAcl'

PUT操作的此实现使用ACL子资源为存储桶中已存在的对象设置访问控制列表( acl )权限...对象的ACL设置在对象版本级别。默认情况下，PUT设置对象的当前版本的ACL。

我在亚马逊论坛的my request of support中找不到关于为什么PutObjectAcl是必要的解释，但根据我的理解，创建对象的ACL的操作可能是在对象首次上传到存储桶中时进行的，应该由进行上传的应用程序(或IAM用户)显式请求。您可以在上面的亚马逊论坛讨论和下面的讨论中找到我的政策的副本：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "s3:ListBucket"
      ],
      "Effect": "Allow",
      "Resource": "arn:aws:s3:::<bucket-name>"
    },
    {
      "Action": [
        "s3:DeleteObject",
        "s3:GetObject",
        "s3:PutObject",
        "s3:PutObjectAcl"
      ],
      "Effect": "Allow",
      "Resource": "arn:aws:s3:::<bucket-name>/*"
    }
  ]
}

在选择存储桶名称时也要考虑Heroku's suggestions：例如，避免标点符号。