IAM 身份與存取控制

IAM 身份驗證與存取控制是 AWS 用來決定誰能呼叫 AWS API、可以操作哪些資源，以及在什麼條件下才能操作的核心機制。SAA-C03 中的所有其他安全主題——VPC 安全性、KMS 加密、S3 資料保護、跨帳號架構——最終都歸結為一個 AWS IAM 評估結果：Allow 或 Deny。SAA-C03 考試指南的工作陳述 1.1「設計對 AWS 資源的安全存取」，大量倚重 IAM 身份驗證與存取控制，因為這是考試中最常被考生答錯的一大主題。若搞錯評估邏輯、搞錯跨帳號模式、搞錯基於身份與基於資源的政策之間的差異，就可能損失整個領域的分數。

在 SAA-C03 的深度要求下，這個主題不只是背名詞定義——「IAM 角色是暫時的，IAM 使用者是永久的」——而是關於如何設計存取控制。我應該把哪種政策類型附加到 S3 儲存貯體，哪種又附加到 EC2 執行個體設定檔？當 SCP 裡存在明確拒絕，而身份政策卻試圖允許時，到底會發生什麼事？Account A 的 Lambda 要如何以最小的安全 IAM 足跡，向 Account B 的 DynamoDB 資料表寫入資料？本指南將逐一拆解 IAM 身份驗證與存取控制的每個組成單元，搭配白話文類比、必背數字，以及 SAA-C03 最愛出的陷阱情境。

什麼是 IAM 身份驗證與存取控制，為何對 SAA-C03 如此重要

IAM 身份驗證與存取控制，是 AWS IAM 構件（使用者、群組、角色、政策、權限邊界、工作階段政策）與 AWS Organizations 構件（服務控制政策、資源控制政策）的組合，共同構成每個 AWS 服務請求的授權平面。IAM 是一項全球性的 AWS 服務（不限定區域），免費使用，而它的判斷——Allow 或 Deny——是每一個 API 呼叫在 AWS 觸及任何資源前必須通過的關卡。

SAA-C03 要求架構師能夠端對端地設計 IAM 身份驗證與存取控制。這意味著選擇正確的基本元件（IAM 使用者 vs IAM 角色 vs 聯合身份）、選擇正確的政策類型（基於身份 vs 基於資源 vs 工作階段政策）、在不破壞工作負載的前提下套用最小權限原則，以及排查為何看似正確的 IAM 政策仍回傳 AccessDenied。SAA-C03 考試指南在工作陳述 1.1 下，明確列出「政策評估邏輯」、「跨帳號存取模式」、「最小權限原則」為受測技能。

IAM 身份驗證與存取控制在 SAA-C03 中的位置

工作陳述 1.1 是 IAM 身份驗證與存取控制的主要考點，但同樣的知識也會出現在其他領域：領域 2 的高可用性題目預設你了解服務連結角色（service-linked roles）與 EC2 執行個體設定檔；領域 3 的分析情境（Lake Formation、Athena、Glue）會測試細粒度的 IAM 存取控制；領域 4 的成本情境有時也會測試最小權限 IAM 政策如何防止意外支出。只要在這裡徹底掌握 IAM，整份考試大約三分之一的題目難度都會隨之降低。

白話文解釋 — IAM 身份驗證與存取控制

SAA-C03 的術語，一旦對應到日常生活中的場景就容易多了。以下三個類比，涵蓋了考試測驗的所有主要 IAM 概念。

類比 1：辦公大樓的門禁系統

想像一棟企業辦公大樓。IAM 使用者就是員工識別證，上面印有本人照片——屬於特定個人、有效期長、只能進入被授權的區域。IAM 群組是部門門禁群組，針對某個職能設定一次，讓所有工程師的識別證自動繼承「可進入 3、4、5 號會議室」的權限。IAM 角色是訪客臨時證，放在前台——任何人（或任何 AWS 服務）都可以向警衛（AWS STS）借用，穿戴一段時間後歸還，不留下任何長期鑰匙。Root 使用者是持有主鑰匙的大樓業主——擁有更換所有門鎖的超級權力，這也正是你必須把主鑰匙鎖進保險箱（啟用 MFA、刪除存取金鑰）、只在不可取代的場合才動用它的原因。

MFA 是識別證讀卡機後方的第二道驗票閘門：即使識別證被盜，沒有實體憑證也無法通過第二道關卡。基於身份的政策是貼在識別證上的規則（此識別證可進入 3、4、5 號室）。基於資源的政策是貼在門上的規則（此門對工程部門的識別證開放，或對 Account B 發出的訪客臨時證開放）。**明確拒絕（explicit deny）**是那塊大紅色「禁止進入」警示牌——不論你的識別證寫了什麼，拒絕永遠優先。

類比 2：有監考官的開書考試

想像一場規則嚴格的認證考試。監考官就是 IAM——他們核對你的身份（驗證），然後查閱規則手冊（授權），確認你能做和不能做的事。規則手冊就是你的 IAM 政策。最小權限原則意謂手冊寫的是「你可以使用這三本參考書」，而非「你可以使用圖書館裡的所有書」——允許範圍愈小，座位遭到入侵時造成的損害就愈小。明確拒絕是監考官用紅筆批注的「不行」——即使允許清單裡說你可以翻開那本書，紅筆批注仍然凌駕一切。預設拒絕是頁首那條規則：若手冊從未提及某個動作，你就無法執行它。這就是 IAM 政策評估邏輯的核心記憶圖像：預設拒絕、允許取聯集、任何明確拒絕均獲勝。

類比 3：飯店前台與房卡

飯店可以完美地映射 IAM 的所有概念。Root 使用者是飯店業主——擁有無條件覆蓋所有規則的權力，是唯一能關閉飯店或更改租約名稱的人。前台服務員是 IAM——他們簽發房卡（IAM 使用者、IAM 角色），並設定特定的存取範圍（僅限 305 號房、僅限泳池、僅限健身房）。退房時即失效的房卡就是 IAM 角色——暫時的存取權，時間到自動作廢，就算遺忘帶走也不會造成長期風險。MFA 是辦理入住時的簽名加上掃描的身份證件——兩個因素共同證明你就是訂房人。飯店的門鎖也有自己的清單（「此門對婚宴賓客房卡開放」）——這就是附加在門上的資源型政策，會與你的房卡規則一併評估。

IAM 基本組成：使用者、群組、角色與政策

AWS IAM 有四個基本元件。SAA-C03 所有 IAM 身份驗證與存取控制題目都是以它們為基礎構建的，考試會獎勵那些清楚知道每個元件是什麼、不是什麼的架構師。

IAM 使用者

IAM 使用者是單一 AWS 帳號中的一個身份。它可以有主控台密碼（用於登入 AWS Management Console）、最多兩組有效存取金鑰（供 AWS CLI、SDK、PowerShell 使用——設計為兩組以便不中斷地輪換），以及選配的 MFA 裝置。IAM 使用者從設計上就是長期存在的，這正是現代 AWS IAM 最佳實踐要你遠離它的原因。每新增一個 IAM 使用者，就多了一組需要輪換的憑證、多了一個需要離職處理的人員、多了一把可能洩漏到 GitHub 的存取金鑰。

AWS 在 SAA-C03 時代的架構建議：盡量減少 IAM 使用者的數量，人員帳號優先使用 IAM Identity Center，服務帳號優先使用 IAM 角色。

IAM 群組

IAM 群組是一個便利的容器。你把 IAM 政策附加到群組，群組中的所有 IAM 使用者成員就會繼承這些政策。群組本身無法作為主體——你無法「以群組身份登入」，信任政策中不存在 GroupArn，群組也不能巢狀。它唯一的作用，是在你確實需要管理大量 IAM 使用者時，讓 IAM 政策的管理更具擴充性。

IAM 角色

IAM 角色是 SAA-C03 層級中 IAM 身份驗證與存取控制最重要的構件。角色有附加的政策，但沒有長期憑證。主體——AWS 服務（EC2、Lambda、ECS 任務）、同帳號的 IAM 使用者、其他 AWS 帳號的 IAM 使用者，或聯合身份——透過假設（assume）角色，AWS STS 就會簽發暫時安全憑證作為交換。這些憑證由存取金鑰 ID、私密存取金鑰及**工作階段權杖（session token）**組成，三者缺一不可，且均會自動過期。

以下情境應使用 IAM 角色，這是 IAM 身份驗證與存取控制的正確設計：

• 授予 Amazon EC2 執行個體透過**執行個體設定檔（instance profile）**存取 S3 的權限（憑證由 IMDS 自動輪換）。
• 讓 AWS Lambda 函數、ECS 任務或 EKS Pod 存取其他 AWS 服務（執行角色 / 任務角色 / IRSA）。
• 跨帳號存取——Account A 的使用者或服務透過 sts:AssumeRole 假設 Account B 的 IAM 角色。
• 身份聯合——SAML 2.0、OIDC 或 Web Identity；外部身份換取 IAM 角色工作階段。
• 服務連結角色（service-linked roles）——由 AWS 服務（Auto Scaling、Organizations、Trusted Advisor 等）建立，用來代表你管理資源的預定義角色。

IAM 政策（受管政策 vs 內嵌政策）

IAM 政策是一份 JSON 文件，包含 Version、一或多個 Statement，每個陳述式包含 Effect（Allow/Deny）、Action、Resource，以及選填的 Condition 與 Principal 區塊。政策的交付形式如下：

• AWS 受管政策（AWS-managed policy）——由 AWS 維護（如 AmazonS3ReadOnlyAccess、AmazonDynamoDBFullAccess）。適用於標準職務功能。
• 客戶受管政策（Customer-managed policy）——由你撰寫，可重複使用，並有版本控管（最多保留 5 個版本）。建議用在多個身份共享的客製化最小權限政策。
• 內嵌政策（Inline policy）——直接嵌入某一個 IAM 使用者、群組或角色中，與該身份共存亡。只在真的需要 1:1 綁定時使用（例如：一個只服務單一工作負載、且日後絕不能附加多餘政策的角色）。

基於身份的政策 vs 基於資源的政策 — 各自的適用時機

身份型政策與資源型政策的區別，是 SAA-C03 中最常被架構師輕忽的概念。許多跨帳號題目完全取決於對此的理解。

基於身份的政策

基於身份的政策（identity-based policy）附加在身份上——IAM 使用者、IAM 群組或 IAM 角色——用來說明「此身份可以對 Y 執行 X」。每當該身份發出請求時，IAM 就會評估這些政策。這是最常見的 IAM 政策形式。

基於資源的政策

基於資源的政策（resource-based policy）附加在資源上——S3 儲存貯體、Lambda 函數、SNS 主題、SQS 佇列、ECR 儲存庫、KMS 金鑰、API Gateway REST API、OpenSearch 網域、Secrets Manager 密鑰——用來說明「這些主體可以對此資源執行 X」。與基於身份的政策不同，資源型政策一定包含 Principal 元素，用來指定此政策適用的對象。

只有部分 AWS 服務支援資源型政策。以下是 SAA-C03 必須認識的清單：

• Amazon S3——儲存貯體政策，以及物件層級的 ACL（ACL 已大多被政策 + Block Public Access 取代而逐漸淘汰）。
• AWS KMS——金鑰政策（key policy），對每把 KMS 金鑰都是強制必要的，也是加密金鑰的主要存取控制機制。
• AWS Lambda——函數上的資源型政策，控制哪些帳號或服務可以呼叫它。
• Amazon SNS、Amazon SQS——主題與佇列政策，控制誰可以發布或消費。
• AWS Secrets Manager——個別密鑰上的資源型政策。
• Amazon ECR——容器映像的儲存庫政策。
• API Gateway——資源型政策，限制哪些 VPC 端點或來源 IP 可以呼叫 API。

為何跨帳號存取通常需要兩者並用

對於跨帳號的 IAM 身份驗證與存取控制，一般規則是：呼叫方帳號的基於身份的政策，以及資源所在帳號的基於資源的政策，兩者都必須允許該動作。Account A 的主體對 Account B 的儲存貯體呼叫 s3:GetObject，需要：

1. Account A 的基於身份的 IAM 政策，允許對該儲存貯體 ARN 執行 s3:GetObject。
2. Account B 的資源型儲存貯體政策，允許 Account A（或 Account A 中的某個主體）呼叫 s3:GetObject。

重要例外：當主體假設 Account B 的 IAM 角色時，通常不需要資源型政策，因為主體現在是在 Account B 內部行動。Account B 角色上的信任政策已經控制了誰可以假設它。

政策評估邏輯 — 明確拒絕永遠優先

這是 IAM 身份驗證與存取控制中考最多的演算法。把它背下來，整整一類 SAA-C03 情境題就變得輕而易舉。

評估流程

當請求抵達時，AWS 會收集該主體與該資源的所有適用政策。這個集合可能包含：

1. AWS Organizations SCP（服務控制政策）——在 OU/帳號層級設定的護欄。
2. AWS Organizations RCP（資源控制政策）——較新的護欄，限制資源型政策能授予什麼（針對支援的服務）。
3. 基於資源的政策——附加在目標資源上的政策。
4. 基於身份的政策——附加在呼叫主體上的政策。
5. 權限邊界（Permissions boundaries）——附加在主體上的上限政策（若有）。
6. 工作階段政策（Session policies）——在 AssumeRole 或 GetFederationToken 時傳入的內嵌政策。

整個集合的評估規則：

• 從**隱含拒絕（implicit deny）**開始（預設）。
• 任何適用政策中存在明確 Deny → 最終答案為 Deny，不再繼續。
• 否則，若至少有一個適用政策包含對該動作的明確 Allow，最終答案為 Allow。
• 若沒有任何政策包含明確 Allow，隱含拒絕成立，最終答案為 Deny。

在 AWS Organizations 情境中若有 SCP，SCP 也必須允許該動作；若 SCP 拒絕或未允許，任何基於身份的政策都無法使該動作成功。

圖解（文字版）

想像一串過濾器，請求只有在每個適用過濾器都通過以下條件時才會放行：「無明確拒絕，且在相關範圍內至少存在一個允許」：

• SCP 允許（或不存在 SCP）→ 通過
• 資源政策：無明確拒絕 → 通過
• 身份政策：無明確拒絕 → 通過
• 權限邊界：無明確拒絕，且動作在上限內 → 通過
• 工作階段政策（若存在）：無明確拒絕，且動作在上限內 → 通過
• 上述環節中某處存在明確 Allow → 最終 Allow

任何一個環節包含明確 Deny，或在必須包含 Allow 時（基於身份的政策 + 權限邊界 + 工作階段政策，若三者同時存在則均須允許）未包含，都會導致請求失敗。

實際範例

Account A 的開發者 IAM 使用者擁有 AmazonS3FullAccess。該使用者隸屬於一個 IAM 群組，該群組有一條內嵌政策：Deny s3:DeleteObject on bucket logs-critical。現在他對 logs-critical 中的物件呼叫 DeleteObject。

• 使用者上的 AWS 受管政策：Allow s3:*。
• 群組的內嵌政策：Deny s3:DeleteObject on logs-critical。
• 最終決定：Deny，因為明確拒絕覆蓋了允許。

現在換一個儲存貯體，對 logs-noncritical 呼叫 DeleteObject：

• 使用者上的 AWS 受管政策：Allow s3:*。
• 群組的內嵌政策：無符合項目（不同的儲存貯體）。
• 最終決定：Allow，因為不存在適用的拒絕，且存在允許。

IAM 角色 vs IAM 使用者 — SAA-C03 深度下的選擇指引

在 Cloud Practitioner 的深度，「角色 = 暫時，使用者 = 永久」就夠了。在 SAA-C03 的深度，你需要在設計情境中做出選擇。

選擇 IAM 角色的時機

• AWS 服務需要存取另一個 AWS 服務（EC2 → S3、Lambda → DynamoDB、ECS 任務 → SQS）。永遠使用服務原生角色模式：EC2 執行個體設定檔（instance profile）、Lambda 執行角色（execution role）、ECS 任務角色（task role）、EKS IRSA（IAM Roles for Service Accounts）。
• 一個 AWS 帳號中的工作負載需要存取另一個 AWS 帳號的資源。使用跨帳號角色假設（cross-account role assumption）。
• 企業員工透過 SAML 2.0 或 OIDC 身份提供者登入。使用**聯合（federation）**對應到 IAM 角色（直接對應或透過 IAM Identity Center）。
• 行動或 Web 應用程式需要為終端使用者提供短期 AWS 憑證。使用 Amazon Cognito 身份集區（identity pools） → IAM 角色。

只在以下情況選擇 IAM 使用者

• 舊有或第三方工具絕對無法假設角色。
• 內部部署腳本確實無法納入任何聯合方案。
• 即便如此，也必須啟用 MFA、設定嚴格的最小權限 IAM 政策、定期輪換存取金鑰，並考慮對內部部署工作負載使用 IAM Roles Anywhere（搭配 X.509 憑證）。

對照比較

透過角色假設與 AWS STS 進行跨帳號存取

跨帳號存取是 SAA-C03 上測驗最多的 IAM 身份驗證與存取控制情境。每份考題大約會出現兩到三種變體。

標準模式

假設 Account A（帳號 ID 111111111111）的 Lambda 函數需要讀取 Account B（帳號 ID 222222222222）的 S3 儲存貯體中的物件。

1. 在 Account B 建立 IAM 角色 CrossAccountS3Reader：
   • 信任政策（誰可以假設）：允許主體 arn:aws:iam::111111111111:root（或更精確的主體，例如 Lambda 執行角色 ARN）呼叫 sts:AssumeRole。
   • 權限政策（角色被假設後可以做什麼）：允許對該儲存貯體執行 s3:GetObject。
2. 在 Account A，Lambda 執行角色有一條基於身份的政策，允許對 Account B 的角色 ARN arn:aws:iam::222222222222:role/CrossAccountS3Reader 執行 sts:AssumeRole。
3. 執行時，Lambda 程式碼呼叫 sts:AssumeRole 並帶入目標角色 ARN，AWS STS 回傳短期憑證。Lambda 使用這些憑證呼叫 s3:GetObject。
4. 在 Account B 內部，請求現在以假設角色的身份發出，因此適用的是角色本身的基於身份的政策，不需要額外的儲存貯體政策。

sts:AssumeRole 必知要點

• 預設工作階段時長：1 小時。
• 角色的最長工作階段時長：1 – 12 小時（可在角色上設定）。
• External ID：信任政策要求的選填字串，用來防止「混淆代理人（confused deputy）」問題——當第三方 AWS 帳號假設你帳號中的角色時尤為重要。
• 要求 MFA：信任政策條件 aws:MultiFactorAuthPresent: true 可強制假設方提供 MFA 權杖。
• 工作階段政策：你可以在 AssumeRole 時傳入一個內嵌 IAM 政策，進一步縮小該工作階段的有效權限——只能縮小，無法擴大。

其他值得了解的 STS API

• AssumeRoleWithSAML——用於 SAML 2.0 身份聯合（Microsoft Entra ID、ADFS、Okta）。
• AssumeRoleWithWebIdentity——用於 OIDC/Web Identity 聯合（Amazon Cognito 身份集區、Google、Facebook）。
• GetFederationToken——舊版 API，供不使用真實 IdP 而自行管理聯合使用者的代理應用程式使用。
• GetSessionToken——為 IAM 使用者回傳暫時憑證，通常用於滿足 CLI 存取的 MFA 要求。

混淆代理人問題與 External ID

假設一個第三方 SaaS 工具請你在 AWS 帳號中授予它一個 IAM 角色，以便監控你的資源。若沒有防護措施，同一家 SaaS 廠商的另一位客戶可能誘騙該工具使用你的角色。External ID 是信任政策在每次 AssumeRole 呼叫時要求的一個秘密字串；SaaS 廠商針對每位客戶傳入對應的 External ID，將假設行為綁定到特定的客戶關係。這是 SAA-C03 的經典情境題。

最小權限原則 — 受管政策、內嵌政策、邊界、工作階段

最小權限原則（least privilege）是 IAM 身份驗證與存取控制的基礎原則：只授予每個主體完成任務所需的最小權限，且只在必要的最短時間內有效。這是 AWS 引用最頻繁的最佳實踐，也貫穿 SAA-C03 的情境題。

從最小開始，按需擴展

每份客戶受管 IAM 政策，都應從針對特定資源 ARN 的最小 API 動作集合開始。避免從 Action: "*" 起步再逐步收緊。只有在 AWS 受管政策與職務功能高度吻合時才使用它；否則請自行撰寫客戶受管政策。

權限邊界

權限邊界（permissions boundary）是一項進階的 IAM 功能，可為 IAM 使用者或 IAM 角色附加第二份政策。這份政策不授予任何權限——它限制基於身份的政策最多能授予多少。有效權限是基於身份的政策與權限邊界的交集。

當團隊主管需要將建立 IAM 使用者/角色的能力委派給開發人員，但又要確保開發人員無法建立具有管理員權力的角色時，就會用到權限邊界。邊界強制執行「無論你授予什麼，都不能超過這個上限」。

工作階段政策

工作階段政策（session policy）是在假設角色時傳入的內嵌 IAM 政策（透過 sts:AssumeRole 或 GetFederationToken）。它只能縮小該特定工作階段的角色有效權限，無法擴大。適合用於將更短暫、較低權限的範圍交給子工作流程使用。

IAM Access Analyzer

當 SAA-C03 問到「如何找出過度授權的政策？」或「如何產生最小權限政策？」，你應該想到的工具就是 AWS IAM Access Analyzer。它有三大主要功能：

• 外部存取發現（External access findings）——持續掃描資源型政策（S3、KMS、Lambda、SQS、SNS、Secrets Manager 等），找出對信任區域外主體的授予。
• 未使用存取發現（Unused access findings）——找出未曾使用的 IAM 使用者/角色，以及政策中未被使用的特定權限。
• 從 CloudTrail 產生政策（Policy generation from CloudTrail）——觀察某身份的實際 API 活動，產生一份只包含實際用到動作的精煉 IAM 政策。

Root 帳號安全 — MFA、存取金鑰，以及只有 Root 能做的事

Root 使用者是 AWS 帳號最初的電子郵件地址型擁有者，對每個資源和每項帳單設定都有無條件、不受限制的存取權。正因為這份權力，Root 使用者同時也是帳號中最大的風險，也是 SAA-C03 的常見考題。

只有 Root 使用者才能執行的任務

• 變更 AWS 帳號的 Root 電子郵件地址或 Root 密碼。
• 變更 AWS 帳號名稱。
• 關閉 AWS 帳號。
• 變更或取消 AWS 支援方案。
• 在所有管理員 IAM 使用者均遭鎖定時，還原 IAM 權限。
• 在 AWS Marketplace 中註冊成為賣家。
• 啟用發票稅務設定及部分帳單配置。

Root 使用者最佳實踐

1. 立即為 Root 使用者啟用 MFA。 優先使用 Passkey 或硬體 MFA（FIDO2）；虛擬 MFA 亦可接受。
2. 刪除所有 Root 存取金鑰。 強烈不建議以程式化方式使用 Root；請改用 IAM 使用者或角色。
3. 使用強度高且唯一的密碼。
4. 只在一次性設定和 Root 限定任務時使用 Root。 日常管理請建立管理員 IAM 使用者，或建立具有 AdministratorAccess 的 IAM Identity Center 使用者。
5. 不要分享 Root 憑證。 每位管理員都應有自己的身份。

驗證方式：MFA 類型、存取金鑰、密碼政策

IAM 身份驗證與存取控制支援多種驗證因素。SAA-C03 要求你能夠區分它們。

主控台密碼 + 密碼政策

每個 IAM 使用者都可以選配主控台密碼。帳號層級的 IAM 密碼政策可強制執行最小長度、字元複雜度、輪換週期、防止重複使用，以及是否允許使用者自行變更密碼。密碼政策適用於帳號中所有 IAM 使用者，但不適用於 Root 使用者（Root 有其自身不可更改的最低要求）。

存取金鑰

存取金鑰是 AWS CLI、AWS SDK 和 AWS PowerShell 使用的長期憑證。每個 IAM 使用者最多可以同時擁有 2 組有效存取金鑰，以便在零停機的情況下輪換——先建立新金鑰、將工作負載切換過去，再刪除舊金鑰。程式化工作負載應盡可能使用 IAM 角色（EC2 執行個體設定檔、Lambda 執行角色、ECS 任務角色、內部部署使用 IAM Roles Anywhere）取代長期存取金鑰。

MFA — 虛擬、硬體與 Passkey

多因素驗證（MFA）在密碼之上增加第二個驗證因素。IAM 支援：

• 虛擬 MFA 裝置——驗證器應用程式（Google Authenticator、Authy、1Password、Duo），產生每隔數秒更新的 6 位數 TOTP 驗證碼。最便宜也最常見。
• 硬體 MFA 裝置——實體金鑰卡（Gemalto/SafeNet）或 FIDO2 安全金鑰（YubiKey）。密鑰無法從裝置中複製。
• Passkey / FIDO2 驗證器——iOS、Android、macOS、Windows Hello 及硬體安全金鑰。防釣魚攻擊，是 IAM 使用者與 Root 使用者最推薦的現代驗證因素。

MFA 是免費的——啟用 MFA 不需要額外的 AWS 費用。只有購買實體硬體權杖時才需要付費。

IAM 身份驗證與存取控制的必背數字

數字是 SAA-C03 的送分題，前提是你已經記熟。以下清單涵蓋考試常用的 IAM 數字陷阱。

常見考試陷阱 — IAM 身份驗證與存取控制

每份 SAA-C03 考題都可能出現其中幾個。在看選項之前就能認出陷阱模式，是答題的一半功夫。

陷阱 1：IAM 角色 vs IAM 使用者

任何描述「有 STS 暫時憑證的 IAM 使用者」或「有密碼和長期存取金鑰的 IAM 角色」的選項，都是干擾項。使用者 = 長期憑證，可選配密碼。角色 = 短期 STS 憑證（存取金鑰 + 私密存取金鑰 + 工作階段權杖），無密碼，無持久存取金鑰。

陷阱 2：明確拒絕 vs 無權限

情境說「使用者在某政策中有 s3:*，但仍無法刪除物件。為什麼？」可能的選項包括「政策設定錯誤」、「缺少儲存貯體政策」等。正確答案通常是某處存在明確拒絕——SCP 拒絕、儲存貯體政策拒絕、權限邊界拒絕，或群組政策拒絕。明確拒絕永遠勝過明確允許。

陷阱 3：跨帳號——角色建立在哪一側？

常見混淆：「Account A 需要讀取 Account B 的 S3，IAM 角色應建立在哪裡？」角色建立在 Account B（擁有資源的帳號）。Account A 獲得一條基於身份的政策，允許對 Account B 的角色 ARN 執行 sts:AssumeRole。Account B 角色上的信任政策允許 Account A 假設它。

陷阱 4：資源型政策 vs 基於身份的政策

若考題問到 KMS 金鑰（必須有金鑰政策）或以 S3 儲存貯體政策授予跨帳號存取，這是資源型政策題。若是問「此使用者一般來說可以做什麼」，這是基於身份的政策題。KMS 尤其嚴格：若金鑰政策未允許存取，任何 IAM 政策都無法授予它。

陷阱 5：IAM 不限定區域

任何描述「按區域建立 IAM 使用者」、「跨區域複製 IAM 政策」或「為 IAM 選擇一個區域」的選項都是錯的。IAM 是全球性服務。但 STS 有區域端點（以及一個舊版的全球端點）。建議優先使用區域性 STS 端點，以降低延遲並提高韌性。

陷阱 6：SCP 只限制，不授予

SCP 允許 s3:DeleteBucket，並不代表本身就授予了該權限——成員帳號的 IAM 政策仍需明確授予。反之，SCP 拒絕某個動作，則無論帳號內的任何 IAM 政策如何設定，該動作都會被封鎖。在 SAA-C03 中：當使用者「有管理員政策但仍無法執行 X」，SCP 是首要的懷疑對象。

陷阱 7：權限邊界不授予任何權限

權限邊界是上限，不是授予。一個有邊界但沒有基於身份的政策的主體，實際上沒有任何權限——邊界只限制基於身份的政策最多能授予多少。

陷阱 8：工作階段政策只能縮小

在 AssumeRole 時傳入工作階段政策，只能限制該工作階段的角色有效權限，無法在假設時擴大權限。

陷阱 9：信任政策是資源型政策

附加在 IAM 角色上的信任政策，技術上屬於資源型政策——角色本身是資源，信任政策指定哪些主體可以假設它。這一點很重要，因為修改信任政策就是變更跨帳號存取的方法。

陷阱 10：服務連結角色是特殊角色

服務連結角色（SLR）是 AWS 服務（Auto Scaling、Organizations、Trusted Advisor）為自身建立的預定義角色。它們與服務緊密綁定，通常在服務使用中時無法刪除，且擁有不應自行修改的預寫權限。若情境問到 Auto Scaling 自動管理 EC2，SLR 的答案就是「已為你自動設定好」。

IAM vs 資源型政策用於跨帳號 — 決策樹

以下是 SAA-C03 希望你內化的決策流程。

1. 工作負載是否跨越 AWS 帳號邊界？
   • 否 → 呼叫方的基於身份的政策就足夠了。
   • 是 → 繼續。
2. 目標資源是否屬於支援資源型政策的服務（S3、KMS、Lambda、SNS、SQS、Secrets Manager、ECR、API Gateway、OpenSearch）？
   • 是 → 有兩種方式可行。
     • 方案 A — 資源型政策：在目標資源上建立資源型政策，允許另一帳號的主體存取；呼叫方帳號同時需要基於身份的政策。無需角色假設。適合簡單、單向的跨帳號唯讀共享。
     • 方案 B — 跨帳號 IAM 角色：在目標帳號建立 IAM 角色，信任政策允許呼叫方。稽核紀錄更清晰、最小權限更精確，且在目標服務不支援資源型政策、或需要強制 MFA/ExternalId 時為必要選擇。
   • 否 → 只能使用方案 B（角色假設）。
3. 是否涉及第三方廠商？
   • 是 → 在信任政策中加入 External ID 以防止混淆代理人問題。
4. 跨帳號存取是否需要 MFA？
   • 是 → 在信任政策中加入 aws:MultiFactorAuthPresent: true 條件。

IAM 身份驗證與存取控制 vs VPC 與加密 — IAM 的邊界在哪裡

IAM 身份驗證與存取控制是防禦的其中一層。它決定 API 呼叫是否被允許。它不決定網路流量是否能到達資源（那是 VPC 安全群組、NACL 和端點的職責），也不決定靜態資料在遭竊後是否無法讀取（那是 KMS 加密和 S3 儲存貯體加密設定的職責）。

安全設計需要三層並用：IAM 身份驗證與存取控制用來授權 API 呼叫；VPC 構件用來限制網路路徑；加密搭配金鑰政策用來保護資料，即使其他層防線失守也能守住。SAA-C03 情境題通常會獎勵結合多層的答案——例如「最小權限 IAM 角色 + 帶有端點政策的 VPC 端點 + 限制解密的 SSE-KMS 金鑰政策」。

IAM Identity Center — 企業身份的進階選擇

雖然 IAM Identity Center（SSO）的深層機制屬於 multi-account-federation 主題，但你應該了解本主題的邊界：

• AWS IAM 是帳號內的全球原生元件，處理 IAM 使用者、IAM 角色、IAM 政策以及 STS 簽發的憑證。
• IAM Identity Center 建立在 AWS Organizations 之上，負責跨多個 AWS 帳號的企業身份聯合，並自動在每個目標帳號中將**權限集（permission sets）**實例化為 IAM 角色。

若 SAA-C03 問到透過 SAML/OIDC 讓員工跨多個帳號單一登入，答案是 IAM Identity Center。若問到授予 EC2 執行個體存取 S3 的權限，答案是以執行個體設定檔附加的 IAM 角色。這是兩種不同工具，解決不同的問題。

常見問題 — IAM 身份驗證與存取控制 Top 6

Q1：IAM 政策評估邏輯如何解決 Allow 和 Deny 之間的衝突？

IAM 身份驗證與存取控制的每次評估都從隱含拒絕開始，然後收集所有適用政策：SCP、資源型政策、基於身份的政策、權限邊界，以及工作階段政策。若任何適用政策對此動作在此資源上包含明確 Deny，最終答案就是 Deny。 若不存在明確 Deny，且至少一個適用政策包含明確 Allow（且所有必要範圍如權限邊界也允許），最終答案為 Allow。否則隱含拒絕成立。最重要的一點：明確 Deny 永遠覆蓋明確 Allow，無論 Deny 來自何處。

Q2：何時需要在基於身份的政策之外，額外設定資源型政策？

對於同帳號存取，幾乎所有 AWS 服務只需要呼叫方的基於身份的政策即可。對於跨帳號存取，你需要呼叫方帳號的基於身份的政策，以及目標帳號的資源型政策——除非使用角色假設模式，此時角色上的信任政策（本身就是一種資源型政策）就取代了對目標資源設定資源型政策的需求。有兩個 AWS 服務例外，資源型政策幾乎是必要的：AWS KMS（每把金鑰都有強制性的金鑰政策），以及來自跨帳號主體的 AWS Lambda 呼叫（函數上的資源型政策）。

Q3：讓 Account A 的 Lambda 向 Account B 的 S3 儲存貯體寫入資料，最乾淨的方式是什麼？

有兩種乾淨的方案。方案 A——儲存貯體政策：在 Account B 新增一條資源型 S3 儲存貯體政策，允許 Account A 的 Lambda 執行角色 ARN 執行 s3:PutObject，同時在 Lambda 執行角色上設定基於身份的政策允許 s3:PutObject 至該儲存貯體。方案 B——跨帳號角色：在 Account B 建立一個 IAM 角色，信任政策允許 Lambda 執行角色假設它，並設定允許 s3:PutObject 的權限政策；讓 Lambda 呼叫 sts:AssumeRole 並使用回傳的憑證。方案 B 的可稽核性更高，且可加入 MFA/ExternalId 條件；方案 A 對低複雜度的單向寫入較為簡單。若涉及 SSE-KMS，Account B 的 KMS 金鑰政策也必須允許 Lambda 角色解密——這是 SAA-C03 中常見的易忽略點。

Q4：如何保護新 AWS 帳號的 Root 使用者？

立即為 Root 使用者啟用 MFA——硬體 FIDO2 金鑰或 Passkey 為理想選擇，虛擬 MFA 裝置亦可接受。刪除任何現有的 Root 存取金鑰。設定強度高且唯一的密碼，並將憑證鎖入安全儲存。為所有日常管理任務建立專屬管理員身份（現代最佳實踐是 IAM Identity Center 使用者；具有 AdministratorAccess 受管政策的 IAM 使用者亦可接受）。只在少數 Root 限定動作（如關閉帳號、變更 Root 電子郵件、在 AWS Marketplace 註冊）時才使用 Root 使用者。絕對不要將 Root 憑證嵌入腳本、CI/CD 或應用程式。

Q5：權限邊界與工作階段政策有何不同？

權限邊界是附加在 IAM 使用者或 IAM 角色上的 IAM 政策，用來限制基於身份的政策最多能授予該主體多少權限。它本身不授予任何東西——有效權限是基於身份的政策與邊界的交集。工作階段政策是在呼叫 sts:AssumeRole（或 GetFederationToken）時傳入的內嵌 IAM 政策，進一步縮小該特定工作階段的有效權限，且不修改底層的 IAM 角色或使用者設定。邊界持續存在於身份上；工作階段政策只在單次 STS 工作階段中有效。兩者都是執行最小權限原則的方式——邊界用於委派場景（團隊主管限制開發人員能建立的角色上限），工作階段政策用於細粒度的單次工作階段縮減。

Q6：如何在 AWS 受管政策、客戶受管政策與內嵌政策之間做選擇？

AWS 受管政策由 AWS 維護（如 ReadOnlyAccess、AmazonS3FullAccess）。在職務功能高度吻合且不需要調整措辭時，可作為起點使用。客戶受管政策由你自己撰寫，可跨身份重複使用，有版本控管（保留 5 個版本），是 IAM 身份驗證與存取控制的最佳選擇：大多數生產工作負載應以最小權限措辭撰寫並存放於此。內嵌政策直接嵌入單一身份，無法重複使用。只有在你需要嚴格的 1:1 身份與權限綁定時才使用（例如：一個單一用途的 IAM 角色，且永遠不能累積多餘的不相關權限）。SAA-C03 的最佳實踐指引：優先使用受管政策而非內嵌政策；需要客製化最小權限政策時，優先使用客戶受管政策而非 AWS 受管政策。

延伸閱讀

• AWS IAM 使用者指南 — 簡介
• IAM 政策評估邏輯
• 基於身份的政策與基於資源的政策
• IAM 角色
• AWS STS AssumeRole API
• IAM 安全最佳實踐
• IAM 權限邊界
• IAM 與 STS 配額
• IAM Access Analyzer
• 在 AWS 中使用 MFA
• AWS SAA-C03 考試指南（PDF）