本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 委派存取權限的政策範例
下列範例示範如何允許或授予 AWS 帳戶 存取另一個 中的資源 AWS 帳戶。若要了解如何使用這些範例 JSON 政策文件來建立 IAM 政策，請參閱 [正在使用 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 帳戶
如需示範如何使用 IAM 角色授予某個帳戶中使用者存取另一個帳戶中 AWS 資源的教學課程，請參閱 [IAM 教學課程：使用 IAM 角色在 AWS 帳戶之間委派存取權](tutorial_cross-account-with-roles.md)。
**重要**
您可以在角色信任政策的 `Principal` 元素中包含特定角色或使用者的 ARN。當您儲存政策時， 會將 ARN AWS 轉換為唯一的委託人 ID。如果有人希望藉由刪除並重新建立角色或使用者來提升特權，這麼做可有助於減輕此類風險。您通常不會在主控台中看到此 ID，因為在顯示信任政策時還會反向轉換回 ARN。不過，如果您刪除角色或使用者，則關係會中斷。即使重新建立使用者或角色，您的政策都不再適用，因為它不符合信任政策中所儲存的主體 ID。發生這種情況時，主體 ID 會顯示在主控台中，因為 AWS 無法再將其對應回 ARN。結果是，如果您刪除並重新建立了信任政策的 `Principal` 元素所引用的使用者或角色，您必須編輯角色來替換 ARN。當您儲存政策時，它會轉換為新的主體 ID。
## 使用政策將存取權限委託給服務
以下範例顯示一個可以連接到角色的政策。此政策可讓 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 使用資源類型政策 (一個 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 具有 Amazon SQS 佇列，而此佇列使用連接至佇列的資源類型政策向帳戶 B 授予佇列存取權。然後，帳戶 B 使用 IAM 群組原則委派帳戶 B 中群組的存取權。
以下範例佇列政策為帳戶 B 授予許可，以對帳戶 A 中名為 *queue1* 的佇列執行 `SendMessage` 和 `ReceiveMessage` 動作，但只能在 2014 年 11 月 30 日中午 12:00 至下午 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` 操作。
## 當拒絕存取帳戶時，不得委託存取
如果另一個帳戶明確拒絕存取使用者的父帳戶，則 AWS 帳戶 無法將存取權委派給另一個帳戶的 資源。拒絕將傳播到該帳戶內的所有使用者，無論使用者的現有政策是否授予這些使用者存取許可。
例如，帳戶 A 編寫了一個針對其帳戶中 S3 儲存貯體的儲存貯體政策，其中明確拒絕了帳戶 B 存取帳戶 A 的儲存貯體。但帳戶 B 編寫了一個 IAM 使用者政策，其中對帳戶 B 中的一個使用者授予了對帳戶 A 的儲存貯體的存取權限。應用於帳戶 A 的 S3 儲存貯體的「明確拒絕」將傳播到帳戶 B 中的使用者。它會覆蓋用於對帳戶 B 中使用者授予存取權限的 IAM 使用者政策 (有關如何計算許可的詳細資訊，請參閱 [政策評估邏輯](reference_policies_evaluation-logic.md))。
帳戶 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 儲存貯體存取許可的政策。