規模化 IAM — 身份聯邦、Permission Boundaries 與 ABAC

IAM 身分聯手與許可邊界是兩項關鍵技術，能將龐大的多帳戶 AWS 環境轉變為 DevOps 團隊可以大規模治理的架構，而不會淹沒在長期存取金鑰或手動維護的策略中。在 DOP-C02 考試中，只要情境設定為「開發人員應自我服務建立角色但不能提升權限」、「GitHub Actions 必須在沒有靜態認證的情況下進行部署」或「中央安全部門必須對委派管理員可以授予的權限設定上限」，領域 6 任務 6.1 就會出現身分聯手與許可邊界。正確答案總是結合了身分聯手（使人員和 CI 系統永不持有長期認證）、許可邊界（使委派管理員不能超過組織上限）以及服務控制策略 (SCP)（為整個帳戶設定圍欄），形成多層控制，即使單個配置錯誤的策略也無法繞過。

本專業深度指南涵蓋了您在 DOP-C02 中會遇到的所有身分聯手與許可邊界原語：SAML 2.0 與 OIDC 身分供應商、作為推薦的人員進入點的 IAM 身分中心 (IAM Identity Center)、使用工作階段標籤的 ABAC、身分策略/資源策略/許可邊界/SCP/工作階段策略之間的精確評估順序、針對 EC2/ECS/Lambda/CodeBuild 的機器身分模式、無靜態金鑰的 GitHub Actions OIDC 信任、使用 STS 的角色鏈接、用於策略產生與外部存取偵測的 IAM Access Analyzer，以及正統的委派管理員模式 —— 平台團隊賦予應用團隊自我服務建立 IAM 角色的權力，但受限於他們無法移除的許可邊界。

什麼是 IAM 身分聯手與許可邊界？

IAM 身分聯手與許可邊界是兩項互補的原語。身分聯手讓外部身分存放區（企業 IdP、GitHub、Okta、Active Directory）驗證使用者並假設 IAM 角色以獲取臨時認證，從而消除了對具備長期存取金鑰的 IAM 使用者的需求。許可邊界 (Permission Boundary) 是一項進階 IAM 功能，它設定了身分型策略可以授予 IAM 使用者或角色的最大權限，即使附加了更寬鬆的身分策略也是如此。兩者結合，讓 DevOps 平台團隊可以將「建立自己的 IAM 角色」委派給應用團隊，同時保證這些團隊無法超越組織設定的權限上限。

為什麼身分聯手與許可邊界對 DOP-C02 很重要

DOP-C02 任務 6.1 明確將「身分聯手技術」和「使用 IAM 許可邊界進行權限管理委派」列為必備知識。SAA-C03 的單帳戶 IAM 模式已不足夠。專業級情境涉及擁有 50 個帳戶的組織，中央平台團隊需要強制執行應用團隊開發人員的行為上限，管道必須在不使用靜態認證的情況下跨帳戶部署，且工作階段標籤驅動 ABAC，使得一個角色定義能服務數十個專案團隊。

IAM 授權的五個層級

理解身分聯手與許可邊界需要同時掌握五個授權層級：SCP（組織級別的允許清單上限）、許可邊界（單個實體的身分策略上限）、身分策略（主體可以做什麼）、資源策略（資源允許什麼）以及工作階段策略（每次 STS 調用時的縮小範圍）。在 DOP-C02 考試中，任何單層答案通常都是錯誤的；正確答案會橫跨至少三層進行考量。

白話文解釋 IAM 身分聯手與許可邊界

身分聯手與許可邊界聽起來像是難以理解的縮寫，但透過三個日常生活類比可以揭示其結構。

類比 1 —— 辦公大樓安全通行證系統（門禁類比）

想像一棟 50 層的辦公大樓（您的 AWS 組織），有一個中央接待處（IAM 身分中心）、一個公司簽約的外部證件局（SAML/OIDC IdP），以及每層樓的租戶經理（委派管理員）。身分聯手就是規定任何人 —— 員工、供應商、承包商 —— 都不能獲得永久的大樓通行證；每個人每天早上在接待處出示公司證件，並領取一張臨時的當天通行證。

在這個系統中，來自原公司的證件就是您在 Okta/Azure AD/Auth0 的 SAML 或 OIDC 身分。接待處的發證櫃檯將公司證件轉換為大樓當天通行證，這就是 sts:AssumeRoleWithSAML 或 sts:AssumeRoleWithWebIdentity。當天通行證本身（具有 1 到 12 小時的有效期限）就是臨時 STS 認證。每部電梯中張貼的大樓通用規則（如「禁止吸菸、禁止攜帶武器、禁止錄音」），無論其通行證顏色為何都適用於每位訪客，這就是 SCP。租戶經理在核發通行證時設定的進入特定房間的上限就是角色上的許可邊界。經理交給您參加今天會議的特定房間鑰匙就是您的身分策略。房間門口的規則（如「此房間僅對註冊訪客開放」）就是資源策略。而經理在敏感活動當天實施的臨時降級（「今天即使您的通行證通常允許，也無法進入 40-45 樓」）就是在 AssumeRole 時應用的工作階段策略。五個層級。僅限當天通行證。到處都沒有永久證件。

類比 2 —— 醫院處方權限系統（醫療/藥房類比）

想像一家醫院，醫生（開發人員）、住院醫生（初級工程師）和外部代班醫生（CI 系統，如 GitHub Actions）都開處方。身分聯手與許可邊界就是分層權限系統，防止任何醫生開出不該開的管制藥品。

由州委員會（您的企業 IdP）核發的醫療執照是 SAML/OIDC 斷言。由醫院董事會（組織管理）設定的適用於大樓內每個人的醫院政策手冊（「鴉片類藥物處方不得超過 30 天供應量，麻醉藥品未經顧問簽字不得使用」）就是 SCP。醫務主任在授予新任主治醫生特權列表時設定的科室級上限（「即使您簽署自己的特權修正案，也不能超過此上限」）就是許可邊界。醫生實際的特權列表（「可以開胰島素、抗生素和降血壓藥」）是身分策略。藥房自己的配藥規則（「管制藥品架僅對列入管制清單的主體開放」）是資源策略。值班期間的限制（「在本次 8 小時值班期間，不得為與該醫生有利益衝突的患者 X 開處方」）是工作階段策略。代班醫生（機器身分）不會獲得永久執照 —— 他們在每次值班時透過身分聯手獲得一班制的臨時認證。醫院信任外部執照委員會，但仍執行自己系統的每一層。

類比 3 —— 大使館簽證與海關分層檢查系統（邊境管制類比）

想像國際機場的邊境管制系統。身分聯手與許可邊界是旅客從護照到入境從事特定活動之間的一系列分層檢查站。

由您政府驗證的母國護照是 IdP 核發的 SAML/OIDC 權杖。將您的護照轉換為入境簽證的大使館是 IAM 身分中心或 AssumeRoleWithSAML 端點。類別為「觀光 90 天」或「工作許可 2 年」或「過境 24 小時」的簽證戳記本身是臨時 STS 認證。每個機場張貼的列出無論簽證類型為何都絕不允許的類別（「禁止攜帶武器、禁止攜帶農產品」）的海關申報單是 SCP。規定「觀光簽證持有者不得從事有酬工作，即使當地雇主提供合約」的每類簽證上限是角色上的許可邊界。准許您從事特定工作的特定雇主信函是身分策略。特定工作場所的安全規則是資源策略。而工作場所經理應用的每班限制（「今天您只被允許進入 A 區」）是工作階段策略。身分聯手使這成為可能 —— 國家信任發證政府，簽證自動到期，其他一切在數百萬旅客中保持一致。

SAML 2.0 聯手 —— 企業標準 IdP 路徑

SAML 2.0 是長期的企業聯手協定，DOP-C02 要求您瞭解其 IAM 細節。

建立信任

在 SAML 聯手中，您透過上傳 IdP 的中繼資料 XML（包含 IdP 簽署憑證、SSO 端點 URL 和實體 ID 的文件），在每個 AWS 帳戶中建立一個 IAM SAML 身分供應商。中繼資料由 Okta、Azure AD、ADFS、Ping、OneLogin、Auth0 和 Google Workspace 以可下載文件或發布 URL 的形式提供。一旦註冊，IdP 就是信任根；AWS 將接受由 IdP 憑證簽署的任何 SAML 斷言。

AssumeRoleWithSAML 流程

使用者在 IdP 處進行身分驗證（瀏覽器重定向到 Okta 登入、MFA 等）。IdP 核發包含使用者身分和使用者獲准假設的角色 ARN 列表（編碼在 https://aws.amazon.com/SAML/Attributes/Role 屬性中）的已簽署 SAML 回應。使用者的瀏覽器將斷言 POST 到 AWS 登入頁面，該頁面調用 sts:AssumeRoleWithSAML 並為所選角色返回臨時認證。工作階段持續時間：1 到 12 小時，在角色的 MaxSessionDuration 上設定。

ABAC 的 SAML 屬性映射

SAML 斷言可以攜帶屬性（部門、成本中心、專案），AWS 透過 https://aws.amazon.com/SAML/Attributes/PrincipalTag 命名空間將其轉換為工作階段標籤。工作階段標籤驅動 ABAC —— 身分策略使用 aws:PrincipalTag/department 僅授予對標記有相同部門的資源的存取權限。一個角色定義可以服務數十個部門，因為斷言提供的標籤在工作階段期間縮小了有效存取範圍。

何時選擇 SAML

當企業 IdP 已建立且集中化（ADFS、Azure AD、Okta）、當員工主要使用基於瀏覽器的主控台存取，且 MFA、條件式存取和生命週期管理已存在於 IdP 中時，請選擇 SAML。在「5,000 名開發人員、中央 Active Directory、必須在沒有 IAM 使用者的情況下存取 AWS 主控台」為要求的 DOP-C02 情境中，SAML 是答案。

OIDC 聯手 —— CI/CD 與 Web 身分的現代選擇

OIDC (OpenID Connect) 是現代基於 OAuth 2.0 的聯手協定，DOP-C02 強調將其用於機器身分和 CI 系統。

為什麼 GitHub Actions 和 CI/CD 要使用 OIDC

旗艦使用案例是 GitHub Actions 在不將長期存取金鑰存儲為儲存庫秘密的情況下部署到 AWS。GitHub 在每次工作流運行時發布 OIDC 權杖；AWS 根據 GitHub 發布的 JWKS 驗證權杖簽署，並透過 sts:AssumeRoleWithWebIdentity 核發臨時認證。角色的信任策略使用 token.actions.githubusercontent.com:sub 條件鎖定 GitHub 組織、儲存庫和分支 —— 只有指定的工作流可以假設該角色。

GitHub OIDC 的信任策略模式

{
  "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 宣告鎖定到確切的分支或環境，以防止分支 (fork) 或功能分支假設生產角色。

用於行動和 Web 應用程式的 Cognito 身分池

Cognito 身分池提供另一種 OIDC 形式 —— 向透過 Google、Apple、Facebook 或自定義 OIDC IdP 驗證的行動/Web 應用程式終端使用者核發 AWS 臨時認證。應用程式收到範圍限於已驗證或未驗證角色的認證，並透過身分池角色映射進行精確控制。

OIDC 供應商指紋 (Thumbprint)

建立 IAM OIDC 供應商時，AWS 會記錄 IdP 的 TLS 憑證 SHA-1 指紋。如果 IdP 輪換其憑證，您必須更新指紋，否則 AssumeRoleWithWebIdentity 調用將失敗。AWS 現在會自動獲取知名供應商（GitHub、Bitbucket）的指紋，但第三方 OIDC 供應商可能需要手動重新整理指紋。

AWS IAM 身分中心 —— 推薦的人員進入點

AWS IAM 身分中心 (IAM Identity Center，原 AWS SSO) 是受管的多帳戶聯手服務，DOP-C02 將其視為預設的人員存取模式。

身分中心如何運作

身分中心維護一個身分存放區（內建，或透過 SCIM 從 Azure AD/Okta/Google Workspace 同步），以及一個權限集目錄。使用者登入單一 AWS 存取入口網站 URL，查看所有分配的帳戶和權限集，然後點擊進入以在他們有權存取的任何帳戶中獲取臨時認證。在幕後，身分中心在每個成員帳戶中配置名為 AWSReservedSSO_<PermissionSetName>_<HASH> 的 IAM 角色，其信任策略允許身分中心服務假設該角色。

權限集 (Permission Sets)

權限集是一個模板，結合了 AWS 受管策略、客戶受管策略、內嵌策略以及（關鍵的）一個許可邊界，形成一個可重複使用的組合。分配權限集 + 帳戶 + 使用者/群組，身分中心就會在該帳戶中配置對應的角色。一個權限集可以服務於適用相同存取模式的所有帳戶 —— 中央定義，分散執行。

身分中心 vs 直接 SAML/OIDC

身分中心封裝了 SAML 聯手，但增加了多帳戶編排、工作階段生命週期治理和存取入口網站使用者體驗。對於「100 個帳戶中 5,000 名開發人員需要瀏覽器主控台存取」的答案始終是身分中心，絕不是手動維護的按帳戶 SAML 供應商。

工作階段持續時間與 ABAC

權限集定義了工作階段持續時間（1-12 小時）。身分中心透過將 IdP 屬性映射到工作階段標籤來支持 ABAC —— costCenter SCIM 屬性會自動變為 aws:PrincipalTag/costCenter。ABAC 權限集在其策略中引用 aws:PrincipalTag，授予僅限於使用者成本中心的存取權限，而不會造成每個成本中心的角色激增。

許可邊界 —— 身分策略的上限

許可邊界 (Permission Boundaries) 是 DOP-C02 在委派情境中測試最嚴格的 IAM 功能。

許可邊界的作用

許可邊界是附加到 IAM 使用者或角色的 IAM 受管策略，它定義了該實體可以擁有的最大權限，無論附加了什麼身分策略。它不授予權限，僅限制權限。有效權限是身分策略與許可邊界的交集。

許可邊界使用案例 —— 開發者自我服務

正統使用案例：平台團隊希望開發人員為其應用程式建立 IAM 角色，而無需提交票據。如果沒有許可邊界，授予 iam:CreateRole 和 iam:AttachRolePolicy 會讓開發人員建立具備 AdministratorAccess 的角色，從而破壞最小權限。有了許可邊界，平台團隊可以：

1. 定義一個受管策略 DevPermissionBoundary，其中包含任何開發人員建立的角色可能擁有的最大權限（例如 S3 讀/寫、針對標記資料表的 DynamoDB 讀/寫、CloudWatch Logs 寫入 —— 但沒有 IAM、沒有 Organizations、沒有 KMS 金鑰建立）。
2. 僅在 iam:PermissionsBoundary 等於 arn:aws:iam::123:policy/DevPermissionBoundary 的角色上，授予開發人員 iam:CreateRole 和 iam:PutRolePolicy 權限。
3. 現在開發人員可以建立他們需要的任何角色；角色的有效權限永遠不會超過該邊界，即使開發人員附加了 AdministratorAccess 作為身分策略也是如此。

許可邊界 vs SCP

許可邊界評估陷阱

一個常見陷阱：開發人員認為附加許可邊界會授予權限。事實並非如此。如果沒有身分策略授予 s3:GetObject，即使邊界允許 S3，該角色也無法讀取 S3。邊界是上限，而不是底限。兩層都必須允許。

設定 iam:PermissionsBoundary 條件

平台團隊授予開發人員 iam:CreateRole 的策略必須透過條件強制附加邊界：

{
  "Effect": "Allow",
  "Action": ["iam:CreateRole", "iam:PutRolePolicy", "iam:AttachRolePolicy"],
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "iam:PermissionsBoundary": "arn:aws:iam::123:policy/DevPermissionBoundary"
    }
  }
}

同時要求僅對帶有此邊界的角色授予 iam:PassRole 權限，並明確拒絕 iam:DeleteRolePermissionsBoundary 和 iam:PutRolePermissionsBoundary，使開發人員無法移除或更改邊界。

SCP vs 許可邊界 vs 工作階段策略 —— 五層評估

DOP-C02 經常測試精確的評估順序。請記住這個層級結構。

評估順序 (AWS 權威)

要使 API 調用成功，所有適用的層級都必須允許該調用：

1. SCP —— 適用於帳戶/OU 中的每個主體（包括根使用者）。如果移除了 FullAWSAccess，則預設拒絕；否則僅限允許清單中的動作。
2. 基於資源的策略 —— 明確的允許可以授予跨帳戶存取權限，而無需身分策略。明確的拒絕則否決一切。
3. 身分型策略 —— 主體的使用者/角色策略必須允許。
4. 許可邊界 —— 對於已附加的使用者和角色必須允許。
5. 工作階段策略 —— 在 AssumeRole 或 GetFederationToken 時傳遞，進一步縮小範圍。

任何層級的明確拒絕都會覆寫所有允許。預設行為是拒絕 —— 跨身分策略或資源策略至少需要一個明確的允許。

跨帳戶特殊情況

跨帳戶存取要求信任帳戶的資源/角色策略以及受信任帳戶的身分策略兩者都允許該動作。調用主體上的許可邊界適用。兩個帳戶上的 SCP 均適用。

工作階段策略使用案例

工作階段策略是在 sts:AssumeRole 時傳遞的內嵌策略。使用案例：CI 管道假設一個部署角色，但對於特定的部署，透過傳遞工作階段策略進一步縮小存取範圍（例如，僅允許寫入特定的堆疊名稱）。角色的身分策略仍然適用；工作階段策略與其相交。

ABAC —— 大規模標籤型存取控制

ABAC (Attribute-Based Access Control) 是 DOP-C02 推薦的多團隊擴展模式。

ABAC 如何運作

不為每個團隊設定一個角色，而是定義一個使用標籤條件的身分策略角色：

{
  "Effect": "Allow",
  "Action": ["s3:GetObject", "s3:PutObject"],
  "Resource": "arn:aws:s3:::*/*",
  "Condition": {
    "StringEquals": {
      "aws:PrincipalTag/project": "${aws:ResourceTag/project}"
    }
  }
}

具有工作階段標籤 project=alpha 的使用者僅能存取標記為 project=alpha 的 S3 物件。一個角色定義可以服務於任意數量的專案。

來自聯手的工作階段標籤

ABAC 之所以有效，是因為身分聯手可以提供工作階段標籤。映射到工作階段標籤的 SAML 屬性、映射到工作階段標籤的 OIDC 權杖宣告、映射到工作階段標籤的 IAM 身分中心 SCIM 屬性 —— 都會自動填充 aws:PrincipalTag。

ABAC 的權衡

ABAC 擴展性極佳，但要求對所有資源進行嚴格的標籤管理。沒有正確標籤的資源對受 ABAC 限制的主體是不可見的 —— 優點是防止意外存取，缺點是忘記標籤時會破壞工作流。將 ABAC 與要求所有資源都具備 project 標籤的 Config 規則，以及用於追溯標記的 AWS Resource Groups 標籤編輯器結合使用。

ABAC vs RBAC

RBAC（基於角色）為每個存取模式建立一個角色：AlphaProjectDeveloper、BetaProjectDeveloper 等。角色數量會迅速爆炸。ABAC 建立一個角色，並在工作階段時變更標籤。提到「100 個專案團隊需要針對其自身資源的類似存取模式」的 DOP-C02 情境始終是 ABAC。

機器身分 —— EC2, ECS, Lambda, CodeBuild

身分聯手也涵蓋了機器身分；DOP-C02 要求您瞭解每個計算原語的身分機制。

EC2 執行個體設定檔 (Instance Profiles)

附加透過執行個體設定檔的角色讓 EC2 執行個體從 IMDSv2 (http://169.254.169.254/latest/meta-data/iam/security-credentials/<role>) 獲取臨時認證。務必強制執行 IMDSv2（要求權杖）以防止基於 SSRF 的認證盜取。切勿在使用者數據或 AMI 中嵌入存取金鑰。

ECS 任務角色 (Task Roles)

ECS 任務（Fargate 或 EC2）透過 ECS 代理程式的中繼資料端點假設任務角色。這與執行個體設定檔不同：每個任務可以有自己的角色，提供每個微服務的最小權限。任務執行角色 (Task Execution Role)（與任務角色分開）是 ECS 用於從 ECR 提取映像和寫入日誌的角色 —— 請將這兩者分開。

Lambda 執行角色

Lambda 函數會自動假設其執行角色；臨時認證透過環境變數公開。Lambda 執行角色應為每個函數一個，並具備最小的 CloudWatch Logs 和按函數資源的權限。

CodeBuild 服務角色

CodeBuild 使用服務角色來存取 CodeCommit/S3 來源、推送到 ECR、寫入 CloudWatch Logs 並執行任何部署動作。CodeBuild 在建置期間也可以透過 STS 假設跨帳戶角色 —— 這是跨帳戶成品部署的正統模式。

角色鏈接與 STS —— 跨帳戶存取模式

角色鏈接 (Role Chaining) 是一個角色假設另一個角色的模式，在 DOP-C02 中被大量測試。

sts:AssumeRole 機制

角色 A（已驗證）調用角色 B 的 sts:AssumeRole，提供角色 B 的 ARN 和外部 ID（建議用於跨帳戶）。角色 B 的信任策略必須允許角色 A 的主體。返回的認證在請求的持續時間內有效（鏈接角色的上限為 1 小時，而第一跳則高達 12 小時）。

鏈接角色的工作階段限制

無論角色的設定為何，鏈接角色的 MaxSessionDuration 上限為 1 小時。考試會測試這一點 —— 使用鏈接角色運行的超過 1 小時的管道必須重新整理認證。

外部 ID 用於第三方存取

在授予第三方 SaaS（Datadog、Splunk Observability、第三方 SIEM）跨帳戶存取權限時，要求在信任策略中使用 sts:ExternalId。外部 ID 是一個共享秘密，可防止混淆代理問題 —— 即使攻擊者得知您的帳戶 ID 和角色 ARN，在沒有 SaaS 使用的外部 ID 的情況下，他們也無法假設該角色。

AssumeRole 的來源 IP 條件

信任策略可以要求 aws:SourceIp 位於已知的 CIDR 範圍內，將角色假設限制在公司網絡或特定的 NAT 出口 IP。與 VPC 端點結合使用以進一步鎖定。

IAM Access Analyzer —— 產生與外部存取

IAM Access Analyzer 是 DOP-C02 要求您善用的服務。

從 CloudTrail 產生策略

Access Analyzer 可以分析角色的 CloudTrail 歷史紀錄，並產生反映角色實際執行動作的最小權限策略。工作流：角色帶著寬鬆權限運行 30-90 天，Access Analyzer 根據觀察到的動作產生緊湊策略，平台團隊將寬鬆策略替換為產生的策略。這實現了最小權限精煉的自動化。

外部存取發現

Access Analyzer 持續評估資源策略（S3 儲存貯體、KMS 金鑰、IAM 角色、Lambda 函數、Secrets Manager 秘密、SQS 佇列等），偵測來自信任區域（組織或指定的信任區域）以外的存取。發現結果會流向 Security Hub 進行彙總。考試測試識別「我們需要偵測開發人員何時使 S3 儲存貯體具備跨帳戶寫入權限」 —— 答案是 Access Analyzer。

未使用的存取發現

Access Analyzer 還會識別未使用的 IAM 角色以及角色內未使用的權限，提供可執行的最小權限建議。這與 Access Analyzer 策略產生相輔相成。

IAM 策略模擬器與 CloudTrail 用於權限稽核

策略模擬器和 CloudTrail 是驗證身分聯手與許可邊界設定的日常工具。

策略模擬器 (Policy Simulator)

IAM 策略模擬器在不執行動作的情況下，針對特定資源評估主體是否具備特定動作的權限。它會考量身分策略、資源策略、許可邊界和 SCP。在生產環境推出邊界變更前，使用它來驗證變更。

用於授權稽核的 CloudTrail

每個 IAM 授權決策都會記錄到 CloudTrail（AssumeRole、ConsoleLogin、DecodeAuthorizationMessage）。詢問「誰在什麼時候假設了這個角色」的 DOP-C02 情境就是 CloudTrail 查詢。與 CloudTrail Lake 結合使用，可實現 SQL 查詢的多年度歷史紀錄。

常考陷阱 (Common Exam Traps)

DOP-C02 有一些可預測的身分聯手與許可邊界陷阱：

1. 將 GitHub 秘密存儲為 IAM 存取金鑰 —— 錯誤。始終使用具備 AssumeRoleWithWebIdentity 的 OIDC 聯手。
2. 混淆 SCP 與許可邊界 —— SCP 是組織級別（整個帳戶），許可邊界是按 IAM 實體。委派案例使用許可邊界；帳戶範圍的預防性控制使用 SCP。
3. 假設許可邊界會授予權限 —— 它們僅起限制作用。身分策略仍必須允許。有效權限集是交集。
4. 忘記鏈接角色的 1 小時工作階段上限 —— 使用鏈接角色且長度超過 1 小時的管道必須重新整理認證。
5. 第三方信任缺少外部 ID —— 沒有外部 ID，混淆代理會讓任何得知您 ARN 的帳戶假設該角色。
6. 對機器使用 IAM 使用者 —— 始終使用角色。EC2 執行個體設定檔、ECS 任務角色、Lambda 執行角色、EKS IRSA。絕不使用長期存取金鑰。
7. 按團隊角色爆炸 (RBAC) 而非 ABAC —— 對於許多類似的團隊，一個帶有工作階段標籤的 ABAC 角色可擴展；每個團隊一個角色在大規模下是錯誤答案。
8. 忘記拒絕邊界移除 —— 如果開發人員可以調用 iam:DeleteRolePermissionsBoundary，整個委派模型就會崩潰。對邊界變更進行明確拒絕是強制性的。
9. 信任策略 sub 宣告過於寬鬆 —— repo:org/*:* 允許任何分支進行部署。請鎖定到 repo:org/repo:ref:refs/heads/main 或 :environment:production。
10. 啟用 IMDSv1 —— 易受 SSRF 攻擊。始終強制執行 IMDSv2 權杖要求模式。

常見問題

Q1：何時使用 SAML vs OIDC vs IAM 身分中心？ SAML 用於舊式企業 IdP (ADFS, Okta classic)。OIDC 用於現代 Web/行動應用程式和 CI 系統（GitHub Actions, Cognito 面向使用者）。IAM 身分中心用於跨多個 AWS 帳戶的集中式人員存取 —— 它封裝了 SAML 並增加了帳戶感知的使用者體驗。DOP-C02 中人員存取的預設為身分中心；CI 的預設為 OIDC。

Q2：委派角色建立使用許可邊界還是 SCP？ 許可邊界。SCP 不能在帳戶內對自己設定；只有組織管理帳戶或委派管理員可以更改 SCP。許可邊界由帳戶內的 IAM 管理員針對單個使用者/角色設定。委派「開發人員可以在此上限內建立角色」正是許可邊界的使用案例。

Q3：許可邊界可以授予 SCP 禁止的動作嗎？ 不可以。SCP 作為外層上限首先被評估。許可邊界隨後進一步縮小範圍。身分策略也必須允許。有效權限集是這三者的交集。從 SCP 中移除某個動作會為帳戶中的每個人移除該動作，無論邊界或身分策略如何。

Q4：如何在不存儲 AWS 金鑰的情況下讓 GitHub Actions 進行部署？ 在您的 AWS 帳戶中配置 GitHub OIDC 身分供應商。建立一個部署角色，其信任策略允許來自 token.actions.githubusercontent.com 的 sts:AssumeRoleWithWebIdentity，且 sub 宣告鎖定到您的特定儲存庫和分支（例如 repo:org/repo:ref:refs/heads/main）。配置工作流，使用角色 ARN 調用 aws-actions/configure-aws-credentials@v4。工作流在每次運行時獲取短期認證。

Q5：什麼是 ABAC，它何時優於 RBAC？ ABAC 在主體和資源上使用標籤，根據屬性匹配（例如 aws:PrincipalTag/project = aws:ResourceTag/project）授予存取權限。RBAC 針對每個存取模式使用角色。當許多團隊共享相同的存取模式但處理不相交的資源集時，ABAC 勝出 —— 100 個專案團隊只需一個角色，而不是 100 個角色。需要嚴格的資源標籤管理和 IdP 提供的工作階段標籤。

Q6：角色鏈接與直接 AssumeRole 有何不同？ 角色鏈接是一個角色假設另一個角色 (Role A → Role B)。直接 AssumeRole 是來自長期主體（IAM 使用者）或聯手工作階段對角色的假設。無論目標角色的 MaxSessionDuration 設定為何，鏈接角色的上限均為 1 小時。第一跳工作階段則可長達 12 小時。

Q7：外部 ID 的作用是什麼，我何時必須使用它？ 外部 ID 是信任策略條件 sts:ExternalId 中的共享秘密。在授予第三方（例如 Datadog）跨帳戶存取權限時是必需的。沒有它，可能會發生混淆代理：得知您角色 ARN 的攻擊者可以從該第三方的不同客戶帳戶假設該角色。AWS 強烈建議對您無法控制的服務進行任何跨帳戶信任時使用外部 ID。

Q8：我可以對 IAM 使用者使用許可邊界，還是只能對角色使用？ 兩者都可以。許可邊界附加到 IAM 使用者和 IAM 角色。它們對 AWS 服務主體或根使用者沒有影響。對於 IAM 身分中心配置的角色，權限集定義中包含了邊界；直接修改角色的邊界會在下次配置同步時被覆寫。

Q9：為什麼我的 Lambda 角色在邊界允許的情況下仍執行動作失敗？ 因為邊界是上限，而不是授權。Lambda 執行角色的身分策略也必須允許該動作。請同時檢查兩者：附加到角色的身分策略以及許可邊界。有效權限是兩者的交集。

Q10：如何偵測跨帳戶存取洩漏？ IAM Access Analyzer 外部存取發現。在每個帳戶中啟用 Access Analyzer（或使用 Security 委派管理員），將您的信任區域定義為您的組織，Access Analyzer 會持續評估 S3 儲存貯體、KMS 金鑰、IAM 角色、Lambda 函數、Secrets Manager 秘密、SQS 佇列等的資源策略是否存在跨區域存取。發現結果會流向 Security Hub。

總結 —— IAM 身分聯手與許可邊界心法

IAM 身分聯手透過信任外部 IdP 消除長期認證；許可邊界對委派管理員可以授予的權限設定上限。在 DOP-C02 任務 6.1 中，正確答案始終結合了：OU 級別的 SCP、開發人員建立角色上的許可邊界、用於實際權限的身分策略、跨團隊擴展的 ABAC、用於 CI 的 OIDC 聯手、用於人員的身分中心、用於計算的機器角色（執行個體設定檔、任務角色、執行角色）、用於持續驗證的 IAM Access Analyzer 以及用於稽核的 CloudTrail。每個專業級的身分與存取情境都融合了這三項或更多技術 —— 單層答案都是干擾項。

成熟的 DOP-C02 答案模式是分層的：SCP 為帳戶設定圍欄；許可邊界為開發人員設定圍欄；身分策略授予工作負載所需的權限；ABAC 按標籤劃分範圍；工作階段策略縮小每次調用的範圍。身分聯手是通用的進入點 —— 人員透過身分中心，機器透過 OIDC 或執行個體角色，第三方透過外部 ID。長期存取金鑰在任何地方都是錯誤答案。