AWS S3 IAM策略，用于对单个存储桶执行读写权限

在Michael Hartl’Rails教程的第11.4.4节“ 生产中的图像上传 ”中，建议使用Amazon Web Services S3作为云存储服务。 在页面底部的一个注释中，作者自己将本书的这一部分定义为“具有挑战性”，并且还表明它“可以跳过而不会失去连续性”。

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

我发现在Stackoverflow上这是一个常见问题：例如，请参阅“ 尝试设置Amazon的S3存储桶：403禁止错误和设置权限 ”。

实际上， Amazon Web Services针对需要对单个S3存储桶具有读写权限的应用程序的解决方案不起作用，并且尝试上载图像的用户从Heroku的AWS服务器接收403禁止状态。

预定义的“AmazonS3FullAccess”策略确实有效，但不应将其视为最终解决方案，因为不需要向IAM用户授予太多权限，因此也不需要向应用程序授予权限，并且我认为也可能是安全漏洞。

那么正确的IAM政策是什么？

Answer 1

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

除了存在似乎合乎逻辑的ListBucket ， PutObject ， GetObject和DeleteObject操作之外，我发现PutObjectAcl也是必需的。

从AWS的访问控制列表（ACL）概述 ：

“Amazon S3访问控制列表（ACL）使您能够管理对存储桶和对象的访问。每个存储桶和对象都有一个ACL作为子资源附加到它。它定义了哪些AWS账户或组被授予访问权限和访问类型。收到针对资源的请求后，Amazon S3会检查相应的ACL以validation请求者是否具有必要的访问权限。当您创建存储桶或对象时，Amazon S3会创建一个默认ACL，授予资源所有者对资源的完全控制权“

此外，从’PutObjectAcl’的文档 ：

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

我在亚马逊论坛的支持请求中找不到解释为什么PutObjectAcl是必要的，但根据我的理解，可能是第一次将对象上传到存储桶中时创建对象的ACL的操作应该是明确的由进行上传的应用程序（或IAM用户）请求。 您可以在上面的亚马逊论坛讨论中找到我的政策的副本，如下所示：

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

还要考虑Heroku关于您的桶名称选择的建议 ：避免例如标点符号。