AWS帳號快速購買 AWS STS 取得臨時憑證（AssumeRole）報 AccessDenied 的權限邊界排查
先看結論：AssumeRole 的 AccessDenied，不是只有 IAM 權限不夠
AWS STS 取得臨時憑證時，如果在 AssumeRole 這一步報 AccessDenied，很多人第一反應是去補一條 IAM 權限。這個方向不一定錯，但常常只改到一半。因為 AssumeRole 成功與否，至少要同時通過兩道門：呼叫端本身要有發起 sts:AssumeRole 的權限，目標角色的信任政策也要接受這個主體。再往外看，還可能被權限邊界、組織 SCP、會話策略或條件式限制擋住。
所以，AccessDenied 不是單一問題，而是多個拒絕訊號的總和。排查時如果只盯著角色的權限政策，很容易繞遠路。真正有效的做法，是先判斷拒絕發生在哪一層，再對症處理。
第一步：把拒絕拆成兩道門
第一道門：呼叫端有沒有被允許發起 sts:AssumeRole
AWS帳號快速購買 你目前使用的身分，可能是 IAM User、IAM Role，甚至是經由 SSO 進來的角色。只要要去扮演另一個角色，就必須先有 sts:AssumeRole 的允許。這個允許不是只看一份政策，而是要看有效權限是否成立。也就是說，呼叫端的身分政策要允許，權限邊界也不能把它擋掉，組織層級的 SCP 也不能明確拒絕。
很多人誤以為只要在目標角色上加了信任關係，來源端就自然能扮演成功。其實不是。信任關係只代表目標角色願意接受你，並不代表你有能力去呼叫它。
第二道門：目標角色的信任政策有沒有接受這個主體
就算來源端有 sts:AssumeRole 權限，目標角色的信任政策如果沒有把你的帳號、角色或使用者列進去，STS 一樣會拒絕。跨帳號場景尤其常見。許多團隊只在目標角色的權限政策上做文章，卻忘了信任政策才是誰能來扮演的入口。
如果信任政策還加了條件，例如要求 ExternalId、要求必須使用 MFA、限制來源 IP、限制特定組織 ID，任何一項不符合都會讓 AssumeRole 失敗。這類錯誤表面上看起來也是 AccessDenied，但根因其實是條件不匹配，不是單純缺權限。
權限邊界在這裡怎麼發揮作用
權限邊界的角色很容易被誤解。它不是拿來授權的，而是拿來設上限的。你可以把它理解成一把尺：身分政策給了多少，權限邊界最多只允許到哪裡。真正的有效權限，取決於身分政策與權限邊界的交集；如果再加上 SCP，還要再被組織層級做一次交集。只要任何一層明確拒絕，最後都會失敗。
這裡最常出現兩種情況。
- 第一種，呼叫端身上有身分政策，但權限邊界沒有放行
sts:AssumeRole，結果被邊界擋住。 - 第二種，呼叫端可以成功扮演角色，但扮演之後的新角色因為自己的權限邊界太窄，後續動作又被擋住。這種情況常被誤認為是
AssumeRole失敗，實際上是後續 API 被拒。
因此，排查時一定要先確認：到底是拿臨時憑證這一步失敗，還是拿到之後做其他事失敗。兩者看起來像同一件事，實際上根因完全不同。
最實用的排查順序
先確認當前呼叫者到底是誰
很多事故的第一個坑，就是你以為自己是在用某個 IAM User，其實終端裡已經切到另一個角色，或者本地憑證來自 SSO。先把當前身分釐清，知道是哪個 arn 在呼叫 AssumeRole，後面的判斷才有依據。
如果是自動化流程，例如 CI、Lambda、容器任務，還要確認實際執行的服務角色是誰。有時候真正被拒絕的不是你以為的那個帳號，而是背後那個默默承擔執行權限的角色。
再看 CloudTrail，先抓到拒絕發生在哪一段
CloudTrail 是排障時最好用的證據。當你看到事件來源是 sts.amazonaws.com，事件名稱是 AssumeRole，並且伴隨 AccessDenied，就表示問題真的發生在扮演階段。接著要看事件中的請求主體、目標角色 ARN、錯誤訊息與條件上下文，判斷是權限不夠、信任關係不符，還是條件未命中。
如果 CloudTrail 顯示的是 AccessDenied，但事件本身不是 AssumeRole，那就要小心了。可能你已經拿到臨時憑證，只是後面的操作被拒。這時候不該再盯著 STS，而是要去看真正失敗的 API 是哪一個。
檢查呼叫端的身分政策與權限邊界
呼叫端要能 AssumeRole，至少要有一條允許針對目標角色 ARN 執行 sts:AssumeRole 的政策。除此之外，權限邊界也要允許這個動作。若身分政策有放行，但權限邊界沒有覆蓋到同樣的資源與動作，最後還是會失敗。
這一步很容易漏看，因為控制台裡你常只注意到身分政策，看不到邊界的實際限制。尤其是一些由平台團隊統一套上的邊界，對使用者來說像是透明的，但它對有效權限的影響非常大。
檢查目標角色的信任政策
信任政策要回答的問題很簡單：誰可以來扮演我。它看的不是資源權限，而是主體是否被接受。若你是跨帳號扮演，通常要確認來源帳號或來源角色是否真的在信任關係裡。若信任政策還有條件，就要逐一核對條件值，尤其是 ExternalId、MFA、來源 IP、aws:PrincipalOrgID 這些欄位。
有些團隊為了安全，會把信任政策寫得很細。這本來沒問題，但只要部署或自動化流程有一個參數沒對上，AssumeRole 就會直接拒絕。這不是 AWS 故意刁難，而是條件真的沒有通過。
再往外看 SCP 與組織限制
如果帳號在 AWS Organizations 裡，SCP 可能直接把 sts:AssumeRole 或相關 IAM 動作封掉。SCP 的特性是頂層限制，沒有例外授權的概念。也就是說，就算你在 IAM 身分政策裡補得再完整，只要 SCP 不放行，最後還是被擋。
很多跨帳號排障會卡在這裡。來源帳號看起來一切正常，目標角色信任政策也沒問題，但就是拿不到臨時憑證。最後查到的根因卻是組織層級在禁止某個動作。這種問題最麻煩，因為單看某個帳號內的政策，完全看不出來。
AWS帳號快速購買 注意會話策略與角色鏈
如果你在呼叫 AssumeRole 時又附加了 session policy，那份會話策略也會限制最後拿到的臨時憑證能做什麼。它不會幫你擴權，只會縮權。只要會話策略與既有權限衝突，結果仍然是拒絕。
另外，角色鏈也很常造成誤判。當 A 角色再去扮演 B 角色時，會話長度與條件限制可能和直接扮演不同。某些情況下，扮演鏈一長，能設定的會話時間會被壓縮，或者部分條件不再符合。這時候要回頭看整條扮演路徑，而不是只看最後一跳。
AWS帳號快速購買 幾個最容易踩坑的真實場景
場景一：以為是角色沒權限，其實是邊界把 sts:AssumeRole 擋了
最典型的情況是，開發者看到角色有一堆 IAM Policy，就認定可以扮演別的角色。結果實際執行時仍然 AccessDenied。查半天才發現，平台團隊在這個角色上套了一個權限邊界，而邊界裡根本沒允許 sts:AssumeRole。這時候補身分政策沒有用，因為邊界才是上限。
場景二：來源端有權限，目標角色不信任這個主體
這個場景在跨帳號時特別常見。來源端的使用者或角色明明已經被授權可以呼叫 AssumeRole，但目標角色的信任政策只信任另一個帳號，或者只信任某個特定角色 ARN。結果就是來源端一切正常，扮演請求卻被拒絕。這時候要改的不是來源端的權限，而是目標角色的信任關係。
AWS帳號快速購買 場景三：條件式限制沒對上
有些角色要求必須帶 ExternalId，有些要求開啟 MFA，有些限制必須從公司網段發起。這些條件如果不符合，錯誤訊息通常還是 AccessDenied，不會特別告訴你是哪個條件失敗。排查時一定要把條件一條一條對，不要只看主體是否在名單裡。
場景四：成功扮演了，但後面的操作被權限邊界擋下
這是最容易被誤解的一種。你已經拿到了臨時憑證，說明 AssumeRole 本身成功了，可是接著去做 S3、EC2、KMS 等操作又出現 AccessDenied。這時候真正該查的，是被扮演角色自己的有效權限，而不是 STS。很多人把這兩段混在一起，結果一直在錯的地方補洞。
一套可以直接照著走的排查清單
- 確認當前執行身分，弄清楚到底是哪個主體在呼叫
AssumeRole。 - 檢查該主體的身分政策，是否明確允許對目標角色 ARN 執行
sts:AssumeRole。 - 檢查該主體是否套用了權限邊界，邊界是否也允許同樣的動作與資源。
- 檢查目標角色的信任政策，是否信任來源帳號、來源角色或使用者。
- 若有條件限制，逐一核對
ExternalId、MFA、來源 IP、組織 ID 等條件值。 - 若帳號受 Organizations 管理，再看 SCP 是否存在顯式拒絕。
- 若有 session policy 或角色鏈，確認是否被會話層級的限制縮掉權限。
- 最後回到 CloudTrail，把實際拒絕的事件與錯誤上下文對上。
修正時的原則：先改入口，再改上限，最後再查後續操作
處理這類問題時，最有效的順序通常是先確認信任政策，再確認呼叫端權限，最後才去看邊界與組織限制。因為信任政策是能不能進門，身分政策與權限邊界是你能不能走到門口，SCP 是整個樓層的總開關。若順序搞反，常會把時間花在不相關的地方。
如果你的目標是讓某個服務穩定拿到臨時憑證，建議把每一層的責任分清楚。誰負責授權、誰負責限制、誰負責信任，邏輯越清楚，未來出事時越容易定位。反過來說，若一開始把所有權限都堆到一起，最後只會讓排查變成猜謎。
最後的提醒：不要把權限邊界當成萬能解釋
權限邊界確實常常是 AssumeRole 失敗的原因，但它不是唯一原因，也不一定是第一原因。很多 AccessDenied 看起來像邊界問題，實際上是信任政策、條件式限制或 SCP 擋下來的。真正成熟的排查方式，不是先猜哪裡壞了，而是先把每一層的責任劃清楚，再用證據一層一層排掉。
只要你記住一件事就夠了：AssumeRole 不是單點授權，而是多層門禁。呼叫端、權限邊界、信任政策、SCP、會話策略，任何一層出問題，都可能長得像同一個 AccessDenied。把這個結構看懂，臨時憑證的問題就不再難查。
