IAM 角色与基于资源的策略有何不同 - Amazon Identity and Access Management
关于在基于资源的策略中委派 Amazon 权限
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅中国的 Amazon Web Services 服务入门。

IAM 角色与基于资源的策略有何不同

对于一些 Amazon 服务，您可以授予对资源的跨账户访问权限。为此，您可将策略直接附加到要共享的资源，而不是将角色用作代理。要共享的资源必须支持基于资源的策略。与基于身份的策略不同，基于资源的策略指定谁（哪个主体）可以访问该资源。

注意

IAM 角色和基于资源的策略仅在单个分区内跨账户委派访问权限。例如，假定您在标准 aws 分区的美国西部（加利福尼亚北部）中有一个账户。您在 aws-cn 分区的中国（北京）中也有一个账户。您不能使用中国（北京）的账户中 Amazon S3 基于资源的策略，来允许标准 aws 账户中用户的访问权限。

与使用角色进行跨账户访问相比，使用基于资源的策略进行跨账户访问具有一些优势。利用通过基于资源的策略访问的资源，主体仍在可信账户中工作，并且无需放弃其权限来接收角色权限。换言之，主体既能够继续访问可信账户中的资源，又能继续访问信任账户中的资源。这对于向另一个账户中的共享资源复制信息或从中复制信息之类的任务非常有用。要了解您信任区域之外的账户（受信任的企业或账户）中的主体是否有权承担您的角色，请参阅什么是 IAM Access Analyzer？。

可在基于资源的策略中指定的主体包括账户、IAM 用户、联合身份用户、IAM 角色、代入角色会话或 Amazon 服务。有关更多信息，请参阅指定主体。

以下列表包括一些支持基于资源的策略的 Amazon 服务。有关支持向资源而非主体附加权限策略的更多 Amazon 服务的完整列表，请参阅 使用 IAM 的Amazon服务 并寻找具有基于资源列中为是的服务。

  • Amazon S3 存储桶 - 策略将附加到存储桶，但该策略可控制对存储桶和存储桶中的对象的访问。有关更多信息，请转至 Amazon Simple Storage Service 用户指南中的访问控制。

    在某些情况下，可能最好使用角色对 Amazon S3 进行跨账户访问。有关更多信息，请参阅 Amazon Simple Storage Service 用户指南中的示例演练。

  • Amazon Simple Notification Service (Amazon SNS) 主题 — 有关更多信息，请转至 Amazon Simple Notification Service 开发人员指南中的管理对 Amazon SNS 主题的访问。

  • Amazon Simple Queue Service (Amazon SQS) 队列 — 有关更多信息，请转至 Amazon Simple Queue Service 开发人员指南中的附录：访问策略语言

关于在基于资源的策略中委派 Amazon 权限

如果资源向账户中的主体授予权限，则您随后可将这些权限委派给特定的 IAM 身份。身份是您账户中的用户、用户组或角色。可以通过将策略附加到身份来委派权限。您可以授予拥有资源的账户所允许的最多权限。

假定基于资源的策略允许您账户中的所有主体对资源进行完全管理访问。随后，您可以将完全访问权限、只读访问权限或任何其他部分访问权限委派给 Amazon 账户中的主体。或者，如果基于资源的策略仅允许列表权限，则您只能委派列表访问权限。如果您尝试委派的权限超出您的账户所拥有的权限，您的主体将只有列表访问权限。有关将策略附加到 IAM 身份的信息，请参阅 管理 IAM policy。

注意

IAM 角色和基于资源的策略仅在单个分区内跨账户委派访问权限。例如，您不能在标准 aws 分区的账户与 aws-cn 分区中的账户之间添加跨账户访问权限。

例如，假定您管理 AccountA 和 AccountB。在 AccountA 中，您将有名为 BucketA 的 Amazon S3 存储桶。您将基于资源的策略附加到 BucketA，这将允许 AccountB 中的所有主体对存储桶中的对象进行完全访问。这些主体可以创建、读取或删除该存储桶中的任何对象。在 AccountB 中，您将策略附加到名为 User2 的 IAM 用户。该策略允许用户对 BucketA 中的对象进行只读访问。这意味着，User2 可以查看对象，但不能创建、编辑或删除对象。

委托对 Amazon 账户的访问权限

  1. AccountA 通过在基于资源的策略中将 AccountB 指定为主体来向 BucketA 提供对 AccountB 的完全访问权限。因此，AccountB 有权对 BucketA 执行任何操作，并且 AccountB 管理员可以向其在 AccountB 中的用户委派访问权限。

  2. AccountB 根用户具有授予给该账户的所有权限。因此，根用户具有对 BucketA 的完全访问权限。

  3. AccountB 管理员不向 User1 授予访问权限。默认情况下，除了明确授予的权限之外，用户不具有任何权限。因此，User1 无权访问 BucketA。

  4. AccountB 管理员向 User2 授予对 BucketA 的只读访问权限。User2 可以查看存储桶中的对象。AccountB 可委派的最大访问级别是授予给账户的访问级别。在此情况下，基于资源的策略授予了对 AccountB 的完全访问权限，但仅向 User2 授予了只读访问权限。

IAM 将在主体发出请求时对主体的权限进行评估。因此，如果您使用通配符 (*) 向用户授予对资源的完全访问权限，则主体可以访问您的 Amazon 账户有权访问的任何资源。甚至对于您在创建用户策略后添加或获得其访问权的资源也是如此。

在上述示例中，如果 AccountB 已将允许对所有账户中的所有资源进行完全访问的策略附加到 User2，则 User2 将自动具有 AccountB 有权访问的任何资源的访问权限。这包括 BucketA 访问权限以及由 AccountA 中的基于资源的策略授予的对任何其他资源的访问权限。

重要

仅向信任实体授予访问权限，并提供最低级别的访问权限。只要可信实体是其他 Amazon 账户，该账户就能够将访问权限委派给其任何 IAM 用户。可信 Amazon 账户可委派的访问权限范围仅限于它所获得的访问权限；它委派的权限不能超出账户本身所获得的访问权限。

有关权限、策略以及用于编写策略的权限策略语言的信息，请参阅适用于 Amazon 资源的 Access Management。