AWS代理商開戶 AWS IAM權限衝突排查方法

第一章：為什麼會出現「看似授權卻被拒」

在 AWS 的權限世界裡，最折磨人的不是「完全沒權限」，而是「明明你看到你有權限，卻還是被拒」。同一個動作（Action）與同一個資源（Resource），你在控制台上看到策略寫了允許，甚至你也能在某些情境成功，但換一個條件或流程就失敗。這通常不是直覺上的邏輯錯誤，而是 AWS IAM 權限評估規則與多層策略疊加後的結果。

理解「權限衝突」要先抓住兩個核心概念：第一是評估順序的方向性，AWS 以「拒絕優先」為原則；第二是權限的影響範圍可能來自不只一張策略，還有權限邊界、組織政策、會話繼承與條件鍵。當你把問題拆開看，就會發現「衝突」常常不是兩張策略單純互打，而是同一張邏輯被不同層級重新約束。

第二章：權限衝突的六大典型來源

排查 IAM 問題，效率最高的做法是先列出高頻原因，並用固定流程逐一驗證。下面我用六個最常見的來源，把「衝突」可能出現的地方一次講透。

1. 顯式 Deny 永遠勝過 Allow

如果任何策略（包含資源策略、角色策略、帳戶政策或組織政策）出現了明確的 Deny，而且條件符合，那麼即使其他地方都有 Allow，也會被拒絕。這是最重要的規則，因為很多人只盯著允許內容，卻忽略了拒絕其實藏在另一層。

例如你在角色策略中允許 s3:GetObject，但某個組織策略用條件阻擋特定前綴或特定網路來源，最後仍然會失敗。你以為是「沒有 Allow」，但其實是「有 Deny」。

2. 權限邊界（Permissions Boundary）收縮了能力

權限邊界特別容易造成誤判。因為很多人看角色本身的 policy 很完整，但最終仍然被限制在「邊界」所允許的範圍內。邊界相當於一個上限：就算角色策略允許超出邊界，結果也會被截斷。

你可以把它想成「你拿到門票，但進門還要看票根上限」。排查時一定要檢查角色或使用者是否設定了 permissions boundary。

3. 組織（Organizations）或帳戶層級政策的影響

Organizations 的 SCP（Service Control Policy）與帳戶策略常常比你在 IAM 裡配置的角色更「大」。SCP 可以直接限制某些服務或動作，即使你在角色裡允許了也仍然不行。這是第二高頻來源，尤其在有治理要求的企業環境。

很多團隊在本地測試時沒問題，因為測試帳戶沒有同樣的 SCP；一上生產就失敗，根因通常就在這層。

4. 會話與角色假設（AssumeRole）造成的權限落差

當你使用 STS AssumeRole，權限會沿用「角色本身的策略」與「會話條件」結果，而不是你原先使用者擁有的全部能力。有時候你以為「我使用者能做，所以我假設的角色也一定能」，但實際上角色可能缺少關鍵 action，或者被會話政策（如 session policy）縮小了範圍。

此外，某些服務要求額外的信任策略條件（例如外部 ID、來源帳戶、或特定主體），信任策略沒過也會造成看似權限衝突的錯誤。

AWS代理商開戶 5. 條件鍵（Condition）讓允許看似存在但實際不生效

條件鍵是 IAM 的靈魂，也是一切錯誤的溫床。你可能寫了 Allow，但條件要求特定標籤、特定 VPC endpoint、特定加密狀態、或特定請求頭。只要條件不成立，這個 Allow 就等於沒寫。

更麻煩的是，有些條件鍵在不同服務裡含義不同。例如 S3 的條件鍵與 KMS 的條件鍵互相影響時，你以為只有 S3 控制，其實還要同時滿足 KMS 的策略與 key policy。

6. 資源層級策略與服務自身的額外授權檢查

有些服務不只看 IAM identity policy，還要看資源策略或服務自身的授權機制。例如 S3 bucket policy、KMS key policy、SQS queue policy、SNS topic policy 都可能否決或允許特定主體。

常見情形是：你在 IAM 角色上允許了動作，但資源策略沒有把該角色納入，結果還是被拒。你會覺得「怎麼都寫了 Allow 還是不行？」答案通常就在資源策略。

第三章：建立排查心法：先確認「失敗訊息」再找「是哪一層拒絕」

排查 IAM 問題，最忌諱的是盲試。你應該把錯誤回應當作線索，而不是當作終點。AWS 的錯誤訊息通常會包含動作名稱、資源 ARN、以及拒絕原因。你要做的是建立一個固定流程，把線索轉成「要查的策略清單」。

先記下三件事：Action、Resource、Condition（如果有）

每次失敗，請至少記下：

• 動作：例如 s3:GetObject、kms:Decrypt、sts:AssumeRole
• 資源 ARN：例如 bucket、key、queue、或對應資源的 ARN
• 條件資訊：例如錯誤訊息中提到的特定 key、或者你看到的「因為條件不匹配」類訊息

有些錯誤訊息不會直接列出全部條件，但你仍可從錯誤碼與補充訊息判斷方向。例如若提到 AccessDenied，你多半是在某層策略拒絕；若提到 UnauthorizedOperation，也可能是缺權或資源策略不允許。

理解「Denied」與「Not authorized」的直覺差異

在實務上你會遇到兩種常見狀況：

• 明確 AccessDenied：通常是 IAM 評估結果被拒，代表你可用 simulator 或 CloudTrail 找到拒絕點
• Invalid/Not authorized 類型錯誤：可能是 trust policy 不通過、或資源要求更多授權（例如 KMS key policy），導致整體看起來像權限衝突

你不必死背錯誤碼，但要用它作為「查誰」的依據：identity policy 還是 resource policy 或 trust policy。

第四章：一套可落地的排查流程（建議照順序做）

下面我給你一套我在專案中反覆使用、能把時間壓下來的流程。它不是理論，而是能在現場減少來回的版本。

步驟 1：用 CloudTrail 找到實際使用的角色與策略背景

先用 AWS CloudTrail 定位那次失敗呼叫。你要找到：

• 請求者（principal）：是 user 還是 role
• AWS代理商開戶 是否有 AssumeRole：角色鏈路是否如你預期
• 請求的來源：IP、VPC endpoint、或關聯服務

這一步很關鍵，因為很多「權限衝突」其實只是你以為用的是某角色，但實際呼叫用的是另一個角色，或你以為直接訪問，其實透過代理服務轉發，造成條件鍵（如來源 IP）變了。

步驟 2：收集所有與該主體相關的策略（不要只看一張）

拿到 principal 後，列出可能影響的策略來源：

• 該角色的 identity-based policies（內嵌與掛載）
• 附加的 managed policies
• inline policies
• permissions boundary（若存在）
• 使用者/群組的 policies（若 principal 是 user）
• resource policy（例如 S3 bucket policy、KMS key policy）
• AWS代理商開戶 Organizations 的 SCP（影響動作範圍）

排查時你要做的是「列清單」，而不是「看一眼」。只要漏掉一層（通常是 boundary 或 SCP），你就會覺得自己怎麼怎麼改都沒用。

步驟 3：先判斷是否被顯式 Deny（快速排除）

在列出的策略清單裡，先找所有 Deny。如果存在 Deny，還要檢查是否帶條件。帶條件的 Deny 是否符合當次請求？如果符合，那就直接決定答案方向：你不是缺少 Allow，而是被 Deny 卡住。

這一步可以大幅縮短時間。因為 Deny 的優先性太明確，讓排查變得更像「找阻擋物」而不是「拼允許拼圖」。

步驟 4：用 IAM Policy Simulator / Access Analyzer 驗證「評估結果」

AWS代理商開戶 當你抓到可能的策略集合後，就用工具做「評估」。Policy Simulator 能回答一個很實際的問題：對於某 principal、某 action、某 resource，在給定條件下，最終結果是 Allow 還是 Explicit Deny。

實務建議是：把 simulator 的輸入值盡量對齊真實請求。例如條件鍵中與請求來源、標籤、或加密狀態相關的值，否則你會在測試時「剛好允許」，但在真實環境因為條件不同而失敗。

Access Analyzer 也能幫你找出過度授權或可能的資源可達性問題。它不是替代排查，但在確認資源策略或跨帳戶授權邊界時很有幫助。

步驟 5：針對特定服務做「對應的授權鏈」檢查

AWS代理商開戶 不少權限衝突其實發生在「多步操作」。你在上層看起來只想做 A，但實際會觸發 B、C 的授權。例如：

• 讀 S3 物件可能還需要對 KMS key 的 kms:Decrypt
• 透過加密或格式轉換可能需要額外的服務權限
• 連線到 VPC 或存取特定端點可能依賴網路相關條件

因此你不要只修一個 action。排查時要回到 CloudTrail 逐次看呼叫序列，每一步都要確認它所需要的授權。

步驟 6：採用「最小變更」策略做修正，避免反覆改錯

修正策略時，請避免直接把所有 Allow 塞滿。你應該：

• 優先移除或調整造成拒絕的 Deny（或邊界條件）
• 補上缺少的 action（如果 simulator 顯示應該 Allow 卻沒允許）
• 調整資源條件鍵，使其對應真實請求
• 在跨帳戶場景下補齊兩端：identity policy + resource policy

AWS代理商開戶 最小變更的好處是：你能更容易驗證因果關係，也能降低安全審查的摩擦。

第五章：常見衝突情境的實戰拆解

理論講完，接下來用幾個常見情境，示範你該如何把排查思路落到具體行動。這些案例不需要你真的複製同樣的環境，但你可以照樣學會「怎麼想」。

情境一：S3 讀取被拒，卻明明在 IAM 有 s3:GetObject

這是經典案例。你可能在角色上允許了 bucket 的物件讀取，但仍然收到 AccessDenied。接下來要依序檢查：

• Bucket policy：是否有 Deny 或是否未授權該角色
• 物件是否加密：若是 SSE-KMS，是否需要 kms:Decrypt
• KMS key policy：即使 IAM 有權做 kms decrypt，key policy 也可能拒絕
• 條件鍵：例如要求特定 aws:SourceVpce、特定標籤或加密上下文

很多人只看 S3，不看 KMS。你可以用 CloudTrail 的事件裡是否出現 kms:Decrypt 來快速判斷是否進入了 KMS 授權鏈。

情境二：跨帳戶 AssumeRole 成功但資源存取失敗

你在角色信任策略（trust policy）通過了 AssumeRole，代表第一段鏈路是好的。但第二段「拿到臨時憑證後能不能做事」可能仍然失敗。這時你要檢查：

• 被假設角色的 identity policy 是否包含目標 action
• 該角色是否有 permissions boundary，且 boundary 限制了該 action
• 目標資源的 resource policy 是否信任該跨帳戶 principal（例如 S3 bucket policy、SQS policy）
• 條件鍵是否因為來源帳戶/來源 VPC/標籤而不匹配

跨帳戶最常見的錯誤是「只改其中一端」。請把它當成雙向門禁：你必須在角色端允許，以及在資源端接受。

情境三：同一角色在測試環境 OK，在正式環境被拒

這通常不是角色差異，而是治理差異。優先檢查 Organizations 的 SCP，因為它會在正式環境啟用治理限制。你也要比對：

• 正式帳戶是否套用了更嚴格的 SCP
• 是否啟用額外的帳戶層政策或防護策略
• 是否有不同的 KMS key、不同的 bucket policy 或不同的資源 ARN

這種情境的排查重點不是「修角色」，而是「還原正式環境的實際政策疊加結果」。

情境四：看起來是權限問題，其實是條件鍵不成立

很多 Allow 失效不是因為沒允許，而是因為條件不符合。典型例子是：你在策略中寫了 StringEquals 或 ArnLike，要求某些值必須匹配。但真實呼叫可能因為 SDK 參數不同、或因為代理層改變了請求上下文而導致條件不匹配。

你應該回到 CloudTrail 的 requestParameters 或相關欄位，比對策略條件鍵的期望值與實際值。只要你把兩邊對齊，很多問題會突然「消失」。

AWS代理商開戶 第六章：把排查變成能力：如何避免下次再卡住

排查 IAM 是一種工程能力。你可以把每次事故做成規範，讓團隊未來少走彎路。下面是我建議的做法。

建立「策略清單」模板，讓每次排查不從零開始

你可以在團隊內定義一份固定欄位：

• 主體：user/role/assumed role ARN
• 目標操作：Action
• 目標資源：resource ARN
• 證據：CloudTrail event、錯誤訊息
• 候選來源：identity policies、boundary、SCP、resource policy
• 確認結果：是否 Explicit Deny、是否條件不成立

有這份模板後，每次排查都像在走同一條路，減少意外。

鼓勵最小權限設計，但不要把它做成「不可維運」

很多團隊追求最小權限，結果把策略寫得過度細，條件鍵又太多，導致一旦 SDK 行為或環境變動就全線崩。最小權限不是要你把條件塞到死，而是要你讓授權可理解、可驗證。

你可以把策略拆成可描述的功能模組：例如 S3 讀取模組、KMS 解密模組、網路路徑模組。這樣在排查時更容易定位哪一塊失效。

保留「決策理由」而不是只貼 JSON

策略審查時最缺的是背景。建議在策略管理流程中加入簡短註記：為什麼需要這個 action、為什麼資源用這個 ARN 範圍、條件鍵想保護什麼。未來當權限衝突再次發生，你不用猜。

第七章：結論——真正的排查技巧是「把問題縮小成可證明的假設」

IAM 權限衝突之所以難，是因為它跨越多層策略，而且拒絕規則具有強烈優先性。但只要你遵循一個原則：把每次失敗收斂到「某主體對某 action、對某資源，在某條件下」的評估結果，你就能把模糊的痛苦，轉化成可驗證的假設。

你可以用 CloudTrail 確認實際 principal 與請求上下文，再用 Policy Simulator 或 Access Analyzer 驗證評估結果，最後針對特定服務（S3/KMS、跨帳戶、VPC 條件）做授權鏈檢查。當你這樣做，權限衝突不再是運氣，而是工程上的可控流程。

當你掌握這套方法，下一次遇到「明明有 Allow 卻被拒」，你不會再急著擴大授權範圍，而是直接找到真正的拒絕來源，快速、安全地完成修正。