Amazon SCS-C02: 身分與存取管理 — 學習指南

By Laurynas Brazys · 25 July 2026 · #amazon #scs-c02 #certification #exam-prep #study-guide

屬於 AWS Security Specialty SCS-C02 — 學習指南. 使用經過驗證的解答練習： Amazon 考試中心, 或參加限時模擬考試： ExamRoll.io.

身分、主體與政策評估

IAM 區分身分 (使用者、群組、角色) 與主體 (發出請求的已驗證實體)。使用者是具有靜態憑證的長期身分；角色本身沒有憑證，而是被 擔任 (assume) 以產生短期的 STS 權杖。群組是將政策附加到使用者的容器——它們絕不會是主體，也無法被擔任。

每個 API 呼叫都會經過一個決定性的評估鏈：任何地方的明確拒絕 (explicit Deny) 優先，接著組織層級的 SCP 必須允許，然後權限邊界必須允許，再來是工作階段政策 (如果有的話) 必須允許，最後，至少要有一個身分型或資源型政策包含允許 (Allow)。缺少任何一個允許層都會導致隱性拒絕 (implicit deny)。這就是為什麼分層很重要：一個授予 s3:* 的身分政策，如果 SCP 拒絕了 s3:DeleteBucket 或權限邊界完全排除了 S3，那這個政策就沒有意義了。

資源型政策 (S3 儲存貯體政策、KMS 金鑰政策、SNS 主題政策、Lambda 函數政策) 可以在呼叫者端沒有任何身分政策的情況下，直接將存取權授予主體——但這僅限於 在同一個帳戶內。對於跨帳戶存取，來源帳戶的身分政策和目標帳戶的資源政策都必須允許該操作。

角色、信任政策與 AssumeRole

一個角色有兩種政策文件：信任政策 (誰可以擔任它) 和一或多個 權限政策 (擔任後可以做什麼)。信任政策是套用在角色本身上的一種資源型政策，它使用 sts:AssumeRole 這個動作。如果沒有相符的信任政策，即使呼叫者的身分政策中擁有 sts:AssumeRole 權限，AssumeRole 操作也會失敗並回傳 AccessDenied。

對於跨帳戶委派，信任政策會指定受信任的帳戶，或該帳戶中特定的角色/使用者 ARN，並且——對於第三方存取至關重要的是——會強制執行一個 ExternalId：

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": { "sts:ExternalId": "unique-shared-secret-9271" }
    }
  }]
}

ExternalId 可以防禦 混淆代理人 (confused deputy) 問題：如果沒有它，一個跨多個客戶帳戶擔任角色的第三方 SaaS 供應商，可能會被誘騙去操作錯誤客戶的角色。在條件中省略 sts:ExternalId，或是在執行 sts:AssumeRole 時傳遞錯誤的值，都會在擔任角色時產生 AccessDenied——這是在整合監控或 CSPM 等廠商工具時常見的設定錯誤。

對於 AWS 服務 (如 Lambda、EC2、ECS 任務)，信任政策會指定一個服務主體，例如 "Service": "lambda.amazonaws.com"。一個需要存取 S3 的 Lambda 函數應該擔任一個執行角色，該角色的權限政策授予對儲存貯體的 s3:GetObject 和 s3:PutObject 權限；同樣地，S3 儲存貯體政策也可以將該函數的角色 ARN 指定為主體。在單一帳戶內，這兩種機制都可以獨立運作。

權限邊界

權限邊界是一種附加到使用者或角色上的 進階控制，它設定了該身分所能擁有的最大權限上限，無論其身分型政策授予了什麼權限。有效權限是身分政策與權限邊界的交集。如果一個群組政策授予 ec2:*，但權限邊界只允許 ec2:Describe*，那麼該使用者就只能執行描述 (describe) 操作。

權限邊界通常用於 權限委派：允許開發人員為他們的應用程式建立 IAM 角色，但要求他們建立的每個角色都必須帶有特定的權限邊界。開發人員的 IAM 政策會在 iam:CreateRole 和 iam:PutRolePolicy 動作上包含一個類似 "iam:PermissionsBoundary": "arn:aws:iam::123456789012:policy/DevBoundary" 的條件。這可以在啟用自助服務的同時，防止權限提升 (privilege escalation)。

一個常見的誤解是，群組成員資格或額外附加的政策可以「覆蓋」權限邊界或 SCP。事實上不行——權限邊界和 SCP 是權限的上限 (ceilings)，而不是下限 (floors)。

透過條件強制執行 MFA

有兩個條件金鑰可以驅動 MFA 政策：aws:MultiFactorAuthPresent (布林值，如果工作階段是使用 MFA 取得的，則為 true) 和 aws:MultiFactorAuthAge (數值，距離 MFA 驗證通過後經過的秒數)。為敏感 API 強制執行 MFA 並限制工作階段生命週期的政策看起來像這樣：

{
  "Effect": "Allow",
  "Action": ["rds:DeleteDBInstance", "kms:ScheduleKeyDeletion"],
  "Resource": "*",
  "Condition": {
    "Bool":            { "aws:MultiFactorAuthPresent": "true" },
    "NumericLessThan": { "aws:MultiFactorAuthAge": "7200" }
  }
}

兩小時是 7,200 秒。對於那些從不帶有此金鑰的服務主體呼叫，使用 BoolIfExists 而非 Bool 存在著微妙的危險——它會評估為 true，從而有效地繞過了對這些呼叫者的檢查。因此，當目的是要對人類使用者強制執行時，應優先使用 Bool。

因為使用長期存取金鑰的 CLI 和 SDK 請求不包含 MFA 上下文，使用者必須先呼叫 sts:GetSessionToken (帶上 --serial-number 和 --token-code 參數) 或 sts:AssumeRole (帶上 --serial-number/--token-code 參數)，以取得包含 MFA 上下文的臨時憑證。這些短期憑證接著就能滿足 MultiFactorAuthPresent 條件：

aws sts get-session-token \
  --serial-number arn:aws:iam::123456789012:mfa/alice \
  --token-code 123456 \
  --duration-seconds 7200

IAM Identity Center 與聯盟

IAM Identity Center (前身為 AWS SSO) 可集中管理整個 AWS Organization 的員工存取。權限集合 (Permission sets) 是一種範本，當使用者或群組被指派時，Identity Center 會在每個目標帳戶中將其具現化為 IAM 角色。指派會綁定三樣東西：一個主體 (來自 Identity Center 目錄或像 Okta/Entra ID 這類外部 IdP 的使用者或群組)、一個權限集合，以及一或多個帳戶。

權限集合可以包含 AWS 管理的政策、客戶管理的政策 (透過名稱參考，因此必須存在於每個目標帳戶中)、內嵌政策，以及一個權限邊界。當您編輯權限集合時，Identity Center 會重新佈建底層的角色——您絕對不要直接編輯那些角色。

對於 Identity Center 之外的 SAML 聯盟，AWS 會根據註冊在 IAM SAML 提供者物件上的 IdP 中繼資料來驗證斷言的簽章。當 IdP 輪替其簽署憑證時，必須上傳更新後的中繼資料 XML；否則 STS 會回傳 InvalidIdentityToken / Response Signature Invalid。使用 aws iam update-saml-provider --saml-metadata-document file://metadata.xml --saml-provider-arn ... 來更新中繼資料是最低額外負擔的修復方式——無需重新建立提供者或重新設定信任關係。

根帳戶、憑證報告與最低權限

根使用者擁有不可移除的完整存取權，必須被視為緊急備用身分：啟用硬體或虛擬 MFA 裝置、刪除所有根存取金鑰、不要將其用於日常工作，並將憑證離線儲存。在組織根目錄或 OU 層級使用 SCP，以防止成員帳戶中的管理員停用 GuardDuty、刪除 CloudTrail 或離開特定區域。SCP 絕不會授予權限——它們只會過濾成員帳戶中 IAM 所能授予的權限範圍。

最低權限原則是透過工具而非直覺來實踐的。產生 IAM 憑證報告 (先用 aws iam generate-credential-report 再用 get-credential-report) 來找出未使用的使用者、老舊的存取金鑰，以及沒有 MFA 的使用者。使用 IAM Access Analyzer 來識別將資料暴露給跨帳戶的資源政策，並根據 CloudTrail 活動產生適當規模的政策。使用上次存取資料 (aws iam get-service-last-accessed-details) 來修剪角色中未使用的服務權限。

最後一個值得明確指出的陷阱是：假設只要加上一個身分允許 (Allow) 就足夠了。如果 KMS 金鑰政策沒有指名您的角色、SCP 拒絕了該操作，或是權限邊界遺漏了它，呼叫仍然會失敗。在對 AccessDenied 進行疑難排解時，務必審核整個堆疊——SCP、權限邊界、身分政策、資源政策和工作階段政策。

實務問題：使用案例情境

情境： Meridian Financial 營運一個包含管理、生產和開發工作負載的三帳戶 AWS Organization，其中生產帳戶存放著敏感的交易和客戶資料。他們目前混合使用了傳統的長期有效 IAM 使用者、承包商帳戶，以及一個 Okta SAML 身分識別提供者，導致跨帳戶的存取控制不一致且角色組態分散。

挑戰： 最近發生的一起事件中，一名承包商遭洩露的憑證在沒有 MFA 的情況下擔任了一個跨帳戶角色，並執行了過多的操作，原因在於沒有設定權限邊界或集中的權限集合。Meridian 需要強化聯盟、角色信任，並在所有帳戶中強制執行 MFA 和最低權限原則。

建議方法：

部署與 Okta SAML 整合的 AWS IAM Identity Center 作為單一的聯盟身分平面，並將所有真人使用者和承包商從長期有效的 IAM 使用者遷移到基於 Identity Center 的帳戶，同時停用傳統 IAM 使用者的主控台/金鑰存取。
在 IAM Identity Center 中建立對應到成員帳戶中 IAM 角色的集中式權限集合，並為所有角色實作 IAM 權限邊界 (定義為 IAM 政策)；使用 AWS CloudFormation StackSets 將這些邊界和角色範本部署到所有帳戶。
更新跨帳戶角色的信任政策，使其僅允許來自 Identity Center 主體 ARN 的 sts:AssumeRole，並包含要求 MFA (例如 aws:MultiFactorAuthPresent) 和來源帳戶限制的條件；要求工作階段標籤攜帶身分屬性。
在 IdP (Okta) 端強制執行 MFA，並透過在角色工作階段上要求 MFA 條件來將此強制措施反映在 AWS 中；透過在 AWS Organizations 中應用服務控制政策 (SCP) 來拒絕建立主控台存取或新的 IAM 使用者。
啟用 AWS CloudTrail、AWS Config 和 IAM Access Analyzer 以進行持續監控和政策驗證，並將發現的結果傳送到 CloudWatch/GuardDuty 以進行警示和自動化修復工作流程。

理由： 透過 IAM Identity Center 集中化聯盟、利用權限集合和邊界強制執行最低權限、在信任政策中要求 MFA，以及應用組織層級的 SCP 外加監控，這些做法符合 AWS 的最佳實踐，有助於縮小爆炸半徑、防止權限提升，並提供可稽核性。

IAM 角色與信任政策：PassRole 和 AssumeRole

一個 IAM 角色有兩種不同的政策介面，混淆這兩者是大多數跨帳戶授權失敗的根本原因。信任政策 (AssumeRolePolicyDocument) 回答了誰可以在什麼條件下擔任該角色。許可政策則回答了該角色在被擔任後可以做什麼。兩者都必須允許該操作；單靠信任政策絕不會授予對 S3、KMS 或任何其他服務的存取權限。

當一個 principal 呼叫 sts:AssumeRole 時，STS 會根據呼叫者的身分加上工作階段情境（來源 IP、MFA 狀態、工作階段標籤、外部 ID）來評估目標角色的信任政策。呼叫的 principal 也必須擁有一個基於身分的 Allow 政策，允許對該角色 ARN 執行 sts:AssumeRole。正是這種雙重需求，使得跨帳戶邊界的角色擔任變得安全。

一個要求 MFA 和外部 ID 的典型跨帳戶信任政策如下所示：

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
    "Action": "sts:AssumeRole",
    "Condition": {
      "Bool": { "aws:MultiFactorAuthPresent": "true" },
      "NumericLessThan": { "aws:MultiFactorAuthAge": "3600" },
      "StringEquals": { "sts:ExternalId": "unique-partner-id-8842" }
    }
  }]
}

aws:MultiFactorAuthPresent 這個金鑰只在可被擔任角色的信任政策中有意義，因為 MFA 的情境是在呼叫 STS 時建立的，而不是在後續的服務呼叫中。將 MFA 條件加到 S3 儲存貯體政策或角色的許可政策中是一個常見的錯誤：即使最初的使用者是透過 MFA 進行驗證，擔任角色後的工作階段通常也不會帶有 aws:MultiFactorAuthPresent=true，因此這些條件會默默地拒絕所有操作。請在擔任角色時強制執行 MFA；對於長時間存在的工作階段，可使用 aws:MultiFactorAuthAge 來強制重新驗證。

PassRole 是另一個在考試情境中會遇到的關卡。當你告訴像 CloudFormation、EC2、Lambda 或 CodeBuild 這樣的服務要以某個角色的身分執行時，呼叫的身分必須擁有 `iam:PassRole

實際問題：使用案例情境

情境： Meridian Financial 公司在一個多帳戶的 AWS Organization 中運作，為生產、開發和 CI/CD 工具鏈分別設立了獨立的帳戶；他們使用集中式的 IAM 角色進行跨帳戶部署，並讓第三方 CI 代理程式擔任角色來執行基礎設施變更。身分邊界由角色信任政策強制執行，有些團隊使用長期的執行個體設定檔和 Lambda 函數，這些函數被授予 iam:PassRole 權限，以便將角色附加到執行個體或任務上。

挑戰： 最近一次稽核發現，一個過於寬鬆的 iam:PassRole 權限允許一個 CI/CD principal 將一個 Administrator 角色傳遞給 EC2 執行個體設定檔，而攻擊者利用了一個 AssumeRole 信任關係，取得了跨帳戶的過高權限。

建議方法：

使用 AWS CloudTrail 和 Amazon EventBridge 來識別最近的 iam:PassRole 和 sts:AssumeRole API 呼叫，並在 CloudTrail Lake 或 Athena 中執行查詢，以列出哪些 principal 在何時傳遞了哪些角色 ARN。
跨帳戶執行 IAM Access Analyzer (for IAM) 來發現基於資源的信任政策曝險，並列出可從 Organization 外部或由外部 principal 擔任的角色。
將寬鬆的 iam:PassRole 政策替換為最小權限的 IAM 政策，在 Resource 中明確指定角色 ARN，並添加如 aws:PassedToService 或 aws:PrincipalOrgID 等條件金鑰，以限制誰以及什麼服務可以接收該角色。
強化角色信任政策，要求加入條件——使用 aws:PrincipalOrgID、為第三方使用 sts:ExternalId、要求 aws:SourceIdentity 並強制設定最長工作階段持續時間——以防止未知 principal 進行廣泛的 AssumeRole。
設定 Amazon EventBridge 規則來偵測 iam:PassRole 和 AssumeRole 的異常活動，將警示發送到 Amazon SNS，並建立自動化的 Lambda 教戰手冊 (playbook) 來撤銷或修復過於寬鬆的政策，同時將發現記錄在 AWS Security Hub 和 AWS Config 中，以實現持續合規。