IAM Identity Center 與企業身份聯合

AWS IAM Identity Center 是 AWS Organizations 的員工身分平台——它負責整合你的使用者是誰、他們的身分實際存放在哪裡（內建目錄、AD Connector 或外部 SAML 身分提供者）、如何佈建他們（從 Okta、Microsoft Entra ID、Google Workspace 或 JumpCloud 以 SCIM 推送）、他們能做什麼（在每個成員 AWS 帳號中以 IAM 角色實體化的 permission sets），以及日益重要的如何將身分帶往下游——透過 trusted identity propagation 延伸到 Amazon EMR、Amazon Redshift 與 AWS Glue 等分析引擎。在 SAP-C02，考試期望你能端到端地設計這套架構——而不是只挑對核取方塊——並能依據組織限制（受監管產業、現有 Active Directory 投資、稽核要求、跨帳號存取規模）在原始 SAML 聯合至 IAM、IAM Identity Center 搭配外部 IdP、以及 IAM Identity Center 搭配內建目錄之間做出正確選擇。

本指南假設你已具備 CLF-C02 等級的 AWS 存取管理基礎，並深入 Pro 等級的進階內容：搭配 customer-managed policies 與 permissions boundaries 的 permission set 設計、利用 SAML assertion 中流入 IAM condition keys 的 session tags 實作 ABAC、analytics 工作負載的 trusted identity propagation、作為爆炸半徑控制的委派管理員，以及從舊版 AWS SSO 的遷移路徑。

IAM Identity Center 真正是什麼（以及不是什麼）

AWS IAM Identity Center — 於 2022 年 7 月從 AWS Single Sign-On 更名 — 是一項區域性 AWS 服務，與 AWS Organizations 整合，為員工提供單一登入（SSO）、多帳號存取，以及 AWS 受管與外部 SaaS 應用程式的存取。IAM Identity Center 不會取代 AWS IAM；它架設在 AWS IAM 之上，在底層，每個 IAM Identity Center permission set 都會成為一個 IAM 角色（具有特定命名前綴 AWSReservedSSO_<permission-set-name>_<random-suffix>），存在於 permission set 被指派的每個 AWS 帳號中。使用者在 IAM Identity Center 存取入口網站登入一次，選擇 AWS 帳號與 permission set，即可取得該 IAM 角色的短期 AWS STS 憑證。

IAM Identity Center 不是什麼：它不是客戶身分服務（那是 Amazon Cognito）、不是 AWS 服務主體的 IAM 替代品（Lambda 執行角色、EC2 執行個體設定檔仍使用純 AWS IAM），也不是目錄服務（它有內建目錄，但無法取代 AWS Managed Microsoft AD——當你需要一個真正的目錄來支援 Windows 工作負載、群組原則或 Kerberos 時）。

IAM Identity Center 為何在 SAP-C02 如此重要

SAP-C02 考試指南明確測試「設計跨組織存取策略」（領域 1 — 設計組織複雜性）。在 Pro 等級，幾乎每個多帳號情境現在都以 IAM Identity Center 作為基準答案，將 SAML 聯合至 IAM 和獨立 IAM 使用者帳號視為舊有備用方案。預期會出現結合 IAM Identity Center、AWS Organizations SCPs、AWS Control Tower guardrails，以及 ABAC 的情境，用於多租戶或多專案隔離。

白話文解釋 IAM Identity Center SSO

在淹入 SCIM 和 session tags 之前，先用三個類比涵蓋 SAP-C02 會考到的每個 IAM Identity Center 概念。

類比一：捷運悠遊卡系統

把整個架構想像成台灣的捷運悠遊卡系統。你的公司有 40 個據點（你的 40 個 AWS 帳號）。你不希望每位員工持有 40 張不同的門禁卡與 40 組帳號密碼。因此，你建立了一個統一的客服中心——IAM Identity Center 存取入口網站。員工走進來出示公司識別證（他們來自 Okta 或 Microsoft Entra ID 的外部 IdP 憑證）。服務人員掃描後（SAML assertion），查閱員工今天被允許進入哪些據點（assignments），並為他們選定的據點核發一張臨時悠遊卡（特定 permission set 角色的 STS 短期憑證）。到期時間一到，悠遊卡失效。員工永遠不會持有任何特定據點的永久磁卡。

HR 系統每小時將新進與離職員工推送到服務中心就是 SCIM。每張悠遊卡上的規則（「可進入 3-5 樓，不可進入 12 樓」）就是 permission set 的政策。**「工程師只能進入標記其專案代碼的據點」**就是 ABAC——員工的部門標籤從 HR 流入悠遊卡，每道門在開啟前都會檢查標籤。

類比二：大學圖書館借閱證

IAM Identity Center 就像由教務處核發的大學圖書館借閱證。教務處資料庫是身分來源——或者自行維護（內建目錄）、或每晚從招生辦公室同步（AD Connector）、或完全外包給聯合系統（外部 SAML IdP）。借閱證本身不列明你能借哪些書——圖書館另外有按讀者類別分類的規則冊（permission sets）：「大學部學生最多借 10 本，借期 14 天」、「研究生可進入限閱書庫 30 天」、「教師可申請館際互借」。你出示借閱證時，館員根據你的類別套用對應的規則冊。

Trusted identity propagation 就是你把借來的書帶去館際互借系統時發生的事——互借系統看到的不是「某位讀者借了此書」，而是「化學系陳教授借了此書」，並能套用陳教授專屬的預約規則。Permission set 內的 customer-managed policy 是院系專屬規則補充冊（「化學系在全校通用規則之上，增加這三條特別規定」），讓所在帳號的管理員能自行修改，無需打擾教務處。

類比三：機場快速通關道

想像一個全球航空聯盟。你的常旅客資格（IAM Identity Center 使用者身分）由你的主航空公司核發（外部 IdP，如 Okta）。當你到達合作航空的登機口（成員 AWS 帳號），地勤人員不需要從頭重新驗證你——他們信任聯盟的聲明，並給你臨時登機通行證（permission set 角色 session）。不同合作航空依你的資格等級有不同貴賓室規則——有些機場只給黃金會員，有些限白金會員。這個等級對應貴賓室的映射就是將 permission set 指派給 AWS 帳號。

委派管理員是聯盟讓區域樞紐航空在其轄區負責聯盟服務台——區域樞紐可發放通行證、管理本地貴賓室權限，卻無法修改全球聯盟的頂層規則。Trusted identity propagation 則是你的常旅客身分如何跟著你上由其他航空執行的共掛班機——合作夥伴的機上服務仍認識你本人，而非「某位聯盟旅客」。

身分來源 — 內建目錄 vs AD Connector vs 外部 SAML IdP

身分來源是 IAM Identity Center 部署的第一個架構決策。你可以更換它，但切換身分來源會刪除 IAM Identity Center 中所有現有的使用者與群組，並清除所有指派——這使它成為服務中最痛苦的操作之一，請謹慎選擇。

內建目錄（Identity Center 目錄）

內建目錄將使用者與群組直接儲存在 IAM Identity Center 內，存放於一個受管的多租戶儲存中。你可在主控台手動建立使用者，或透過 SCIM 從非 SAML 來源推送。驗證直接對 IAM Identity Center 進行——不涉及外部 IdP。密碼政策、MFA 與 session 長度全部在 IAM Identity Center 內設定。

在以下情況使用內建目錄：

• 你是沒有現有企業 IdP 的小型團隊。
• 你希望在不啟動聯合專案的情況下，快速實現多帳號 SSO。
• 合規要求禁止依賴外部 IdP。
• 你需要 IAM Identity Center 作為員工身分的記錄系統（system of record）。

Active Directory 整合（AWS Managed Microsoft AD 或 AD Connector）

若你的組織使用內部部署 Active Directory 或 AWS Managed Microsoft AD，你可以將 IAM Identity Center 連接到該目錄。有兩種變體：

• AWS Managed Microsoft AD — 在 VPC 內執行的受管真實 AD；IAM Identity Center 直接與其聯合。在你想現代化至 AWS 託管 AD、同時保留 AD 原生功能（Kerberos、群組原則）時使用。
• AD Connector — 一個輕量目錄閘道，透過 VPN 或 AWS Direct Connect 將 IAM Identity Center 請求代理至現有內部部署 AD。在你想保留內部部署 AD 作為權威來源時使用。

兩種變體都讓 IAM Identity Center 具備原生 AD 群組能見度，因此你可以將 permission sets 指派給真實的 AD 安全群組，無需 SCIM。注意事項：AD 整合是區域性的（目錄必須與 IAM Identity Center 執行個體在相同區域），且某些功能（AD 屬性 ABAC、MFA 政策）的設定方式略有不同。

外部 SAML 2.0 身分提供者

對於使用 Okta、Microsoft Entra ID（Azure AD）、Google Workspace、JumpCloud、Ping Identity、OneLogin 或其他任何 SAML 2.0 IdP 的現代雲端優先組織，你可以將 IAM Identity Center 連接為 SAML 服務提供者。IdP 驗證使用者、發出 SAML assertion，IAM Identity Center 信任該 assertion。使用者與群組的佈建透過 SCIM 2.0 從 IdP 流向 IAM Identity Center——IAM Identity Center 保留一份使用者與群組的本地快取，並在 IdP 推送變更時更新。

選擇正確的身分來源

SCIM 自動佈建 — Okta、Microsoft Entra ID、Google Workspace

若沒有自動佈建，每個新進員工或部門異動都需要手動更新 IAM Identity Center。SCIM 2.0（System for Cross-domain Identity Management）讓外部 IdP 能透過 REST API 以近乎即時的方式（通常最多 40 分鐘，通常只需幾分鐘）推送使用者與群組的變更至 IAM Identity Center，從而解決這個問題。

SCIM 與 IAM Identity Center 的運作方式

1. 你在 IAM Identity Center 主控台啟用自動佈建。AWS 產生一個 SCIM 端點 URL 和一個 bearer access token（預設有效期 1 年；你必須在到期前輪換）。
2. 在 IdP（Okta、Entra ID、Google Workspace）中，你設定一個 IAM Identity Center 佈建應用程式或 SCIM 整合，並貼上端點與 token。
3. 你在 IdP 中將使用者和群組指派給佈建應用程式。只有被指派的主體才會被推送。
4. IdP 將建立/更新/刪除事件推送至 IAM Identity Center。IAM Identity Center 將使用者與群組儲存在本地快取中；當使用外部 IdP 時，它不儲存密碼（驗證仍在 IdP 端進行）。

屬性對應

預設情況下，SCIM 推送一組標準欄位：userName、displayName、emails、givenName、familyName、active（用於停用）以及群組成員。針對 ABAC，你還需要從 IdP 的使用者設定檔對應自訂屬性——部門、成本中心、專案代碼、安全等級、AWS 帳號標籤——至 IAM Identity Center 使用者屬性，這些屬性之後會流入 SAML assertions 和 IAM session tags。

SAP-C02 的 SCIM 陷阱

• 不普遍支援巢狀群組——Okta 預設會將其攤平；Entra ID 需要特定設定。若 SAP-C02 情境暗示「複雜的 AD 群組巢狀結構」，預期會出現巢狀群組必須攤平或仔細對應的說明。
• 以群組指派為最佳實踐——將 permission sets 指派給 SCIM 佈建的群組，而非個別使用者。加入正確 IdP 群組的新進員工，會自動繼承正確的 AWS 帳號存取權。
• SCIM token 輪換是一年一次的節奏——請建立標準作業程序。到期的 token 在被替換前，會悄悄停止佈建。
• 單向同步——SCIM 是 IdP → IAM Identity Center 的單向同步。直接在 IAM Identity Center 進行的變更，在下一次推送時會被覆蓋。
• Entra ID 的限制包含最短 40 分鐘的 SCIM 同步間隔；若需要更快的傳播，可從 Entra 管理入口網站觸發隨需佈建週期。

Permission Sets — AWS 受管、自訂、Boundary、Session Duration

Permission set 是 IAM Identity Center 的授權單位。它是一個範本，在 IAM Identity Center 中集中儲存，並在每個被指派的 AWS 帳號中，以具名 IAM 角色的形式實體化。這個設計使 permission sets 能夠集中管理——修改範本會自動更新每個帳號中的 IAM 角色——也使它們受到 AWS Organizations SCPs 的約束，因為實體化的 IAM 角色存在於每個成員帳號內，受到該帳號 SCP 護欄的限制。

Permission set 的內容

一個 permission set 可包含最多 10 個 AWS 受管政策、最多 20 個以名稱引用的 customer-managed policies（政策本身必須存在於每個目標 AWS 帳號中）、恰好 1 個 inline policy（大小有限制）、1 個 permissions boundary（AWS 受管或 customer-managed），以及 session duration（1 至 12 小時之間）。

Session duration 是使用者以該 permission set 登入時所鑄造的 STS 憑證的最大存活時間。較短的 session 可縮小爆炸半徑；較長的 session 可降低長時間運行工作流程的工程師重新驗證的頻率。AWS 建議高權限 permission sets 設定 1-4 小時，低權限唯讀 permission sets 可設定至 8-12 小時。

Permission set 內的 AWS 受管政策 vs customer-managed policies

• AWS 受管政策（如 AdministratorAccess、ViewOnlyAccess、AmazonS3ReadOnlyAccess）以 ARN 引用，在每個帳號中都能正常運作。最簡單的選項，但粒度較粗。
• Inline policy 直接嵌入 permission set，並套用至所有被指派帳號中的每個實體化 IAM 角色。適合不因帳號而異的全組織細粒度規則。
• Customer-managed policies 是 Pro 等級的關鍵技巧：permission set 以名稱（DevOpsS3WriteAccess）引用政策，IAM Identity Center 在將角色實體化至目標 AWS 帳號時，預期該帳號中已存在一個名為 DevOpsS3WriteAccess 的 customer-managed IAM 政策，並將其附加。這讓帳號管理員能針對每個帳號調整政策內容——生產帳號中的 DevOpsS3WriteAccess 可以比開發帳號中的同名政策更嚴格——同時 permission set 仍集中管理。
• Permissions boundary 限制實體化 IAM 角色的有效權限上限。對於授予 IAM 權限的 permission sets 極為有用：boundary 確保角色無法建立權限超過 boundary 的其他 IAM 主體。

Permission set 設計模式

兩種模式主導良好架構的 IAM Identity Center 部署：

模式 A：職能導向的 permission sets。 依角色建立 permission sets（DataEngineer、NetworkAdmin、ReadOnlyAuditor、Developer），並指派給群組。每個 permission set 內部混合 AWS 受管政策（提供廣度）與 inline policy 或 customer-managed policy（用於組織特定限制）。此模式可擴展至 100+ 帳號規模的組織。

模式 B：環境等級的 permission sets。 依環境建立 permission sets（ProdReadOnly、NonProdFullAccess、ProdBreakGlass），並指派至對應等級的帳號。配合以 OU 為基礎的指派，使 Prod OU 中的新帳號自動繼承稽核人員的 ProdReadOnly。

實際部署通常結合兩個維度，形成一個（角色 × 環境）的 permission set 矩陣。若可以，請將總數控制在約 50 個以下——超過這個數量後，稽核與審查工作將變得困難。

實體化 IAM 角色的命名與主控台訊號

當 permission set 被指派至一個 AWS 帳號時，IAM Identity Center 會建立（或重用）一個名為 AWSReservedSSO_<permission-set-name>_<random-suffix> 的 IAM 角色。角色信任政策僅信任 IAM Identity Center 服務主體；你無法直接從 IAM 使用者假設此角色。主控台透過前綴識別受 SSO 管理的角色，AWS 建議絕不要手動編輯這些角色——變更在下一次 permission set 調和時會被覆蓋。

多帳號存取指派 — 三元組模型

IAM Identity Center 中的指派是一個三元組：(主體, permission set, AWS 帳號)。主體是 IAM Identity Center 使用者或群組；permission set 是你定義的範本之一；AWS 帳號是組織內的特定 AWS 帳號。

以群組指派為原則

對於規模超過幾個工程師的任何組織，你應該將 permission sets 指派給 IAM Identity Center 群組，而非個別使用者。這個模型隨 IdP 擴展：在 Okta 中將工程師加入 engineering-prod-ro 群組，群組透過 SCIM 同步至 IAM Identity Center 中的同名群組，自動授予他們在所有指派該群組的生產帳號中的 ProdReadOnly 存取——無需任何手動的 IAM Identity Center 操作。

跨多帳號指派

你可以透過主控台、API、AWS CloudFormation 或 Terraform 一次將群組對 permission set 的配對指派至多個帳號。對於擁有 50+ 帳號的 AWS Organizations，以程式碼管理指派（Terraform 的 aws_ssoadmin_account_assignment，或 AWS CDK）是必要的——主控台 UX 無法應對數百個指派的規模。

使用者如何在帳號間切換

登入後，使用者進入 IAM Identity Center 存取入口網站，看到 AWS 帳號清單，以及每個帳號下可用的 permission sets。選擇其中一個，即可以該權限聯合登入至對應帳號。對於 AWS CLI v2，使用者一次性執行 aws configure sso，之後每個 session 執行 aws sso login；IAM Identity Center 將短期憑證快取在 CLI 的 SSO 快取中，SDK 可透過 credential_process 整合自動取用。

屬性型存取控制（ABAC）— SAML 屬性 → Session Tags → IAM 條件

ABAC 是 IAM Identity Center 中旗艦級的 Pro 等級授權模式。你無需為每個使用者 × 專案 × 環境的組合撰寫一個 IAM 政策，而是以屬性標記資源，將使用者的屬性作為 session tags 流入 IAM Identity Center 登入，並撰寫一個 IAM 政策，將 ${aws:PrincipalTag/Project} 與 ${aws:ResourceTag/Project} 進行比較。

ABAC 端對端資料流

1. 使用者屬性存在於 IdP（Okta、Entra ID、Google Workspace）或 IAM Identity Center 目錄中——例如 department=Finance、project=Atlas、costCenter=CC-42。
2. SCIM 佈建將該屬性鏡像至 IAM Identity Center 使用者設定檔中，作為使用者屬性。
3. 登入時，IAM Identity Center 配置了存取控制屬性——一個映射，將特定使用者屬性轉換為假設 permission set 角色時 STS session 上的 session tags。
4. 在目標 AWS 帳號內，permission set 或資源上的 IAM 政策以條件鍵中的 ${aws:PrincipalTag/<tag-name>} 引用該 session tag，以決定存取。

在 IAM Identity Center 中啟用 ABAC

1. 在 IAM Identity Center 主控台，開啟存取控制屬性，切換為啟用。
2. 宣告哪些使用者屬性成為 session tag 鍵——例如 Project ← ${user:attribute:project}——使用特殊的映射語法。
3. 撰寫引用這些 session tags 的 permission set 政策：

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject", "s3:PutObject"],
    "Resource": "arn:aws:s3:::data-lake/*",
    "Condition": {
      "StringEquals": {
        "s3:ExistingObjectTag/Project": "${aws:PrincipalTag/Project}"
      }
    }
  }]
}

4. 以匹配的屬性值標記資源（S3 物件、EC2 執行個體、KMS 金鑰）。

結果：一個 IAM 政策服務所有專案。新增專案不需要建立新的 IAM 政策或 permission set——你只需標記專案資源，並將使用者加入正確的 IdP 群組。

ABAC vs RBAC 的 SAP-C02 選擇時機

SAP-C02 情境常考你能否識別何時 ABAC 優於 RBAC。觸發訊號為：

• 同一 AWS 帳號中有許多專案或租戶，各自有其標籤。
• 新專案頻繁啟動——RBAC 每次都需要新的 IAM 角色或 permission set。
• 屬性的真實來源已存在於 IdP 中（HR 系統的專案代碼、ERP 的成本中心）。
• 跨服務執行——S3、EC2、KMS、Secrets Manager、Lambda 都能評估資源標籤，因此一個政策涵蓋多項服務。

當這些訊號出現時，選擇 ABAC 搭配 IAM Identity Center session tags，而非複製 permission sets。

ABAC 陷阱

• Session tag 鍵區分大小寫。project 和 Project 是不同的標籤，不會匹配。
• Session tag 鍵最多 128 個字元；值最多 256 個字元。每個 session 最多可傳遞 50 個 session tags。
• 傳遞性 session tags（當角色鏈接到另一個角色時傳播的標籤）必須在假設角色呼叫中以 TransitiveTagKeys 明確標記——IAM Identity Center 目前不會自動將 ABAC 標籤標記為傳遞性。

Customer-Managed Permission Set Policies — 各帳號彈性

Permission set 中的 customer-managed policies 是最重要的 Pro 等級旋鈕之一，且容易與 AWS 受管或 inline policies 混淆。

運作方式

Permission set 以名稱而非 ARN 引用 customer-managed policy。例如，一個 permission set 可能引用 DataPlatformAccess。當 IAM Identity Center 將角色實體化至目標 AWS 帳號時，它預期該帳號中已存在名為 DataPlatformAccess 的 customer-managed IAM 政策——並以名稱附加該政策。

若政策不存在於目標帳號中，指派會失敗。這意味著你必須預先佈建具名 customer-managed policies 至每個目標帳號（通常透過 AWS CloudFormation StackSets 或 Terraform）。

為何此設計強大

• 各帳號調整：開發帳號中的 DataPlatformAccess 政策可以允許比生產帳號中同名政策更廣泛的 DynamoDB 存取。Permission set 相同；各帳號的政策內容不同。
• 遵守帳號邊界：每個帳號管理員擁有其帳號的政策內容，符合大型 AWS 組織的去中心化所有權。
• 支援 permissions boundary：customer-managed boundaries 運作方式相同——以名稱引用，在每個帳號中佈建 boundary 政策。

何時選擇 customer-managed 而非 inline

經驗法則：若政策內容必須因帳號而異，選 customer-managed policies。若政策是全組織通用且完全相同，inline 嵌入 permission set 更簡單，且避免了各帳號部署的額外工作。

Trusted Identity Propagation (TIP) — EMR、Redshift、Glue、QuickSight

Trusted identity propagation 是 SAP-C02 上最新且最常被考到的 IAM Identity Center 功能之一。傳統問題：當使用者執行 Amazon Redshift 查詢或 Amazon EMR Spark 任務時，下游服務看到的是一個共享 IAM 角色（執行角色、叢集角色），而非真實人員。這使得在 Redshift、Lake Formation、QuickSight 或 Glue 內部按使用者授權，與 IdP 群組成員資格連結幾乎不可能實現。

TIP 透過讓 AWS 分析服務將 IAM Identity Center 使用者的身分 token 帶往下游，改變了這個局面，使下游授權能檢查真實使用者的 IAM Identity Center 群組成員資格。

TIP 端對端運作方式

1. 使用者登入 IAM Identity Center（透過 Okta、Entra ID、內建目錄等），除了一般的 STS 憑證外，還取得一個 OIDC access token。
2. 使用者透過支援 IAM Identity Center 的客戶端（Redshift Query Editor v2、EMR Studio、QuickSight 入口網站）連接至 Amazon Redshift、Amazon EMR Studio、Amazon QuickSight 或 AWS Glue。
3. 客戶端隨請求傳遞 IAM Identity Center 身分 token。
4. AWS 分析服務將身分 token 傳播至下游元件——Lake Formation、Glue Data Catalog——這些元件基於 IAM Identity Center 使用者/群組（而非共享 IAM 角色）執行授權。
5. 稽核日誌（CloudTrail、Redshift 稽核日誌）現在為每個動作記錄真實人員的 IAM Identity Center 身分。

支援 trusted identity propagation 的服務

截至 2026 年，支援的服務包括：

• Amazon Redshift — Redshift Query Editor v2 與 IAM Identity Center 整合；Redshift 可將 IAM Identity Center 群組映射至 Redshift 資料庫角色。
• Amazon EMR Studio — 使用者以其 IAM Identity Center 身分啟動 notebooks，Spark 任務將身分傳播至 Glue Data Catalog 和 Lake Formation。
• AWS Glue 與 AWS Lake Formation — 資料表層級和欄位層級的權限可直接授予 IAM Identity Center 使用者/群組，而非 IAM 主體。
• Amazon QuickSight — 使用者透過 IAM Identity Center 登入，儀表板的列/欄安全性依 IAM Identity Center 屬性鎖定。
• Amazon S3 Access Grants — 更新的 S3 功能，依 IAM Identity Center 身分發行每使用者、每前綴的 S3 憑證。

TIP 前提條件與陷阱

• IAM Identity Center 必須在 AWS Organizations 層級啟用（非獨立帳號執行個體），才能廣泛傳播身分。
• 客戶端工具必須支援 TIP——僅使用 IAM 驗證的舊版驅動程式不會傳播身分。
• 使用外部 IdP 時，某些服務需要配置 AWS IAM Identity Center 受信任 token 發行者，將 IdP 發行的 token 映射為 AWS 識別的身分 token。
• 啟用 TIP 的服務的 CloudTrail 事件包含一個 onBehalfOf 欄位，標明 IAM Identity Center 使用者——在存取審查中善用此欄位。

IAM Identity Center 的委派管理

IAM Identity Center 在 AWS Organizations 管理帳號（付款帳號）建立並主要由其管理。但 AWS 安全最佳實踐是不從管理帳號執行日常操作——其爆炸半徑太大。委派管理讓你提名特定成員帳號來執行 IAM Identity Center 操作（建立 permission sets、進行指派、管理應用程式），而管理帳號保留最終所有權。

委派管理員能做和不能做的事

委派管理員可以：

• 建立、修改和刪除 permission sets。
• 為任何帳號建立和移除指派——除了 AWS Organizations 管理帳號本身。
• 管理 IAM Identity Center 應用程式和 SCIM 設定。
• 設定 ABAC 屬性。

委派管理員不能：

• 進行授予管理帳號存取權的指派（這仍然是管理帳號專屬，以保持爆炸半徑隔離）。
• 更改身分來源或刪除 IAM Identity Center 執行個體。
• 在組織層級啟用或停用 trusted identity propagation 設定。

委派管理員為何在 SAP-C02 中重要

每個良好架構的多帳號藍圖現在都將 Identity/SSO 操作放在專屬的安全或共用服務帳號（通常稱為「Security」或「Identity」帳號），而非管理帳號。AWS Control Tower 的預設 landing zone 會自動設定這一點。描述「盡量減少管理帳號活動」或「集中式安全工具的共用服務帳號」的 SAP-C02 情境，都指向委派管理。

從舊版 AWS SSO 遷移

IAM Identity Center 是 AWS SSO 的更名——同一服務，新名稱，並自 2022 年 7 月起新增了重要功能。若你找到現有的 AWS SSO 文件、部落格文章或引用 aws_sso 架構的 Terraform 模組，它們仍然有效；服務識別符、API 端點和 IAM 前綴為向下相容，仍保留 sso / sso-admin。

更名帶來的變化

• 主控台名稱與導覽：「AWS Single Sign-On」→「IAM Identity Center」。
• URL：存取入口網站 URL 格式從 d-xxxxxxxxxx.awsapps.com/start 更改為 .awsapps.com/start（兩者仍有效）。
• 更名後引入的新功能：permission sets 中的 customer-managed policies、trusted identity propagation、委派管理（適用於許多服務）、屬性存取控制增強、AWS CLI v2 aws sso login 改進，以及帳號執行個體 vs 組織執行個體。

帳號執行個體 vs 組織執行個體

更名後，IAM Identity Center 支援兩種執行個體類型：

• 組織執行個體（Organization instance） — 綁定至 AWS Organizations，從管理帳號管理，支援多帳號指派、trusted identity propagation、委派管理。這是預設值，也是 SAP-C02 假設的類型。
• 帳號執行個體（Account instance） — 單帳號範圍，適用於獨立 AWS 帳號或為每個客戶帳號嵌入 IAM Identity Center 的 SaaS 廠商。功能集有限（無全組織 SSO，TIP 受限）。

若你仍在使用原始 SAML 聯合至 IAM 的遷移步驟

仍在每個帳號的 AWS IAM 中直接設定 SAML 2.0 身分提供者（IAM Identity Center 出現前的模式）的組織，應計畫遷移至 IAM Identity Center：

1. 在管理帳號啟用 IAM Identity Center 並設定身分來源（強烈建議外部 IdP + SCIM）。
2. 將現有 SAML 角色建模為 permission sets。對於每個舊版 SAML IAM 角色，建立一個具有相同政策的 permission set。
3. 將 permission sets 指派至擁有 SAML 信任的相同帳號和群組。
4. 將使用者切換至 IAM Identity Center 存取入口網站 URL；廢棄 IdP 的直接對 AWS 的 SAML 應用程式。
5. 靜觀期後，從每個帳號的 AWS IAM 中移除 SAML 2.0 身分提供者設定，並移除舊版 IAM 角色。

所帶來的效益：集中式 permission set 管理（相較於各帳號 IAM 角色編輯）、內建 CLI SSO、ABAC、TIP 分析資格、SCIM 佈建（不再只是 SAML assertions），以及委派管理。

MFA、Session 政策與安全強化

IAM Identity Center 從其身分來源繼承強驗證，並具備其自身的控制機制。SAP-C02 上的關鍵強化旋鈕：

• Permission sets 中的 MFA 情境 — permission sets 可在其條件中引用 aws:MultiFactorAuthPresent，強制要求提升權限時登入時需完成 MFA。與對特權 permission sets 強制執行升級 MFA 的 IdP 搭配使用。
• Session duration — 依 permission set 調整。管理員設定 1-4 小時，工程師設定 4-8 小時，唯讀可設定至 12 小時。
• 存取入口網站 session — 獨立於 permission set session；控制使用者的入口網站 session 在對 IdP 重新驗證前的存活時間。預設 8 小時。
• 登入日誌 — IAM Identity Center 將登入事件發布至 CloudTrail，並可選擇透過事件匯流排發布至 CloudWatch Logs。這是你 SIEM 的必要輸入。
• 存取審查 — 結合 IAM Identity Center 指派 API 與 AWS IAM Access Analyzer 未使用存取發現（涵蓋實體化的 SSO 角色），以推動季度存取審查。

IAM Identity Center 關鍵數字與限制

常見考試陷阱 — IAM Identity Center SSO

陷阱 1：IAM Identity Center vs 原始 SAML 聯合

在 2026 年，多帳號員工存取的建議答案是 IAM Identity Center。在每個帳號的 AWS IAM 中直接設定 SAML 2.0 IdP 是舊有備用方案。若情境提及「現有 Okta」、「Entra ID」、「多個 AWS 帳號」或「降低各帳號 IAM 角色管理的操作負擔」，請選 IAM Identity Center。

陷阱 2：編輯實體化的 SSO IAM 角色

建議「將 inline policy 直接附加到 AWSReservedSSO_* IAM 角色」的答案選項是錯的——這些編輯在調和時會被覆蓋。正確操作是更新 permission set 本身。

陷阱 3：目標帳號中缺少 customer-managed policy

「指派因找不到政策而失敗」通常意味著 permission set 中以名稱引用的 customer-managed policy 未在該帳號中預先佈建。修復方式：透過 AWS CloudFormation StackSets 部署至正確的 OU。

陷阱 4：SCIM 推送為單向

當設定了外部 IdP + SCIM 時，直接在 IAM Identity Center 中進行的變更（手動建立使用者）將被覆蓋。IdP 始終是啟用 SCIM 時的真實來源。

陷阱 5：Session tags 區分大小寫

Project 和 project 不匹配。比較 aws:PrincipalTag/Project 與 aws:ResourceTag/project 的 ABAC 政策會因鍵的大小寫不同而悄悄失敗。

陷阱 6：Trusted identity propagation 需要支援 TIP 的客戶端

2020 年的 JDBC 驅動程式無法將 IAM Identity Center 身分傳播至 Redshift。情境解決方案：升級客戶端（Redshift Query Editor v2、EMR Studio、QuickSight）或 JDBC/ODBC 驅動程式版本。

陷阱 7：委派管理員無法指派至管理帳號

委派管理刻意封鎖對 AWS Organizations 管理帳號的指派。若情境需要員工存取管理帳號，這些指派必須保留在管理帳號本身。

陷阱 8：更改身分來源會清除指派

從內建目錄切換至外部 IdP（或反向）會刪除 IAM Identity Center 中的所有使用者、群組和指派。請將身分來源規劃為一次性決策。

陷阱 9：帳號執行個體 vs 組織執行個體

只有 IAM Identity Center 的組織執行個體支援多帳號指派、trusted identity propagation 和委派管理。帳號執行個體的範圍限於單一 AWS 帳號，不是 SAP-C02 的預設假設。

陷阱 10：AWS SSO 是相同的服務

使用「AWS SSO」命名的文件或 Terraform 模組仍指 IAM Identity Center。API 命名空間仍為 sso / sso-admin。聲稱「AWS SSO 已被棄用」的干擾答案是錯誤的——它被更名，而非退場。

IAM Identity Center vs AWS IAM Roles Anywhere vs Amazon Cognito — 範圍界定

這三項服務在邊緣有所重疊。正確的範圍界定在 SAP-C02 上會被考到：

• IAM Identity Center — 跨多個 AWS 帳號的員工，互動式登入、permission sets、SSO 入口網站、來自 IdP 的 SCIM。
• AWS IAM Roles Anywhere — 需要透過私有 CA 的 X.509 憑證取得短期 AWS 憑證的內部部署或非 AWS 工作負載，無需長期存取金鑰。
• Amazon Cognito — 行動與 Web 應用程式的客戶（終端使用者）身分，注冊/登入流程、使用者集區與身分集區、token 兌換 IAM 角色的 AWS 憑證。

一句話的範圍規則：若使用者是登入 AWS 工具的員工，選 IAM Identity Center。若主體是伺服器、容器或內部部署工作負載，選 IAM Roles Anywhere（或如果在 AWS 中執行則選執行個體設定檔）。若主體是你的應用程式的客戶，選 Amazon Cognito。

練習情境模式 — 映射至 IAM Identity Center

• 「40 個 AWS 帳號，Microsoft Entra ID 中有 500 名工程師，需要集中的員工 SSO。」→ IAM Identity Center 以 Entra ID 作為外部 SAML IdP + SCIM 自動佈建 + 以群組為基礎的 permission set 指派。
• 「開發和生產帳號應共用相同的 permission set，但開發帳號的 S3 存取應更廣泛。」→ Permission set 中以名稱引用的 customer-managed policy；各帳號內容透過 CloudFormation StackSets 部署。
• 「執行 Redshift 查詢的分析師——列層級安全性必須反映真實使用者，CloudTrail 必須顯示誰執行了每個查詢。」→ IAM Identity Center 搭配 trusted identity propagation 至 Redshift，Redshift 角色映射至 IAM Identity Center 群組。
• 「安全團隊希望從專屬帳號而非管理帳號操作 SSO。」→ 將 IAM Identity Center 委派管理至 Security OU 中的成員帳號。
• 「同一帳號中有許多專案，新專案頻繁出現，希望避免每個專案都建立新的 IAM 角色。」→ ABAC 搭配 session tags，從 IdP 屬性透過 IAM Identity Center 流入 aws:PrincipalTag 條件。
• 「員工離職——必須在 15 分鐘內撤銷其在所有帳號的 AWS 存取。」→ IdP 的 SCIM 取消佈建傳播至 IAM Identity Center；現有 session 在其 permission set session duration 到期時結束。
• 「從各帳號 SAML 2.0 IAM 身分提供者遷移至現代化設定。」→ 將 SAML 角色建模為 permission sets，在一個 OU 中試行，切換，然後移除每個帳號中的舊版 SAML 身分提供者。
• 「稽核員需要跨整個 AWS 組織的季度存取審查。」→ IAM Identity Center 指派 API + IAM Access Analyzer 在實體化的 AWSReservedSSO_* 角色上的未使用存取發現。

FAQ — IAM Identity Center 常見問題

Q1：何時應使用 IAM Identity Center 而非原始 SAML 聯合至 AWS IAM？

只要你有兩個或更多 AWS 帳號，且員工需要在這些帳號間一致登入，就使用 IAM Identity Center。IAM Identity Center 集中了權限管理（permission sets vs 各帳號 IAM 角色）、提供統一的存取入口網站、包含 AWS CLI v2 SSO 支援、啟用 SCIM 佈建、解鎖分析工作負載的 trusted identity propagation，並允許委派管理。原始 SAML 聯合至 IAM 仍適用於一次性情況，但各帳號的操作負擔（每個新帳號都需要一個 SAML 身分提供者設定和各帳號 IAM 角色信任政策）正是 IAM Identity Center 被設計來消除的。在 SAP-C02，預期 IAM Identity Center 在多帳號情境中會是正確答案。

Q2：SCIM 自動佈建與 Okta 或 Microsoft Entra ID 的實際運作方式？

你在 IAM Identity Center 主控台啟用自動佈建，這會產生一個 SCIM 端點 URL 和一個 bearer access token（有效期 1 年）。你將這些貼入 Okta 中的 IAM Identity Center 佈建應用程式，或 Entra ID 中具有佈建功能的企業應用程式。你指派想要佈建的使用者和群組。IdP 透過 SCIM REST 呼叫將使用者和群組推送至 IAM Identity Center，通常在幾分鐘內完成。停用和刪除以相同方式傳播，終止 IAM Identity Center 存取。最佳實踐：將 permission sets 指派給 SCIM 同步的群組，而非個別使用者，使生命週期完全從 IdP 端管理。

Q3：Permission set 中的 AWS 受管政策、customer-managed policies 與 inline policies 有何不同？

AWS 受管政策以 ARN 引用（例如 arn:aws:iam::aws:policy/ReadOnlyAccess），在每個帳號中運作方式相同——最簡單的選項。Inline policies 嵌入 permission set 本身，完全相同的內容附加至每個被指派帳號中的實體化 IAM 角色。Customer-managed policies 僅以名稱引用——permission set 說「附加名為 DataAccess 的政策」，IAM Identity Center 預期每個目標帳號中已存在一個具有確切名稱的 customer-managed IAM 政策。Customer-managed policies 啟用各帳號客製化：開發帳號的 DataAccess 與生產帳號的 DataAccess 可以有不同內容。代價是你必須在每個目標帳號中預先佈建具名政策（AWS CloudFormation StackSets 或 Terraform），指派才能生效。

Q4：IAM Identity Center 中的 ABAC 端對端流程如何運作？

使用者屬性（如 project=Atlas）在你的 IdP 中設定，透過 SCIM 流至 IAM Identity Center 使用者設定檔，並透過 IAM Identity Center 的「存取控制屬性」功能映射為登入時建立的 STS session 上的 session tag 鍵。在目標 AWS 帳號內，permission set 或資源上的 IAM 政策以條件鍵中的 ${aws:PrincipalTag/Project} 引用該 session tag，並與 ${aws:ResourceTag/Project} 的資源標籤比較。結果是一個 IAM 政策服務任意多個專案：新增專案只需標記其資源並將使用者加入匹配的 IdP 群組——無需新的 IAM 政策或 permission set。

Q5：Trusted identity propagation 是什麼，為何對分析工作負載重要？

Trusted identity propagation (TIP) 讓 AWS 分析服務——Amazon Redshift、Amazon EMR、AWS Glue、AWS Lake Formation、Amazon QuickSight 和 Amazon S3 Access Grants——能將 IAM Identity Center 使用者的身分 token 帶往下游，使下游授權和稽核日誌看到的是真實人員，而非計算資源所使用的共享 IAM 角色。這解鎖了真正的逐使用者列層級和欄位層級安全性，將 CloudTrail 事件與特定分析師連結，並實現跨分析管道的一致治理。若沒有 TIP，下游授權基於叢集或 notebook 的共享 IAM 角色，使逐使用者政策和稽核極為困難。TIP 需要 IAM Identity Center 的組織執行個體和支援 TIP 的客戶端（Redshift Query Editor v2、EMR Studio、當前驅動程式版本）。

Q6：為何委派管理是最佳實踐？

從 AWS Organizations 管理帳號執行 IAM Identity Center 會集中爆炸半徑——管理帳號也是帳單、全組織 SCP 和帳號生命週期的所在地，AWS 明確建議盡量減少其日常使用。委派管理讓你提名一個成員帳號（通常在 Security 或 Identity OU 中）作為 IAM Identity Center 的操作主頁：SSO 管理員可以從該帳號建立 permission sets 和指派，無需管理帳號憑證。委派管理員無法指派至管理帳號本身，保留了隔離邊界。這與 AWS Control Tower landing zones 自然配合——後者從第一天起就設立了專屬的安全帳號。

Q7：從舊版 AWS SSO 或原始 SAML 聯合至 IAM 的遷移路徑是什麼？

IAM Identity Center 是更名後的 AWS SSO——兩者之間不需要遷移；現有的 AWS SSO 設定在更名時自動成為 IAM Identity Center 設定。對於仍在每個帳號的 AWS IAM 中直接設定 SAML 2.0 身分提供者（IAM Identity Center 出現前的模式）的組織：在管理帳號啟用 IAM Identity Center，設定身分來源（強烈建議外部 IdP + SCIM），將每個現有 SAML IAM 角色建模為具有相同政策的 permission set，將 permission sets 指派至相同的群組和帳號，將使用者切換至 IAM Identity Center 存取入口網站 URL，靜觀期後移除舊版各帳號 SAML 身分提供者設定和 IAM 角色。

Q8：IAM Identity Center 能自動將 permission sets 指派至整個 AWS Organizations OU 嗎？

不能——IAM Identity Center 將 permission sets 指派至個別 AWS 帳號，而非 OU。對於需要以 OU 為範圍指派的 SAP-C02 Pro 等級情境，答案是 landing zone 自動化：AWS Control Tower Account Factory for Terraform (AFT) 或由 AWS Organizations 事件觸發的自訂 Lambda。自動化監聽帳號加入 OU 的事件，並呼叫 IAM Identity Center 指派 API 套用正確的 permission sets。保持自動化本身的 IAM 政策嚴格範圍，因為它具有全組織授予存取的能力。

Q9：IAM Identity Center session duration、存取入口網站 session 與 MFA 如何互動？

三個獨立的計時器在運作。存取入口網站 session（預設 8 小時，可設定）是使用者的瀏覽器 session 在對 IdP 重新驗證前，對 IAM Identity Center 的存活時間。Permission set session duration（1-12 小時，預設 1）是特定帳號/permission set 的 STS 憑證的有效時間。MFA 強制執行由 IdP 在每次登入時（或對特權群組的升級驗證時）評估，並可在 permission set 層級透過 aws:MultiFactorAuthPresent 條件要求。在 SAP-C02，對管理員等級 permission set 將 session duration 設定短（1-4 小時），對唯讀 permission set 設定較長（8-12 小時）；對大多數員工將入口網站 session 保持在 ≤8 小時。

Q10：應選擇 IAM Identity Center、AWS IAM Roles Anywhere 還是 Amazon Cognito？

IAM Identity Center 適用於跨多個帳號登入 AWS 的員工。AWS IAM Roles Anywhere 適用於需要透過你的私有 CA 的 X.509 憑證取得短期 AWS 憑證的內部部署或非 AWS 工作負載（伺服器、容器、建置代理）。Amazon Cognito 適用於你的應用程式的終端客戶——透過密碼或社交身分登入的行動與 Web 應用程式，並將 token 兌換為 AWS 憑證。三者在實務上不重疊：員工 → IAM Identity Center；機器/工作負載 → IAM Roles Anywhere（或 AWS 中執行的執行個體設定檔）；應用程式客戶 → Amazon Cognito。

延伸閱讀

• AWS IAM Identity Center User Guide
• 管理你的身分來源
• SCIM 自動佈建
• Permission sets 概念
• Permission sets 中的 customer-managed policies
• 存取控制屬性（ABAC）
• Trusted identity propagation
• 委派管理
• IAM session tags
• AWS SSO 更名為 IAM Identity Center
• AWS SAP-C02 考試指南（PDF）