這些題目為學習目的而獨立製作，並非 AWS 官方考題、實際考題、外流題或考題庫。
SAA-032
需要將讀取自家 AWS 帳戶資源的權限委派給外部的 SaaS 監控供應商。供應商會從其自身的 AWS 帳戶呼叫 API。作為在防止混淆代理人(confused deputy)問題的同時委派存取權的架構,下列哪項最為合適?
選項
解析與正確答案
閱讀解析與正確答案（劇透：建議先自行作答）
正確答案：C. 建立信任供應商 AWS 帳戶的 IAM 角色,並於信任政策的 Condition 子句中要求 sts:ExternalId 為供應商發行的唯一值
解析
在對第三方的跨帳戶存取中,於 IAM 角色的信任政策加入 sts:ExternalId 的 Condition 子句為 AWS 的建議做法。不知道 External ID 的第三方即使透過供應商的帳戶也無法擔任該角色,因此可防止混淆代理人問題。
各選項解析
A. 為每個目標資源新增以資源為基礎的政策,允許供應商的 AWS 帳戶進行讀取
可透過以資源為基礎的政策允許的僅限 S3 儲存貯體或 KMS 金鑰等部分服務,且每當讀取對象增加就必須逐一新增,營運容易崩潰,亦不具備 External ID 的保護。
B. 建立供應商專用的 IAM 使用者並附加 ReadOnlyAccess,將發行的存取金鑰共用給供應商並每 90 天輪替一次
將長期存取金鑰交給外部組織的方式,一旦外洩影響範圍極大,失效處理也必須手動進行。即使進行輪替,跨帳戶仍建議採用透過 IAM 角色取得的臨時憑證。
C. 建立信任供應商 AWS 帳戶的 IAM 角色,並於信任政策的 Condition 子句中要求 sts:ExternalId 為供應商發行的唯一值
正解。將供應商發行的 External ID 設為信任政策 Condition 的必要條件,即可從結構上防止混淆代理人問題。
D. 建立僅信任供應商 AWS 帳戶 ID 的 IAM 角色,並附加 ReadOnlyAccess
使用角色這點正確,但若沒有 External ID,便無法防止供應商將其為其他客戶持有的權限張冠李戴,而對自家資源進行操作的混淆代理人問題,不符合需求。
實際使用情境
跨 AWS 帳戶的權限委派,原則上不以共用 IAM 使用者與存取金鑰的方式進行,而應使用 IAM 角色與 AWS STS 的 AssumeRole。由委派方(自家)建立角色,並於信任政策的 Principal 中寫入對方的帳戶 ID 或角色 ARN。對方呼叫 AssumeRole 取得臨時憑證,一旦其有效期限到期,權限便會自動消失。相較於將長期存取金鑰交付外部的方式,外洩時的暴露時間較短,且只要刪除信任政策即可立即阻斷,這點差異相當大。 在第三方 SaaS 這類「單一供應商以相同機制存取眾多客戶帳戶」的情境中,可能發生混淆代理人(confused deputy)問題。若供應商誤指定(或遭攻擊者誘導而指定)客戶 A 的角色 ARN,便會執行客戶 A 未預期的操作。為防止此情形,應於信任政策中以 Condition 要求 sts:ExternalId。External ID 為供應商依各客戶發行的唯一字串,並非機密資訊,而是作為「防止張冠李戴的識別碼」發揮作用。此外,委派的權限最好不要直接使用 ReadOnlyAccess 這類受管政策,而應改為僅限必要 API 的自訂政策。 SAA-C03 中,若出現「外部供應商」「他公司帳戶」「confused deputy」「External ID」等關鍵字,IAM 角色 + sts:ExternalId 即為正解。誤答則排列出共用 IAM 使用者的存取金鑰、共用根使用者憑證、無條件的跨帳戶角色等。另外也應掌握以下區別:若為自家多個帳戶之間(AWS Organizations 之下)則不需要 External ID,而是改用 SCP 或 aws:PrincipalOrgID 條件。