前面三篇處理的是應用程式的跨帳號存取：讓 EC2 使用 IAM Role，讀取另一個帳號的 S3，接下來換成人員的存取管理。

如果每個帳號都要分別建立 IAM User，再逐一設定每位使用者的權限，當帳號與人員越來越多時，管理起來也會越來越複雜。

AWS IAM 提供了 User Group，可以將具有相同工作職責的使用者集中管理，讓群組成員共用對應的 IAM Policy，不過 IAM User Group 的管理範圍有限，當公司需要讓人員登入多個 AWS 帳號時，仍然需要處理跨帳號的身分與權限管理。

今天要介紹的 AWS IAM Identity Center，就是用來集中管理企業人員登入與多帳號存取權限的服務。

在介紹 Identity Center 之前，先從 IAM User Group 的運作方式與限制開始，了解兩者在多帳號環境中的差異。

IAM User Group 能管理什麼？

IAM User Group 是同一個 AWS 帳號內，IAM User 的集合。 將 IAM Policy 附加到群組後，群組中的使用者就能取得對應權限。

例如，在開發帳號建立 Developers 群組，並附加部署所需的 IAM Policy，當新同事加入時，只要將他的 IAM User 加入群組，就不需要重新設定一份相同的權限。

不過，IAM User Group 有幾個限制：

• 成員只能是同一個 AWS 帳號內的 IAM User，不能包含其他帳號的 IAM User 或 IAM Role。
• 群組本身不能登入 AWS，使用者仍然以自己的 IAM User 身分操作。
• 群組不能作為 Bucket Policy 或 Role Trust Policy 中的 Principal。

最後一點與前面的跨帳號實作有關。

假設 Account A 有一個 Developers 群組，不能直接將這個群組的 ARN 放進 Account B 的 Role Trust Policy，讓整個群組切換角色。

不過，可以在群組的 IAM Policy 中授予 sts:AssumeRole，讓成員取得切換至 Account B Role 的權限；Account B 則需要另外設定對應的信任關係。

這種做法可以完成跨帳號存取，但如果公司有多個 AWS 帳號，需要管理不同人員在各帳號中的登入身分、角色與權限，仍然需要逐一維護相關設定。

IAM Identity Center 如何集中管理多帳號存取？

AWS IAM Identity Center 可以集中管理企業人員的登入，以及他們在不同 AWS 帳號與應用程式中的存取權限。

使用者可以透過統一的 AWS Access Portal 登入，再選擇自己被授權存取的帳號與角色，不需要在每個帳號中分別建立 IAM User。

例如，公司有 Development 與 Production 兩個 AWS 帳號，可以透過 IAM Identity Center 集中管理開發人員在不同環境中的權限。

不過，IAM Identity Center 也有 Group，這與前面介紹的 IAM User Group 有什麼不同？

兩邊即使都有一個叫做 Developers 的群組，也不會因為名稱相同就自動連動，Identity Center 的群組不會轉換成各帳號中的 IAM User Group，也不需要替成員在每個帳號建立 IAM User。

另外，IAM Identity Center 有兩種執行個體類型：Organization instance 與 Account instance。

如果要透過 Permission Set 集中管理 AWS Organizations 中的多個帳號，需要使用 Organization instance；Account instance 主要用於單一帳號中的特定應用程式存取情境，不支援透過 Permission Set 管理 AWS 帳號存取權限。

本篇接下來討論的多帳號權限管理，都是以 Organization instance 為前提。

參考：AWS 官方文件｜Organization and account instances of IAM Identity Center

群組、帳號與 Permission Set 怎麼搭配？

在 IAM Identity Center 中，可以先掌握四個主要概念：

其中，Permission Set（權限集）是一份可重複使用的權限範本，可以包含 AWS managed policy、Customer managed policy 或 Inline policy，管理者可以依照工作需求定義不同的操作權限。

接下來用一個情境說明。

假設公司有開發與正式環境兩個 AWS 帳號，開發人員需要在開發環境部署程式，但進入正式環境時，只需要查看監控與日誌；維運人員則負責正式環境的日常操作。

可以先將人員分成 Developers 與 Operators 兩個群組，再安排以下權限：

表中的 Permission Set 名稱都是自訂範例，實際能執行哪些操作，仍然需要透過其中的 IAM Policy 定義。

這裡可以看到，同一個 Developers 群組，在不同 AWS 帳號中，可以被指派不同的 Permission Set。

當 Alice 加入 Developers 群組後，就能透過既有的帳號指派，在開發環境取得部署權限，在正式環境取得監控權限，不需要逐一在不同帳號建立使用者。

因此，IAM Identity Center 的帳號權限指派，主要是在決定「哪個使用者或群組，可以在哪個 AWS 帳號使用哪個 Permission Set」。

透過群組進行權限指派，可以讓相同職責的人員共用一套授權設定，當人員加入、轉換職務或離職時，也比較容易依照群組成員資格調整存取權限。

Permission Set 最後仍然對應到 IAM Role

前面幾篇都是直接在 IAM 中建立 Role，再透過 Permissions Policy 定義該 Role 可以操作哪些 AWS 資源。

IAM Identity Center 的 Permission Set 則提供了集中管理這些角色權限的方式。

當管理者將 Permission Set 指派給特定 AWS 帳號中的使用者或群組後，IAM Identity Center 會在該帳號中建立並管理對應的 IAM Role，並將 Permission Set 定義的權限配置到該角色。

例如，將 ProductionObserve 指派給 Developers 群組，並指定 Production 帳號後，IAM Identity Center 會在 Production 帳號中建立對應的 IAM Role。

使用者透過 AWS Access Portal 選擇 Production 帳號及 ProductionObserve，便可以取得對應 Role 的暫時性憑證，使用該角色的權限操作 AWS 資源。

整個流程可以整理成：

Alice（Developers 群組）
          │
          ▼
透過 AWS Access Portal 登入
          │
          ▼
選擇 Production 帳號
          │
          ▼
選擇 ProductionObserve
          │
          ▼
取得對應 IAM Role 的暫時性權限
          │
          ▼
依照 ProductionObserve 的權限操作 AWS 資源

如果 Alice 同時被授權存取 Development 帳號，也可以在 AWS Access Portal 中選擇 Development 帳號與 DevelopmentAccess，取得開發環境對應的角色權限。

因此，即使 Alice 在開發環境具有部署權限，也不會因此在正式環境自動取得相同的操作權限。

除了透過 AWS Management Console，IAM Identity Center 也支援使用者透過 AWS CLI 取得暫時性憑證，存取被授權的 AWS 帳號，不需要為每個帳號另外建立長期 Access Key。

Permission Set 定義的權限仍會受到其他適用政策的限制，例如 SCP 與資源政策中的明確 Deny，即使 Permission Set 允許某項操作，也不代表使用者一定能成功存取所有對應資源。

參考：AWS 官方文件｜Permission sets

身分來源：使用內建目錄，還是公司的既有系統？

前面提到，IAM Identity Center 可以透過 User 與 Group 分配 AWS 帳號的存取權限，但這些人員身分資料應該由誰負責管理？

IAM Identity Center 支援三種主要的身分來源：

身分來源決定使用者與群組由哪個系統管理，以及使用者如何進行登入驗證。

沒有既有身分系統：使用內建目錄

如果公司目前沒有統一的企業身分系統，主要需求是集中管理 AWS 人員存取，可以使用 IAM Identity Center 內建的 Identity Center directory。

管理者可以直接在 IAM Identity Center 中建立 User 與 Group、設定 MFA，再透過 Permission Set 分配不同帳號的存取權限。

這種方式不需要額外串接外部身分提供者，但也代表需要在 IAM Identity Center 中維護使用者資料及帳號生命週期。

例如，公司郵件帳號停用後，IAM Identity Center 中的使用者不會僅因為信箱停用就自動遭到停權，因此員工離職或轉換職務時，仍然需要將 AWS 存取權限的移除納入管理流程。

已有企業身分系統：串接 External identity provider

如果公司原本就使用 Microsoft Entra ID 或 Okta 管理員工帳號，可以考慮將 IAM Identity Center 串接至既有的身分提供者（Identity Provider，IdP）。

例如，Alice 原本就使用 Microsoft Entra ID 登入公司內部應用程式，串接後，也可以使用相同的企業身分登入 AWS Access Portal。

這樣可以沿用既有的人員登入、MFA 與帳號生命週期管理機制，減少重複維護另一套員工帳號與密碼的工作。

整合時，會遇到兩個常見的標準：

SAML 2.0 負責處理登入驗證，但不會自動同步外部身分提供者中的所有使用者與群組。

如果要自動管理這些身分資料，還需要在支援的身分提供者中設定 SCIM；若不使用 SCIM，則需要另外佈建及維護對應的使用者與群組。

例如，當新同事加入公司時，可以先在 Microsoft Entra ID 中建立員工帳號並加入 Developers 群組，再透過 SCIM 將相關資料同步至 IAM Identity Center。

不過即使 Developers 群組已經成功同步，仍然需要在 IAM Identity Center 中指派對應的 AWS 帳號與 Permission Set，使用者才能取得相應的 AWS 存取權限。

已使用 Active Directory：沿用既有 AD

如果公司已經透過 Active Directory 管理員工帳號與群組，也可以透過 AWS Directory Service，讓 IAM Identity Center 使用既有的 AD 身分資料。

這種方式可以延續原本的 AD 使用者與群組管理機制，讓員工使用既有的企業身分存取 AWS，不需要另外在 Identity Center 中建立獨立的員工密碼。

該如何選擇身分來源？

選擇身分來源時，可以先確認公司目前如何管理員工帳號，以及是否已有統一的 MFA 與人員異動流程。

如果公司已經有既有的身分管理機制，可以評估直接串接，避免重複維護人員資料；如果主要需求只有 AWS 人員存取，也沒有其他企業身分系統，使用內建目錄就能完成基本管理。

身分來源建議在正式導入前先確認，雖然 IAM Identity Center 支援日後更換身分來源，但部分切換情境可能會移除原本的使用者、群組與帳號權限指派，需要重新設定，甚至暫時影響人員登入。

參考：AWS 官方文件｜Manage your identity source

整理 IAM Identity Center 的權限管理方式

回到一開始的多帳號情境，IAM Identity Center 透過統一的登入入口，以及 User、Group、Permission Set 與 AWS Account 之間的指派關係，集中管理不同人員的存取權限。

如果公司已經有成熟的企業身分管理系統，可以透過身分聯合與人員同步，減少重複管理員工帳號的工作；如果沒有既有系統，也可以直接使用 IAM Identity Center 內建目錄管理人員。

而前面幾篇介紹的 IAM Role 仍然是 AWS 存取管理的重要基礎，EC2 等工作負載可以透過 IAM Role 取得操作資源所需的權限，企業人員則可以透過 IAM Identity Center，集中取得不同 AWS 帳號中的角色權限。

下一篇

從 IAM Policy、跨帳號存取到 IAM Identity Center，前面幾篇介紹了 AWS 如何管理不同身分的存取權限，以及多帳號環境中的人員登入與授權方式。

到這裡，身分與治理篇就先告一段落。接下來會進入 AWS 網路篇，從 VPC 的基本架構開始，了解雲端資源如何透過子網、路由表與網路閘道建立連線，以及如何控制不同網路之間的流量。

參考資料

• AWS 官方文件｜IAM user groups
• AWS 官方文件｜What is IAM Identity Center?
• AWS 官方文件｜Organization and account instances
• AWS 官方文件｜Manage AWS accounts with permission sets
• AWS 官方文件｜Configure access to AWS accounts
• AWS 官方文件｜Manage your identity source
• AWS 官方文件｜External identity providers