AWS國際帳號 AWS IAM權限繼承問題解析
第一章：看似簡單的「繼承」，其實是多層判斷
很多人第一次用 IAM 時，會把權限理解成像檔案夾權限那樣：上層加了就往下套用，底下再微調。AWS 當然也有「繼承」的感覺，但它不是單一規則，而是一套判斷鏈：你對某個 API 呼叫想得到結果，AWS 會同時看你的身分（User 或 Role）、你身分上掛的策略、你是否被允許透過特定信任關係扮演、資源本身是否要求額外條件，再加上組織層的管制（例如 SCP）、權限邊界（permissions boundary）等“硬限制”。
因此，當你看到“權限不生效”、或“明明加了卻還是拒絕”，通常不是因為策略沒寫對，而是因為你對「優先順序」或「影響範圍」的模型建立錯了。本文會用幾個典型案例，把這個模型釐清到你能自己驗證、自己推理。
第二章：先建立正確的權限心智模型
在 IAM 中，判斷權限的核心不是“繼承規則”，而是「評估結果」：對某個動作（Action）與資源（Resource）是否允許。AWS 的政策語言允許你寫 Allow 或 Deny。當兩者衝突時，結果由 Deny 主導。
2.1 Identity-based 與 Resource-based：方向不同，影響也不同
大多數人接觸最早的是 Identity-based policy：直接綁在 User、Group、Role 上。它的語意是「這個身分能對哪些資源做什麼」。
但有些服務還支援 Resource-based policy，例如 S3 Bucket Policy、SQS Queue Policy、KMS Key Policy、SNS Topic Policy 等。這類政策的語意是「這個資源允許誰對它做什麼」。
這裡最常見的誤解是：你只看 identity-based，卻忽略了資源端的限制。當你遇到“我明明在 Role 上允許了 s3:GetObject，但仍然 403”，通常就是 bucket policy 或其他資源端條款沒有放行。
2.2 明確拒絕（Explicit Deny）是最高優先
只要任一份政策在符合條件下給出 Deny，最終就會拒絕。這包括身份策略、資源策略、以及組織層策略（SCP）的拒絕效果。換句話說：你加了 Allow，但別處已經 Deny，Allow 也救不了。
因此你在排查時要做的第一件事，不是找“缺什麼 Allow”，而是先找“是否存在 Deny”。
2.3 條件（Condition）不是裝飾，它是開關
Condition 可能讓你以為的“繼承”在某些情境不適用。例如你寫了 Allow，但條件要求特定 VPC、特定標籤（tag）、或特定時間範圍。你以為同一個策略會在所有情況都生效，實際上是：條件不成立時，該陳述（statement）就不算在評估結果裡。
很多看起來像“繼承失效”的問題，其實是條件沒滿足。你在本機測試用的是另一組憑證、另一個來源 IP、或不同的請求標頭，導致 Condition 不一致。
AWS國際帳號 2.4 權限邊界（Permissions Boundary）會“截斷”繼承的期望
AWS國際帳號 permissions boundary 是很多人會忽略的“硬範圍”。你可以把它想成：就算你的 Role 附了很多 Allow，只要超出權限邊界所允許的範圍，超出的部分就會被砍掉。
因此當你覺得“我都加了策略，為什麼還不行”，要檢查這個 Role 是否配置了 permissions boundary。它常用於合規或權限治理，避免開發者用無上限權力。
第三章：常見的「繼承問題」從哪來
IAM 的“繼承”通常發生在幾種關係：User 繼承 Group 的策略；Role 繼承（或更準確說是“集合”）多個政策；以及組織層透過 SCP 影響所有帳號或某些 OU。這些關係的效果常被誤讀為“只要上一層寫了，就必然生效”。
3.1 User 與 Group：以為加在 Group 就一定全套，忽略條件與 Deny
例如你把 S3 讀取權限加在 Group A，然後把 User U 放進去。你理所當然覺得 U 對所有 bucket 都能讀。但如果 bucket policy 裡面限制了特定 Principal 或要求特定條件（比如只允許特定前綴路徑、或要求特定來源 VPC），就會造成“看似繼承，實則被資源策略否決”。
另一方面，如果 Group 的某個策略包含 Deny（即使是為了防呆的 Deny），那也會在符合條件時覆蓋 Allow。很多團隊會用 Deny 來禁止特定敏感動作（例如停止關鍵服務、刪除關鍵資源），但新成員加入 Group 後才發現自己“突然不能做某事”。
3.2 Role 與 AssumeRole：信任關係才是繼承的門檻
Role 的權限不是你以為的“誰能 AssumeRole 就自動拿到全部權限”。實際流程是：你必須先通過 Trust policy 的檢查，才會拿到 Role 的 identity-based policy 所定義的權限。
因此若你遇到“AssumeRole 都成功了但權限仍不足”，就不是 Trust 問題，而是該 Role 的 policies、permissions boundary、以及資源端政策的組合問題。
但若 AssumeRole 甚至失敗，那是信任關係造成，根本沒有進到權限評估階段。
3.3 OU 與 SCP：合規層級的限制會讓 Allow 看起來像沒寫
SCP（Service Control Policy）常被誤解成“額外加一層 Allow”。但 SCP 的作用更像“最大權限上限”。SCP 通常是用來限制某些服務、某些動作、或某些資源範圍，讓帳號不可能越過規範。
這時候你在該帳號的 Role 上寫了 Allow，仍可能因為 SCP 的限制導致最終 Deny。對排查來說，你會感覺是“權限繼承失效”，但真相是：上層直接把最大可用範圍砍掉了。
第四章：用三個情境拆解「為何我以為有權限卻被拒絕」
下面用三個常見場景，展示你如何從症狀推到原因。重點不是背政策，而是建立一套可反覆使用的排查順序。
4.1 情境一：Role 允許了 S3 讀取，卻仍然 403 AccessDenied
你在某個 Role 上加了政策，允許 s3:GetObject，資源範圍是 bucket 的特定前綴。測試時使用該 Role 的臨時憑證呼叫 GetObject，結果回傳 AccessDenied。
你第一個直覺是“我 Role 沒有繼承到 Group 的政策”。但注意：Role 是独立實體，它沒有跟 User 的 Group 直接繼承關係。更關鍵的是，你需要同時檢查：
- 該 Role 是否配置 permissions boundary，是否截斷了你期待的權限。
- 目標 bucket 是否有 bucket policy，是否要求特定條件。
- 你的 Resource 範圍是否與實際請求的物件 ARN 完全匹配（前綴、目錄、通配符都算）。
- AWS國際帳號 是否存在任何 Deny 陳述在符合條件時發生。
很多人在這一步會忽略 bucket policy 的 Condition。例如 bucket policy 要求 s3:DataAccessPointArn 或要求來源是特定 VPC Endpoint。你在測試環境使用不同的網路路徑，就會不符合條件，導致最終拒絕。
因此，“繼承問題”在這裡其實常是“資源端條件問題”或“ARN 不匹配”。權限不是沒加，而是加得不在正確的評估路徑上。
4.2 情境二：你以為 Group 會自動帶來所有權限，結果仍不能呼叫某些 API
你把一個權限集合加在 Group，User 也放進去，理論上應該能用。可是在呼叫某些 API 時仍然提示沒有權限。此時最常見原因有三類。
- 該 API 在策略中沒有被對應到正確的 Action 名稱。IAM 的 Action 拼寫與大小寫都要精準，且有些動作拆分後並非“看起來像就能用”。
- 策略有 Condition 限制，例如要求特定 tag（aws:ResourceTag / aws:RequestTag），但你實際資源沒有這些標籤或請求沒有帶上標籤。
- 另一份策略存在 Deny，或 SCP 在組織層造成拒絕效果。
你可能會問：既然是同一份 Group 策略，為什麼會在某些 API 上失效？答案往往在 Condition 或資源端拒絕。也就是說，“繼承”不代表“一定放行”，它只是把候選政策集合起來。最後的放行仍要看條件與衝突。
4.3 情境三：Allow 寫了，但在合規環境仍被擋下來
當公司使用 SCP 或 permissions boundary 時，最容易出現的心理落差是：我都已經在 Role 上寫了 Allow，為什麼還不給？
在這種情境，建議你把排查順序改成“先上層、後下層”。先查：
- 該帳號或所在 OU 是否套用 SCP。
- 目標 Role 是否有 permissions boundary。
- 是否存在任何顯式 Deny 的陳述。
因為 SCP 與 permissions boundary 都會直接限制最大可用權限。你加再多 Allow，也只是被裁切的那一部分。當你把原因抓準，修正方式也會不同：SCP 需要合規審核才能變更；permissions boundary 需要調整邊界或建立符合邊界的政策。
第五章：正確的排查流程：從“猜”到“證明”
排查權限最怕的是來回試錯。你寫一個策略、測一次、再改一次，會越改越亂。建議建立固定流程，讓每一步都能證明或排除某個假設。
5.1 用錯誤訊息定位是身份問題還是資源問題
當你看到 AccessDenied 時，訊息通常會包含 action、resource、以及是否因為缺少身份權限或因為條件不成立而被拒絕的線索。雖然訊息不會像偵探小說那樣直接說“原因就是 X”，但它仍能幫你判斷你應該先看哪一塊政策。
如果錯誤訊息指向特定 resource ARN 或特定條件，通常意味著 resource 端政策或條件評估在主導。若是 action 明確指出某個動作沒有被允許，則 identity-based 或 SCP 才是起點。
5.2 盤點政策集合：User/Group/Role/Session/邊界
你要先弄清楚“當下到底用的是哪個身分”。特別是你可能透過 STS 取得臨時憑證，而你以為自己在用原始 Role，實際上是經過 AssumeRole chain。
排查時要列出：
- 當前呼叫者是 User 還是 Role（以及 Role 是哪個）。
- 該 Role 上有哪些 identity-based policies，以及是否有 permissions boundary。
- 該 User 是否屬於某些 Group，Group 裡是否有 Deny。
- 是否存在任何會在 Session 層級影響決策的條件（例如基於 tag 或 Session name 的限制）。
當你把政策集合列出來，你就能縮小範圍：你到底是在找“缺 Allow”，還是在找“有 Deny”。
5.3 把 Resource 也納入評估：資源端政策與條件
接著看資源端是否有政策。若是 S3、SQS、KMS、SNS 這類服務，幾乎都要檢查資源端 policy。即使你完全相信 identity-based policy，也不能省略這一步。
此外，資源端政策常見的 Condition 也要特別留意。例如：
- 要求特定 principal（某個 Role ARN）。
- 要求特定前綴（prefix）或特定對象模式。
- 要求特定加密金鑰（KMS key）或特定加密上下文。
- 要求特定來源 VPC Endpoint（VPC endpoint）或 TLS/傳輸層特性。
你如果把條件視為“可選”，通常就會在這裡失敗。
5.4 最終用模擬工具把假設變成結果
排查權限時，最實用的方法是用 AWS 的政策模擬（Policy Simulator）或等效能力檢視最終決策。重點不是“看答案”，而是讓它告訴你：到底哪些 statement 有效、哪些 statement 因條件不成立或因為 ARN 不匹配而無效，哪些 Deny 在生效。
當你在每次修改前都先模擬，就能避免盲改策略。
第六章：把繼承問題變成可設計、可治理的結構
了解 IAM 的評估邏輯之後，你會發現“繼承問題”其實是設計問題：如果團隊在各處散落政策，最後就會變成“誰知道它從哪裡被拒絕”。
6.1 盡量集中責任：身份端只管身份，資源端只管資源
一個可維護的做法是：identity-based policy 儘量只描述“身分能做哪些事情”，資源端 policy 則描述“資源允許哪些身分”。不要在資源端與身份端同時寫大量相互重疊的條件，除非你能明確定義各自責任。
當出現問題時，責任分工清楚，你就能快速判斷是“誰不一致”。
6.2 用 Deny 做防呆，但要有清晰的條件與文件
Deny 是強力武器。用它可以防止誤刪、誤停，但代價是：它會讓後續所有 Allow 變得脆弱。團隊要對 Deny 的目的、適用範圍、以及條件邏輯有清楚文件。
AWS國際帳號 尤其在 Group 或 permissions boundary 中使用 Deny 時，要特別提醒新成員：不是你沒有權限，而是你在某些條件下會被“永遠拒絕”。
AWS國際帳號 6.3 權限邊界與 SCP：把治理寫進架構，不要只靠口頭規範
很多公司希望開發者自由，但又不能讓他們接觸高風險行為。這時候 SCP 與 permissions boundary 就是治理架構的一部分。
但要記住：治理層級會改寫你對 Allow 的直覺。與其讓團隊在錯誤訊息裡反覆學習，不如把“哪些 action 永遠不可用、哪些需要例外流程”在設計階段就定義出來。這樣每次有人申請新權限，就能沿著流程走，而不是靠猜。
第七章：常見誤解整理（你可以拿來對照自己）
- 誤解一：Group 策略就是繼承，所有權限都會在所有資源上生效。實際上仍受資源端政策與條件限制。
- 誤解二：Role 只是容器，能自動拿到 User 的 Group 權限。實際上 Role 與 User 的策略是獨立集合。
- 誤解三：寫了 Allow 就一定能成功。只要存在符合條件的 Deny，結果就會拒絕。
- 誤解四：SCP 是額外加權。實際上 SCP 通常是“最大上限”與限制，不讓你突破組織規範。
- AWS國際帳號 誤解五：permissions boundary 不影響，只是附加檢查。實際上它會截斷超出邊界的權限。
把這些誤解釐清，你就會少走很多彎路。
第八章：寫給實務的結論：如何把問題定位得更快
當你要解釋或處理“AWS IAM 權限繼承問題”，最重要的是把討論從“繼承”轉回“評估”。你要問的是：在這次 API 呼叫中，哪一些 statement 被納入、是否符合 Condition、資源端是否也限制、以及是否存在 Deny 或邊界裁切。
一個快速可行的排查順序可以是：
- 確認呼叫者身分：User 還是 Role？是否經 AssumeRole 得到臨時憑證？
- 先找 Deny：identity、resource、以及組織層的限制。
- 檢查 Condition：你測試的環境是否符合要求的 VPC、標籤、前綴、來源或加密條件。
- 檢查 Resource ARN 與通配符：是否真的覆蓋到目標物件。
- 最後檢查權限邊界與 SCP：它們可能把 Allow 裁切掉。
- 用模擬工具把結論證明出來，而不是憑感覺調策略。
當你用這套方式再遇到權限被拒，就不會把它當成運氣或神秘現象。IAM 的“繼承”只是看起來像層層套用，真正的本質是多政策、多條件、多層控管的最終評估。理解這個本質，你就能把排查速度拉上去，把系統維護成本壓下來。
