# 委派访问权限的策略示例
<a name="id_roles_create_policy-examples"></a>

以下示例演示了如何允许或授权 AWS 账户 访问其他 AWS 账户 中的资源。要了解如何使用这些示例 JSON 策略文档创建 IAM policy，请参阅。[使用 JSON 编辑器创建策略](access_policies_create-console.md#access_policies_create-json-editor)

**Topics**
+ [使用角色委托针对其他 AWS 账户 资源的访问权限](#example-delegate-xaccount-rolesapi)
+ [使用策略将访问权限委托给服务](#id_roles_create_policy-examples-access-to-services)
+ [使用基于资源的策略委托访问另一个账户的 Amazon S3 存储桶](#example-delegate-xaccount-S3)
+ [使用基于资源的策略委托针对另一个账户中的 Amazon SQS 队列的访问权限](#example-delegate-xaccount-SQS)
+ [当拒绝访问账户时，不得委托访问](#example-delegate-xaccount-SQS-denied)

## 使用角色委托针对其他 AWS 账户 资源的访问权限
<a name="example-delegate-xaccount-rolesapi"></a>

 有关介绍如何使用 IAM 角色对一个账户中的用户授权以访问另一个账户中 AWS 资源的教程，请参阅 [IAM 教程：使用 IAM 角色委托跨 AWS 账户的访问权限](tutorial_cross-account-with-roles.md)。

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

## 使用策略将访问权限委托给服务
<a name="id_roles_create_policy-examples-access-to-services"></a>

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

------
#### [ JSON ]

****  

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

------

## 使用基于资源的策略委托访问另一个账户的 Amazon S3 存储桶
<a name="example-delegate-xaccount-S3"></a>

在此示例中，账户 A 使用基于资源的策略（一个 Amazon S3 [存储桶策略](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingBucketPolicies.html)）授权账户 B 针对账户 A 的 S3 存储桶的完全访问权限。然后，账户 B 创建一个 IAM 用户策略，向账户 B 中的一个用户授予针对账户 A 的存储桶的访问权限。

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

------
#### [ JSON ]

****  

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

------

或者，账户 A 可使用 Amazon S3 [访问控制列表 (ACL)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/S3_ACLs_UsingACLs.html) 来授权账户 B 访问 S3 存储桶或某个存储桶内的单个对象。在这种情况下，唯一改变的是账户 A 授权访问账户 B 的方式。如此示例的下一个部分所述，账户 B 仍使用一个策略委托针对账户 B 中的 IAM 组的访问权限。有关控制对 S3 存储桶和对象访问的更多信息，请转到 *Amazon Simple Storage Service 用户指南*中的[访问控制](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingAuthAccess.html)。

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

为执行该策略，账户 B 使用 IAM 将它附加到账户 B 中的相应用户（或组）。

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": {
    "Effect": "Allow",
    "Action": "s3:List*",
    "Resource": [
      "arn:aws:s3:::amzn-s3-demo-bucket",
      "arn:aws:s3:::amzn-s3-demo-bucket/*"
    ]
  }
}
```

------

## 使用基于资源的策略委托针对另一个账户中的 Amazon SQS 队列的访问权限
<a name="example-delegate-xaccount-SQS"></a>

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

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

------
#### [ JSON ]

****  

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

------

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

------
#### [ JSON ]

****  

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

------

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

## 当拒绝访问账户时，不得委托访问
<a name="example-delegate-xaccount-SQS-denied"></a>

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

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

Account A 的存储段策略可能与下列策略类似。在此示例中，账户 A 的 S3 存储桶名为 *amzn-s3-demo-bucket*，账户 B 的账号为 1111-2222-3333。账户 A 使用 Amazon S3 执行该策略。

------
#### [ JSON ]

****  

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

------

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