我读了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 服务政策将有一个 Principal 和 Action “YYY:”。
我能想到的原因是，S3 是需要大量访问控制(如细粒度、分组等)的地方，创建特定 S3 的策略可以简化管理，并占用更少的后端资源？
最佳答案
S3 通过在用户、存储桶和对象的“上下文”中测试所有适用的权限来授权请求。
参见 How Amazon S3 Authorizes a Request .
这份文件初读时会让人感到困惑，但它确实可以让您更好地了解多项政策的情况。
需要注意的几点:
- 用户不拥有存储桶。 账户拥有存储桶，账户拥有用户。
- 如果用户创建了一个存储桶，则拥有该用户的帐户始终拥有该存储桶。
- 如果用户创建了一个对象，则拥有该用户的账户始终拥有该对象——即使创建该对象的存储桶属于不同的账户。
等等，什么？
如果我的账户授予您的用户在我的存储桶中创建对象的权限，那么您实际上将拥有该对象。除非你允许我阅读它，否则我无法阅读它。因为它在我的存储桶中，而且我支付存储它的费用，所以我可以删除它，但这绝对是我对该对象所能做的所有事情，除非您允许我访问它。
因此，存在三个级别的权限在起作用——允许用户执行的操作(IAM 策略)、帐户允许对其存储桶和存储桶中的对象执行的操作(存储桶策略和 ACL)以及帐户允许的操作对他们拥有的对象(对象 ACL)执行此操作。
默认操作是隐式拒绝，但我的帐户有权允许的任何操作都可以通过在任何地方允许它来允许，只要它没有被明确拒绝，在其他地方。显式拒绝将始终拒绝，无一异常(exception)。
模型的含义:
- 我的用户、我的桶、我的对象只需要一次授权；可以在这三个地方的任何一个地方授予访问权限，只需要在一个地方授予访问权限，因为我的账户拥有所有资源……所以我可以在 IAM 策略、存储桶策略或对象上执行此操作。<
- 我的用户，您的存储桶需要两项授权——我在 IAM 策略中允许我的用户，并且您必须在您的存储桶策略中允许我的用户。未经您的同意，我无权对您的存储桶执行操作，您也无权允许我的用户未经我的同意执行操作。
- 可以通过对象 ACL 或存储桶策略使存储桶中的对象公开可读，但 IAM 策略不行，因为 IAM 策略适用于用户，并且“每个人”都不是我的 IAM 用户之一。
因此，由于权限模型，S3 需要多个授权来源。如果您没有做任何跨账户的事情，其中一些将不会很明显，因为您不会意识到某些可能的组合。
我的偏好是我的存储桶策略需要很少的关注。用户在 IAM 中获得访问权限，公共(public)对象在对象级别公开(您可以在存储桶策略中执行此操作，但我更喜欢它在对象级别明确)，因此存储桶策略的用途有限 - 有时有拒绝访问除列表以外的所有 IP 地址的存储桶策略规则，通常存储桶策略拒绝没有 AES-256 的上传(因此您不能“忘记”加密对象)，有时还有用于与 CloudFront 互操作的原始访问身份规则...但我很少定制存储桶策略，因为这是我的设计理念。
关于amazon-web-services - 为什么 S3 权限可以同时由 IAM 策略和存储桶策略管理，而不是仅由其中之一管理？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/45637876/