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

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

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

判断基準

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

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

サービス ポートフォリオ

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

サービスモデル

  • Software as a Service（SaaS）: Gmail、 Google 広告、Gemini Enterprise アプリ などのサービスは Google が完全に管理します。これらのサービスは 開発作業を必要とせず、すぐに使用できます。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 や NotebookLM 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 連携は、サービスデータの規約に基づいてこのデータを処理し、組織またはユーザーのロケーションの外部に保存する場合があります。

ユーザーにリソースへのアクセス権を付与すると、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 と、 で使用される ID を変換する必要があります Google Cloud。

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

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

組織に最適なアーキテクチャ パターンを決定するには、Gemini Enterprise の使用状況と、データ取り込みベースのコネクタを使用する予定があるかどうかを検討してください。

アーキテクチャ パターン

次のフローチャートは、これらの要素に基づいて、組織の要件を満たすパターンを決定する方法を示しています。

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

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

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

    • はい の場合は、判断 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 ライセンスを必要なユーザーにのみ割り当てます。

特典

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

制限事項

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

  • Cloud Identity または Google Workspace がユーザーデータとグループデータの保存に使用するロケーションを制御または制限することはできません。Google はサービスデータの規約に基づいてユーザーデータとグループデータを処理して保存するため、データ リージョンの制御はそのデータを対象としません。Google はそのデータを Google データセンター のロケーション間でレプリケートする可能性があります。

  • Cloud Identity 連携または Google Workspace 連携を使用する場合、Gemini Enterprise は 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 と統合できます。

制限事項

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

SCIM を使用した Workforce Identity 連携

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

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

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

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

特典

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

制限事項

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

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

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

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

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

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

  • Workforce Identity 連携（同期なしまたは SCIM を使用）を使用して、Gemini Enterprise と NotebookLM 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 Federation を使用して認証するかに応じて、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 を切り替える必要が生じたり、認証方法がわからなくなったりする可能性があります。

次のステップ