委派存取權限的政策範例 - AWS Identity and Access Management

本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。

委派存取權限的政策範例

下列範例顯示如何允許或授與其他資源的 AWS 帳戶 存取權 AWS 帳戶。若要了解如何使用這些範例 JSON 政策文件來建立 IAM 政策,請參閱 正在使用 JSON 編輯器建立政策

使用角色委派對其 AWS 帳戶 他資源之資源的存取權

如需顯示如何使用 IAM 角色對某個帳戶中使用者授予存取另一個帳戶中 AWS 資源的教學,請參閱 IAM教學課程:使用IAM角色在 AWS 帳戶間委派存取

重要

您可以在角色信任政策的 Principal 元素中包含特定角色或使用者的 ARN。當您儲存原則時,會將 ARN AWS 轉換為唯一的主參與者識別碼。如果有人希望藉由刪除並重新建立角色或使用者來提升特權,這麼做可有助於減輕此類風險。您通常不會在主控台中看到此 ID,因為在顯示信任政策時還會反向轉換回 ARN。不過,如果您刪除角色或使用者,則關係會中斷。即使重新建立使用者或角色,您的政策都不再適用,因為它不符合信任政策中所儲存的主體 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", "datapipeline.amazonaws.com" ] }, "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:s3:::mybucket", "arn:aws:s3:::mybucket/*" ] } }

或者,帳戶 A 可使用 Amazon S3 存取控制清單 (ACL) 來授予帳戶 B 存取 S3 儲存貯體或某個儲存貯體內的單一物件。這種情況下,唯一改變的是帳戶 A 授權存取帳戶 B 的方式。如此範例的下一個部分所述,帳戶 B 仍使用一個政策委託針對帳戶 B 中的 IAM 群組的存取許可。如需有關對 S3 儲存貯體和物件實施控制存取的詳細資訊,請前往Amazon Simple Storage Service 使用者指南中的存取控制

帳戶 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:s3:::mybucket", "arn:aws: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: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: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 使用者政策 (有關如何計算許可的詳細資訊,請參閱 政策評估邏輯)。

帳戶 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:s3:::mybucket/*" } }

此「明確拒絕」將覆蓋帳戶 B 中所有提供帳戶 A 中 S3 儲存貯體存取許可的政策。