我读了https://aws.amazon.com/blogs/security/iam-policies-and-bucket-policies-and-acls-oh-my-controlling-access-to-s3-resources/，我回答了什么，什么时候，但不是为什么 .
我是AWS的新手，并试图学习它 .
为什么要创建两个方法，而不只是一个？根据文章中的示例，为什么不只是使用IAM策略来处理这两个用例，例如让IAM策略JSON包含'Principal'条目作为“基于关联”或“??”，那么它就像Bucket一样工作政策 . 看起来任何需要策略控制的服务都会创建另一种策略 . 例; YYY服务政策将有一个委托人和行动“YYY：” .
我能想到的原因是，S3需要大量的访问控制（如细粒度，分组等），并且创建特定S3的策略可以简化管理，并减少后端资源的使用？
2 回答
S3通过在用户，存储桶和对象的“上下文”中测试所有适用的权限来授权请求 .
见How Amazon S3 Authorizes a Request .
本文档在首次阅读时会引起混淆，但它确实可以更好地了解多个策略所发生的情况 .
要记住以下几点：
用户不拥有存储桶 . 帐户拥有存储桶，帐户拥有用户 .
如果用户创建存储桶，则拥有该用户的帐户始终拥有该存储桶 .
如果用户创建对象，则拥有该用户的帐户始终拥有该对象 - 即使创建对象的存储桶由其他帐户拥有 .
等等，什么？
如果我的帐户授予您的用户在我的存储桶中创建对象的权限，您实际上将拥有该对象 . 除非你允许我阅读，否则我无法阅读 . 因为它在我的桶里，而我付钱存储它，我可以删除它，但除了你让我访问它之外，我绝对可以对该对象做所有事情 .
因此，有三个级别的权限正在运行 - 允许用户执行的操作（IAM策略），允许对其存储桶执行的事务以及该存储桶中的对象（存储桶策略和ACL）以及事务帐户允许完成到他们拥有的对象（对象ACL） .
默认操作是隐式拒绝，但是我的帐户有权允许的任何内容都可以通过允许它在任何一个地方允许，只要它没有被明确拒绝，在其他地方 . 明确拒绝总是否认，毫无例外 .
模型的含义：
我的用户，我的桶，我的对象只需要一笔赠款;可以在三个地方中的任何一个地方授予访问权限，只需要在一个地方授予访问权限，因为我的帐户拥有所有资源...所以我可以在IAM策略或存储桶策略或对象上执行此操作 .
我的用户，您的存储桶需要两次授权 - 我允许我的用户使用IAM策略， and 您必须允许我的用户使用您的存储桶策略 . 我没有权限允许我的用户在未经我同意的情况下做事 .
可以通过对象ACL或通过桶策略使我的桶中的对象公开可读，但不能通过IAM策略，因为IAM策略适用于用户，"everybody"不是我的IAM用户之一 .
因此，S3需要多个授权来源，因为权限模型 . 如果你没有做任何交叉账户，那么其中一些并不明显，因为你不会意识到某些可能的组合 .
我的首选是我的桶政策很少需要关注 . 用户在IAM中被授予访问权限，公共对象在对象级别公开（您可以在存储桶策略中执行此操作，但我更喜欢在对象级别显式），因此存储桶策略的用途有限 - 有时存在拒绝访问除列表之外的所有IP地址的存储桶策略规则，通常存储桶策略拒绝不使用AES-256进行上载（因此您不能“忘记”加密对象），有时还存在与CloudFront进行互操作的原始访问标识规则...但我对桶策略的定制很少，因为这是我的设计理念 .
存在IAM权限策略和基于资源的策略（例如S3存储桶策略）的原因有很多 .
假设您有一个S3存储桶，并且您希望授予其他帐户的访问权限 . 不可能仅使用IAM策略 . 因此，您需要使用存储桶策略将帐户或IAM实体包含为Principal .
此外，您不能在IAM权限策略中使用Principal，因为当您将策略附加到IAM用户时，当用户发出请求时，它将成为Principal .
请有关详细信息，请查看以下内容：http://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#Principal http://docs.aws.amazon.com/AmazonS3/latest/dev/access-control-overview.html