AWS Identity and Access Management
用户指南
AWS 文档中描述的 AWS 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅 Amazon AWS 入门

委派访问权限的策略示例

以下示例演示了如何允许或授予 AWS账户访问另一个 AWS 账户中的资源。要了解如何使用这些示例 JSON 策略文档创建 IAM 策略,请参阅在“JSON”选项卡上创建策略

使用角色委托针对另一个 AWS 账户的资源的访问权限

有关介绍如何使用 IAM 角色对一个账户中的用户授权以访问另一个账户中 AWS 资源的教程,请参阅教程:使用 IAM 角色委派跨 AWS 账户的访问权限

重要

您可以在角色信任策略的 Principal 元素中包含特定角色或用户的 ARN。保存策略时,AWS 将该 ARN 转换为唯一委托人 ID。如果有人希望通过删除并重新创建角色或用户来提升特权,这样有助于减轻此类风险。您通常不会在控制台中看到这个 ID,因为显示信任策略时它还会反向转换为 ARN。但是,如果您删除角色或用户,这种关系即被打破。即使您重新创建用户或角色,策略也不再适用。因为与信任策略中存储的 ID 不匹配。在这种情况下,委托人 ID 会显示在控制台中,因为 AWS 无法将其映射回 ARN。结果是,如果您删除并重新创建了信任策略的 Principal 元素所引用的用户或角色,您必须编辑角色,替换 ARN。当您保存策略时,它会转换为新的委托人 ID。

使用策略将访问权限委托给服务

以下示例显示了一个可以附加到角色的策略。该策略可使两个服务 Amazon EMR 和 AWS Data Pipeline 担任此角色。然后,这些服务可执行由分配给该角色 (未显示) 的权限策略授权执行的任何任务。要指定多个服务委托人,不用指定两个 Service 元素;您可以只使用一个该元素。实际上,您可以将一组多个服务委托人作为单个 Service 元素的值。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "elasticmapreduce.amazonaws.com.cn", "datapipeline.amazonaws.com.cn" ] }, "Action": "sts:AssumeRole" } ] }

使用基于资源的策略委托访问另一个账户的 Amazon S3 存储桶

在此示例中,账户 A 使用基于资源的策略 (一个 Amazon S3 存储桶策略) 授权账户 B 针对账户 A 的 S3 存储桶的完全访问权限。然后,账户 B 创建一个 IAM 用户策略,向账户 B 中的一个用户授予针对账户 A 的存储桶的访问权限。

账户 A 中的 S3 存储桶策略可能与以下策略类似。在此示例中,账户 A 的 S3 存储桶的名称为 mybucket,账户 B 的账号为 111122223333。它在账户 B 中未指定任何单个用户或组,仅指定账户本身。

{ "Version": "2012-10-17", "Statement": { "Sid": "AccountBAccess1", "Effect": "Allow", "Principal": {"AWS": "111122223333"}, "Action": "s3:*", "Resource": [ "arn:aws-cn:s3:::mybucket", "arn:aws-cn:s3:::mybucket/*" ] } }

或者,账户 A 可使用 Amazon S3 访问控制列表 (ACL) 来授权账户 B 访问 S3 存储桶或某个存储桶内的单个对象。在这种情况下,唯一改变的是账户 A 授权访问账户 B 的方式。如此示例的下一个部分所述,账户 B 仍使用一个策略委托针对账户 B 中的 IAM 组的访问权限。欲了解更多有关对 S3 存储段和数据元实施控制访问的信息,请转到 Amazon Simple Storage Service 开发人员指南 中的 Access Control

账户 B 的管理员可能创建以下策略示例。该策略向账户 B 中的组或用户授予读取访问权限。前一策略向账户 B 授予访问权限。但是,除非组或用户策略显式授予资源访问权限,否则账户 B 中的单个组和用户不能访问资源。此策略中的权限只能是上述跨账户策略中的权限的一个子集。相比于账户 A 在第一个策略中授予账户 B 的权限,账户 B 无法向其组和用户授予更多权限。在此策略中,将显式定义 Action 元素以仅允许 List 操作,而且此策略的 Resource 元素与由账户 A 执行的存储桶策略的 Resource 匹配。

为执行此策略,账户 B 使用 IAM 将它附加到账户 B 中的相应用户 (或组)。

{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "s3:List*", "Resource": [ "arn:aws-cn:s3:::mybucket", "arn:aws-cn:s3:::mybucket/*" ] } }

使用基于资源的策略委托针对另一个账户中的 Amazon SQS 队列的访问权限

在以下示例中,账户 A 有一个 Amazon SQS 队列,该队列使用附加到该队列的基于资源的策略向账户 B 授权队列访问权限。然后,账户 B 使用 IAM 组策略委托针对账户 B 中的组的访问权限。

以下示例队列策略为账户 B 授予权限,以对账户 A 中名为 queue1 的队列执行 SendMessageReceiveMessage 操作,但只能在 2014 年 11 月 30 日中午 12:00 至下午 3:00 之间执行该操作。Account B 的账户编号为 1111-2222-3333。账户 A 使用 Amazon SQS 执行此策略。

{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Principal": {"AWS": "111122223333"}, "Action": [ "sqs:SendMessage", "sqs:ReceiveMessage" ], "Resource": ["arn:aws-cn:sqs:*:123456789012:queue1"], "Condition": { "DateGreaterThan": {"aws:CurrentTime": "2014-11-30T12:00Z"}, "DateLessThan": {"aws:CurrentTime": "2014-11-30T15:00Z"} } } }

账户 B 向账户 B 中的组委托访问权限的策略可能类似于以下示例。账户 B 使用 IAM 将此策略附加到组 (或用户)。

{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "sqs:*", "Resource": "arn:aws-cn:sqs:*:123456789012:queue1" } }

在前述 IAM 用户策略示例中,账户 B 使用通配符授权其用户访问针对账户 A 的队列的所有 Amazon SQS 操作。但是账户 B 可委托的范围仅限于账户 B 被授权访问的范围。拥有第二个策略的账户 B 组只能在 2014 年 11 月 30 日中午至下午 3:00 之间访问该队列。根据账户 A 的 Amazon SQS 队列策略的定义,用户只能执行 SendMessageReceiveMessage 操作。

当拒绝访问账户时,不得委托访问

如果其他账户已显式拒绝访问用户的父账户,则 AWS 账户不得委托针对该账户的资源的访问权限。此“拒绝”将传播到该账户内的所有用户,无论用户的现有策略是否授予这些用户访问权限。

例如,账户 A 编写了一个针对其账户中 S3 存储桶的存储桶策略,其中显式拒绝了账户 B 访问账户 A 的存储桶。但账户 B 编写了一个 IAM 用户策略,其中对账户 B 中的一个用户授予了对账户 A 的存储桶的访问权限。应用于账户 A 的 S3 存储桶的“显式拒绝”将传播到账户 B 中的用户。它会覆盖用于对账户 B 中用户授予访问权限的 IAM 用户策略。(有关如何计算权限的详细信息,请参阅 策略评估逻辑。)

Account A 的存储段策略可能与下列策略类似。在此示例中,账户 A 的 S3 存储桶的名称为 mybucket,账户 B 的账号为 1111-2222-3333。账户 A 使用 Amazon S3 执行此策略。

{ "Version": "2012-10-17", "Statement": { "Sid": "AccountBDeny", "Effect": "Deny", "Principal": {"AWS": "111122223333"}, "Action": "s3:*", "Resource": "arn:aws-cn:s3:::mybucket/*" } }

此“显式拒绝”将覆盖账户 B 中所有提供账户 A 中 S3 存储桶访问权限的策略。