在 AWS 中授予跨帳戶訪問權限的四種方法

當你的亞馬遜網路服務 (Amazon Web Services, AWS) 環境擴展時，你可能需要授予跨帳戶存取資源的權限。這可能是因為多個 AWS 帳戶需要集中管理，或是組織內部的團隊或專案需要共享資源，或是需要與第三方服務整合。然而，授予跨帳戶存取權限需要仔細考慮你的安全性、可用性和管理需求。

在這篇部落格文章中，我們將探討四種使用資源型政策授予跨帳戶存取的方法。每種方法都有其獨特的取捨，最佳選擇取決於你的具體需求和使用案例。

評估不同的跨帳戶存取技術

在 AWS 身分與存取管理 (IAM) 中，跨帳戶存取是透過身分型政策和資源型政策授予的。身分型政策附加在 IAM 角色上，而資源型政策則附加在像是亞馬遜簡單儲存服務 (Amazon Simple Storage Service, Amazon S3) 的儲存桶和 AWS 金鑰管理服務 (AWS Key Management Service, AWS KMS) 的金鑰等資源上。資源型政策要求你指定一個或多個被允許存取資源的主體（IAM 使用者或角色）。

你在資源型政策中如何指定主體的選擇會影響到解決方案的機密性和可用性。了解這種影響並為你的使用案例做出正確的取捨是本文的重點。

一個範例情境

想像一下，你在 AWS 帳戶 A 中有一個 S3 儲存桶，需要被另一個 AWS 帳戶 B 中的不同主體存取。在這個情境中，我們假設帳戶 B 中的主體在其身分型政策中已經擁有存取 S3 的必要權限，我們將專注於撰寫帳戶 A 中的資源型政策。雖然這裡使用的是 Amazon S3，但所討論的概念適用於所有支援資源型政策的 AWS 服務。在接下來的部分中，我們將介紹四種在這種情境下授予跨帳戶存取的方法，並討論每種方法的取捨。

方法一：使用資源型政策的 Principal 元素授予特定 IAM 角色存取權

在這個例子中，你使用 S3 儲存桶政策來授予帳戶 B 中的特定 IAM 角色 (RoleFromAccountB) 存取權，方法是將該 IAM 角色的亞馬遜資源名稱 (ARN) 指定在帳戶 A 的政策的 Principal 元素中。

使用這個儲存桶政策，如果帳戶 B 中的某人刪除或重新建立角色 (RoleFromAccountB)，那麼即使該角色以相同名稱重新建立，也無法再存取 amzn-s3-demo-bucket-account-a 儲存桶。原因是當你儲存此政策時，角色 ARN 會映射到角色的唯一 ID，看起來像這樣：AROADBQP57FF2AEXAMPLE。如果你在刪除引用的角色後查看資源型政策，你會在 Principal 元素中看到一個角色識別碼。

這種行為是有意設計的。資源型政策僅允許你在政策創建時設置為主體的特定角色實例。這有助於防止在你刪除角色但忘記更新資源型政策以移除該角色時，對你的資源進行非預期的存取。這種行為也可能導致可用性風險，因為角色 (RoleFromAccountB) 在重新建立時會有新的唯一 ID，並且將不再能存取儲存桶。角色可能因多種原因被重新建立，包括使用基礎設施即代碼等工具時意外重新建立。

你可能會考慮選擇此方法，如果：

你擁有帳戶 A 和帳戶 B 中的角色，並可以控制這些角色的創建和刪除。
你希望帳戶 A 中的資源型政策在指定角色 (RoleFromAccountB) 被刪除時停止授予存取權。
你優先考慮細緻的存取控制，而不是角色 (RoleFromAccountB) 被刪除時的潛在可用性問題。

方法二：使用資源型政策的 Principal 元素授予帳戶存取權

在這個例子中，你在資源型政策的 Principal 元素中授予特定帳戶存取權。帳戶 A 的資源型政策允許來自帳戶 B 的任何使用者或角色，只要他們的身分型政策也授予他們讀取物件的存取權。

注意：你可以在 Principal 元素中使用 “Principal”: {“AWS”: “111122223333”} 或 “Principal”: {“AWS”: “arn:aws:iam::111122223333:root”}。它們是等效的，長格式 ARN 並不代表根使用者。

這個資源型政策有助於避免方法一中討論的潛在可用性問題。如果帳戶 B 中需要存取儲存桶的角色被重新建立，它在重新建立後仍然可以存取，因為你在 Principal 元素中並未指定角色，而是指定了一個帳戶。如果你使用方法二，你必須對將存取控制決策委派給該帳戶的擁有者感到放心。

這種方法明確地將存取控制決策委派給另一個帳戶 (帳戶 B) 中的 IAM。如果帳戶 B 中的主體被他們的身分型政策允許，他們就可以存取這個儲存桶。

你可能會考慮選擇此方法，如果：

你需要授予帳戶 B 中的許多主體存取權。
你希望將存取決策委派給主體存在的帳戶 (帳戶 B)。
你優先考慮管理的便利性和可用性，而不是細緻的存取控制。

方法三：使用 aws:PrincipalArn 條件授予特定 IAM 角色存取權

這種方法在方法二的基礎上擴展，並添加了一個條件，只授予特定 IAM 角色存取權。與方法二類似，你使用帳戶號碼作為 Principal 元素的值，但也使用 aws:PrincipalArn 條件鍵來限制存取帳戶 B 中的特定主體。

aws:PrincipalArn 條件鍵是一個全域條件鍵，它將發出請求的主體的 ARN 與你在政策中指定的 ARN 進行比較。對於 IAM 角色，請求上下文返回角色的 ARN，而不是假設角色的使用者的 ARN。

這個政策具有與方法二中政策相同的可用性優勢：對此資源的存取將在角色重新建立後仍然有效。這是因為角色僅在用於 Principal 元素時才會被轉換為其唯一識別碼。當它用於條件時，則不會被轉換為唯一識別碼。如果帳戶 B 中的角色 (RoleFromAccountB) 被重新建立，無論是意外還是故意，政策將繼續授予存取權，因為角色與資源型政策中條件鍵指定的角色 ARN 相匹配。因此，方法三在可用性和安全性之間提供了一個平衡的方法。

你可能會考慮選擇此方法，如果：

你對此政策在角色 (RoleFromAccountB) 被重新建立時，仍然會繼續授予 aws:PrincipalArn 條件鍵中指定的角色存取權感到放心。
你不擁有你授予存取權的帳戶 B，並且無法控制該角色何時可能被重新建立。
你希望在可用性和機密性之間取得平衡。

方法四：授予整個 AWS Organizations 組織存取權

這種方法專注於不同的使用案例，並不是前面列出的方法的替代方案。如果你有一個資源（例如 S3 儲存桶），你希望與整個組織共享，但不希望與組織外的任何人共享，則使用此方法。

無法使用資源型政策的 Principal 元素指定一個組織，因此你必須使用 aws:PrincipalOrgId 條件鍵來限制存取特定組織。在這個政策中，你在 Principal 元素中指定一個萬用字元，表示任何人都可以存取儲存桶。然後，條件將「任何人」縮小到僅限於屬於指定組織並且擁有允許他們存取的身分型政策的 AWS 帳戶主體。

然後，你可以添加一個額外的條件區塊，使用政策變數將 aws:PrincipalAccount 條件鍵與 aws:ResourceAccount 條件鍵進行比較。這個額外的條件區塊是可選的，並將擁有儲存桶的帳戶 (帳戶 A) 排除在允許聲明之外。使用這個額外的條件區塊的原因是，帳戶 A 中的主體仍然需要在其身分型政策中有一個允許聲明才能存取這個儲存桶。如果你選擇排除這個 aws:PrincipalAccount 比較，帳戶 A 中的主體將在其身分型政策中沒有明確的允許聲明的情況下被授予存取儲存桶的權限。當主體和資源在同一個帳戶中時，政策評估邏輯只需要身分型政策或資源型政策（但不需要兩者）允許請求。

你可能會考慮選擇此方法，如果：

你有一個應該對整個組織可存取的共享資源。

結論

選擇授予跨帳戶存取的方法需要仔細考慮你的需求和使用案例。本文中討論的四種方法各有其優勢和取捨。通過了解這些方法及其影響，你可以決定最合適的方式來授予 AWS 資源的跨帳戶存取權。記得定期審查和審計你的資源型政策，以確保它們與你的安全和存取需求一致。

要了解資源型政策如何與 Amazon S3 一起運作，請參閱部落格文章《IAM Policies and Bucket Policies and ACLs! Oh My! Controlling Access to S3 Resources》。

如果你對這篇文章有意見，請在下方的評論區提交評論。如果你對這篇文章有疑問，請聯繫 AWS 支援。

Jay Goradia
Jay 是 AWS 的技術帳戶經理 (TAM)，他與企業客戶密切合作，通過戰略指導和技術專業知識加速他們的雲端旅程。利用他的安全背景，他幫助組織了解 AWS 的安全最佳實踐。