AWS 存取管理是一整套 AWS 服務、概念與實務的集合，決定誰可以登入你的 AWS 帳號、登入後能做什麼，以及身分如何被驗證。旗艦服務是 AWS Identity and Access Management（AWS IAM），讓你建立使用者、群組、角色以及落實最小權限原則的 IAM 政策。對於擁有眾多員工與多個 AWS 帳號的組織而言，AWS IAM Identity Center（前身為 AWS SSO）則集中管理員工存取。AWS IAM 與 IAM Identity Center 共同構成 AWS 上每一次 API 呼叫的驗證與授權層。
在 CLF-C02 考試中，Task Statement 2.3（「辨識 AWS 存取管理能力」）期望你能分辨 IAM 使用者與 IAM 角色、用 IAM 政策落實最小權限、設定 MFA、保護根帳號，並知道何時該用 IAM Identity Center 而不是直接用 AWS IAM。本指南會用白話帶你走過每個概念，點出最常見的陷阱，並給你容易記住的類比，讓這些詞彙牢牢黏在腦中。
什麼是 AWS 存取管理（AWS IAM）？
AWS 存取管理是 AWS 原生的框架，控制對任何 AWS 服務中 AWS 資源的存取。它主要透過 AWS IAM 提供，這是一個全球性且免費的 AWS 服務，負責身分驗證（你是否真的是你所宣稱的人？）與授權（你是否被允許執行這個 API 呼叫？）。AWS IAM 儲存身分（IAM 使用者、IAM 角色）、群組（IAM 群組）與權限文件（IAM 政策），然後即時根據這些文件評估每一個請求。
任何對 AWS API 的請求，不論是透過 AWS Management Console、AWS CLI、AWS SDK，或 AWS Management Console 行動應用程式，在 AWS 真正執行之前都會先經過 AWS IAM。如果 AWS IAM 無法辨識呼叫者，或呼叫者的 IAM 政策沒有授予所需權限，請求就會被拒絕。這正是為什麼 AWS 存取管理位於 AWS 責任共擔模型的核心：身分與存取管理永遠是客戶的責任，不論底層服務託管程度有多高。
- AWS IAM：在單一 AWS 帳號中建立與管理身分與權限的 AWS 服務。
- IAM Identity Center：從單一 SSO 入口聯邦化多個 AWS 帳號員工身分的 AWS 服務。
- IAM 政策：授予或拒絕特定 AWS API 動作對特定資源權限的 JSON 文件。
- 最小權限：只授予工作負載絕對需要的權限，多一分都不給的安全原則。
- Reference: https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html
為什麼 AWS 存取管理對 CLF-C02 很重要
CLF-C02 的 Security and Compliance 領域佔考試 30% 的比重，而 AWS 存取管理（IAM、IAM Identity Center）是該領域中提及最多的子主題。考生最常在三個問題上卡關：「何時該用 IAM 角色而不是 IAM 使用者？」、「建立 AWS 帳號後對根帳號要做什麼？」以及「哪個 AWS 服務為員工聯邦存取發放憑證？」。把這三題穩穩答對，你在 AWS 存取管理相關題目上就已經領先大多數 CLF-C02 考生了。
白話文解釋 AWS Access Management
理論如果能對應到具體的東西就容易多了。以下是三個不同的類比，涵蓋 CLF-C02 上所有主要的 AWS 存取管理概念。
類比一：有門禁卡的辦公大樓
想像一棟大型企業辦公大樓。IAM 使用者就像員工識別證，上面印著該員工的照片，屬於某一個特定的人，有個長期使用的 PIN，可以打開這個人被允許通過的門。IAM 群組就像團隊共用門禁碼，你只要設定一次「工程部可以進入 3、4、5 號房」，每張工程師的識別證就自動繼承這個權限。IAM 角色就像放在櫃台的臨時訪客識別帶：任何人（或任何 AWS 服務）都可以跟警衛（AWS STS，也就是 AWS Security Token Service）借出一條，戴在身上用一段時間，離開時歸還。沒有人會永久把角色戴在身上。根使用者就是手握萬能鑰匙的大樓所有人，他可以重新設定每一道門的鎖，但因為萬能鑰匙一旦遺失後果不堪設想，所以要把它收在保險箱裡（AWS 根憑證鎖起來、啟用 MFA），只在真正獨一無二的任務時才取出來用。
MFA（多重要素驗證）就像識別證讀卡機之後的第二道閘門，即使識別證被偷，沒有另外拍硬體權杖、驗證器 App 或 passkey 也進不去。IAM 政策就是貼在每道門上的書面規則（「識別證必須有工程部標籤，時間必須是 08:00-20:00」）。IAM Identity Center則是企業大廳接待櫃台：訪客簽到一次，就被引導進入他被授權進入的 12 棟不同建築（AWS 帳號），不必刷 12 次識別證。
類比二：開書考試的規則
想像你在參加一場有嚴格規則的開書認證考試。監考官就是 AWS IAM，他會檢查你的身分證（身分驗證），然後翻規則手冊（授權）看你能做什麼、不能做什麼。規則手冊就是你的 IAM 政策。最小權限表示規則手冊上應該寫「你可以使用這三本參考書」，而不是「你可以使用圖書館裡所有的書」，允許的範圍越小，座位被搞砸時損失也越小。IAM 政策中的**明確拒絕（explicit deny）**就像監考官那面大大的紅色「禁止」牌，不管其他權限怎麼寫，拒絕一定贏。這就是 AWS IAM 政策評估邏輯的核心：預設拒絕、允許採聯集、明確拒絕推翻任何允許。
類比三：飯店櫃台與房卡
飯店完美抓住了 AWS 存取管理的精髓。根使用者就是飯店老闆，他有萬能的覆寫鑰匙，是唯一可以結束營業、更改租約名稱或關閉銀行帳戶的人。櫃台人員就是 AWS IAM，他發放具有特定存取權的房卡（IAM 使用者、IAM 角色）（只能進 305 號房、只能去游泳池、只能去健身房）。退房時會失效的房卡就是 IAM 角色：它提供臨時存取權並會自動停用，就算忘了交還也不會造成長期風險。MFA就是你 check-in 時留下的簽名，再加上他們掃描的照片身分證，兩個要素一起證明你真的是預訂名單上的人。IAM Identity Center則是飯店連鎖品牌的會員計畫：一個會員檔案、一次登入，就能入住品牌旗下 200 間分店（AWS 帳號）中的任何一家，不用每次都重開帳戶。
考試當天，看到題目寫「IAM 角色」時，在腦中浮現臨時訪客識別帶或退房失效的房卡的畫面，這會阻止你把 IAM 角色跟 IAM 使用者搞混，那正是 CLF-C02 上第一名的 AWS IAM 陷阱。Reference: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html
核心運作原則——身分、驗證與授權
每一個 AWS IAM 決策都遵循相同的三步驟流程：識別、驗證、授權。掌握這個流程後，每一題 AWS 存取管理題目都會變得更容易解讀。
識別：是誰發出這個請求？
當請求抵達 AWS 時，AWS IAM 會抽取主體（principal），也就是發出呼叫的 IAM 使用者、IAM 角色、AWS 服務或聯邦身分。主體會嵌入在請求簽章中（AWS CLI 與 SDK 呼叫）或由當前的 AWS Management Console 工作階段推斷出來。沒有有效的主體，就沒有東西可以評估，請求會立刻被拒絕。
驗證：這個主體真的是他本人嗎？
身分驗證證明主體持有有效的憑證。對 AWS IAM 使用者而言，這代表使用者名稱加密碼（AWS Management Console），或存取金鑰 ID 加私密存取金鑰（AWS CLI、SDK）。對 IAM 角色而言，呼叫者出示先前由 AWS Security Token Service（AWS STS）發放的臨時憑證（存取金鑰 ID、私密存取金鑰與工作階段權杖）。多重要素驗證（MFA）則在上面疊加第二個要素，通常是來自虛擬 MFA 裝置的 TOTP、FIDO2 硬體金鑰，或 passkey。
授權：這個主體被允許做這件事嗎？
授權就是 IAM 政策評估。AWS IAM 收集所有適用的 IAM 政策，包括掛在主體上的身分型政策、掛在目標資源上的資源型政策、權限界線、AWS Organizations 服務控制政策（SCPs）與工作階段政策，然後用一套固定的演算法跑過這些政策。最終結果永遠只有兩個字：允許（Allow）或拒絕（Deny）。
- 預設情況下，每一個請求都是隱含拒絕（implicitly denied）。
- 任何適用的 IAM 政策中出現明確允許（explicit Allow），決策就會翻轉為允許。
- 任何適用的 IAM 政策中出現明確拒絕（explicit Deny），會推翻每一個允許。
- AWS Organizations 層級的 SCPs（服務控制政策）可以限制成員帳號中的 IAM 政策所能授予的權限，但 SCPs 本身永遠不會授予權限。
Reference: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html
IAM 基本元件：使用者、群組、角色與政策
AWS IAM 有四個基本元件，每一題 CLF-C02 都建立在它們之上。知道每一個是什麼，更重要的是知道每一個不是什麼，是拉高你 AWS 存取管理分數最關鍵的槓桿。
IAM 使用者
IAM 使用者代表單一 AWS 帳號中的一個身分，通常是一個人或一個長期運行的外部應用程式。一個 IAM 使用者有一個唯一名稱、可以有一組主控台密碼，還可以擁有最多兩把可用的存取金鑰（好讓你在不中斷的情況下輪替）。由於 IAM 使用者的憑證本質上就是長期的，它在 AWS 存取管理中是風險最高的元件，應該盡量少用。AWS 最佳實務是，只要可以，就優先選擇 IAM 角色與 IAM Identity Center，而不是建立新的 IAM 使用者。
IAM 群組
IAM 群組是一個容器，把多個 IAM 使用者綁在一起，讓你把 IAM 政策掛一次就套用到每一個成員。一個使用者可以同時屬於多個 IAM 群組。群組不是身分，你無法「以群組身分登入」，也不能把憑證嵌在群組裡，它們純粹是為了讓 IAM 政策管理可以規模化而存在。
IAM 角色
IAM 角色是一個掛著 IAM 政策但沒有長期憑證的身分。取而代之的是，主體（一個 AWS 服務、一個 AWS 帳號、一個聯邦身分使用者、另一個 AWS 帳號中的 IAM 使用者）去承擔（assume）這個角色，然後從 AWS STS 拿到短期安全憑證。這些臨時憑證會過期（預設 1 小時，許多工作流程可調整到最多 12 小時），並且不會留下任何持久性的秘密。IAM 角色是以下情境最正確的 AWS IAM 元件：
- 讓 Amazon EC2 執行個體存取 Amazon S3（一個 EC2 instance profile），而不必把存取金鑰埋進 AMI。
- 讓 AWS Lambda 函式寫入 Amazon DynamoDB，而不必硬編碼憑證。
- 跨帳號存取，當 Account A 的使用者偶爾需要存取 Account B 的資源時。
- 從企業身分提供者（SAML 2.0、OIDC，或 Google、Facebook、Amazon Cognito 這類網頁身分提供者）來的聯邦身分。
IAM 政策（managed 與 inline）
IAM 政策是一份 JSON 文件，列出在特定資源上被允許或拒絕的 AWS API 動作，也可以選擇性地加上條件過濾。有兩種呈現格式：
- **受管政策（managed policies）**是獨立存在的 IAM 政策物件，你建立一次就可以掛給許多身分。AWS 受管政策是 AWS 預先建好並維護的（例如
AmazonS3ReadOnlyAccess）。客戶受管政策則是你自己撰寫並管理版本的政策。 - **內嵌政策（inline policies）**直接嵌在單一 IAM 使用者、IAM 群組或 IAM 角色中，跟著它一起生、一起死。當你想要身分與權限之間有嚴格的 1:1 綁定時用 inline IAM 政策，其他情況一律用受管 IAM 政策以便重用。
CLF-C02 要記得，AWS 建議受管 IAM 政策優於內嵌 IAM 政策，因為受管政策可重用、有版本、易於稽核。內嵌 IAM 政策在少數一次性、緊密耦合的情境下沒問題，但不容易擴展。Reference: https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html
IAM 使用者 vs IAM 角色——關鍵差異與使用時機
這是 CLF-C02 AWS 存取管理題目中最常考的差異。答錯的話整個 Security 領域的題目都會跟著失分。
什麼時候該用 IAM 使用者
當你需要擁有長期憑證的持久性身分時，IAM 使用者才適合。典型例子：AWS 帳號最早期的小團隊人類使用者登入 AWS Management Console；不支援角色承擔的第三方監控工具；或舊有的地端腳本。每多一個 IAM 使用者就多一份長期憑證管理成本：輪替、離職流程、MFA 啟用。
什麼時候該用 IAM 角色
只要呼叫者不需要把憑證帶在身上幾週或幾個月，就適合用 IAM 角色。CLF-C02 上最常見的情境有：
- EC2 service-access：透過 instance profile 把 IAM 角色掛在 Amazon EC2 執行個體上；Amazon EC2 執行個體中繼資料服務會向應用程式暴露會輪替的短期憑證。user-data 裡沒有秘密，原始碼庫裡也沒有秘密。
- 跨帳號存取：AWS 帳號 A 中的使用者或服務透過
sts:AssumeRole承擔 AWS 帳號 B 裡的 IAM 角色，取得短期憑證、完成工作，事後沒有東西需要清理。 - 聯邦身分：SAML 2.0 身分提供者（例如 Active Directory Federation Services）或網頁身分提供者（例如 Amazon Cognito user pools）發出斷言；AWS IAM 信任該斷言並回傳綁定在所選 IAM 角色上的短期憑證。
CLF-C02 一再出現的陷阱，是選項描述「具有臨時權限的 IAM 使用者」或「有密碼的 IAM 角色」。這兩個都不存在。IAM 使用者永遠有長期憑證、選擇性地有密碼；IAM 角色永遠沒有密碼、永遠沒有長期憑證，被承擔時永遠透過 AWS STS 發出短期憑證。如果情境說「讓 Amazon EC2 執行個體存取 Amazon S3」或「讓 Account A 的工作負載在 1 小時內到達 Account B」，那就是 IAM 角色，不是 IAM 使用者。Reference: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html
兩者並列比較
| 面向 | IAM 使用者 | IAM 角色 |
|---|---|---|
| 憑證壽命 | 長期（主控台密碼 + 存取金鑰） | 短期，承擔時由 AWS STS 發放 |
| 有密碼嗎？ | 選用 | 永遠沒有 |
| 誰會使用？ | 特定的人或外部系統 | 任何被角色信任政策允許的主體 |
| 最佳實務定位 | 盡量少用；優先選 IAM Identity Center | AWS 服務、跨帳號、聯邦身分的首選 |
| 典型 CLF-C02 關鍵字 | 「長期」、「主控台登入」、「個別工程師」 | 「EC2 role」、「跨帳號」、「臨時」、「聯邦身分」 |
最小權限原則——受管政策 vs 內嵌政策
最小權限是 AWS 存取管理最根本的原則：給每一個 IAM 使用者、IAM 群組或 IAM 角色只有完成任務所需的權限，時間也以最短為限。這是 AWS IAM User Guide 中被強調最多的最佳實務，也會一再出現在 CLF-C02 的情境題中。
從窄處開始
每一份 IAM 政策都從最小集合的 API 動作與具體的資源 ARN 開始。不要從 "Action": "*" 開始再「往回剝」，那種做法最後通常會給出遠超工作負載實際需要的權限。若 AWS 受管政策跟工作職能相當貼近，就當作基準線；但優先選擇根據工作負載實際呼叫動作調校過的客戶受管 IAM 政策。
IAM Access Analyzer
AWS IAM Access Analyzer 是 AWS IAM 裡的一個功能，協助你自動走向最小權限。在 CLF-C02 上它有兩大能力：
- 外部存取分析——持續掃描資源型 IAM 政策（Amazon S3 bucket 政策、IAM 角色信任政策、AWS KMS 金鑰政策等），並標示出任何把存取授予信任邊界外主體的政策。
- 未使用存取分析與政策產生——檢視某段時間窗內的 AWS CloudTrail 活動，產生一份只授予該身分實際用過權限的精煉 IAM 政策。
當考題問「組織要如何確保 IAM 政策只授予必要的權限？」答案幾乎永遠是 AWS IAM Access Analyzer。它是 AWS 安全最佳實務指引中明確點名用來達成最小權限的 AWS IAM 功能。Reference: https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html
權限界線與工作階段政策
有兩種進階的 IAM 政策型別可以進一步收緊最小權限：
- **權限界線（permissions boundary）**是一個進階功能，設定身分型 IAM 政策對 IAM 使用者或 IAM 角色所能授予的權限上限。權限界線本身不授予權限，只限制其他 IAM 政策可以授予的範圍。
- **工作階段政策（session policy）**是透過 AWS STS 承擔角色時一併傳入的政策；它收緊該特定工作階段的有效權限，不會修改底層的 IAM 角色。
這兩種元件都是為了阻止不慎給出過多權限而存在，在 CLF-C02 上偶爾會以干擾選項的形式出現。
根帳號安全——只有 root 能做的事與保護方式
根使用者就是你第一次開通 AWS 帳號時建立、以電子郵件地址為基底的帳號擁有者。它對該 AWS 帳號中每一個資源、每一項帳單設定都有無條件、無限制的存取權。這份力量也讓根使用者成為整個帳號上最大的單點風險。
只有根使用者能做的事
有一小撮任務只能由根使用者完成，不論 IAM 政策多寬鬆，都無法委派給任何 IAM 使用者或 IAM 角色：
- 變更 AWS 帳號的電子郵件地址或根密碼。
- 變更 AWS 帳號名稱。
- 關閉 AWS 帳號。
- 變更或取消 AWS Support 方案。
- 當每一個管理員 IAM 使用者都被鎖在帳號外時還原 IAM 使用者權限（帳號復原）。
- 註冊成為 AWS Marketplace 的賣家。
- 設定某些 AWS 帳單與稅務資訊。
如何保護根使用者
AWS IAM 圍繞根使用者的最佳實務既短、又具體、又非常會被考：
- 只用根使用者完成一次性的初始設定，然後立刻建立一個擁有管理員權限的 IAM 使用者（或更好的選擇：一個 IAM Identity Center 使用者）來處理日常管理。
- **為根使用者啟用 MFA。**CLF-C02 常常把這題講成「建立新 AWS 帳號後第一件該做的事是什麼？」，答案就是「為根使用者啟用 MFA」。
- **刪除或停用根存取金鑰。**若有根存取金鑰，把它輪替或移除；強烈不建議程式化使用根使用者。
- 為根使用者設定強壯且唯一的密碼，並把憑證實體鎖起來。
- 絕對不要共享根使用者；若多人需要管理員存取，給每個人自己的身分與一份 admin IAM 政策。
一個經典的 CLF-C02 陷阱：你無法掛一份 IAM 政策到根使用者上來限制 root 能做什麼。就連 AWS Organizations 的服務控制政策（SCPs），對管理帳號的根使用者，也不像對成員帳號那樣明確適用。唯一有效的保護就是不要使用根使用者，除了一次性初始設定與少數 root 專屬任務以外，並把根憑證與 MFA 鎖起來。Reference: https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html
驗證方式：MFA、存取金鑰、密碼政策
AWS IAM 支援多種驗證要素，CLF-C02 會考你能否分辨它們。
主控台密碼 + 密碼政策
每一個 IAM 使用者都可以選擇性地有一組主控台密碼。帳號層級的 IAM 密碼政策強制最短長度、字元類別、輪替週期、重用防止，以及使用者是否可以自行變更密碼。密碼政策會套用到 AWS 帳號中所有的 IAM 使用者，但不適用於根使用者（根使用者有自己一套強密碼要求）。
存取金鑰
存取金鑰是 AWS CLI、AWS SDK 與 AWS PowerShell 所使用的長期憑證（存取金鑰 ID + 私密存取金鑰）。每一個 IAM 使用者最多可以有兩把可用的存取金鑰，讓新金鑰可以在舊金鑰刪除之前就先配發，達到零停機輪替。對於非人類的工作負載，AWS 強烈建議把存取金鑰換成 IAM 角色（EC2 instance profile、Lambda 執行角色、ECS 任務角色），徹底避免長期秘密。
MFA——虛擬、硬體與 passkey
多重要素驗證在密碼之上再加上第二個要素。AWS IAM 支援三種形式：
- 虛擬 MFA 裝置——手機上的驗證器 App（Google Authenticator、Authy、1Password 等），產生輪替的 6 位數 TOTP。最便宜也最常見。
- 硬體 MFA 裝置——實體鑰匙圈（AWS 販售 Gemalto/SafeNet 裝置）或 FIDO2 安全金鑰（例如 YubiKey）。比虛擬 MFA 更穩健，因為秘密無法從硬體裝置上被拷貝出來。
- Passkey / FIDO 驗證器——AWS 支援內建於 iOS、Android、macOS、Windows Hello 與硬體安全金鑰上的 passkey。Passkey 抗釣魚，是 IAM 使用者與根使用者現代首選的驗證要素。
- MFA 對根使用者必須強制啟用，對每一個擁有高權限的 IAM 使用者也應啟用。
- 虛擬 MFA = 驗證器 App。硬體 MFA = 實體權杖。Passkey = 基於 FIDO、抗釣魚。
- MFA 是免費的，啟用它 AWS 不收任何費用（只有自己買硬體權杖時才需付費）。
- Reference: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html
IAM Identity Center（SSO）— 聯邦存取與跨帳號管理
AWS IAM Identity Center（前身為 AWS Single Sign-On，有時仍被稱作 AWS SSO）是針對員工身分的 AWS 存取管理服務，處理組織裡需要登入單一或多個 AWS 帳號的人類使用者。在 2026 年，它是 AWS 上推薦的人員存取管理方式。
IAM Identity Center 做什麼
- 提供一個單一登入入口。使用者用公司身分登入一次，就能看到他被授權的每一個 AWS 帳號與 SaaS 應用程式的圖磚。
- 透過 SAML 2.0 或 OIDC 與現有的企業身分提供者聯邦，常見整合對象包括 Microsoft Entra ID（前 Azure AD）、Okta、Ping Identity、Google Workspace，以及透過 AWS Directory Service 串接的地端 Active Directory。
- 也可作為自有的身分庫（內建目錄）運行，適合還沒有 IdP 的組織。
- 管理權限集（permission sets），這些權限集會套用到 AWS Organizations 結構裡的 AWS 帳號上；使用者被對應到權限集，IAM Identity Center 會自動在每個目標 AWS 帳號中建立所需的 IAM 角色。
- 為 AWS CLI v2 工作階段發放短期憑證，讓工程師再也不必在筆電上存放長期存取金鑰。
什麼時候選 IAM Identity Center，什麼時候選純 AWS IAM
| 情境 | 建議元件 |
|---|---|
| 員工（workforce）存取一個或多個 AWS 帳號 | IAM Identity Center |
| 從企業身分提供者進行聯邦存取 | IAM Identity Center（最簡單）或 SAML 聯邦至 IAM 角色 |
| AWS 服務對 AWS 服務存取（Amazon EC2 → Amazon S3） | IAM 角色 |
| AWS 帳號之間的臨時跨帳號存取 | IAM 角色（以 sts:AssumeRole 承擔） |
| 無法承擔角色的外部應用程式 | IAM 使用者（最後手段，搭配嚴格的最小權限 IAM 政策） |
AWS 目前的最佳實務建議，在多帳號 AWS 環境下，把 IAM Identity Center 當作員工存取的預設機制，而不是在每個帳號建立 IAM 使用者。許多 CLF-C02 題目現在描述的是多帳號情境，期待的答案就是 IAM Identity Center。如果情境提到「employees」、「workforce」、「登入一次」、「多個 AWS 帳號」或「SAML 2.0 / OIDC 聯邦」，你的第一候選答案就該是 IAM Identity Center。Reference: https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html
聯邦身分——SAML 2.0、Web Identity 與 Cognito
聯邦身分讓你不必為每一個已經在別處有身分的使用者建立 IAM 使用者，就能授予他們 AWS 存取權。
SAML 2.0 聯邦
當員工已經住在 SAML 2.0 身分提供者裡（Microsoft Entra ID、Active Directory Federation Services、Okta、Ping），你可以選擇：
- 使用 IAM Identity Center（最簡單；IAM Identity Center 為每一個 AWS 帳號居中處理 SAML 關係），或
- 在 AWS IAM 內部設定一個 SAML 2.0 身分提供者，把 SAML 斷言對應到信任該提供者的 IAM 角色。
不論走哪條路，最終結果都一樣：使用者在公司 IdP 登入、拿到 SAML 斷言、透過 AWS STS 換取短期憑證。
Web Identity 聯邦與 Amazon Cognito
對於要呼叫 AWS API 的面向客戶行動或網頁應用程式（例如讓使用者把照片上傳到 Amazon S3 的 App），Amazon Cognito user pools 與 identity pools 是首選整合方案。Cognito 處理透過 Google、Apple、Facebook、Amazon 或任何相容 OIDC 提供者的登入，並把社交登入權杖換成綁在 IAM 角色上的短期 AWS 憑證。
直接的 web identity 聯邦（OIDC-to-IAM）仍然被支援，但 Amazon Cognito 把它包成一個更高階的 AWS 服務，同時處理使用者目錄、MFA、使用者遷移與屬性對應。
聯邦身分沒有持久憑證
SAML 與 web identity 聯邦兩種方式，都不會在使用者裝置上或在 IdP 中留下長期的 AWS 憑證，使用者拿到的是會自行過期的 STS 臨時憑證。這是核心的 AWS 安全勝利，也是 CLF-C02 常見的情境題（「哪種方式能避免長期 AWS 憑證？」→ 用 IAM 角色做聯邦身分）。
AWS IAM 是全球性的，不是 Region 範圍
AWS IAM 是一個全球性的 AWS 服務。IAM 使用者、IAM 群組、IAM 角色與 IAM 政策在每一個 AWS 帳號中只建立一次，就立即在每一個 AWS Region（區域）上可用。你建立 IAM 使用者時不用挑 Region，也不用在每個部署工作負載的 Region 重建一次 IAM 使用者。IAM Identity Center 的目錄與員工入口的權限集也是一樣，雖然 IAM Identity Center 執行個體本身是配發在某一個主 Region。
提到「在 us-east-1 建立 IAM 使用者」或「在多個 region 之間複製 IAM 政策」的選項都是干擾項。AWS IAM 是全球性的，你永遠不會跨 Region 複製 IAM 身分。不要把它跟 AWS Identity and Access Management Roles Anywhere 或 Amazon Cognito user pools 混淆，後兩者是 Region 級的 AWS 服務。Reference: https://docs.aws.amazon.com/IAM/latest/UserGuide/intro-structure.html
AWS IAM vs AWS Organizations——帳號內控管 vs 多帳號控管
CLF-C02 上的 AWS 存取管理題目有時會把 AWS IAM 跟 AWS Organizations 與它的**服務控制政策（SCPs）**混在一起。它們是互補的，不是互斥的。
- AWS IAM 控制單一 AWS 帳號內的身分能做什麼。
- AWS Organizations 控制整個 AWS 帳號（或 Organizational Unit）被允許做什麼，涵蓋帳號內每一個身分。
- 服務控制政策（SCPs）是 AWS Organizations 的護欄，它們設定成員帳號中任何 IAM 政策能授予的最大權限。SCPs 本身永遠不授予權限，只做限制。
- AWS IAM Identity Center坐在 AWS Organizations 之上，把員工身分分派到成員 AWS 帳號中的權限集。
一個常見的 CLF-C02 考試陷阱：「一份 IAM 政策授予了 s3:*，但使用者還是不能寫入 Amazon S3，為什麼？」典型答案就是 AWS Organizations 層級的 SCP 把這個動作對整個帳號封鎖掉。SCPs 定義了外部邊界；IAM 政策在這個邊界內填入內容。動作必須兩邊都允許才會成功。Reference: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html
憑證儲存：AWS Secrets Manager 與 AWS Systems Manager Parameter Store
AWS 存取管理不只關乎誰登入，也涵蓋你的應用程式如何儲存資料庫、API 與第三方服務的憑證。有兩個 AWS 服務在 CLF-C02 的認知層級會被考：
- AWS Secrets Manager——專門的秘密儲存 AWS 服務，內建自動輪替（對 Amazon RDS、Amazon Redshift、Amazon DocumentDB 特別強）。按秘密數計費。當輪替、跨帳號共享或細粒度存取很重要時使用它。
- AWS Systems Manager Parameter Store——免費層級的純文字與加密設定參數，帶版本控制。當你不需要輪替時，適合一般設定與輕量秘密儲存。
這兩個 AWS 服務都與 AWS IAM 政策整合，只有指定的 IAM 使用者、IAM 角色與 IAM Identity Center 權限集可以讀取某一份秘密。這能讓資料庫密碼與第三方 API 金鑰遠離原始碼庫，也遠離 Amazon EC2 的 user-data 腳本。
AWS 存取管理的關鍵數字與必背事實
把這份短清單背起來，它涵蓋了 CLF-C02 上大多數 AWS IAM 的數字與分類陷阱。
- AWS IAM 是全球性的——不是 Region 範圍的。
- AWS IAM 免費——IAM 使用者、IAM 角色、IAM 政策與 MFA 都不直接收費。
- 每個 IAM 使用者同一時間最多兩把可用的存取金鑰（用於輪替）。
- MFA 類型：虛擬（驗證器 App）、硬體（實體權杖、FIDO2）、passkey。
- 承擔 IAM 角色的預設工作階段長度：1 小時（大多數流程可調整到最多 12 小時）。
- 根使用者 = 一次性初始設定加上少數 root 專屬動作；立即啟用 MFA；把憑證鎖起來。
- 最小權限原則——授予最少權限；用 AWS IAM Access Analyzer 稽核。
- IAM Identity Center = 員工身分，取代舊的 AWS SSO 名稱。
- SCPs 限制成員帳號中的 IAM 政策所能授予的權限；它們本身永遠不授予。
- Reference: https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html
常見考試陷阱——AWS 存取管理
預期每一次 CLF-C02 嘗試中至少會遇到其中一個。在讀選項之前就先學會辨認模式。
陷阱 1：IAM 角色 vs IAM 使用者
選項描述「具有臨時憑證的 IAM 使用者」或「帶長期存取金鑰的 IAM 角色」都是陷阱。IAM 使用者 = 長期憑證。IAM 角色 = 由 AWS STS 發放的短期憑證。若情境涉及 Amazon EC2 執行個體、AWS Lambda 函式或跨帳號存取，正確的 AWS 存取管理元件是 IAM 角色。
陷阱 2：根使用者 vs 管理員 IAM 使用者
「管理員」是指「掛了 AdministratorAccess IAM 政策」。「根使用者」是指原始帳號擁有者。他們不是同一個人。Root 擁有管理員沒有的能力（關閉 AWS 帳號、變更 root email）。日常管理應該用 IAM 使用者或 IAM Identity Center 使用者來做，而不是用根使用者。
陷阱 3：AWS IAM vs IAM Identity Center
AWS IAM 是帳號內的身分服務。IAM Identity Center 是多帳號員工入口。提到「employees」、「single sign-on」、「多個 AWS 帳號」或「SAML」的題目通常要的是 IAM Identity Center。提到「給 Amazon EC2 執行個體存取 Amazon S3」的題目要的是 AWS IAM 角色。
陷阱 4：AWS IAM 不是 Region 範圍
任何暗示你要按 Region 建立 IAM 使用者、跨 Region 複製 IAM 政策，或為 AWS IAM 挑 Region 的選項都是錯的。AWS IAM 是全球性的。
陷阱 5：SCPs 永遠不授予，只限制
若某 SCP 拒絕了 s3:DeleteBucket，那個成員帳號中的任何 IAM 政策都無法授予 s3:DeleteBucket，不論它有多寬鬆。但 SCP 允許 s3:DeleteBucket 並不會自動授予權限，成員帳號中的 IAM 政策也必須授予它。
陷阱 6：MFA 適用於 root 與 IAM 使用者
有些題目暗示 MFA 只適用於根使用者。MFA 應該在根使用者以及每一個擁有高權限的 IAM 使用者上啟用，尤其是掛著管理員等級 IAM 政策的 IAM 使用者。
AWS 存取管理 vs AWS 安全治理——範圍邊界
AWS 存取管理（Task 2.3——AWS IAM、IAM Identity Center）處理的是誰登入、能做什麼。安全治理與合規（Task 2.2——AWS Config、AWS Organizations、AWS Control Tower、AWS Artifact）處理的則是身分層之上的組織護欄、合規文件、偵測與預防控制。兩者在 AWS Organizations（它同時承載用於存取管理限制的 SCPs 與用於治理的護欄）與 AWS IAM Access Analyzer（橫跨存取管理與治理）上重疊。當 CLF-C02 題目問「誰能做什麼」時，是存取管理；問「這個帳號是否以合規的方式設定」時，是治理。
練習題連結——Task 2.3 對應情境
- 「哪個 AWS 服務讓 Amazon EC2 執行個體存取 Amazon S3 而不用長期憑證？」→ IAM 角色（透過 instance profile 掛載）。
- 「公司建立新 AWS 帳號後應立刻做什麼？」→ 為根使用者啟用 MFA，並建立一個管理員 IAM 使用者或 IAM Identity Center 使用者來處理日常管理。
- 「擁有 15 個 AWS 帳號的公司應如何管理員工登入？」→ 以企業身分提供者聯邦的 IAM Identity Center。
- 「哪個 AWS 服務可以協助找出授予超出需要權限的 IAM 政策？」→ AWS IAM Access Analyzer。
- 「臨時跨帳號存取最好用哪個 AWS IAM 元件？」→ 透過 AWS STS 承擔的 IAM 角色。
FAQ——AWS 存取管理高頻問題
Q1：AWS IAM 與 IAM Identity Center 有什麼不同？
AWS IAM 管理一個 AWS 帳號內的身分與 IAM 政策，包含 IAM 使用者、IAM 群組、IAM 角色、IAM 政策。AWS IAM Identity Center（前身為 AWS SSO）坐在 AWS Organizations 之上，提供單一登入入口、SAML/OIDC 聯邦，以及會對應到多個 AWS 帳號 IAM 角色的權限集。2026 年，IAM Identity Center 是多帳號環境下員工存取的推薦預設選項；AWS IAM 則繼續作為 AWS 服務、應用程式與跨帳號角色的低階 AWS 存取管理服務原語。
Q2：什麼時候用 IAM 使用者，什麼時候用 IAM 角色？
只要可能就用 IAM 角色，因為它發放短期憑證、不會留下持久秘密。Amazon EC2 服務存取、AWS Lambda 執行、跨帳號存取與聯邦身分，IAM 角色都是對的 AWS IAM 元件。只在確實需要長期持久身分時才用 IAM 使用者，例如無法承擔角色的第三方工具，並搭配最小權限、MFA 與存取金鑰輪替來控制風險。
Q3：建立 AWS 帳號後馬上要對根使用者做什麼？
立刻為根使用者啟用 MFA（虛擬 MFA 裝置、硬體 MFA 裝置或 passkey），刪除任何根存取金鑰，設定強壯且唯一的密碼，並建立另一個管理員身分，最好是 IAM Identity Center 使用者，或一個掛著 AdministratorAccess IAM 政策的 IAM 使用者，用它來處理所有後續的管理工作。把根憑證鎖起來，只有在關閉 AWS 帳號、變更 root email 這類 root 專屬動作時才取出來用。
Q4：AWS 如何落實最小權限原則？
從最小的 IAM 政策開始，只在工作負載明確需要時才加權限。用 AWS IAM Access Analyzer 找出外部存取，並從 AWS CloudTrail 活動產生精煉的 IAM 政策。優先選擇受管 IAM 政策以利重用；為會建立其他 IAM 角色的 IAM 角色設權限界線；並加上 AWS Organizations SCPs 作為最上層護欄。在 CLF-C02 上，「最小權限」與「IAM Access Analyzer」是緊密連結的關鍵詞。
Q5：AWS IAM 是免費的嗎？MFA 是免費的嗎？
是的，AWS IAM 是免費的 AWS 服務，IAM 使用者、IAM 群組、IAM 角色或 IAM 政策都不收費。MFA 也是免費的，只有在你購買實體硬體 MFA 權杖時才要付費；而 passkey 與虛擬 MFA App 都不用錢。當然，那些 IAM 政策授予存取的 AWS 資源（Amazon EC2、Amazon S3 等）仍會計費，只是 AWS IAM 本身不計費。
Q6：可以用 IAM 政策或 SCP 來限制 AWS 根使用者嗎？
不行，你無法用 IAM 政策對 AWS 帳號的根使用者做出有意義的限制，而 AWS Organizations 層級的 SCPs 對管理帳號的根使用者也不像對成員帳號那樣明確適用。根使用者唯一有效的保護就是不要使用它：啟用 MFA、刪除存取金鑰、把憑證鎖起來，並把日常工作委派給 IAM 使用者、IAM 角色或 IAM Identity Center 權限集。
Q7：SAML 聯邦與 Amazon Cognito 有什麼不同？
SAML 2.0 聯邦是員工模式，企業身分提供者（Microsoft Entra ID、Active Directory Federation Services、Okta、Ping）發出 SAML 斷言，AWS IAM 或 IAM Identity Center 信任該斷言，使用者拿到某個 IAM 角色的短期憑證。Amazon Cognito 則是面向客戶的模式，user pools 管理你應用程式終端使用者的註冊與登入，identity pools 把登入權杖換成綁在 IAM 角色上的短期 AWS 憑證。員工 = SAML + IAM Identity Center；你應用程式的客戶 = Amazon Cognito。