IAM 角色、政策與資源權限

AWS Identity and Access Management（IAM）是每位 AWS 開發者每天都活在其中的授權層。無論是 AWS Lambda 函式呼叫 Amazon DynamoDB、Amazon ECS 任務從 Amazon ECR 拉取容器映像，還是 Amazon EC2 執行個體從 AWS Secrets Manager 讀取密鑰，所有 API 呼叫都必須先通過 AWS IAM 引擎的審核，至少要有一條 IAM 政策允許，且沒有任何政策明確拒絕。對於 DVA-C02 考試，Task Statement 2.1（「為應用程式與 AWS 服務實作身分驗證及／或授權」）使得 IAM 角色、IAM 政策、AWS STS 操作以及政策評估演算法，成為 Domain 2 中出題頻率最高的主題，並且這些知識也會出現在 Domain 1、Domain 3 與 Domain 4 的題目中。

本指南從開發者的視角出發，涵蓋完整的 IAM 政策結構（程式碼審查時會遇到的所有欄位）、從 AWS SDK 呼叫的每一個 AWS STS 操作、每種 AWS 運算服務（AWS Lambda、Amazon EC2、Amazon ECS on EC2、Amazon ECS on AWS Fargate、Amazon EKS with IRSA）所使用的 IAM 角色類型、AWS SDK 用戶端內部的憑證刷新機制，以及開發者在 DVA-C02 v2.1 中被要求了解的新機制——AWS IAM Roles Anywhere、AWS IAM Identity Center 與 AWS IAM Access Analyzer 政策生成。

IAM 對 DVA-C02 開發者的意義

CLF-C02 的 IAM 討論停在「使用者、群組、角色、MFA、最小權限」。DVA-C02 從「這裡有一份 JSON 政策，請找出 Lambda 函式在執行階段出現 AccessDeniedException 的原因」開始。DVA-C02 的每道 IAM 情境題都假設你能像閱讀應用程式程式碼一樣閱讀 IAM 政策：你能說出 Statement 中六個必要欄位、預測 AWS STS 回應中的 Principal、知道特定 AWS 服務在執行階段有哪些條件金鑰，並且清楚題目中運算平台使用的是哪種 IAM 角色類型。

DVA-C02 考試指南（v2.1，2024 年 12 月）明確列出透過 sts:AssumeRole 的跨帳號存取、權限邊界、IAM 條件金鑰、資源型政策，以及政策評估演算法。同時也將 Amazon Cognito（另有專題）與 AWS IAM Identity Center 納入認識程度的要求。IAM Roles Anywhere 現在是 2026 年 AWS 詞彙的一部分，執行混合工作負載的開發者需要能夠辨識它。

IAM 政策文件是開發者的契約

每道 DVA-C02 IAM 相關題目，不是直接給你一份 JSON 政策，就是用文字描述一份政策。本主題的其餘部分將教你快速閱讀這兩種表述方式，預測 IAM 政策評估演算法的結果，並將情境對應到運算平台所使用的特定 IAM 角色類型。

白話文解釋 — IAM 的三種類比

以下三種類比涵蓋 DVA-C02 中所有 IAM 概念。選一個最能記住的，考試時就靠它。

類比一 — 科技廠房的門禁卡與輪班主管吊牌

想像一座嚴格管制的科技廠房。IAM 使用者是正式員工識別證，屬於特定個人，可 24 小時開啟被授權的門禁。IAM 角色是輪班主管吊牌，放在警衛室；任何能證明自己是授權主管的人（信任政策）都可以借出吊牌、配戴最多一小時，輪班結束後自動失效。AWS STS 是警衛室值班員，核驗你的憑證、核發吊牌、在背面寫上到期時間，並將交接記錄在簿冊上。權限邊界是吊牌背面的職務說明書，寫著「此主管只能開啟 1 至 5 樓的門，無論其識別證原本有何授權」。工作階段政策是值班員今日貼在吊牌上的便利貼：「今天限定，不得進入伺服器機房」。資源上的資源型政策是門上的規定，列出哪些吊牌可以進入。明確拒絕是門上的紅色鎖定標籤——無論任何吊牌寫了什麼，只要標籤還在，任何人都無法開門。IAM Roles Anywhere 則是針對持有外部公司識別證的外包商所設計的機制：值班員核驗外包商的身分證件（由受信任憑證機構核發的 X.509 憑證），並核發相同類型的暫時吊牌給外部人員。

類比二 — 嚴格監考的開卷考試

IAM 政策評估就像一場嚴格監考的開卷考試。監考官（AWS IAM）接收每一筆請求，確認你的身分，然後審閱四層規則手冊：來自 AWS Organizations 的服務控制政策（考試委員會的外部規則）、權限邊界（你所在座位區的規定）、身分型政策（你個人的小抄）、資源型政策（你試圖翻開的特定書本上的規定）。只要任何一本規則手冊對你正在嘗試的操作包含明確「禁止」，你的請求就會失敗——明確拒絕永遠優先。否則，監考官需要在至少一處看到明確「允許」，而且四本規則手冊都不能對該操作保持沉默。工作階段政策是監考官今天貼在你桌上的便利貼，因為你要求暫時縮小授權範圍。IAM 條件金鑰是**「唯有在……的情況下」子句**——「允許，但前提是你配戴識別證且現在是下午 5 點前」。此類比可完整對應六步驟 IAM 政策評估演算法，協助你應對最棘手的 DVA-C02 情境題。

類比三 — 餐廳廚房的職位分工與臨時幫手

想像一家忙碌的餐廳廚房正在進行晚班。主廚是擁有長期憑證的 IAM 使用者帳號。線廚是 IAM 角色——一個具名的工作站（炒菜、冷盤、甜點），任何具備資格的人都可以填補一班的空缺。食譜卡是 IAM 政策——清楚寫明該工作站的廚師可以使用哪些食材、哪些爐台，以及在什麼條件下（「只能從冷藏庫取材，只能在下午 4 點到晚上 10 點之間」）。出菜口是資源型政策——只有被授權工作站的菜餚才能端出。AWS Lambda 執行角色是交給自動化助理廚師的食譜卡，每道菜最多執行 15 分鐘。Amazon EC2 執行個體設定檔是夾在固定工作站上的個人食譜夾。Amazon ECS 任務角色是給單一外燴任務的臨時廚師食譜卡，與任務執行角色分開——後者是廚房主任的卡片，只用來從冷藏庫取出食材（Amazon ECR 映像拉取、Secrets Manager 取值）。Amazon EKS IRSA 綁定是貼有 Kubernetes 服務帳號名稱的護貝名牌，讓廚房管理系統（Amazon EKS）在輪班開始時知道要交給這位臨時廚師哪張食譜卡。

IAM 政策結構 — Version、Statement、Effect、Action、Resource、Condition

IAM 政策是一份 JSON 文件，包含兩個頂層金鑰與一個陳述式陣列：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowS3ReadExampleBucket",
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": [
        "arn:aws:s3:::example-bucket",
        "arn:aws:s3:::example-bucket/*"
      ],
      "Condition": {
        "StringEquals": {"aws:RequestedRegion": "us-east-1"},
        "Bool": {"aws:MultiFactorAuthPresent": "true"}
      }
    }
  ]
}

Version 元素

"Version": "2012-10-17" 是目前的 AWS IAM 政策語言版本，條件金鑰與政策變數都需要它才能運作。"2008-10-17" 是舊版，新政策中絕對不應出現。若省略 Version，AWS 預設使用 2008-10-17 文法，多項現代功能將悄悄失效——這是 DVA-C02 常見的除錯陷阱。

Statement 元素

Statement 是一個或多個陳述式的列表。每條陳述式是一條獨立規則，AWS IAM 會個別評估後再依允許／拒絕聯集邏輯合併。

Sid 元素

"Sid" 是選填的陳述式識別碼，評估引擎不使用它，僅供人類與工具參照特定陳述式。不過在 AWS KMS 金鑰政策中，Sid 較為重要，因為 AWS KMS 主控台工具會查找特定 Sid 值來辨識預設陳述式。

Effect 元素

"Effect" 只能是 "Allow" 或 "Deny" 之一，沒有第三個值。在最終決策中，Deny 永遠優先於 Allow——請記住，這是 IAM 政策評估邏輯的基石。

Action 元素（以及 NotAction）

"Action" 指定陳述式適用的 AWS API 操作。操作名稱一律為小寫服務前綴加上駝峰式動詞：s3:GetObject、dynamodb:PutItem、lambda:InvokeFunction、kms:Decrypt。允許使用萬用字元（s3:Get*、s3:*）。陳述式可以列出單一字串、字串陣列，或單一 "*"。NotAction 列出以外的所有操作——使用時需謹慎，因為否定的範圍通常比預期更大。

Resource 元素（以及 NotResource）

"Resource" 是 ARN 或 ARN 陣列，指定陳述式適用的資源。某些操作（如 s3:ListAllMyBuckets）只在帳號層級有意義，因此只接受 "*"。物件層級的 Amazon S3 操作需要 bucket/* ARN 模式。當你同時需要儲存貯體層級與物件層級存取時，應在同一條陳述式中同時列出儲存貯體 ARN 與 bucket/* ARN。NotResource 是否定形式，實務上很少是正確選擇。

Principal 元素（僅限資源型政策）

"Principal" 只出現在資源型政策與信任政策中，指定此規則適用的對象：AWS 帳號（{"AWS": "arn:aws:iam::111122223333:root"}）、IAM 使用者、IAM 角色、AWS 服務（{"Service": "lambda.amazonaws.com"}）、聯合身分（{"Federated": "cognito-identity.amazonaws.com"}），或 "*"。身分型政策永遠不含 Principal，因為主體已是政策所附加的身分。

Condition 元素

"Condition" 是 IAM 政策中最具表達力的部分，也是 DVA-C02 測試最多的部分。它將條件運算子（StringEquals、StringLike、NumericLessThan、DateGreaterThan、Bool、IpAddress、ArnLike 等）對應到條件金鑰與預期值的映射。AWS IAM 對條件區塊的評估方式為：跨運算子之間用 AND、同一運算子內跨金鑰用 AND、同一金鑰的值陣列用 OR。常見的考試條件金鑰包括：

• aws:MultiFactorAuthPresent——要求對此操作啟用 MFA。
• aws:SourceIp——依呼叫者 IP 限制（適合內部部署 VPN 用戶端）。
• aws:RequestedRegion——限制操作只能在一個或多個 AWS 區域執行。
• aws:PrincipalTag/Department、aws:ResourceTag/Project——屬性型存取控制（ABAC）。
• aws:SecureTransport——要求 TLS（HTTPS）。
• aws:SourceVpce、aws:SourceVpc——限制只能透過特定 VPC 端點或 VPC 存取。
• sts:ExternalId——跨帳號角色代入時防止混淆代理人問題的保護金鑰。
• aws:PrincipalOrgID——限制只有 AWS Organizations 組織內的身分才能存取。

IAM 政策類型 — 身分型 vs 資源型、受管 vs 內嵌、邊界、工作階段、SCP

AWS IAM 有六種不同的政策類型。DVA-C02 要求你能說出它們的名稱、將它們附加到正確的物件，並推理它們組合後的效果。

身分型政策

附加到 IAM 使用者、IAM 群組或 IAM 角色。列出該主體可以執行的操作。分為三種風格：AWS 受管、客戶受管或內嵌。

資源型政策

附加到資源——Amazon S3 儲存貯體政策、AWS Lambda 函式資源政策、Amazon SNS 主題政策、Amazon SQS 佇列政策、AWS KMS 金鑰政策、Amazon ECR 儲存庫政策、Amazon API Gateway 資源政策。由於身分並非隱含，必須包含 Principal 元素。資源型政策是唯一可以在不需要另一帳號同時授予權限的情況下，允許跨帳號存取的 IAM 政策類型——例如資源型政策寫明「帳號 111122223333 可以對此儲存貯體執行 s3:GetObject」就已足夠，但另一帳號的身分型政策也必須允許 s3:GetObject。對於 AWS KMS，金鑰政策是強制性的，單靠身分型政策永遠不夠。

AWS 受管 vs 客戶受管 vs 內嵌政策

• AWS 受管：預建 IAM 政策，如 AmazonS3ReadOnlyAccess、AWSLambdaBasicExecutionRole。方便，但通常比最小權限更廣泛。
• 客戶受管：你自行撰寫並版本化。可附加到多個身分。AWS 最多保留五個版本，可回滾。
• 內嵌：嵌入在確切的一個 IAM 使用者、IAM 群組或 IAM 角色內部，無法重複使用。刪除身分時，內嵌 IAM 政策也隨之消失——有時候這正是你想要的（一次性的緊密耦合）。

權限邊界

權限邊界是以邊界形式附加到 IAM 使用者或 IAM 角色的身分型 IAM 政策。它不授予任何權限，只上限有效權限。身分的實際權限是其身分型政策與權限邊界的交集。DVA-C02 中的經典使用案例是委派管理：你賦予開發者為其 AWS Lambda 函式建立 IAM 角色的權限，但在委派中附加權限邊界要求，使得他們建立的每個角色本身永遠不會超過邊界範圍。這防止了透過自行建立具有 AdministratorAccess 的新 IAM 角色來提升特權。

工作階段政策

工作階段政策是在 sts:AssumeRole（或 AssumeRoleWithSAML、AssumeRoleWithWebIdentity 或 GetFederationToken）呼叫中，透過 Policy 或 PolicyArns 參數傳入的暫時性 IAM 政策。它只適用於該特定呼叫所回傳的憑證。工作階段的有效權限是 IAM 角色身分型政策與工作階段政策的交集。工作階段政策非常適合「這個 AWS Lambda 函式呼叫只應被限制在某個特定 Amazon S3 前綴」這類模式。

服務控制政策（SCP）

SCP 存在於 AWS Organizations 中，附加到組織根目錄、組織單元或個別 AWS 帳號。它設定成員帳號中任何 IAM 政策可授予的最大權限。SCP 本身從不授予權限，只用來限制。對於 DVA-C02，你需要知道：在成員帳號中，即使是根使用者的呼叫，若有 SCP 拒絕 s3:DeleteBucket，該呼叫也會被封鎖；而允許 s3:* 的 SCP，仍然需要帳號內的 IAM 政策實際授予該操作。

六種類型如何層疊

主體發出請求時，有效權限的計算方式如下：

1. 從隱含拒絕開始（預設不允許任何操作）。
2. 如果任何 SCP 拒絕該操作，請求被拒絕。
3. 如果任何權限邊界拒絕（或僅僅未允許）該操作，請求被拒絕。
4. 如果任何資源型政策、身分型政策或工作階段政策對該操作有明確拒絕，請求被拒絕。
5. 否則，若至少一條身分型政策、資源型政策或工作階段政策有通過所有條件的明確允許，且 SCP 與邊界也未限制，則請求被允許。
6. 否則，請求因預設而被拒絕。

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

請將此演算法背起來。這是 DVA-C02 Domain 2 中最常出題的概念。

為什麼明確拒絕優先——開發者的思維模型

把它想成請求處理器頂端的防禦性 if 陳述式：if (policy.explicitlyDenies(action)) return 403; 在其他任何邏輯之前執行。只有通過拒絕閘道後，允許邏輯才會運行。在正式環境中，這讓你可以在組織根目錄部署「拒絕所有危險操作」的 SCP，而不必擔心初階工程師的客戶受管 IAM 政策會意外授予這些操作。

跨帳號存取評估

當呼叫主體與目標資源位於不同 AWS 帳號時，AWS IAM 會在兩個帳號中評估呼叫。呼叫者的身分型政策必須允許該操作，且目標帳號必須（a）有一份資源型政策允許該呼叫者，或（b）有一個 IAM 角色供呼叫者透過 sts:AssumeRole 代入，且該角色的身分型政策允許該操作。Amazon S3 是最寬鬆的情況，因為 Amazon S3 儲存貯體政策單獨即可授予跨帳號存取。

AWS Lambda 執行角色 — 最常考的運算 IAM 角色

AWS Lambda 執行角色是 AWS Lambda 在函式啟動時代入的 IAM 角色。信任政策必須允許 lambda.amazonaws.com 呼叫 sts:AssumeRole：

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"Service": "lambda.amazonaws.com"},
    "Action": "sts:AssumeRole"
  }]
}

每個 AWS Lambda 函式必須恰好有一個執行角色。AWS Lambda 將來自該角色的暫時憑證以 AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY 和 AWS_SESSION_TOKEN 環境變數的形式注入函式環境。AWS SDK 透過預設憑證提供鏈自動取用這些環境變數。你永遠不應在 AWS Lambda 處理器中硬式編碼憑證——執行角色就是憑證進入函式的方式。

執行角色至少應附加 AWS 受管政策 AWSLambdaBasicExecutionRole，授予 logs:CreateLogGroup、logs:CreateLogStream 和 logs:PutLogEvents 對 Amazon CloudWatch Logs 的權限。若函式在 VPC 內執行，還需要 AWSLambdaVPCAccessExecutionRole；若讀取 Amazon Kinesis 資料串流，則需要 AWSLambdaKinesisExecutionRole；若以 Amazon SQS 為事件來源，則需要 AWSLambdaSQSQueueExecutionRole；若處理 Amazon DynamoDB 串流，則需要 AWSLambdaDynamoDBExecutionRole。除此之外，依據最小權限原則，加上函式程式碼實際需要的 AWS 服務權限——例如針對特定資料表的 dynamodb:PutItem、針對特定前綴的 s3:GetObject。

EC2 執行個體設定檔 — IAM 角色的 EC2 包裝容器

Amazon EC2 執行個體無法直接使用 IAM 角色，必須將 IAM 角色包裝在執行個體設定檔（1 對 1 的容器）中，再將執行個體設定檔附加到 Amazon EC2 執行個體。Amazon EC2 接著透過**執行個體中繼資料服務（IMDS）**在 http://169.254.169.254/latest/meta-data/iam/security-credentials/ROLE_NAME 公開輪換的短期憑證。AWS SDK 自動使用 IMDS 並透明地輪換憑證——大約每 6 小時核發一組新憑證。請使用 IMDSv2（基於工作階段 Token 的方式）來防範 SSRF 攻擊；啟動執行個體時使用 HttpTokens=required 設定，強制要求 IMDSv2。

透過 AWS Management Console 與 AWS CloudFormation 將 IAM 角色附加到 Amazon EC2 執行個體時，會自動建立同名的執行個體設定檔。若直接使用 AWS CLI 或 AWS SDK，則必須自行建立執行個體設定檔，並呼叫 aws iam add-role-to-instance-profile。

ECS 任務角色 vs ECS 任務執行角色 — 最常被搞混的一對

Amazon ECS 每個任務使用兩個獨立的 IAM 角色，混淆兩者是容器部署主題中 DVA-C02 的第一大陷阱。

ECS 任務角色

任務角色是容器內應用程式程式碼使用的 IAM 角色。若容器在執行階段呼叫 aws s3 cp ... 或 aws dynamodb put-item ...，所需的權限屬於任務角色。任務角色是 AWS Lambda 執行角色或 Amazon EC2 執行個體設定檔的直接類比。

ECS 任務執行角色

任務執行角色是 Amazon ECS（受管服務本身，而非你的容器）用來建立任務的 IAM 角色。它需要從 Amazon ECR 拉取容器映像的權限（ecr:GetAuthorizationToken、ecr:BatchGetImage）、寫入 Amazon CloudWatch Logs 的權限（logs:CreateLogStream、logs:PutLogEvents），以及——關鍵地——當任務定義透過 secrets 屬性參照 AWS Secrets Manager 或 AWS Systems Manager Parameter Store 中的密鑰時，擷取這些密鑰的權限。由於解析發生在任務啟動期間、容器執行之前，因此需要的是 Amazon ECS 的權限，而非容器本身的權限。

並排比較

兩者在 AWS Fargate 上同樣適用——AWS Fargate 任務使用相同的任務角色與任務執行角色模型。AWS Fargate 有一個額外細節：因為沒有底層 Amazon EC2 執行個體提供 IMDS，任務角色的憑證透過 Amazon ECS 代理程式內部的專用憑證端點傳遞，位址為 http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI。AWS SDK 透過預設憑證提供鏈自動取用。

Amazon EKS IRSA — 服務帳號的 IAM 角色

在 Amazon EKS 上，個別 Pod 可透過 IAM Roles for Service Accounts（IRSA） 機制代入個別 IAM 角色。IRSA 的運作方式如下：

1. Amazon EKS 叢集發布一個 OpenID Connect（OIDC）身分提供者 URL。
2. 你在 AWS 帳號中將該 OIDC 提供者註冊為 IAM 身分提供者。
3. 你建立一個 IAM 角色，其信任政策允許該 OIDC 提供者呼叫 sts:AssumeRoleWithWebIdentity，並附帶針對 system:serviceaccount:<namespace>:<serviceAccountName> 的條件。
4. 你在 Kubernetes 服務帳號上加上 eks.amazonaws.com/role-arn: arn:aws:iam::...:role/... 的標註。
5. 使用該服務帳號的每個 Pod 都會取得一個投影服務帳號 Token；Pod 內的 AWS SDK 自動取用該 Token 並呼叫 sts:AssumeRoleWithWebIdentity。

結果：在不共用節點層級憑證的情況下，實現 Pod 層級的 IAM 隔離。這是 Amazon ECS 任務角色在 Amazon EKS 上的對應機制。Amazon EKS 現在也提供 EKS Pod Identity，這是一種更簡單的替代方案，透過節點上的代理程式注入憑證，但 IRSA 仍是 DVA-C02 中你應該熟悉的詞彙。

你會在程式碼中呼叫的 AWS STS 操作

AWS Security Token Service（AWS STS）是核發暫時性安全憑證的 AWS 服務。每組暫時憑證包含三個部分：存取金鑰 ID、私密存取金鑰與工作階段 Token——每次簽署請求都必須同時送出這三者。DVA-C02 要求你能說出四個主要 STS 操作的名稱，並了解它們之間的差異。

sts:AssumeRole

最常見的 STS 呼叫。任何 IAM 主體（IAM 使用者或另一個 IAM 角色）以目標角色的 ARN 呼叫 AssumeRole。目標角色的信任政策必須允許呼叫者。AWS STS 回傳有效期為 15 分鐘至 12 小時的憑證（DurationSeconds 參數；預設 1 小時；最大值受目標角色的 MaxSessionDuration 限制）。AssumeRole 是跨帳號存取在程式碼中的實現方式。可傳入的參數包括：

• ExternalId——目標帳號要求的不透明字串，防止第三方廠商的混淆代理人問題。
• Policy 或 PolicyArns——工作階段政策，用來進一步限制此工作階段。
• DurationSeconds——900 至 43200（角色最大工作階段時長）。
• SerialNumber + TokenCode——要求在代入時提供 MFA。
• RoleSessionName——出現在 AWS CloudTrail 日誌中的標籤，供稽核人員追蹤工作階段。

sts:AssumeRoleWithWebIdentity

由已透過 Web 身分提供者（Amazon Cognito、Login with Amazon、Google、Facebook，或任何 OIDC 相容的 IdP，包含 Amazon EKS 的 OIDC 發行者用於 IRSA）驗證使用者的程式碼呼叫。呼叫者不需要 AWS 憑證，只需提供 IdP 核發的 WebIdentityToken。AWS STS 驗證 Token、檢查目標 IAM 角色信任政策中的 OIDC 提供者與 Token 聲明條件，然後回傳憑證。這是驅動 Amazon Cognito 身分集區、行動應用程式至 Amazon S3 情境，以及 Amazon EKS IRSA 的 STS 呼叫。

sts:AssumeRoleWithSAML

AssumeRoleWithWebIdentity 的 SAML 對應版本。當 IdP 使用 SAML 2.0（Active Directory Federation Services、Microsoft Entra ID 不透過 IAM Identity Center、Okta、Ping）時，用於員工 SSO 整合。在應用程式程式碼中較少見，通常由登入流程處理。

sts:GetSessionToken

回傳呼叫中的 IAM 使用者本身（而非其他 IAM 角色）的暫時憑證，通常用於 MFA 包裝情境。主要使用案例：IAM 使用者有一條 IAM 政策，要求對破壞性操作啟用 MFA。使用者先以其 MFA 碼呼叫 GetSessionToken；回傳的憑證帶有 aws:MultiFactorAuthPresent: true 旗標，使用者再以這些憑證進行需要 MFA 的呼叫。GetSessionToken 永遠不會回傳比使用者現有有效權限更廣的憑證——工作階段憑證完全繼承使用者的權限，不多不少。

sts:GetFederationToken

由受信任的 IAM 使用者（絕對不是角色）代表 AWS IAM 中不存在的聯合使用者呼叫。典型模式：後端服務持有 IAM 使用者憑證，外部客戶以非 AWS 身分驗證到該後端，後端再以限定於該客戶資料範圍的工作階段政策呼叫 GetFederationToken。AWS STS 回傳有效期為 15 分鐘至 36 小時的憑證。現代 AWS 架構幾乎一律偏好 AssumeRole 而非 GetFederationToken，但此操作仍在 DVA-C02 考試範疇中。

STS 呼叫比較表

AWS SDK 內部的暫時憑證刷新

每個 AWS SDK（Python 的 boto3、AWS SDK for JavaScript v3、AWS SDK for Java v2、AWS SDK for Go 等）都內建預設憑證提供鏈，依序搜尋以下來源：環境變數、共用憑證檔案、AWS IAM Identity Center SSO 快取、容器憑證端點（Amazon ECS / AWS Fargate）、IMDSv2（Amazon EC2）、AssumeRoleWithWebIdentity（Amazon EKS IRSA 或具備 AWS_WEB_IDENTITY_TOKEN_FILE 的 AWS Lambda），以及任何你明確傳入的憑證。當解析出的憑證提供者回傳暫時憑證時，AWS SDK 會快取它們，並在到期前的緩衝時間內（通常 5 至 15 分鐘）自動重新取得。你永遠不需要手動在迴圈中呼叫 sts:AssumeRole；SDK 自動處理刷新。對於 AssumeRole，SDK 的 STS.AssumeRoleProvider 會在 Expiration 前重新呼叫 STS 並在背後替換憑證——你的程式碼只需持續使用高層次的 AWS SDK 用戶端。

AWS IAM Roles Anywhere — 內部部署與非 AWS 工作負載的 IAM

AWS IAM Roles Anywhere 讓在 AWS 以外執行的工作負載（內部部署伺服器、其他雲端的容器、CI 執行器）能夠在不建立長期 IAM 使用者的情況下取得暫時 AWS 憑證。工作負載持有由你已在 AWS IAM Roles Anywhere 中註冊為信任錨點的憑證機構核發的 X.509 憑證。工作負載向 CreateSession 端點提交憑證與簽署請求，AWS IAM Roles Anywhere 驗證後，回傳限定於某個設定檔（指定要代入的 IAM 角色及選填的工作階段政策）的暫時 AWS 憑證。DVA-C02 以認識程度處理此功能：了解它的存在、知道它是向資料中心伺服器或建置代理程式分發長期存取金鑰的現代替代方案，並知道它核發的暫時憑證與 sts:AssumeRole 性質相同。

IAM Identity Center — 員工 SSO 開發者速覽

對於 DVA-C02，你需要對 AWS IAM Identity Center 有認識程度的了解，雖然它主要是員工與治理工具。開發者需知的關鍵事實：

• IAM Identity Center 跨多個 AWS 帳號聯合人員登入。開發者在入口網站 URL 登入一次，選擇 AWS 帳號，選擇權限集，即可取得短期憑證。
• 權限集在每個目標帳號中以名稱前綴為 AWSReservedSSO_ 的 IAM 角色形式具體呈現。
• IAM Identity Center 透過 aws configure sso 與 AWS CLI v2 整合，為開發者刷新憑證，且不會在 ~/.aws/credentials 中留下長期存取金鑰。
• IAM Identity Center 是現代員工存取的推薦方式；直接以 SAML 2.0 聯合到 IAM 角色仍然可行，但 IAM Identity Center 更簡單。

IAM Access Analyzer 從 AWS CloudTrail 生成政策

AWS IAM Access Analyzer 的政策生成功能可在可設定的時間窗口（最多 90 天）內，檢查 IAM 角色在 AWS CloudTrail 中的活動，並產生一份精簡的最小權限 IAM 政策，只列出該角色實際使用過的操作。在 DVA-C02 中，每當題目問「開發者在交付原型後，如何精煉過於寬泛的 IAM 政策？」，這就是答案。步驟如下：

1. 以寬泛的 AWS 受管 IAM 政策（或萬用字元）快速部署。
2. 讓工作負載運行一段具代表性的時間。
3. 針對該 IAM 角色執行 IAM Access Analyzer 政策生成。
4. 審閱生成的 IAM 政策；以它取代寬泛的政策並附加。
5. 重新部署並重新測試。

Access Analyzer 也具備外部存取分析功能，監看資源型政策（Amazon S3 儲存貯體政策、IAM 角色信任政策、AWS KMS 金鑰政策、AWS Lambda 資源政策、Amazon SNS/SQS 資源政策），並標記任何授予信任區域外主體存取權限的情況。

開發者的跨帳號存取模式

以下三種 DVA-C02 跨帳號存取模式反覆出現，你應該能閉著眼睛選出正確答案。

模式 A — 含信任政策的 sts:AssumeRole

帳號 A 的開發者需要偶爾存取帳號 B 的 Amazon DynamoDB。在帳號 B 中建立一個 IAM 角色，其信任政策允許 arn:aws:iam::111111111111:root（帳號 A）或帳號 A 中的特定 IAM 使用者／角色呼叫 sts:AssumeRole。將最小權限的 Amazon DynamoDB IAM 政策附加到該角色。開發者呼叫 aws sts assume-role --role-arn arn:aws:iam::222222222222:role/DynamoReader ...，取得短期憑證後使用。若帳號 B 是第三方，則加上 ExternalId。

模式 B — 僅用資源型政策

帳號 A 的 AWS Lambda 函式需要讀取帳號 B 的 Amazon S3 儲存貯體。在帳號 B 的 Amazon S3 儲存貯體政策中允許帳號 A Lambda 執行角色 ARN 執行 s3:GetObject。AWS Lambda 函式的執行角色也需要針對該 ARN 的 s3:GetObject 權限。不需要 AssumeRole 呼叫——Amazon S3 單靠資源型政策即支援跨帳號存取。Amazon SNS、Amazon SQS、AWS Lambda、AWS KMS 與 Amazon ECR 也支援此模式。

模式 C — IAM Identity Center 權限集

人員開發者每天需要在五個 AWS 帳號之間切換。IAM Identity Center、權限集、aws configure sso。完全不需要手動的 AssumeRole 腳本。

IAM 條件金鑰 — 開發者深度解析

條件金鑰是 DVA-C02 用來區分優秀候選人與卓越候選人的關鍵。請熟記以下條件金鑰：

• aws:MultiFactorAuthPresent / aws:MultiFactorAuthAge——要求 MFA，可選擇性地限制在 N 秒內。
• aws:SourceIp——呼叫者 IP 的 CIDR 列表。使用 IpAddress 或 NotIpAddress 運算子。
• aws:SourceVpc / aws:SourceVpce——限制特定 VPC 或 VPC 端點。對於「只能從我們的 VPC 存取」的 Amazon S3 儲存貯體政策不可或缺。
• aws:RequestedRegion——強制執行「Amazon EC2 不得在 us-east-1 以外區域使用」。
• aws:SecureTransport——要求 HTTPS（"aws:SecureTransport": "true"）。
• aws:PrincipalOrgID——只授予 AWS Organizations 組織內身分的存取權限（搭配萬用字元主體時可防止外部洩漏）。
• aws:PrincipalTag/Key 與 aws:ResourceTag/Key——屬性型存取控制（ABAC）。為 IAM 角色標記 Department=Finance，為 Amazon S3 物件標記 Department=Finance，寫一條政策，當 aws:PrincipalTag/Department == aws:ResourceTag/Department 時允許存取。
• aws:SourceArn、aws:SourceAccount——用於服務對服務呼叫（例如 Amazon SNS 發布到 Amazon SQS），防止混淆代理人問題。
• sts:ExternalId——在 sts:AssumeRole 呼叫中要求特定字串，是第三方廠商混淆代理人的標準防護措施。
• sts:RoleSessionName——強制特定工作階段名稱，有助於稽核追蹤。
• AWS 服務特定金鑰——s3:prefix、s3:x-amz-server-side-encryption、dynamodb:LeadingKeys、ec2:ResourceTag/Key。

DVA-C02 常見 IAM 考試陷阱

陷阱一 — 明確拒絕不需要相符的允許

若任何適用 IAM 政策對該操作有 Effect: Deny，即使沒有任何明確允許，請求也會被拒絕。明確拒絕不需要相符的允許來「抵消」。

陷阱二 — SCP 不授予權限

寫著 Effect: Allow, Action: s3:* 的 SCP，本身不足以讓呼叫者使用 Amazon S3。呼叫者的 IAM 政策也必須授予該操作。

陷阱三 — 權限邊界同樣不授予權限

允許 s3:* 的權限邊界，本身不足以讓呼叫者使用 Amazon S3。邊界只限制身分型 IAM 政策可有效授予的範圍。

陷阱四 — 任務角色 vs 任務執行角色

容器執行階段的 Amazon S3 存取 → 任務角色。Amazon ECR 映像拉取與啟動期間從 AWS Secrets Manager 取得密鑰 → 任務執行角色。若題目是「任務無法啟動，因為容器映像無法拉取」，問題在執行角色。若題目是「任務正常執行，但程式碼在 s3:GetObject 時出現 AccessDenied」，問題在任務角色。

陷阱五 — 同帳號 IAM 使用者透過 AssumeRole 進行 MFA

若要對你自己的 IAM 使用者執行破壞性操作要求 MFA，慣用做法是 sts:GetSessionToken + MFA，而非 sts:AssumeRole。帶有 MFA 的 AssumeRole 也有效，但增加了一個不必要的角色抽象層。

陷阱六 — AWS Lambda 函式的資源型政策 vs 執行角色

輸入方向（誰可以呼叫）= 資源型政策。輸出方向（函式可以做什麼）= 執行角色。若題目是「Amazon API Gateway 呼叫 AWS Lambda 函式時出現 403 AccessDenied」，請檢查 Lambda 資源型政策。

陷阱七 — IMDSv1 vs IMDSv2 與 SSRF

IMDSv2 需要工作階段 Token（PUT /latest/api/token）。Amazon EC2 應用程式中的 SSRF 漏洞，若只支援 IMDSv1，可用來竊取執行個體設定檔憑證。若 DVA-C02 題目提到 Amazon EC2 上的 SSRF 與憑證竊取，答案是「要求 IMDSv2」。

陷阱八 — VPC 中的 Lambda 與執行角色

將 AWS Lambda 函式放在 VPC 內，不會改變執行角色的基本需求；函式仍然需要 AWSLambdaVPCAccessExecutionRole 受管政策（或相等的 ec2:CreateNetworkInterface / ec2:DescribeNetworkInterfaces / ec2:DeleteNetworkInterface 權限），以及其應用程式權限。

陷阱九 — 跨帳號 AWS KMS

AWS KMS 跨帳號使用一律需要兩個條件同時滿足：金鑰所在帳號的金鑰政策允許呼叫者，且呼叫者帳號的 IAM 政策授予 AWS KMS 操作。AWS KMS 在這一點比 Amazon S3 更嚴格。

陷阱十 — 行動應用程式的 AssumeRoleWithWebIdentity vs AssumeRole vs IAM 使用者

上傳照片到 Amazon S3 的行動應用程式，絕對不能內嵌 IAM 使用者憑證。正確答案是 AssumeRoleWithWebIdentity——通常由 Amazon Cognito 身分集區仲介。

必背數字與重要事實

練習題對應索引

• 「Amazon ECS 任務無法從 Amazon ECR 拉取容器映像」→ 任務執行角色缺少 ecr:*。
• 「AWS Lambda 函式寫入 Amazon DynamoDB 時出現 AccessDeniedException」→ 執行角色缺少 dynamodb:PutItem。
• 「Amazon EKS Pod 需要專屬 IAM 權限」→ 透過 sts:AssumeRoleWithWebIdentity 搭配服務帳號標註的 IRSA。
• 「內部部署 CI 執行器需要 AWS 憑證」→ AWS IAM Roles Anywhere 搭配信任錨點。
• 「在正式環境運行一個月後精煉過於寬泛的 IAM 角色」→ 從 AWS CloudTrail 進行 AWS IAM Access Analyzer 政策生成。
• 「從帳號 A 跨帳號存取帳號 B 的 Amazon S3 儲存貯體」→ B 的儲存貯體政策 + A 的 IAM 政策，或在 B 中建立角色後透過 sts:AssumeRole 代入。
• 「第三方廠商存取我們的 AWS 帳號」→ 含信任政策的 IAM 角色 + sts:ExternalId 條件。
• 「SSRF 竊取 Amazon EC2 憑證」→ 要求 IMDSv2。
• 「強制所有開發者在破壞性操作前使用 MFA」→ aws:MultiFactorAuthPresent: true 條件或 sts:GetSessionToken + MFA。

FAQ — DVA-C02 IAM 高頻問題

Q1：身分型政策與資源型政策有什麼差異？各自在什麼情況下附加？

身分型政策附加到 IAM 使用者、IAM 群組或 IAM 角色，列出該主體可以執行的操作。資源型政策附加到 AWS 資源（Amazon S3 儲存貯體、AWS Lambda 函式、AWS KMS 金鑰、Amazon SNS 主題、Amazon SQS 佇列、Amazon ECR 儲存庫、Amazon API Gateway 資源），列出哪些主體可以對其執行操作。日常權限大多使用身分型政策；資源型政策適用於以下情況：需要跨帳號存取而不強迫呼叫者代入角色（Amazon S3 是經典案例）、需要讓某個服務呼叫你的 AWS Lambda 函式（Amazon EventBridge、Amazon API Gateway），或是 AWS KMS 要求時（AWS KMS 金鑰政策是強制性的，絕非選填）。

Q2：sts:AssumeRole 與 sts:AssumeRoleWithWebIdentity 有什麼差異？

sts:AssumeRole 由持有有效 AWS 憑證的現有 IAM 主體（IAM 使用者或 IAM 角色）呼叫；AWS STS 檢查目標角色的信任政策，可選擇性地要求 MFA 或 ExternalId，並回傳暫時憑證。sts:AssumeRoleWithWebIdentity 由持有來自受信任 OIDC 或 Web 身分提供者（Amazon Cognito、Login with Amazon、Google、Facebook，或 Amazon EKS 的 OIDC 發行者用於 IRSA）Token 的任何人呼叫。呼叫者完全沒有 AWS 憑證；AWS STS 驗證 Web Token、檢查角色信任政策中的 OIDC 提供者及 Token 聲明條件，然後回傳憑證。AssumeRoleWithWebIdentity 驅動行動應用程式至 AWS 的存取，以及 Amazon EKS IRSA。

Q3：什麼是權限邊界？開發者什麼時候該使用它？

權限邊界是以邊界形式附加到 IAM 使用者或 IAM 角色的 IAM 政策。它不授予權限，只上限有效權限。身分的實際有效權限是其身分型政策與邊界的交集。當你委派其他開發者建立 IAM 角色的能力，但想確保他們建立的角色永遠不會超過固定上限時，就該使用它——例如「開發者可以建立新的 AWS Lambda 執行角色，但這些角色永遠不得授予 iam:* 或 kms:*」。邊界防止特權提升。

Q4：Amazon ECS 任務角色與任務執行角色有什麼差異？

任務角色由容器內的應用程式程式碼使用——這是你的 AWS SDK 用戶端在執行階段呼叫 Amazon DynamoDB、Amazon S3、Amazon SQS 時所取用的角色。任務執行角色由 Amazon ECS 代理程式代表你，在任務啟動期間使用——用於拉取 Amazon ECR 的容器映像、寫入 Amazon CloudWatch Logs，以及解析任務定義中參照的 AWS Secrets Manager 或 AWS Systems Manager Parameter Store 密鑰。混淆兩者會看到「任務無法啟動」（執行角色問題）或「任務正常執行，但 API 呼叫出現 AccessDenied」（任務角色問題）。兩者在 AWS Fargate 上同樣適用。

Q5：明確拒絕如何與其他 IAM 政策層互動？

任何適用 IAM 政策（身分型、資源型、權限邊界、工作階段政策或 SCP）中的明確拒絕都是最終結果。沒有任何地方的允許可以覆蓋它。這是 IAM 政策評估引擎首先套用的規則。這也正是明確拒絕是最安全防護機制的原因：你可以在組織根目錄部署「拒絕所有危險操作」的 SCP，並確信沒有任何下游 IAM 政策能在成員帳號中意外啟用這些操作。

Q6：AWS SDK 如何刷新暫時憑證？

每個 AWS SDK 都使用預設憑證提供鏈。當該鏈解析出暫時憑證（來自 AWS Lambda 環境變數、Amazon EC2 的 IMDSv2、Amazon ECS 和 AWS Fargate 的容器憑證端點、明確角色切換的 AssumeRole 提供者，或 Amazon EKS IRSA 的 AssumeRoleWithWebIdentity）時，SDK 會快取這些憑證及其 Expiration 時間戳記。在每次請求前，SDK 檢查憑證是否即將在緩衝時間內（5 至 15 分鐘）到期，若是，則透明地重新取得。你永遠不應手動撰寫憑證刷新迴圈——若在 DVA-C02 情境中看到這樣的做法，很可能是錯誤答案。

Q7：什麼是 ExternalId？為什麼第三方廠商會要求它？

sts:ExternalId 是目標 IAM 角色信任政策中的條件金鑰，也是 sts:AssumeRole 呼叫的參數。它防止你讓第三方廠商透過跨帳號 AssumeRole 存取你的 AWS 帳號時出現混淆代理人問題。廠商為每個客戶生成一個唯一的不透明字串；你的信任政策要求 Condition: {StringEquals: {sts:ExternalId: "your-unique-string"}}。若同一廠商的另一位客戶試圖誘騙廠商呼叫你的角色，ExternalId 不會匹配，代入就會失敗。

Q8：什麼時候應該使用 AWS IAM Roles Anywhere 而非 IAM 使用者存取金鑰？

在 2026 年，幾乎任何時候都應該優先選擇 Roles Anywhere。儲存在內部部署伺服器、建置代理程式或其他雲端的長期 IAM 使用者存取金鑰是持續性的安全風險。AWS IAM Roles Anywhere 讓相同的工作負載透過提交由你已在信任錨點中註冊的憑證機構核發的 X.509 憑證，取得自動輪換的暫時 AWS 憑證。只有在目標平台確實無法進行憑證型驗證時，才使用 IAM 使用者存取金鑰。

Q9：為什麼我的跨帳號 AWS KMS 呼叫失敗，即使我的 IAM 政策允許 kms:Decrypt？

因為 AWS KMS 同時要求呼叫者的 IAM 政策以及金鑰所在帳號的 AWS KMS 金鑰政策都允許該操作。與 Amazon S3 不同，AWS KMS 跨帳號存取既不能單靠資源型政策，也不能單靠身分型政策授予。請在金鑰政策中新增一條陳述式，列出呼叫者的 IAM 角色 ARN，並確認呼叫者的 IAM 政策也對該金鑰 ARN 授予了 kms:Decrypt。

Q10：如何從觀察到的行為產生最小權限 IAM 政策？

以寬泛的 AWS 受管 IAM 政策部署，讓工作負載至少運行數天（理想上跑完一個完整的業務週期），然後使用 AWS IAM Access Analyzer 政策生成，檢查最多 90 天的 AWS CloudTrail 歷史記錄，生成一份精煉的 IAM 政策，只包含角色實際呼叫過的操作。審閱生成的 IAM 政策，以它取代寬泛的政策並附加，重新部署，然後監看 AWS CloudTrail 中的新 AccessDenied 事件，以確認是否有遺漏的操作。

延伸閱讀

• AWS IAM JSON Policy Reference
• AWS IAM Policy Evaluation Logic
• AWS IAM Roles
• AWS IAM Permissions Boundaries
• AWS IAM Session Policies
• AWS STS API Reference
• AWS Lambda Execution Role
• Amazon ECS Task IAM Roles
• Amazon EKS IRSA
• AWS IAM Roles Anywhere
• AWS IAM Access Analyzer Policy Generation
• AWS Certified Developer Associate DVA-C02 Exam Guide (PDF)