AWS 身份驗證深度解析——IAM、IAM Identity Center、Cognito、MFA、STS 與排錯

SCS-C02 Security Specialty 考試對 AWS 身份驗證的要求，早已不是「建立一個 IAM user 然後交出 access key」那麼簡單。安全工程師必須能針對企業員工、聯合身份的員工隊伍、應用程式客戶端與終端使用者，設計出縱深防禦的身份架構——並在登入失敗或稽核詢問「到底是誰在 UTC 03:42 存取了這個資源」時，能夠拿出確切的證據。SCS-C02 Domain 4（身份與存取管理，佔考試 16%）的 Task Statement 4.1——「設計、實作並排查 AWS 資源的身份驗證」——這一句話就涵蓋了：IAM user vs role、SAML 2.0 與 OIDC 聯合、IAM Identity Center 企業 SSO、Amazon Cognito 客戶身份、MFA 強制執行模式、AWS STS API 全貌、session 時長調整、role chaining 注意事項，以及 CloudTrail、IAM Access Advisor、IAM Policy Simulator 排查工具箱。本指南以安全工程師被評分的角度——爆炸半徑最小化、稽核忠實度、MFA 正確性，以及真正出現在 CloudTrail 的失敗模式——完整走過整個身份驗證設計面。

本深度解析與授權政策指南互補，後者涵蓋已通過驗證的 principal 能做什麼。本文聚焦於首先證明 principal 是誰。

SCS-C02 身份驗證範圍——你被評分的項目

AWS Certified Security Specialty（SCS-C02）考試指南明確列出 Task Statement 4.1 的知識要求：驗證 AWS principal 和終端使用者的方法與服務、使用 SAML 和 OIDC provider 的聯合、IAM Identity Center 的人員 SSO、Amazon Cognito 的應用程式登入、MFA 設定與強制執行、AWS STS 暫時憑證 API，以及診斷失敗身份驗證的排查工具。測試技能包括：設定 IAM Identity Center、整合第三方 IdP、為應用程式設計身份驗證流程、強制執行 MFA，以及閱讀 CloudTrail 找出登入失敗原因。

考試在 Task 4.1 不測試的，是 principal 通過驗證後能做什麼（那是 Task 4.2——授權，在授權政策指南中涵蓋）。閱讀情境題時要清楚區分邊界：「使用者無法登入」是身份驗證問題；「使用者已登入但在 s3:GetObject 拿到 AccessDenied」是授權問題。干擾選項經常把這兩者混淆。

白話文解釋 AWS 身份驗證

在深入 SAML assertion 和 STS API 之前，用三個來自不同領域的心智模型，就能涵蓋 SCS-C02 所有身份驗證概念。

類比一：捷運站的自動驗票閘門與站務系統

把台北捷運系統想像成有 50 個站（你的 AWS 帳號）。持有長期 access key 的 IAM user 就像是發給員工的永久悠遊卡——方便，但如果掉在路上，任何人都能刷進去，直到你想起來停用才算數。安全團隊最不喜歡這種設計。

透過 STS 承擔的 IAM role 就像是站務中心發給每位訪客的一次性臨時票卡，有效期限 1 到 12 小時。這張票不能複製，因為它會到期；就算外洩，爆炸半徑最多只有一個 session。AWS STS AssumeRole 是站務員列印票卡的動作；AssumeRoleWithSAML 是站務員接受你另一家公司的員工證並印出通行票；AssumeRoleWithWebIdentity 是站務員接受你的 Google 或 Apple 帳號登入。

IAM Identity Center 是整個大型捷運系統的統一驗票中心——在一個服務台刷卡，這個服務台決定你今天能進哪些站、哪些月台。Amazon Cognito 是專門為乘客打造的獨立旅客服務中心——乘客走上前，用自己的電子信箱和密碼（或透過 Google）證明身份，然後拿到一條手環，可以使用乘客專屬設施，如便利商店和電子報報攤。這條手環永遠無法開啟員工專用區域。

MFA 是進入機房那道門的雙重驗證：先刷悠遊卡，再做生物辨識掃描。CloudTrail 日誌簿是站務員記錄每次刷卡——成功和拒絕——的帳本，包含時間戳記、誰嘗試、哪個閘門，以及結果。

類比二：有多個櫃台的國際機場

你正在進行國際旅行。報到櫃台驗證你的護照並發給你登機證——這就是 AssumeRole 鑄造 STS 憑證。你的登機證有效期限印記（session 時長），並列明你可以通過哪些登機門（role 的權限）。在安檢時，MFA 是第二道關卡——護照加上航空公司 App 的 QR Code。

SAML 聯合是航空聯盟：你在一家主要航空公司有常客資格，走進合作航空公司的航廈，出示你的主要航空公司卡，合作航空公司的報到員工就給你一張合作登機證——AssumeRoleWithSAML。使用 web identity 的 OIDC 聯合是當你用 Google 或 Apple 登入自助報到機，機器印給你一張合作通行証——AssumeRoleWithWebIdentity。

IAM Identity Center 是聯盟的樞紐機場，在一個超級櫃台為每家成員航空公司印登機證。Amazon Cognito user pool 是某家航空公司自己的常客計畫資料庫——會員註冊、密碼重設、MFA 登錄。Cognito identity pool 是把常客卡換成一張可進入合作航空公司貴賓室的單日臨時通行證的服務台。

Role chaining 是當你拿著國內段登機證，走過轉機廊，換成另一張國際段登機證——但每次換票都會從你能繼續旅行的總時間扣除，直到你需要重新報到。

類比三：醫院的識別手環系統

醫院為建築物裡的每個人發放彩色識別手環。長期 IAM access key 就像員工永久胸牌——絕不應帶在訪客身上。透過 STS 取得的 IAM role 是在掛號台發給的拋棄式手環；預約結束後到期。MFA 是領取管制病房手環時要求的第二道身份驗證。

IAM Identity Center 是中央員工證辦公室，任何醫院部門都可以向它申請手環。Amazon Cognito user pool 是病患入口網站登入系統——病患有自己的電子信箱和密碼，與員工身份系統分開。Cognito identity pool 是讓病患的入口網站登入換成一個短期手環的服務台，讓病患的手機 App 能存取特定 bucket 中自己的檢驗報告。

CloudTrail 是中央護理站的日誌簿：每個手環的發放、每扇門的嘗試、每次拒絕都被記錄。IAM Access Advisor 是年度審查，標記出 90 天內未被使用的手環。IAM Policy Simulator 是試跑演練，安全護理師模擬「如果帶著這條手環的病患試著開那扇門，會不會打開？」——而不需要真的有人走到那扇門前。

IAM User vs IAM Role——為何 Role 是 SCS-C02 的預設答案

第一個身份驗證選擇是影響最深遠的。SCS-C02 很大程度上評分你對何時使用各種選項的理解。

IAM user——長期有效、風險較高、越來越少見

IAM user 是儲存在特定 AWS 帳號中的 AWS 內部 principal。它有唯一的 ARN，可以有主控台密碼，可以有最多兩對 access key（AKIA... 加上 secret），可以被分配 MFA。憑證有效期限是無限期，除非你輪換或刪除——這就是核心安全問題。公開的 Git repository 中洩露的 access key 是 SCS-C02 的經典事件情境。

2026 年 IAM user 的合法使用場景極為有限：

• AWS Organizations 管理帳號中的break-glass 使用者，僅在 IAM Identity Center 或 IdP 無法存取時使用，搭配密封信封中存放的硬體 MFA token，並在每次登入時觸發 CloudTrail 警報。
• 少數無法使用 role 的遺留系統服務帳號（罕見且持續減少）。
• 特定需要 AWS access key 的第三方 SaaS 整合（大多數現代整合現在已支援帶有 external ID 的 sts:AssumeRole）。

其他所有情況——企業工程師、在 EC2、Lambda、ECS、EKS 執行的應用程式、on-premises 工作負載、第三方 SaaS 整合——IAM role 才是正確答案。

IAM role——短期有效、可稽核、爆炸半徑受限

IAM role 有一個信任政策（誰可以承擔它）和以身份為基礎的政策（承擔後能做什麼）。任何信任政策允許的人都可以呼叫 AWS STS 取得暫時憑證（access key、secret key 和 session token），並在可設定的時長後到期。Role 涵蓋四大主要使用案例：

• 跨帳號存取——帳號 B 中的 role 信任帳號 A 中的 principal。
• 服務 role——Lambda 執行 role、EC2 instance profile、ECS task role、EKS pod identity，AWS 服務代表工作負載承擔一個 role。
• 聯合——SAML 2.0 IdP（AssumeRoleWithSAML）或 OIDC IdP（AssumeRoleWithWebIdentity）用外部身份斷言換取 AWS 憑證。
• IAM Identity Center permission set——在底層，每個 permission set 在每個指派的帳號中以 AWSReservedSSO_* 前綴的 IAM role 形式實體化。

信任政策的精確度

Role 的信任政策是安全模型的一半。鬆散的信任政策是考試和面試最愛考的，也是 SCS-C02 的重點。三個常見陷阱：

• Principal: "*" 沒有條件——任何 AWS 帳號中的任何人都可以承擔這個 role。務必將範圍限縮至特定的 principal ARN、帳號 ID，或使用服務 principal。
• 第三方 SaaS 整合缺少 sts:ExternalId——沒有 external ID，第三方 SaaS 就成為「confused deputy」，SaaS 的其他租戶可能利用它來存取你的資源。ExternalId 必須是每個租戶唯一的、不可猜測的字串。
• 鏈式 assume-role 情境缺少 aws:SourceIdentity 強制執行——在鏈式 role 的信任政策中沒有 sts:SetSourceIdentity，就會在 CloudTrail 中喪失對原始 principal 的歸因追蹤。

AWS STS 深度解析——AssumeRole、AssumeRoleWithSAML、AssumeRoleWithWebIdentity

AWS Security Token Service（STS）是 AWS 中所有短期憑證背後的 API。SCS-C02 期望你對三個主要 API 以及一些輔助 API 能夠熟練運用。

AssumeRole——萬用主力

sts:AssumeRole 由一個 AWS principal（IAM user、另一個 role 或 AWS 服務）呼叫，以承擔目標 IAM role。輸入包括目標 role ARN、session name（記錄到 CloudTrail；選一個能識別人員或任務的名稱）、可選的時長（預設 1 小時，最大值由 role 的 MaxSessionDuration 決定，可設定 1-12 小時）、可選的 session tag（用於 ABAC）、可選的傳遞 tag key（用於 role chaining）、以及若信任政策要求時的可選 ExternalId。

輸出是一個 AccessKeyId（ASIA... 前綴表示暫時金鑰）、SecretAccessKey、SessionToken（每次 API 呼叫都必須隨 access key 一併發送）和到期時間戳記。

AssumeRoleWithSAML——企業員工 SAML 2.0 聯合

sts:AssumeRoleWithSAML 由一個匿名呼叫者（還沒有 AWS 憑證——這正是聯合的重點）呼叫，提供一個由 SAML IdP 簽署的 base64 編碼 SAML 2.0 response，該 IdP 的 metadata 已在目標 AWS 帳號中登錄為 samlProvider。SAML response 必須包含對應 SAML 斷言角色和 SAML provider ARN 的屬性陳述，以及不超過 role 的 MaxSessionDuration 的 session 時長。

這個 API 是原始「SAML 到 IAM」聯合使用的——通常是在 IAM Identity Center 出現之前設定的。2026 年大部分企業員工身份已遷移至 IAM Identity Center，後者在底層仍使用此基礎 API，但以 permission set 的形式將其隱藏起來。

AssumeRoleWithWebIdentity——OIDC 聯合

sts:AssumeRoleWithWebIdentity 由匿名呼叫者呼叫，提供由 OIDC IdP 簽署的 OIDC ID token，該 IdP 的 issuer URL 已在 AWS 帳號中登錄為 OIDC provider。IdP 可以是公共的（Google、Apple、Facebook、Login with Amazon）、企業的（GitHub Actions、GitLab CI、CircleCI 用於 CI/CD 聯合），也可以是 Cognito user pool 或任何符合標準的 OIDC token 發行者。

這是以下場景背後的 API：

• 透過 Cognito identity pool 的行動和網頁應用程式登入。
• GitHub Actions、GitLab pipeline 等的 CI/CD 短期憑證。
• EKS 服務帳號 IAM role（IRSA）——kubelet 將 Kubernetes 服務帳號 JWT 換取 AWS 憑證。
• EKS Pod Identity——IRSA 更新、更簡化的版本。

Session 時長限制與 role chaining

每個 role 的最大 session 時長透過 MaxSessionDuration 設定（1-12 小時；預設 1 小時）。SAML 聯合時，SAML response 可以透過 SessionDuration 屬性請求不超過該上限的時長。OIDC 聯合時，時長在 API 呼叫中請求。

Role chaining 是指一個 role 的 session 呼叫 sts:AssumeRole 以承擔第二個 role。AWS 對鏈式 session 強制施加 1 小時的硬性上限，無論任何一個 role 的 MaxSessionDuration 設定為何。這是 SCS-C02 的高頻陷阱——題目描述一個長時間運行的批次作業，因為從一個 role 鏈接到另一個 role 而在 1 小時後失敗。

Source identity 保存

sts:SourceIdentity 是跨 role chain 和服務間呼叫保存原始人員或 principal 歸因的現代做法。下游 role 的信任政策可以要求 sts:SetSourceIdentity，CloudTrail 就會在每個事件中記錄 sourceIdentity。沒有它，一長串的 assume-role 呼叫就會模糊掉誰真正觸發了那個動作。

SAML 2.0 vs OIDC 聯合——各自的適用場景

企業員工聯合到 AWS IAM 使用兩種協定之一。SCS-C02 期望你選對。

SAML 2.0 聯合

SAML 是較舊的、基於 XML 的、使用瀏覽器重新導向的協定，被大多數企業 IdP 使用（Okta、Microsoft Entra ID、ADFS、PingFederate、Ping Identity、OneLogin）。IdP 用私鑰簽署 SAML response；AWS 用 SAML provider 設定中登錄的公鑰憑證驗證簽章。SAML 聯合自然與 IAM Identity Center 企業 SSO 配對，也與舊式的每帳號 AssumeRoleWithSAML 模式配對。

以下情況使用 SAML 聯合：

• IdP 是為 SAML 設定的傳統企業 SSO 產品。
• 使用案例是互動式企業員工登入 AWS 管理主控台。
• 你需要根據 SAML 屬性（群組成員、部門等）進行精細的 role 對應。

OIDC 聯合

OIDC（OpenID Connect）是建立在 OAuth 2.0 之上的現代、基於 JSON 的、對 REST 友善的協定。IdP 發行簽署的 JWT（ID token）；AWS 對 IdP 的 JWKS endpoint 驗證它。以下情況使用 OIDC：

• 使用案例是非互動式的——CI/CD pipeline、Kubernetes pod、呼叫 AWS API 的伺服器工作負載。
• IdP 原生發行 JWT（GitHub Actions、GitLab、EKS、Cognito user pool 作為 IdP）。
• 你需要在 role 信任政策中使用精細的 subject claim 條件（例如，只允許特定 GitHub repo 的 main branch 承擔這個 role）。

OIDC 信任政策的條件鍵

現代 OIDC 信任政策使用基於 claim 的條件，嚴格限縮誰可以承擔這個 role：

{
  "Effect": "Allow",
  "Principal": {
    "Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com"
  },
  "Action": "sts:AssumeRoleWithWebIdentity",
  "Condition": {
    "StringEquals": {
      "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
    },
    "StringLike": {
      "token.actions.githubusercontent.com:sub": "repo:my-org/my-repo:ref:refs/heads/main"
    }
  }
}

沒有 sub 條件，任何 GitHub Actions 工作流程（任何 repo）都可以承擔這個 role——等同於對整個公開網際網路開放的提權漏洞。

IAM Identity Center 企業身份驗證

IAM Identity Center（2022 年 7 月從 AWS Single Sign-On 改名）是建立在 AWS Organizations 之上的 AWS 原生企業 SSO 服務。它是 SCS-C02「跨多個 AWS 帳號的人員身份驗證」的預設答案。

身份來源

IAM Identity Center 支援三種身份來源：

• 內建目錄——IAM Identity Center 自行儲存使用者和群組；適合沒有既有 IdP 的小型團隊。
• Active Directory 整合——AWS Managed Microsoft AD 或 AD Connector 連接地端 AD；原生 AD 群組可見性。
• 外部 SAML 2.0 IdP——Okta、Microsoft Entra ID（Azure AD）、Google Workspace、JumpCloud、Ping；SCIM 2.0 自動佈建同步使用者和群組。

對 SCS-C02 而言，任何「現代企業員工、既有企業 IdP」情境的預設答案，是外部 SAML IdP 加 SCIM 自動佈建；內建目錄僅保留給極小型團隊或氣隙（air-gapped）環境。

Permission set 與實體化 role

Permission set 是一個模板，參照 AWS 受管政策、客戶受管政策、行內政策、可選的 permissions boundary 和 session 時長（1 到 12 小時）。指派給 AWS 帳號時，IAM Identity Center 在該帳號內將 permission set 實體化為名稱格式為 AWSReservedSSO_<permission-set-name>_<random-suffix> 的 IAM role。這個實體化 role 的信任政策只信任 IAM Identity Center 服務 principal——IAM user 無法直接 AssumeRole。

IAM Identity Center 中的 MFA

當 IAM Identity Center 使用內建目錄或 AD 驗證時，MFA 在 IAM Identity Center 內部設定：選擇永遠要求、情境感知（當來源 IP、瀏覽器或裝置是新的時才要求 MFA），或從不（不建議）。支援的驗證器包括安全金鑰（FIDO2 / WebAuthn / Passkey）、虛擬驗證器 App（TOTP）和平台內建驗證器（Touch ID、Face ID、Windows Hello）。

當 IAM Identity Center 聯合到外部 SAML IdP 時，MFA 在 IdP 端強制執行（Okta MFA、Entra ID Conditional Access、Google 兩步驟驗證）。IAM Identity Center 信任 IdP 的身份驗證斷言，不再重新提示。安全工程師的工作是確保 IdP 的 MFA 政策嚴格——例如，Entra ID 的 Conditional Access 要求所有登入 IAM Identity Center 應用程式的行為都必須使用抗釣魚 MFA。

Amazon Cognito——客戶身份、User Pool 與 Identity Pool

IAM Identity Center 是給員工用的，Amazon Cognito 是給你應用程式的客戶用的。SCS-C02 大量考 Cognito，因為安全工程師經常被要求為面向客戶的行動和網頁應用程式設計身份驗證。

User pool——客戶目錄

Cognito user pool 是你應用程式的完全受管使用者目錄和身份驗證服務。它處理註冊、登入、密碼重設、電子信箱/SMS 驗證、MFA、帳號復原，以及聯合登入（user pool 本身可以作為 OIDC 服務提供者，委派給 Google 或 Apple 等社群 IdP，或企業 SAML IdP）。成功登入後，user pool 發行三個 JWT：

• ID token——關於使用者的 claim（sub、email、自訂屬性）；由應用程式消費以顯示個人資料。
• Access token——短期授權 token；隨 API 呼叫發送到你的應用程式或 API Gateway。
• Refresh token——長效；用於取得新的 ID 和 access token 而不再次提示使用者。

SCS-C02 測試的 user pool 功能：

• MFA 強制執行——可選、必要或自適應（基於風險）。支援 SMS、TOTP 驗證器 App 和電子信箱 OTP（較新）。注意：SMS MFA 容易受到 SIM 卡劫持；高保障應用程式使用 TOTP 或 WebAuthn（Cognito user pool 已新增 Passkey/WebAuthn 支援）。
• 進階安全功能（ASF）——付費方案，新增自適應身份驗證（對登入嘗試進行風險評分、封鎖可疑 IP、風險升高時要求 MFA）、洩露憑證偵測（對照洩露密碼清單檢查）和帳號接管防護。
• Lambda triggers——Pre Sign-up、Pre Authentication、Post Authentication、Pre Token Generation、Custom Message、Custom Authentication Challenge——讓你注入自訂邏輯、自訂 claim 或多步驟身份驗證流程。
• App clients——定義哪些客戶端（網頁應用程式、行動應用程式、機器對機器）可以呼叫 user pool，並設定允許的 OAuth flow（authorization code grant、implicit、client credentials）和 scope。

Identity pool——為應用程式使用者提供聯合 AWS 憑證

Cognito identity pool（舊稱「federated identities」）是與 user pool 完全分開的服務，儘管共用品牌名稱。它只做一件事：將一個已驗證的身份（來自 user pool、社群 IdP、SAML IdP 或開發者驗證的身份）換取短期 AWS STS 憑證，供行動或網頁應用程式直接呼叫 AWS 服務（S3 GetObject、DynamoDB Query 等）。

底層使用 AssumeRoleWithWebIdentity。Identity pool 設定包含：

• 一或多個受信任來驗證使用者的身份 provider。
• 透過受信任 IdP 登入的使用者所承擔的已驗證 IAM role。
• 可選的訪客使用者承擔的未驗證 IAM role（謹慎使用；許多 SCS-C02 情境將未驗證存取標記為錯誤設定）。
• Role 對應——根據使用者 claim 選擇特定 IAM role 的規則（例如「cognito:groups 包含 premium 的使用者取得 premium role」）。

何時結合 user pool + identity pool

典型模式：客戶透過 user pool 登入你的應用程式（處理密碼、MFA、聯合到 Google）。應用程式收到 ID 和 access token，呼叫 user pool 的個人資料端點或你的應用程式 API；如果應用程式需要從裝置直接呼叫 AWS 服務（上傳到 S3、查詢 DynamoDB），就把 user pool 的 ID token 傳遞給 identity pool，取得短期 AWS STS 憑證，再直接呼叫 AWS API。

Cognito vs IAM Identity Center——範圍邊界

這兩個服務在正確使用下沒有重疊：

• IAM Identity Center——你的員工登入 AWS 工具（主控台、CLI、與 AWS 整合的 SaaS）。
• Cognito user pool + identity pool——你的客戶登入你在 AWS 上建立的應用程式。

SCS-C02 干擾選項：「使用 IAM Identity Center 來驗證我們 SaaS 應用程式的客戶」。錯誤——IAM Identity Center 只限企業員工，並非設計用於客戶規模的自助服務註冊。正確答案是 Cognito user pool。

MFA 強制執行模式——aws:MultiFactorAuthPresent、SCP、硬體 vs 虛擬 vs Passkey

MFA 是 SCS-C02 上效益最高的身份驗證控制。考試從三個層面測試：設定 MFA、透過政策強制執行 MFA，以及選擇正確的 MFA 因子類型。

設定 MFA

• IAM user——指派虛擬 MFA（TOTP）、硬體 MFA（YubiKey、Gemalto）或 FIDO2 安全金鑰。Root user 支援全部三種加 Passkey。
• IAM Identity Center 內建目錄——Passkey、安全金鑰、TOTP、平台內建驗證器。
• 外部 IdP 聯合——MFA 在 IdP 端強制執行，而非在 AWS 端。聯合 session 繼承 IdP 的 MFA 斷言。
• Cognito user pool——SMS、TOTP 驗證器 App、WebAuthn / Passkey，以及透過進階安全功能的可選自適應（基於風險）MFA。

透過 IAM 政策強制執行 MFA——aws:MultiFactorAuthPresent

設定本身不強制執行 MFA——使用者可以已登錄 MFA 卻仍在沒有 MFA 的情況下呼叫 API（例如，使用長期 access key）。強制執行需在 IAM 政策中使用 aws:MultiFactorAuthPresent 條件鍵：

{
  "Sid": "DenySensitiveActionsWithoutMFA",
  "Effect": "Deny",
  "Action": [
    "iam:DeleteVirtualMFADevice",
    "kms:ScheduleKeyDeletion",
    "s3:DeleteBucket"
  ],
  "Resource": "*",
  "Condition": {
    "BoolIfExists": {
      "aws:MultiFactorAuthPresent": "false"
    }
  }
}

BoolIfExists 運算子至關重要。使用 Bool 時，沒有 MFA context 的請求（例如服務連結 role 呼叫或服務 principal 呼叫）會被錯誤評估為「MFA 不存在」。BoolIfExists 只在鍵存在且為 false 時才回傳 false；當鍵不存在（服務對服務呼叫）時，條件被視為不符合，所以拒絕不會觸發。這避免了破壞合法在沒有 MFA 情況下運作的 AWS 服務。

透過 SCP 強制執行 MFA

附加到 AWS Organizations 中 OU 或帳號的服務控制政策（SCP），可以在組織層級強制執行最敏感 API 的 MFA：

{
  "Sid": "DenyDestructiveActionsWithoutMFA",
  "Effect": "Deny",
  "NotAction": [
    "iam:CreateVirtualMFADevice",
    "iam:EnableMFADevice",
    "iam:GetUser",
    "iam:ListMFADevices",
    "iam:ListVirtualMFADevices",
    "iam:ResyncMFADevice",
    "sts:GetSessionToken"
  ],
  "Resource": "*",
  "Condition": {
    "BoolIfExists": {
      "aws:MultiFactorAuthPresent": "false"
    }
  }
}

NotAction 的豁免列表不可缺少——沒有它，政策會拒絕使用者首次登錄 MFA 所需的那些 API，讓新使用者陷入無法登錄的僵局。

選擇 MFA 因子類型——抗釣魚性是關鍵維度

對於每個 AWS 帳號的 root user，必須使用硬體 FIDO2 token（YubiKey、Titan）或 Passkey。對於 IAM Identity Center 高權限 permission set，要求 IdP 強制執行抗釣魚 MFA。對於 Cognito user pool 客戶，提供 TOTP 或 Passkey 作為 SMS 的替代選項，並使用進階安全功能偵測高風險登入。

身份驗證排查——CloudTrail、IAM Access Advisor、IAM Policy Simulator

當登入失敗時，安全工程師就是那個值班的人。SCS-C02 深入測試排查工具箱。

CloudTrail 登入事件

CloudTrail 記錄管理事件（包含 STS 的 API 呼叫）以及一種特殊的 AWS 主控台登入事件（事件來源 signin.amazonaws.com）。診斷失敗身份驗證的關鍵欄位：

• eventName——ConsoleLogin、AssumeRole、AssumeRoleWithSAML、AssumeRoleWithWebIdentity、GetSessionToken、ExitRole。
• responseElements.ConsoleLogin——Success 或 Failure。
• errorCode 和 errorMessage——失敗時，code 會說明具體失敗原因（Failed authentication、InvalidClientTokenId、AccessDenied、TokenRefreshRequired）。
• additionalEventData.MFAUsed——ConsoleLogin 的 Yes 或 No。
• userIdentity——type（IAMUser、AssumedRole、AWSAccount、FederatedUser）、principalId、ARN，以及（聯合呼叫）包含 mfaAuthenticated 的 sessionContext.attributes。
• sourceIPAddress——登入來源 IP；對照核准的企業 IP 範圍或 VPN 出口 IP 交叉比對。

IAM Identity Center 登入事件，查看事件來源 sso.amazonaws.com 和 sso-directory.amazonaws.com。Cognito 事件，查看 cognito-idp.amazonaws.com（user pool）和 cognito-identity.amazonaws.com（identity pool）。

IAM Access Advisor——最後使用分析

IAM Access Advisor 顯示 IAM user、群組或 role 最後一次使用其有權限呼叫的每個 AWS 服務的時間。用於身份驗證排查和清理：

• 偵測休眠 principal——IAM user 超過 90 天沒有服務活動，是停用的候選者。
• 調整 permission set 規模——對於 IAM Identity Center permission set 的實體化 role，Access Advisor 揭示哪些服務從未被碰過，表明附加的 AWS 受管政策範圍過廣。
• 識別廢棄的 role——因專案建立後再也未使用的聯合 role。

組織層級的 Access Advisor 涵蓋 SCP，讓你看到某個服務最後一次被 OU 中任何人使用的時間——是調整 SCP 規模的依據。

IAM Policy Simulator——假設情境測試

IAM Policy Simulator 評估一個 principal 假設性的請求是否會被允許或拒絕，而不用真的發出呼叫。輸入：principal ARN（user 或 role）、動作、資源、可選的 context key（包括 aws:MultiFactorAuthPresent、aws:SourceIp、session tag）。輸出：Allow / Deny / Implicit Deny，以及驅動結果的具體陳述。

當使用者回報「我無法存取 S3 bucket，但我認為我應該可以」時：

1. 用使用者的 ARN 開啟 Policy Simulator。
2. 輸入動作（s3:GetObject）和資源（bucket ARN）。
3. 設定符合使用者實際 session 的 context key——特別是 aws:MultiFactorAuthPresent、來源 IP，以及聯合的任何 session tag。
4. 執行模擬並檢查哪個陳述驅動了結果。

Policy Simulator 評估以身份為基礎的政策、以資源為基礎的政策、permissions boundary 和 SCP。限制：它不評估在 AssumeRole 時傳入的 session policy，也不涵蓋每個服務的以資源為基礎的政策（只涵蓋已知的——S3、KMS、Lambda、SNS、SQS）。

將排查工具箱整合應用

典型的 SCS-C02 情境：「一位使用者回報，在登錄新的 MFA 裝置後無法登入 AWS 管理主控台」。診斷流程：

1. CloudTrail：過濾 signin.amazonaws.com，eventName ConsoleLogin，搭配使用者的 ARN。檢查 errorMessage——常見值包括 Failed authentication（密碼錯誤）、MFA required（使用者未提供 MFA）、MFA invalid（驗證碼錯誤或 TOTP 時鐘不同步）。
2. 若與 MFA 相關，檢查使用者的 MFA 裝置清單（aws iam list-mfa-devices），與使用者實際提供的進行比對。新登錄的虛擬 MFA 裝置需要時鐘同步；硬體 token 需要正確的序號登錄。
3. 若失敗是登入後的 AccessDenied（權限問題，非身份驗證問題），轉向 IAM Policy Simulator 找出拒絕的陳述。
4. 若使用者的 IAM principal 看起來正確，但他們說「我對任何東西都沒有權限」，檢查 IAM Access Advisor 確認他們預期使用的服務是否曾在其 ARN 下被存取過。

身份驗證架構模式——端到端範例

模式一：企業工程師存取 50 個 AWS 帳號

身份來源：Microsoft Entra ID，搭配要求抗釣魚 MFA 的 Conditional Access。聯合：Entra ID 透過 SAML 2.0 聯合到 AWS IAM Identity Center 作為身份來源。佈建：Entra ID 的 SCIM 2.0 同步使用者和群組（工程師、管理員、稽核員）。Permission set：以工作職能為基礎（DataEngineer、NetworkAdmin、ReadOnlyAuditor），工程師 session 時長 4 小時、管理員 permission set 1 小時，以客戶受管政策處理每帳號差異。MFA 強制執行：在 Entra ID 透過 Conditional Access；AWS 端在 SCP 中使用 aws:MultiFactorAuthPresent 拒絕破壞性動作。稽核：全組織 CloudTrail 軌跡到中央 S3 bucket；Athena 查詢用於隨機稽核；每季 Access Advisor 審查。

模式二：帶有客戶登入的行動應用程式

身份來源：Cognito user pool，搭配 WebAuthn / Passkey MFA、用於基於風險身份驗證的進階安全功能，以及用於自訂 claim 的 Lambda trigger。聯合：可選的社群登入，透過 Google 和 Apple 作為 user pool IdP。從裝置存取 AWS：Cognito identity pool 透過 AssumeRoleWithWebIdentity 將 user pool ID token 換取 STS 憑證；承擔的 IAM role 的 S3 政策使用 ${cognito-identity.amazonaws.com:sub} 將每位使用者限縮在自己的 bucket 前綴。稽核：CloudTrail 擷取 cognito-idp.amazonaws.com 和 cognito-identity.amazonaws.com 事件；user pool 的 CloudWatch Logs 匯出追蹤登入成功/失敗指標。

模式三：GitHub Actions 部署到 AWS

身份來源：GitHub Actions OIDC issuer（token.actions.githubusercontent.com），已在 AWS 帳號中登錄為 OIDC provider。聯合：工作流程呼叫 AssumeRoleWithWebIdentity，提供 GitHub 發行的 OIDC JWT。信任政策條件：透過 token.actions.githubusercontent.com:sub claim 限縮到特定 repo 和 branch——GitHub 機密中沒有長期 IAM access key。Session 時長：1 小時，每次 pipeline 執行時刷新。稽核：CloudTrail AssumeRoleWithWebIdentity 事件，userIdentity.principalId 顯示 OIDC subject；與 GitHub workflow run ID 交叉比對。

模式四：On-premises 伺服器呼叫 AWS API

身份來源：你的私有 CA 向地端伺服器發行 X.509 憑證。聯合：AWS IAM Roles Anywhere，私有 CA 登錄為 Trust Anchor；伺服器的憑證透過 mutual TLS 呈現給 IAM Roles Anywhere endpoint，換取透過 CreateSession 取得的短期憑證。稽核：CloudTrail 記錄 rolesanywhere.amazonaws.com 事件；憑證序號與地端資產清單交叉比對。

身份驗證關鍵數字與限制

常見考試陷阱——SCS-C02 身份驗證

陷阱一：工作負載使用帶有長期 access key 的 IAM user

干擾選項：「建立 IAM user，產生 access key，儲存在 EC2 user data 中」。正確答案：EC2 instance profile 自動承擔 role；不需要靜態憑證。

陷阱二：aws:MultiFactorAuthPresent 使用 Bool 而非 BoolIfExists

帶有 Bool: false 的拒絕政策會阻斷合法的非人工呼叫者。務必使用 BoolIfExists: false，只在 MFA 應存在的 context 中明確不存在時才拒絕。

陷阱三：Role chaining 觸及 1 小時上限

一個 4 小時的批次作業如果鏈式 role 會在第 1 小時失敗。修正：避免鏈接（直接承擔下游 role）或每小時刷新憑證。

陷阱四：Cognito user pool vs identity pool 混淆

User pool 驗證客戶並發行 JWT。Identity pool 將 JWT 換取 AWS STS 憑證。它們是分開的服務，通常一起使用。SCS-C02 干擾選項會互換兩者——仔細閱讀。

陷阱五：SMS MFA 作為高權限帳號的主要因子

SMS 容易受到 SIM 卡劫持。對於 root user 和高權限 permission set，必須使用 FIDO2 / Passkey。

陷阱六：OIDC 信任政策沒有 sub claim 條件

沒有 sub 條件的 GitHub Actions OIDC role 信任政策，允許網際網路上任何 GitHub repo 承擔這個 role。務必限縮到特定 repo 和 branch。

陷阱七：SAML response 重放攻擊防護

SAML response 必須包含 NotOnOrAfter 時間戳記和唯一的 assertion ID。沒有這些，被攔截的 response 就可能被重放。AWS 自動拒絕超出有效視窗的 response——但 IdP 必須正確發行它們。

陷阱八：Cognito identity pool 未驗證 role 擁有廣泛權限

給未驗證 identity pool role s3:* 存取一個 bucket，等於網際網路上的任何人都可以呼叫該 bucket 的 AWS API。要麼停用未驗證存取，要麼將其 role 限縮到嚴格定義的唯讀資源集。

陷阱九：第三方 SaaS role 缺少 External ID

沒有信任政策中的 sts:ExternalId，第三方 SaaS 就成為 confused deputy。務必要求每個租戶提供唯一的 ExternalId。

陷阱十：MFA 已設定但未強制執行

使用者可以已登錄 MFA 卻仍在沒有 MFA 的情況下呼叫 API（長期 access key，沒有 MFA context）。登錄是設定；強制執行需要在 IAM 政策或 SCP 中使用 aws:MultiFactorAuthPresent 條件。

陷阱十一：編輯 AWSReservedSSO_* IAM role

這些實體化 role 由 IAM Identity Center 管理；手動編輯會在下次協調時被還原。請修改 permission set，而不是 role。

陷阱十二：Cognito access token 用來授權 AWS 服務呼叫

Cognito user pool access token 是給你應用程式的 API 用的，不是給 AWS 服務 API 用的。直接呼叫 AWS API 需要從 Cognito identity pool 換取的 STS 憑證。

FAQ——SCS-C02 AWS 身份驗證

Q1：我應該什麼時候用 IAM user，什麼時候用 IAM role？

2026 年 SCS-C02 的答案，預設使用 IAM role。IAM user 的合法使用場景很窄：AWS Organizations 管理帳號中的 break-glass 使用者（硬體 MFA 存放在密封信封中，每次登入都觸發 CloudTrail 警報）、真的無法使用聯合的遺留系統，以及少數仍需要靜態 AWS access key 的第三方 SaaS 整合（名單持續縮小——大多數已支援帶 ExternalId 的 sts:AssumeRole）。企業員工使用 IAM Identity Center；AWS 工作負載使用服務 role（Lambda 執行 role、EC2 instance profile、ECS task role、EKS pod identity）；CI/CD 使用 OIDC 聯合；on-premises 工作負載使用 IAM Roles Anywhere；應用程式客戶使用 Amazon Cognito。

Q2：如何正確強制執行 MFA 而不破壞服務連結 role？

使用 aws:MultiFactorAuthPresent 條件鍵搭配 BoolIfExists 運算子，而不是 Bool。BoolIfExists 對於像 AWS 服務 principal 或服務連結 role 這類合法在沒有 MFA 情況下運作的呼叫者，評估為「鍵不存在，條件不符合」，所以拒絕不會對它們觸發。在 OU 層級的 SCP 中應用拒絕，以組織範圍保護破壞性動作（KMS 金鑰刪除、IAM user 刪除、S3 bucket 刪除），在以身份為基礎的政策中進行範圍較小的強制執行。務必豁免使用者首次登錄 MFA 所需的 IAM API（iam:EnableMFADevice、iam:CreateVirtualMFADevice、sts:GetSessionToken、iam:ListMFADevices）——沒有豁免，未登錄的新使用者就無法完成登錄。

Q3：AssumeRole、AssumeRoleWithSAML 和 AssumeRoleWithWebIdentity 的差異是什麼？

AssumeRole 由 AWS principal（IAM user、另一個 role 或 AWS 服務）呼叫以承擔目標 IAM role；輸入包括 role ARN、session name 和可選的 ExternalId。AssumeRoleWithSAML 由匿名呼叫者呼叫，提供由 metadata 已在 IAM 中登錄為 SAML provider 的 IdP 簽署的 base64 SAML 2.0 response；用於企業員工瀏覽器導向聯合。AssumeRoleWithWebIdentity 由匿名呼叫者呼叫，提供由已登錄為 OIDC provider 的 IdP 簽署的 OIDC JWT；用於非互動式工作負載（透過 GitHub Actions 的 CI/CD pipeline、透過 IRSA 的 EKS 服務帳號、透過 Cognito identity pool 的行動應用程式）。三者都回傳短期的 ASIA... 憑證加到期時間戳記；role 的 MaxSessionDuration 限制存活時間，且 role chaining 被硬性限制在 1 小時，無論設定為何。

Q4：Cognito user pool 和 identity pool 有什麼差異？

User pool 是完全受管的客戶目錄和身份驗證服務，處理註冊、登入、密碼重設、MFA 和聯合登入（支援 OIDC 和 SAML IdP 作為上游 provider）。成功驗證後，user pool 發行 ID、access 和 refresh JWT，你的應用程式驗證並用來呼叫應用程式 API。Identity pool（儘管共用品牌名稱，但是分開的服務）接受一個已驗證的身份（來自 user pool、社群 IdP、SAML IdP 或開發者驗證的來源），並換取 AWS STS 短期憑證，讓行動或網頁應用程式可以直接呼叫 AWS 服務 API（S3、DynamoDB 等）。兩者通常一起使用：user pool 驗證，identity pool 聯合到 AWS。SCS-C02 干擾選項經常互換兩者——只有 user pool 可以驗證使用者；只有 identity pool 發行 AWS 憑證。

Q5：如何排查 IAM Identity Center 使用者的登入失敗？

從CloudTrail 開始，過濾事件來源 sso.amazonaws.com（以及身份來源在 sso-directory.amazonaws.com 的事件），加上若使用者到達 AWS 主控台聯合步驟時的 signin.amazonaws.com。errorMessage 欄位說明具體失敗原因：Failed authentication（IdP 端憑證錯誤）、MFA required（使用者未完成 MFA）、assertion expired（SAML response 時間戳記超出視窗）、principalNotFound（SCIM 尚未同步該使用者），或 accessDenied（使用者沒有被請求帳號的指派）。如果 IdP 是外部的，也要查 IdP 自己的稽核日誌，確認上游身份驗證結果。對於登入後的權限相關失敗（使用者成功登入但呼叫 API 時拿到 AccessDenied），轉向 IAM Policy Simulator，使用實體化的 AWSReservedSSO_* role ARN、請求的動作和資源，以及使用者預期的 session context（MFA 是否存在、來源 IP、session tag）。

Q6：如何在不使用長期 access key 的情況下，將 GitHub Actions 聯合到 AWS？

在 IAM 中將 GitHub Actions OIDC issuer（https://token.actions.githubusercontent.com）登錄為 OIDC provider。建立一個 IAM role，其信任政策將 OIDC provider 列為 Federated principal，動作 sts:AssumeRoleWithWebIdentity，並附加條件將 token.actions.githubusercontent.com:sub claim 限縮到特定 repo 和 branch——例如 production 部署用 repo:my-org/my-repo:ref:refs/heads/main，或環境範圍信任用 repo:my-org/my-repo:environment:production。GitHub Actions 工作流程使用官方的 aws-actions/configure-aws-credentials action 搭配 role-to-assume，它會呼叫 AssumeRoleWithWebIdentity 提供 GitHub 發行的 JWT，取得短期 ASIA... 憑證，並在剩餘的工作流程中使用它們。沒有 IAM user、沒有靜態 access key、沒有長期機密存在 GitHub 中。CloudTrail 以 GitHub 工作流程作為 userIdentity.principalId 記錄 AssumeRoleWithWebIdentity 事件。

Q7：如何在 AWS 強制執行抗釣魚 MFA？

抗釣魚 MFA 意味著 FIDO2 / WebAuthn / Passkey——憑證綁定到信賴方的來源 URL，無法被中繼到釣魚網站。對於每個 AWS 帳號的 root user，登錄硬體 FIDO2 token（YubiKey、Titan Security Key）或 Passkey；AWS 現在每個 root user 最多支援 8 個 MFA 裝置，登錄兩個作為備援。對於 IAM user，登錄 FIDO2 金鑰而非 TOTP。對於使用內建目錄的 IAM Identity Center，設定 MFA 要求安全金鑰（FIDO2 / Passkey），對高權限 permission set 停用 TOTP 和 SMS。對於使用外部 IdP 的 IAM Identity Center，由 IdP 強制執行 MFA——設定 Conditional Access（Entra ID）、驗證政策（Okta）或 session 控制（Google Workspace），要求 IAM Identity Center 應用程式的所有登入必須使用抗釣魚因子。對於 Cognito user pool，啟用 WebAuthn / Passkey 作為 MFA 選項，並使用進階安全功能在高風險登入時升級為 Passkey 必要。

Q8：CloudTrail 對 AssumeRole 事件顯示什麼？如何關聯它們？

AssumeRole、AssumeRoleWithSAML 和 AssumeRoleWithWebIdentity 全部被記錄為來自 sts.amazonaws.com 的管理事件。關鍵欄位：eventName（哪個 API）、userIdentity（呼叫 principal——跨帳號時是來源帳號的 principal，聯合時是沒有 IAM 身份的 awsAccount）、requestParameters.roleArn（被承擔的 role）、requestParameters.roleSessionName（你控制的標籤——選一個能識別人員或任務的）、responseElements.assumedRoleUser.assumedRoleId（承擔 role session 的唯一 ID）和 additionalEventData.MFAAuthenticated。承擔 session 後的後續 API 呼叫顯示 userIdentity.type=AssumedRole 和相同的 assumedRoleId，因此可以將每個動作追溯到原始登入。若 sts:SourceIdentity 已設定，原始 principal 的身份也會在每個下游事件中被記錄。

Q9：我應該什麼時候使用 IAM Roles Anywhere？

IAM Roles Anywhere 適用於需要短期 AWS 憑證而不使用長期 access key 的非 AWS 工作負載。使用場景是具有既有 PKI 基礎設施（私有 CA 向每個工作負載發行 X.509 憑證）的地端伺服器、建置代理或非 AWS 雲端工作負載。你在 IAM Roles Anywhere 中將私有 CA 的憑證登錄為 Trust Anchor，定義一個將 trust anchor + IAM role + session policy 對應的 Profile，工作負載透過 mutual TLS 向 IAM Roles Anywhere endpoint 提交憑證，換取相當於 AssumeRole 的憑證。CloudTrail 記錄 rolesanywhere.amazonaws.com 事件；憑證的 subject CN 出現在 session name 中。在 AWS 內部執行的工作負載，使用 instance profile 或 pod identity 即可。

Q10：為什麼 role chaining 被限制在 1 小時？如何解決？

當一個承擔的 role session 呼叫 AssumeRole 承擔另一個 role 時，AWS STS 強制將第二個 session 限制在 1 小時，無論任何一個 role 的 MaxSessionDuration 為何。這是一個有意為之的安全控制，防止透過反覆鏈接無限延伸。CloudTrail 事件顯示一個正常的 AssumeRole 呼叫，但回傳的憑證有 1 小時到期時間。解決方案：透過讓原始 principal 直接承擔下游 role 來避免鏈接（修改下游 role 的信任政策）；在長時間執行的作業中，在每個小時邊界前重新呼叫 AssumeRoleWithWebIdentity 或 AssumeRoleWithSAML 從原始聯合來源刷新憑證；或重構工作流程，讓長時間執行的步驟使用能自動取得新鮮憑證的服務 role（Lambda、ECS task、EC2 instance profile）。1 小時上限是 SCS-C02 上測試最頻繁的 STS 特性。

Q11：如何在 CloudTrail 中區分身份驗證失敗和授權失敗？

身份驗證失敗出現為沒有成功發行憑證的事件：signin.amazonaws.com 的 ConsoleLogin，responseElements.ConsoleLogin=Failure；或 STS 的 AssumeRoleWithSAML / AssumeRoleWithWebIdentity，設有 errorCode 但沒有 responseElements.credentials。授權失敗出現在身份驗證成功之後，作為目標服務上帶有 errorCode=AccessDenied 和描述政策結果的 errorMessage 的 API 事件。轉折點是使用者是否成功取得憑證。SCS-C02 情境有時會模糊地描述問題（「使用者無法存取 S3」）——你的工作是讀取 CloudTrail 片段，判斷哪種失敗發生，並選擇對應的診斷工具：身份驗證問題用 IdP 日誌和 IAM Identity Center 登入日誌；授權問題用 IAM Policy Simulator。

延伸閱讀

• AWS IAM User Guide
• IAM Roles
• STS Temporary Security Credentials
• STS AssumeRole API
• STS AssumeRoleWithSAML API
• STS AssumeRoleWithWebIdentity API
• Using MFA in AWS
• IAM Condition Keys
• IAM Identity Center User Guide
• Amazon Cognito Developer Guide
• Cognito User Pools
• Cognito Identity Pools
• IAM Access Advisor
• IAM Policy Simulator
• CloudTrail AWS Console Sign-in Events