翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
IAM フェデレーション
注記
ユーザーとグループを管理するための中央ユーザーディレクトリが既にある場合は、IAM Identity Center を主要なワークフォースアクセスサービスとして使用することをお勧めします。このセクションで後述する設計上の考慮事項のいずれかにより IAM Identity Center を使用できない場合は、AWS 内に個別の IAM ユーザーを作成する代わりに IAM フェデレーションを使用してください。
IAM フェデレーションは、ユーザーを認証し、 リソースへのアクセスを許可するために必要な情報を共有する目的で、当事者間で信頼システムを確立します。このシステムには、ユーザーディレクトリに接続されている 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 アサーションを提供します。その後、フェデレーティッドユーザーは、アイデンティティアカウントから他の AWS アカウントにアクセスする cross-account-roles ことを想定できます。
次の図は、単一アカウントの 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 ユーザーのアクションの分析をサポートしていません。