IAM フェデレーション

注記

ユーザーとグループを管理するための中央ユーザーディレクトリが既にある場合は、IAM Identity Center を主要なワークフォースアクセスサービスとして使用することをお勧めします。このセクションで後述する設計上の考慮事項のいずれかにより IAM Identity Center を使用できない場合は、AWS 内で個別の IAM ユーザーを作成する代わりに IAM フェデレーションを使用してください。

IAM フェデレーションは、ユーザーを認証し、リソースへのアクセスを許可するために必要な情報を共有する目的で、2 つの当事者間に信頼システムを確立します。このシステムには、ユーザーディレクトリに接続されている ID プロバイダー (IdP) と、IAM で管理されているサービスプロバイダー (SP) が必要です。IdP はユーザーを認証し、関連する認可コンテキストデータを IAM に提供し、IAM は AWS アカウントと環境のリソースへのアクセスを制御します。

IAM フェデレーションは、SAML 2.0 や OpenID Connect (OIDC) などの一般的に使用される標準をサポートしています。SAML ベースのフェデレーションは多くの IdPsされており、ユーザーが AWS マネジメントコンソールにサインインしたり、IAM ユーザーを作成せずに AWS API を呼び出すためのフェデレーションシングルサインオンアクセスを有効にします。IAM を使用して AWS でユーザー ID を作成するか、既存の IdP (Microsoft Active Directory、Okta、Ping Identity、Microsoft Entra ID など) に接続できます。または、OIDC 互換 IdP と AWS アカウント間の信頼を確立する場合は、IAM OIDC ID プロバイダーを使用できます。

IAM フェデレーションには、マルチアカウントフェデレーションとシングルアカウントフェデレーションの 2 つの設計パターンがあります。

マルチアカウント IAM フェデレーション

このマルチアカウント IAM パターンでは、IdP と統合する必要があるすべての AWS アカウントの間に個別の SAML 信頼関係を確立します。アクセス許可は、個々のアカウントごとにマッピングおよびプロビジョニングされます。この設計パターンは、ロールとポリシーを管理するための分散アプローチを提供し、アカウントごとに個別の SAML または OIDC IdP を有効にし、アクセス制御にフェデレーティッドユーザー属性を使用する柔軟性を提供します。

マルチアカウント IAM フェデレーションには以下の利点があります。

• すべての AWS アカウントへの一元的なアクセスを提供し、各 AWS アカウントのアクセス許可を分散的に管理できます。

• マルチアカウント設定でスケーラビリティを実現します。

• コンプライアンス要件を満たします。

• ID を一元管理できます。

この設計は、AWS アカウントで区切られた分散された方法でアクセス許可を管理する場合に特に役立ちます。また、AWS アカウントの Active Directory ユーザー間で繰り返し可能な IAM アクセス許可がない場合にも役立ちます。たとえば、アカウント間でわずかなバリエーションでリソースアクセスを提供するネットワーク管理者をサポートしています。

SAML プロバイダーはアカウントごとに個別に作成する必要があるため、各 AWS アカウントには IAM ロールとそのアクセス許可の作成、更新、削除を管理するプロセスが必要です。つまり、同じ職務機能に対して異なるレベルの機密性を持つ AWS アカウントに対して、正確で個別の IAM ロールのアクセス許可を定義できます。

次の図は、マルチアカウント IAM フェデレーションパターンを示しています。

シングルアカウント IAM フェデレーション (hub-and-spokeモデル）

注記

このセクションで説明する特定のシナリオでは、この設計パターンを使用します。ほとんどのシナリオでは、IAM Identity Center ベースのフェデレーションまたはマルチアカウント IAM フェデレーションが推奨されます。質問がある場合は、AWS サポートにお問い合わせください。

シングルアカウントフェデレーションパターンでは、IdP と単一の AWS アカウント (アイデンティティアカウント) の間に SAML 信頼関係が確立されます。アクセス許可は、一元化された ID アカウントを通じてマッピングおよびプロビジョニングされます。この設計パターンは、シンプルさと効率を提供します。ID プロバイダーは、ID アカウントの特定の IAM ロール (およびアクセス許可) にマッピングされた SAML アサーションを提供します。フェデレーティッドユーザーは、cross-account-rolesを引き受けて、アイデンティティアカウントから他の AWS アカウントにアクセスできます。

次の図は、単一アカウントの IAM フェデレーションパターンを示しています。

ユースケース: 

• AWS アカウントが 1 つあるが、場合によっては、独立したサンドボックスまたはテスト用に存続期間の短い AWS アカウントを作成する必要がある企業。

• メインアカウントで本番サービスを維持するが、一時的なプロジェクトベースの学生アカウントを提供する教育機関。 

注記

これらのユースケースでは、本番データがフェデレーティッドアカウントに渡されないようにし、潜在的なセキュリティリスクを排除するために、強力なガバナンスと期限付きリサイクルプロセスが必要です。これらのシナリオでは、監査プロセスも困難です。

IAM フェデレーションと IAM Identity Center の選択に関する設計上の考慮事項

• IAM Identity Center では、アカウントを一度に 1 つのディレクトリにのみ接続できます。複数のディレクトリを使用する場合、またはユーザー属性に基づいてアクセス許可を管理する場合は、設計の代替として IAM フェデレーションを使用することを検討してください。Microsoft Active Directory フェデレーションサービス (AD FS)、Okta、Microsoft Entra ID など、SAML 2.0 プロトコルをサポートする IdP が必要です。IdP および SP メタデータを交換し、IAM ロールを企業のディレクトリグループとユーザーにマッピングするように SAML アサーションを設定することで、双方向の信頼を確立できます。

• IAM OIDC ID プロバイダーを使用して OIDC 互換 IdP と AWS アカウント間の信頼を確立する場合は、IAM フェデレーションの使用を検討してください。IAM コンソールを使用して OIDC ID プロバイダーを作成すると、コンソールはサムプリントの取得を試みます。あわせて、OIDC IdP のサムプリントを手動で取得し、コンソールで正しいサムプリントが取得されていることを確認することをお勧めします。詳細については、IAM ドキュメントの「IAM で OIDC ID プロバイダーを作成する」を参照してください。

• 社内ディレクトリユーザーに職務機能に対する反復可能なアクセス許可がない場合は、IAM フェデレーションを使用します。たとえば、ネットワーク管理者やデータベース管理者が異なる場合、AWS アカウントでカスタマイズされた IAM ロールのアクセス許可が必要になることがあります。IAM Identity Center でこれを実現するには、個別のカスタマー管理ポリシーを作成し、アクセス許可セットで参照できます。詳細については、AWS ブログ記事「AWS IAM Identity Center でカスタマー管理ポリシーを高度なユースケースに使用する方法」を参照してください。

• 各アカウントが独自のアクセス許可を管理する分散アクセス許可モデル、または AWS CloudFormation StackSets を通じて一元化されたアクセス許可モデルを使用している場合は、IAM フェデレーションの使用を検討してください。一元化されたアクセス許可と分散されたアクセス許可の両方を含むハイブリッドモデルを使用している場合は、IAM Identity Center の使用を検討してください。詳細については、IAM ドキュメントの「ID プロバイダーとフェデレーション」を参照してください。

• Amazon Q Developer Professional や AWS CLI バージョン 2 などのサービスと機能には、AWS Identity Center のサポートが組み込まれています。ただし、これらの機能の一部は IAM フェデレーションではサポートされていません。

• IAM Access Analyzer は現在、IAM Identity Center ユーザーアクションの分析をサポートしていません。