ID 連携のアーキテクチャ パターン

このドキュメントでは、 Google Cloudを外部 ID プロバイダ（IdP）と連携させるための 4 つのアーキテクチャ パターンを比較します。また、ユースケースに適したアーキテクチャを選択するためのガイダンスも提供します。

4 つのアーキテクチャ パターンは次のとおりです。

決定要因

組織に適したアーキテクチャ パターンを選択するには、次のようないくつかの要素を考慮します。

  • サービス ポートフォリオ: Google サービスのポートフォリオと、Google Workspace やGoogle Cloud以外のサービス（Google 広告、Google マップ、Chrome Enterprise など）が含まれているかどうか。
  • データ所在地: データ所在地と主権の要件。
  • Gemini Enterprise と Microsoft 365 の統合: Gemini Enterprise または Gemini Notebook Enterprise の使用状況と、Gemini Enterprise を Microsoft 365 サービスと統合する予定があるかどうか。

サービス ポートフォリオ

Google サービスでは、認証と認可の管理方法が異なります。これは、ID 連携の構成方法に影響します。これらの違いは、サービスモデル（SaaS、PaaS、IaaS）と認可モデル（IAM、サービス固有）の 2 つの要素によって決まります。

サービスモデル

  • Software as a Service（SaaS）: Google が Gmail、Google 広告、Gemini Enterprise アプリなどのサービスを完全に管理します。これらのサービスは開発作業を必要とせず、すぐに使用できます。SaaS サービスは多くのユーザーを対象としているため、ほとんどのユーザーがアクセスを必要とする可能性があります。
  • Platform as a Service（PaaS）または Infrastructure as a Service（IaaS）: ほとんどのGoogle Cloud サービスは PaaS または IaaS です。これらのサービスを使用すると、技術ユーザーはカスタム ワークロードの開発、デプロイ、運用を行うことができます。これらのサービスは技術的なユーザーを対象としているため、アクセスを必要とするのは一部のユーザーのみです。

承認モデル

Google サービスは、次の 2 つの方法のいずれかで認可を実装します。

  • IAM: ほとんどの Google Cloud サービスは、IAM を使用して、管理者がリソースへのきめ細かいアクセスを管理できるようにします。
  • サービス固有の認可: Google 広告、Looker、Google Workspace などのサービスは IAM を使用しません。代わりに、管理者は各サービスに固有のツールを使用してアクセス権を管理します。

これらの要素により、次のサービス グループが作成されます。

SaaS PaaS または IaaS
IAM ベースの認可 Google Cloud Gemini Enterprise app や Gemini Notebook Enterprise などの SaaS サービス Google Cloud BigQuery や Compute Engine などの PaaS サービスと IaaS サービス
サービス固有の承認 Google 広告、Google Workspace、Google マップなどのクラウド以外の Google サービス なし

組織に適したアーキテクチャ パターンを選択するには、組織に適用されるサービス グループを検討します。

データ所在地

ユーザーの認証とセッションの管理を行うため、Cloud Identity、Google Workspace、Workforce Identity 連携はユーザーの個人情報を処理します。ユーザー情報には、次のようなものが含まれます。

  • ユーザー名またはメールアドレス
  • ユーザーの姓名などの属性
  • グループ名とメンバーシップ

Cloud Identity、Google Workspace、Workforce Identity 連携は、サービスデータの条件に基づいてこのデータを処理し、組織またはユーザーのロケーション外に保存する場合があります。

  • Cloud Identity と Google Workspace は、サービスデータを Google データセンターに保存し、すべてのデータセンターに複製する場合があります。保存されるデータには、認証に不可欠ではない情報（部署名、住所、電話番号など）が含まれる場合があります。
  • Workforce Identity 連携は、サービスデータを Google Cloudリージョンに保存し、すべてのリージョン間で複製する場合があります。

ユーザーにリソースへのアクセス権を付与すると、IAM はプリンシパル ID をロール バインディングに保存します。 Google Cloud は、サービスデータの条件に基づいてロール バインディングを処理し、すべての Google Cloud リージョンに保存する場合があります。

このページで説明するアーキテクチャ パターンでは、ユーザー情報の保存が必要ですが、ユーザー情報の保存期間が異なります。

多くの IdP では、対応するユーザー アカウントのステータスが IdP で変更されたときに、ユーザー アカウントの停止または削除を自動化できます。IdP とその構成によっては、IdP が一定の猶予期間が経過するまでユーザー アカウントの削除を遅らせることがあります。これにより、 Google Cloudがユーザー情報を保存する期間が延長される可能性があります。

Gemini Enterprise と Microsoft 365 の統合

Gemini Enterprise では、次の 2 種類のコネクタを使用して Microsoft 365 サービスに接続できます。

  • データ取り込みベースのコネクタ: これらのコネクタは Microsoft 365 をクロールして、 Google Cloudに検索インデックスを構築します。ユーザーがプロンプトを送信すると、Gemini Enterprise はこのインデックスを使用してコンテンツを検索し、Microsoft 365 から取得したアクセス制御リスト（ACL）を評価してアクセスチェックをローカルで実行します。
  • 連携コネクタ: これらのコネクタは、各プロンプトに対して Microsoft 365 にクエリを実行します。委任された承認を使用して、Microsoft 365 がアクセス チェックを直接実行できるようにします。

データ取り込みベースのコネクタには、ユーザー フェデレーションに関する特定の要件があります。

  • グループ メンバーシップの認識: Microsoft 365 ACL には、ユーザーだけでなくグループのエントリを含めることができます。ユーザーがコンテンツにアクセスできるかどうかを評価するには、コネクタはユーザーが属するすべてのグループを考慮する必要があります。コネクタがユーザーのグループのサブセットのみを認識している場合、アクセスが誤って許可または拒否される可能性があります。
  • ID の変換: ACL を評価するには、コネクタが Microsoft 365 で使用されるユーザー ID とグループ ID を Google Cloudで使用される ID に変換する必要があります。

Workforce Identity 連携を使用する場合、Gemini Enterprise と互換性があるように属性マッピングを構成すると、Gemini Enterprise は ID を確実に変換し、ACL を評価できます。

Cloud Identity または Google Workspace の連携を使用する場合、 Google Cloudではなく Microsoft Entra ID がユーザーとグループのプロビジョニングの属性マッピングを制御します。Entra は、ユーザーとグループの識別子の変換ルールを決定します。これには複雑な変換が含まれる場合があります。ACL を評価するには、Gemini Enterprise コネクタで同じ変換ルールを適用する必要がありますが、コネクタには Entra 構成の可視性がありません。そのため、Cloud Identity 連携または Google Workspace 連携を使用すると、Gemini Enterprise はユーザーとグループの ID を確実に変換できず、ACL を確実に評価できません。

組織に適したアーキテクチャ パターンを判断するには、Gemini Enterprise の使用状況と、データ取り込みベースのコネクタを使用する予定があるかどうかを検討します。

アーキテクチャ パターン

次のフローチャートは、これらの要因によって、どのパターンが組織の要件を満たすかがどのように決定されるかを示しています。

ID 連携パターンを選択する方法を示すフローチャート。

  1. 組織の大部分で Google Workspace を使用していますか？

  2. Google 広告や Google マップなど、 Google Cloud 以外のサービスも使用していますか？

    • 「はい」の場合は、決定事項 3 に進みます。
    • 「いいえ」の場合は、決定事項 4 に進みます。

  3. Gemini Enterprise を使用して Microsoft 365 と統合する予定はありますか？

  4. Gemini Enterprise を使用する予定はありますか？

  5. ユーザー情報の保存を最小限に抑える必要があるデータ所在地に関する要件はありますか？

Cloud Identity または Google Workspace の連携

組織が次のいずれかの条件を満たす場合は、このパターンを選択します。

  • 組織の大部分がすでに Google Workspace を使用している。
  • Google 広告や Google マップなどの Google Cloud 以外の Google サービスを使用しているが、データ取り込みベースのコネクタを使用して Gemini Enterprise を Microsoft 365 と統合する予定がない。
  • Google Cloud サービスのみを使用し、Gemini Enterprise を使用する予定がなく、ユーザーデータの保存を最小限に抑えるための厳格なデータ所在地要件がない。

このパターンでは、Workforce Identity 連携は使用しません。代わりに、Cloud Identity アカウントまたは Google Workspace アカウントを IdP と連携させ、事前ユーザー プロビジョニングとグループ プロビジョニングを使用します。

Cloud Identity と Google Workspace の連携のアーキテクチャ。

このパターンでは、ユーザーがログインする前にユーザーとグループをプロビジョニングする必要があります。そうしないと、ログイン試行が失敗します。

  • ユーザーのプロビジョニング: ユーザーのオンボーディングとオフボーディングをタイムリーに行うことができます。
  • グループのプロビジョニング: グループを使用して、Google サービスと Google Cloud リソースへのアクセスを管理できます。

組織内のユーザーの一部のみが Google Workspace を必要とする場合は、Google Workspace サブスクリプションと Cloud Identity サブスクリプションの両方をアカウントに追加し、Google Workspace ライセンスを必要とするユーザーにのみ割り当てます。

特典

  • ユーザーは、Google サービスが IAM を使用しているかどうかに関係なく、Google サービスに対して認証できます。Cloud Identity アカウントまたは Google Workspace アカウントで、ユーザーが使用できる Google サービスを制御します。
  • シングル サインオン（SSO）と事前プロビジョニングをユーザーのサブセットに制限し、緊急アクセス ユーザーなどの特定のユーザーを Cloud Identity または Google Workspace で直接管理し続けることができます。
  • 外部 IdP からグループをプロビジョニングしたり、Cloud Identity アカウントまたは Google Workspace アカウントでグループをローカルに管理したり、両方の方法を組み合わせたりできます。

制限事項

  • ユーザー アカウントを事前にプロビジョニングするとオーバーヘッドが増加し、オンボーディング プロセスが遅くなる可能性があります。

  • Cloud Identity または Google Workspace がユーザーデータとグループデータの保存に使用するロケーションを制御または制限することはできません。Google はサービスデータの条件に基づいてユーザーデータとグループデータを処理して保存するため、データ リージョン制御はこれらのデータを対象としていません。Google は、Google データセンターの所在地全体でこれらのデータを複製する可能性があります。

  • Gemini Enterprise は、Cloud Identity 連携または Google Workspace 連携を使用する場合、Microsoft データソースへの接続を限定的にサポートします。

Workforce Identity 連携（同期なし）

組織が次の条件を満たしている場合は、このパターンを選択します。

  • Google Cloud サービスのみを使用している。
  • Gemini Enterprise を使用しているが、IdP によって課せられたグループの制限内に収まることを想定している。
  • 個人ユーザー情報の保存を最小限に抑える必要があるデータ所在地に関する要件がある。

同期なしの Workforce Identity 連携のアーキテクチャ。

このパターンでは、Workforce Identity 連携を使用して、Google Cloud 組織を外部 IdP と連携させます。

このパターンでは、ユーザー プロビジョニングやグループ プロビジョニングは必要ありません。ユーザーがログインするたびに、IdP はグループ メンバーシップやカスタム属性など、ユーザーに関する必要な情報を Google Cloudに渡し、 Google Cloud はその情報をユーザー セッションの期間のみ保持します。

特典

  • Google Cloudでユーザー アカウントやグループを保存または管理する必要はありません。
  • このパターンを使用すると、データ取り込みベースのコネクタを使用して Gemini Enterprise を Microsoft 365 と統合できます。

制限事項

  • Workforce Identity 連携は IAM 機能であり、IAM を使用するサービスにのみアクセスできます。Workforce Identity 連携を使用して認証するユーザーは、Google 広告、Looker、Google マーケティング プラットフォームなどの Google サービスにアクセスできません。
  • Workforce Identity 連携を使用して認証するユーザーは、一部の Google Cloud 機能にアクセスできません。詳細については、ID 連携: プロダクトと制限事項をご覧ください。
  • 多くの IdP では、SAML アサーションまたは ID トークンで Workforce Identity 連携に渡すことができるグループ メンバーシップの数が制限されています。これらの上限を超えないようにするには、グループ ガバナンスを強化し、アサーションまたはトークンに含めるグループのタイプを制限する必要がある場合があります。
  • Gemini Notebook Enterprise ノートブックなどのリソースを共有する場合、グループを名前で検索することはできません。代わりに、ユーザーが識別子を手動で入力する必要があります。

Microsoft Entra ID を使用している場合は、追加属性を構成して、このパターンのバリエーションを使用できます。追加の属性を構成すると、Workforce Identity 連携はユーザー認証中に Microsoft Graph API へのコールバックを実行して、グループ メンバーシップを取得します。この構成により、SAML アサーションと ID トークンに対する Entra のグループ メンバーシップの上限を回避し、ユーザーごとに最大 999 個のグループ メンバーシップを使用できます。

SCIM を使用した Workforce Identity 連携

組織が次の条件を満たしている場合は、このパターンを選択します。

  • Google Cloud サービスのみを使用している。つまり、Google 広告や Google マップなどの外部の Google サービスを使用しません。
  • Gemini Enterprise または Gemini Notebook Enterprise を使用する予定で、ユーザーあたり最大 2,000 個のグループ メンバーシップをサポートする必要がある場合、またはリソースを共有するときに名前でグループを検索する機能が必要な場合。

SCIM を使用した Workforce Identity 連携のアーキテクチャ。

このパターンでは、Workforce Identity 連携を使用してGoogle Cloud 組織を連携します。Gemini Enterprise で使用できるグループの数を増やすには、SCIM を構成して、グループ メンバーシップ情報を事前にプロビジョニングします。

特典

  • このパターンを使用すると、データ取り込みベースのコネクタを使用して Gemini Enterprise を Microsoft 365 と統合できます。
  • ユーザーごとに最大 2,000 個のグループ メンバーシップを使用して、Gemini Enterprise と Gemini Notebook Enterprise へのアクセスを制御し、Gemini Enterprise データ取り込みベースのコネクタでアクセス チェックを実行できます。
  • Gemini Notebook Enterprise ノートブックなどのリソースを共有するときに、名前でグループを検索して、ユーザー エクスペリエンスを向上させることができます。

制限事項

  • SCIM プロビジョニングされたグループのサポートは、Gemini Enterprise と Gemini Notebook Enterprise に限定されます。他のサービスは、IdP が SAML アサーションまたは ID トークンで渡すグループ メンバーシップのみを使用できます。
  • Workforce Identity 連携は IAM 機能であり、IAM を使用するサービスにのみアクセスできます。Workforce Identity 連携を使用して認証するユーザーは、Google 広告、Looker、Google マーケティング プラットフォームなどの Google サービスにアクセスできません。
  • Workforce Identity 連携を使用して認証するユーザーは、 Google Cloud の一部の機能にアクセスできません。詳細については、ID 連携: プロダクトと制限事項をご覧ください。

ハイブリッド Cloud Identity と Workforce Identity 連携

組織が次の条件を満たしている場合は、このパターンを選択します。

  • Google Cloud 以外の Google サービス（Google 広告や Google マップなど）を使用している。
  • Gemini Enterprise を使用して Microsoft 365 と統合する予定である。

ハイブリッド Cloud Identity と Workforce Identity 連携の連携のアーキテクチャ。

このパターンは、前の 2 つのパターンを組み合わせたものです。

  • Workforce Identity 連携（同期なしまたは SCIM あり）を使用して、Gemini Enterprise と Gemini Notebook Enterprise へのアクセスを管理します。
  • Cloud Identity または Google Workspace の連携を使用して、 Google Cloud や非クラウドの Google サービスなど、他のサービスへのアクセスを管理します。

特典

このパターンを使用すると、前の 2 つのパターンの利点を組み合わせることができます。

  • Gemini Enterprise を Microsoft データソースに接続する際に、機能の制限はありません。
  • ユーザーは、サービスが IAM を使用しているかどうかに関係なく、Google サービスに対して認証できます。
  • Google Cloud 機能の完全なセットを使用します。

制限事項

  • 外部 IdP で、Cloud Identity 用と Workforce Identity 連携用の 2 つの個別の証明書利用者構成を維持する必要があります。
  • ユーザーが Cloud Identity を使用するように構成されているか、Workforce Identity 連携を使用するように構成されているかによって、ログイン エクスペリエンスが異なる場合があります。
  • IAM 許可ポリシーを管理する場合は、ユーザーの認証方法に応じて異なるプリンシパル ID を使用する必要があります。たとえば、外部 IdP で bob@example.com として認識されているユーザーは、Cloud Identity 連携を使用して認証するか、Workforce Identity 連携を使用して認証するかによって、IAM でプリンシパル ID bob@example.com または principal://iam.googleapis.com/locations/global/workforcePools/POOL_ID//subject/SUBJECT_ID を持つ場合があります。
  • Cloud Identity ユーザーと Workforce Identity 連携プリンシパルが混在するグループを作成することはできません。Cloud Identity グループには Cloud Identity ユーザーのみを含めることができ、Workforce Identity グループには Workforce Identity 連携プリンシパルのみを含めることができます。
  • Gemini Enterprise 以外に Workforce Identity 連携を使用すると、ユーザーが ID を切り替える必要が生じたり、認証方法がわからなくなったりする可能性があります。

次のステップ