为什么S3权限可以由IAM策略和桶策略来管理，而不仅仅是一个或另一个？

Question

我读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的策略可以减轻管理，并减少后端资源？

Answer 1

为什么存在IAM权限策略和基于资源的策略（如S3存储桶策略）有各种原因。

比方说，您有一个S3存储桶，并且您想授予对其他帐户的访问权限。这是不可能的，只能使用IAM策略。因此，您需要存储桶策略将帐户或IAM实体包含为委托人。

此外，您不能在IAM权限策略中使用Principal，因为当您将策略附加到IAM用户时，当用户提出请求时，它将成为委托人。

请看看进入了解详情如下： 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

Answer 2

S3授权通过测试所有的政府部门，在用户，桶和对象的“上下文”的请求。

参见How Amazon S3 Authorizes a Request。

该文档在第一次阅读时感到困惑，但它确实给出了有关多个策略发生的更好的意义。

有几点要记住：

• 用户没有自己的水桶。 帐户自己的存储桶和帐户自己的用户。
• 如果用户创建存储桶，拥有该用户的帐户始终拥有该存储桶。
• 如果用户创建一个对象，拥有该用户的帐户始终拥有该对象 - 即使该对象创建的存储桶由不同的帐户拥有。

等等，什么？

如果我的帐户为您的用户授予在我的存储桶中创建对象的权限，那么您实际上会拥有该对象。除非您允许我阅读，否则我无法阅读。既然它存在于我的存储桶中，并且我正在付钱来存储它，我可以删除它，但除非您允许我访问它，否则这绝对是我可以对该对象执行的所有操作。

因此，有三个级别的权限允许用户被允许执行的操作（IAM策略），允许对其存储桶及其对象（存储桶策略和ACL）以及事物帐户允许对他们拥有的对象（对象ACL）进行处理。

的默认操作是隐含的否认，但任何我的帐户有权力允许可以通过允许它在任何一个地方是允许的，只要它没有明确拒绝，在其他地方。显式拒绝将永远否认，无一例外。

启示模型：

• 我的用户，我斗，我的目标只需要一个授权;访问可以在三个地方中的任何一个地方授予，只需要在一个地方授予访问权限，因为我的帐户拥有所有资源......所以我可以在IAM策略，存储桶策略或对象中执行此操作。
• 我的用户，你的水桶需要两笔赠款 - 我让我的用户在IAM政策，和你必须让我的YOUT桶政策的用户。未经您的同意，我无权在您的存储桶中执行任何操作，并且您没有权限允许我的用户在未经我同意的情况下执行操作。
• ，可以让我在我的水桶对象通过任一对象ACL或通过桶政策公开可读，但不是IAM政策，因为IAM政策适用于用户，“大家”是不是我的IAM用户之一。

所以，S3需要becase的权限模型的补助多个来源。如果你没有做任何交叉账户，其中一些并不明显，因为你不知道一些可能的组合。

我的选择是对我的桶的政策需要稍加注意。用户可以在IAM中获得访问权限，公共对象在对象级别公开（您可以在存储桶策略中执行此操作，但我更喜欢在对象级别显式执行此操作），因此存储桶策略的用途有限 - 有时存在存储桶策略规则拒绝除列表以外的所有IP地址的访问，通常情况下存储桶策略拒绝没有AES-256的上载（因此您不能“忘记”加密对象），有时存在用于与CloudFront进行互操作的原始访问身份规则...但我很少定制桶政策，因为这是我的设计理念。