IAM 聯合身分 - AWS 方案指引
多帳戶 IAM 聯合單一帳戶 IAM 聯合

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

IAM 聯合身分

注意

如果您已有管理使用者和群組的中央使用者目錄，建議您使用 IAM Identity Center 做為主要人力資源存取服務。如果本節稍後討論的任何設計考量使您無法使用 IAM Identity Center，請使用 IAM 聯合，而不是在 AWS 中建立個別的 IAM 使用者。

IAM 聯合會在兩方之間建立信任系統，以驗證使用者並共用授權其存取 資源所需的資訊。此系統需要連線至使用者目錄的身分提供者 (IdP)，以及 IAM 中管理的服務提供者 (SP)。IdP 負責驗證使用者，並向 IAM 提供相關的授權內容資料，而 IAM 控制對 AWS 帳戶和環境中資源的存取。

IAM 聯合支援常用的標準，例如 SAML 2.0 和 OpenID Connect (OIDC)。許多 IdPs 支援 SAML 型聯合，並啟用聯合單一登入存取，讓使用者登入 AWS 管理主控台或呼叫 AWS API，而無需建立 IAM 使用者。您可以使用 IAM 在 AWS 中建立使用者身分，或連線到現有的 IdP （例如 Microsoft Active Directory、Okta、Ping Identity 或 Microsoft Entra ID)。或者，當您想要在 OIDC 相容 IdP 和 AWS 帳戶之間建立信任時，您可以使用 IAM OIDC 身分提供者。

IAM 聯合有兩種設計模式：多帳戶聯合或單一帳戶聯合。

多帳戶 IAM 聯合

在此多帳戶 IAM 模式中，您可以在 IdP 與需要整合的所有 AWS 帳戶之間建立單獨的 SAML 信任關係。許可會根據個別帳戶進行映射和佈建。此設計模式提供管理角色和政策的分散式方法，並可讓您靈活地為每個帳戶啟用單獨的 SAML 或 OIDC IdP，並使用聯合身分使用者屬性進行存取控制。

多帳戶 IAM 聯合提供以下優點：

  • 提供所有 AWS 帳戶的集中存取，並可讓您以分散式方式管理每個 AWS 帳戶的許可。

  • 在多帳戶設定中實現可擴展性。

  • 符合合規要求。

  • 可讓您從中央位置管理身分。

如果您想要以分散式方式管理許可，並以 AWS 帳戶分隔，此設計特別有用。當您在其 AWS 帳戶中的 Active Directory 使用者之間沒有可重複的 IAM 許可時，這也很有幫助。例如，它支援網路管理員，這些管理員可能會在帳戶之間提供略有變化的資源存取。

SAML 供應商必須在每個帳戶中分別建立，因此每個 AWS 帳戶都需要程序來管理 IAM 角色及其許可的建立、更新和刪除。這表示您可以為相同任務函數具有不同敏感度層級的 AWS 帳戶定義精確且不同的 IAM 角色許可。

下圖說明多帳戶 IAM 聯合模式。

多帳戶 IAM 聯合模式

單一帳戶 IAM 聯合 ( hub-and-spoke 模型）

注意

將此設計模式用於本節所述的特定案例。對於大多數案例，建議採用以 IAM Identity Center 為基礎的聯合或多帳戶 IAM 聯合。如有疑問，請聯絡 AWS Support。

在單一帳戶聯合模式中，會在 IdP 和單一 AWS 帳戶 （身分帳戶） 之間建立 SAML 信任關係。許可會透過集中式身分帳戶進行映射和佈建。此設計模式提供簡單性和效率。身分提供者提供映射到身分帳戶中特定 IAM 角色 （和許可） 的 SAML 聲明。然後，聯合身分使用者可以擔任cross-account-roles，從身分帳戶存取其他 AWS 帳戶。

下圖說明單一帳戶 IAM 聯合模式。

單一帳戶 IAM 聯合模式

使用案例： 

  • 擁有單一 AWS 帳戶，但有時需要建立短期 AWS 帳戶以進行隔離沙盒或測試的公司。

  • 在主要帳戶中維護其生產服務的教育機構，但提供以專案為基礎的臨時學生帳戶。 

注意

這些使用案例需要強大的控管和有時間限制的回收程序，以確保生產資料不會傳入聯合帳戶，並消除潛在的安全風險。在這些案例中，稽核程序也很困難。

在 IAM 聯合和 IAM Identity Center 之間進行選擇的設計考量

  • IAM Identity Center 一次僅支援將帳戶連線至一個目錄。如果您使用多個目錄或想要根據使用者屬性管理許可，請考慮使用 IAM 聯合做為設計替代方案。您應該擁有支援 SAML 2.0 通訊協定的 IdP，例如 Microsoft Active Directory Federation Service (AD FS)、Okta 或 Microsoft Entra ID。您可以透過交換 IdP 和 SP 中繼資料，以及設定 SAML 聲明將 IAM 角色映射至公司目錄群組和使用者來建立雙向信任。

  • 如果您使用 IAM OIDC 身分提供者在 OIDC 相容 IdP 與您的 AWS 帳戶之間建立信任，請考慮使用 IAM 聯合。當您使用 IAM 主控台建立 OIDC 身分提供者時，主控台會嘗試為您擷取指紋。我們建議您同時手動取得您的 OIDC IdP 的使用指紋，並且驗證您的主控台已擷取到正確的指紋。如需詳細資訊，請參閱 IAM 文件中的在 IAM 中建立 OIDC 身分提供者。

  • 如果您的公司目錄使用者沒有任務函數的可重複許可，請使用 IAM 聯合。例如，不同的網路或資料庫管理員可能需要 AWS 帳戶中的自訂 IAM 角色許可。若要在 IAM Identity Center 中達成此目的，您可以建立個別的客戶受管政策，並在許可集中參考這些政策。如需詳細資訊，請參閱 AWS 部落格文章如何針對進階使用案例使用 AWS IAM Identity Center 中的客戶受管政策。

  • 如果您使用的是分散式許可模型，其中每個帳戶都會管理自己的許可，或透過 AWS CloudFormation StackSets 集中式許可模型，請考慮使用 IAM 聯合。如果您使用的是同時涉及集中和分散式許可的混合模型，請考慮使用 IAM Identity Center。如需詳細資訊，請參閱 IAM 文件中的身分提供者和聯合。

  • Amazon Q Developer Professional 和 AWS CLI 第 2 版等服務和功能內建支援 AWS Identity Center。不過，IAM 聯合不支援其中一些功能。

  • IAM Access Analyzer 目前不支援分析 IAM Identity Center 使用者動作。