Amazon Web Services（AWS）於二零二六年十一月五日在官方資安部落格宣布推出 Account Access Manager：在組織級 IAM Identity Center 的中央聯合之上，直接把各帳戶既有 IAM 角色指派給人力用戶與群組，並以 Trusted Identity Propagation 保留用戶級可稽核性；商業區域免額外費用（不含選擇加入商業區、GovCloud、中國等非商業區）。

AWS／官方：推出 Account Access Manager——Identity Center 中央聯合配對既有 IAM 角色；用戶級可見；商業區免額外費用

Amazon Web Services（AWS）於二零二六年十一月五日在 AWS Security Blog 發表〈Introducing AWS account access manager〉，由 Moumita Saha、Blake Franzen 與 Omar Zoma 撰寫，介紹 Identity and Access Management（IAM）新能力 Account Access Manager。官方定位為：把團隊慣用的 IAM 角色彈性，透過 IAM Identity Center 的中央聯合交付，並內建用戶級可見性。企業可把各帳戶既有 IAM 角色指派給 Identity Center 的用戶與群組，亦可與既有 permission sets 並用，兩者共用已從企業身分提供者同步的同一批用戶與群組。本文已核對 AWS Security Blog 原文條款與限制，來源真實性已驗證。對香港多帳戶 AWS 環境、須同時保留自訂 trust policy／ABAC 又要中央稽核的團隊，屬值得評估的身分存取治理選項。

一、核心事件：IAM 角色彈性與 Identity Center 中央控制不再二選一

官方要解決的取捨

官方指出，過往要把人力用戶帶進 AWS 帳戶，大致陷入兩種取捨：一是在各帳戶分別以 IAM 角色聯合，可保留自訂 trust policy、標籤與角色路徑，但身分提供者與角色指派要逐帳戶管理，難以把同一群組一次配到多帳戶，也難有「誰在哪裡有權」的統一視圖；二是經 Identity Center 的 permission sets 做單點聯合與中央佈建，存取形態較一致，但對角色因帳戶而異、或難以把既有角色抽象成統一 permission set 的團隊，常感受限。

Account Access Manager 的主張

Account Access Manager 的目標是去掉上述取捨：保留 Identity Center 的單點聯合與身分傳播好處，同時繼續使用帳戶內既有 IAM 角色的彈性，包括屬性型存取控制（ABAC）、以網絡條件或 IdP 斷言（群組、部門、成本中心等）收緊的 trust policy，以及以角色路徑做大規模組織。指派對象是用戶與群組；即使多人共用同一 IAM 角色，透過 Trusted Identity Propagation，每個角色工作階段仍帶用戶脈絡，動作可歸因到個人。管理面可經 IAM 主控台、AWS CLI（含 aws login 與 account-access API）、SDK、CloudFormation，以及 HashiCorp Terraform 與 Pulumi。

二、技術原理深度解析

賦權（entitlement）模型

官方說明，賦權需三個元素：用戶或群組識別、目標帳戶識別，以及該帳戶內的 IAM 角色 ARN（相對 permission set 路徑改為角色 ARN）。管理員建立 entitlement 後，用戶可從 Account Access Manager 入口、Identity Center 存取入口，或以 CLI aws login 取得憑證。角色工作階段最長依該 IAM 角色設定，上限十二小時。

Trust policy 與防混淆代理人

指派前須更新目標 IAM 角色的 trust policy，允許服務主體 account-access.amazonaws.com 執行 sts:AssumeRole、sts:SetContext、sts:TagSession，並以 aws:SourceAccount 與 aws:SourceArn（指向啟用時建立的 Account Access Manager 應用 ARN）做條件約束，降低混淆代理人風險。官方建議把此 trust 陳述式寫進角色建立管線，使新角色「第一天」即可被指派；僅在下游政策會讀取主體標籤時才加入 sts:TagSession。

啟用前置與範圍

前置條件包括：組織管理帳戶內已有 Identity Center 組織實例；管理帳戶啟用本功能；以 organizations enable-aws-service-access --service-principal account-access.amazonaws.com 授權服務存取；CLI 工作流程需 AWS CLI v2.36.0 或更新。官方寫明商業區域免額外費用並預設可用，但排除選擇加入的商業區域、GovCloud（美國）、中國及其他非商業區域。若 Identity Center 使用客戶管理 KMS 金鑰（例如跨區域複寫時），啟用前須檢查金鑰政策，確保本服務可讀取用戶、群組與實例資料。

四、日常應用場景

1. 開發者與技術團隊

多帳戶開發／測試／生產拆分後，開發者常要在不同帳戶假設不同角色。Account Access Manager 讓平台團隊把既有 Developer、ReadOnly、BreakGlass 等角色直接指派到 Identity Center 群組，開發者以統一入口或 aws login 進帳戶，而不必為每個帳戶另建 IdP 聯合。注意官方明示 aws sso configure 等 Identity Center 專用流程與本能力的賦權不相容，應改走 aws login；若仍要用 aws sso login，須另參官方 IAM Account Access Manager 的 CLI 整合說明。

2. 企業與隱私敏感行業

金融、法律、醫療與受規管行業常已累積大量「帳戶內量身訂做」的 IAM 角色（含 ABAC 標籤與嚴格 trust）。新能力允許繼續使用這些角色，同時把「誰被賦權哪個角色」收到中央，並靠 Trusted Identity Propagation 做用戶級稽核，有助滿足內外部審計對「共用角色下誰動過手」的追問。啟動夥伴名單涵蓋 Okta、Ping Identity、Cisco Duo 以及多個存取治理／特權存取供應商，便於與既有 IdP 與治理工具銜接。

3. 一般用戶／中小企雲端運維

帳戶數不多、但已用 Identity Center 的團隊，可先在測試組織啟用、建立第一個 entitlement，驗證入口網域白名單與防火牆規則後再推廣。官方提醒若環境有 NGFW／Secure Web Gateway，需預先允許 Account Access 入口與控制面／執行時期端點，避免上線當日無法登入。

4. 香港與亞洲市場視角

本港企業上雲常見「一業務線一帳戶」或「租戶／環境拆分」，身分又多接 Azure AD／Okta 等企業目錄。過去要嘛為彈性犧牲中央視圖，要嘛為中央管理犠牲角色細緻度。Account Access Manager 若適用所在商業區域，可作為把既有 IAM 角色資產納入 Identity Center 治理的路徑，減少重複身分與逐帳戶聯合維護。對同時使用本地資料中心與 AWS、並關心雲端身分邊界的香港團隊，宜一併檢視角色 trust、工作階段時長與破窗流程是否仍符合內部資安政策。

五、專業評價與潛在考量

優勢

官方明確對準「IAM 角色彈性 vs Identity Center 中央控制」的長期痛點，並允許與 permission sets 並存，遷移路徑較務實。
Trusted Identity Propagation 把共用角色下的動作歸因到個人，強化稽核可用性。
支援主控台、CLI／API、CloudFormation 與主流 IaC，便於納入既有基礎設施即程式碼流程；商業區域免額外費用降低試用門檻。

需要留意的地方

須在組織管理帳戶、且與 Identity Center 主區域一致的條件下啟用；帳戶結構與委派管理模型不當會擴大管理面風險。
每個角色都要先改 trust policy，存量角色多時屬一次性工程債，官方亦建議自動化。
控制台無法跨帳戶自動搜尋角色名稱，指派時須事先知道角色名；群組賦權優於逐人賦權，否則行政成本回升。
區域可用性有排除清單；GovCloud、中國及部分選擇加入區域不在「商業區預設可用／免額外費用」描述內，跨區合規部署須再核對。
本文僅整理官方公開產品說明，不含實測延遲或配額數字；上線前仍應在測試組織驗證入口、CLI 與稽核日誌。

結語

Account Access Manager 把「帳戶內既有 IAM 角色」接上 Identity Center 的中央聯合與用戶級可見性，讓企業不必再在彈性與集中治理之間硬選一邊。對已在 AWS 多帳戶環境累積大量自訂角色、又希望統一人力存取與稽核的香港團隊，十一月五日這篇官方說明提供了可操作的啟用步驟與信任政策範本。若你的機構正在整理雲端身分、零信任邊界、帳戶間權限與可稽核的聯合登入，可參考 YSK Limited 的香港雲端遷移與網絡安全服務，把身分聯合、角色治理與暴露面收斂做成可驗證的工程項目。

參考來源

AWS Security Blog（2026-11-05）：Introducing AWS account access manager: IAM role flexibility with centralized workforce access
發現來源（AWS Security Blog RSS）：https://aws.amazon.com/blogs/security/feed/