ID プロバイダを構成する

Gemini Enterprise でデータソースのアクセス制御を適用してデータを保護するには、ID プロバイダを構成する必要があります。これには、ID プロバイダの設定とデータソースの権限の管理が含まれます。 Google は ID プロバイダを使って、検索を実行しているエンドユーザーを特定し、結果として返されるドキュメントへのアクセス権があるかどうかを判断します。

ID プロバイダのタイプを選択する

選択する ID プロバイダのタイプは、Gemini Enterprise app に接続されているデータソースによって異なります。Gemini Enterprise は次のオプションをサポートしています。

ID プロバイダのタイプ 使用する状況
Google Identity Gemini Enterprise には、Google Identity を ID プロバイダとして使用することをおすすめします。

Google Identity は次のものをサポートしています。
  • データ取り込みまたはデータ フェデレーションを使用するすべてのファーストパーティ Google データソース。Google Workspace データソースに接続する場合は、Google Identity を使用する必要があります。
  • データ連携を使用するすべてのサードパーティ データソース。ユーザーは OAuth を使用してサードパーティ サービスで直接認証します。
  • データの取り込みを使用するすべてのサードパーティ データソース。ただし、SharePoint、OneDrive、Outlook などの Microsoft 365 データソースは除きます。これらのデータソースには Microsoft Entra ID と Workforce Identity 連携が必要です。
Google Identity を構成する前に、組織で使用する一意のユーザー属性（通常はユーザーのメールアドレス）を特定します。ユーザーが複数のメールアドレスを持っている場合は、メール エイリアスを追加する必要があります。
サードパーティの ID プロバイダ Gemini Enterprise をサードパーティのデータソースにのみ接続し、Microsoft Entra ID、Okta、AD FS などの OIDC または SAML 2.0 をサポートするサードパーティの ID プロバイダをすでに使用している場合は、Google Identity または Workforce Identity 連携を使用できます。 新しい設定には Google Identity を使用することをおすすめします。Workforce Identity 連携をすでにご利用のお客様は、Workforce Identity 連携を継続してご利用いただけます。詳細については、Workforce Identity 連携をご覧ください。

Workforce Identity 連携を構成する前に、組織で使用する一意のユーザー属性を特定し、Workforce Identity 連携にマッピングします。

Google Workspace コネクタのアクセス制御

Google Workspace コネクタ（Google Workspace のユーザーや Google グループなど）でエンタープライズ データ グラウンディングと検索を使用する場合、Gemini Enterprise はソースシステムのアクセス制御リスト（ACL）と権限を厳密に尊重します。

基本原則: 権限昇格なし

Gemini Enterprise を使用するユーザーは、ソースの Google Workspace アプリケーションで直接アクセスすることをすでに承認されている情報についてのみ、回答を表示してグラウンディングできます。Gemini Enterprise は、ソースシステムのアクセス制御をバイパスしたり、追加の権限を付与したりすることはありません。

  • Google Workspace のユーザー（ディレクトリ）: 検索結果とグラウンディング結果でのユーザーの公開設定は、組織のディレクトリの公開設定に準拠します。たとえば、Google Workspace ディレクトリでのユーザーの可視性が自分の部門または組織部門に制限されている場合、Gemini Enterprise を使用して検索できるのは、その部門内の同僚のみです。制限付きの部門に所属する従業員のプロフィールは表示できません。

  • Google グループ: コンテンツの検出とグラウンディングは、グループのメンバーシップとアクセス設定に準拠します。ユーザーは、メンバーであり、閲覧権限がある Google グループのコンテンツのみを検索して閲覧できます。メンバーでないユーザーは、Gemini Enterprise を通じて限定公開グループのディスカッションを見つけたり、表示したりすることはできません。

権限を管理する場所

Google Cloud コンソールの Gemini Enterprise コネクタ設定で、アクセス制御と可視性の設定を構成することはありません。代わりに、Google Workspace 管理者がソースシステムで権限、メンバーシップ、公開範囲の設定を構成します。

  • ユーザー プロフィールの公開設定: Google Workspace 管理者は、Google 管理コンソールでユーザー プロフィールの公開設定を行います。詳細については、ディレクトリ共有を設定するをご覧ください。

  • グループへのアクセスとメンバーシップ: Google Workspace 管理者は、Google グループまたは Google 管理コンソールでグループへのアクセスとメンバーシップを構成します。詳しくは、グループを設定、管理するをご覧ください。

サードパーティの ID プロバイダ用の Workforce Identity 連携

このセクションでは、サードパーティの ID プロバイダ用に Workforce Identity 連携を構成する方法について説明します。必要に応じて、Workforce Identity 連携の設定が予期したとおりに機能しているかどうかを確認できます。

Workforce Identity 連携を構成する

サードパーティの ID コネクタを使用して Workforce Identity 連携を構成する方法については、次のリソースをご覧ください。

ID プロバイダ リソース
Entra ID
Okta
OIDC または SAML 2.0

属性マッピングを構成する

属性マッピングを使用すると、Workforce Identity 連携を使用してサードパーティの ID 情報を Google に接続できます。

Workforce Identity 連携で属性マッピングを構成する場合は、次の点を考慮してください。

  • google.subject 属性は、属性のマッピング、ライセンスの割り当て、ノートブックの共有に使用されます。ライセンスの割り当てでは大文字と小文字が区別されるため、google.subject をユーザーのメールアドレス（小文字）にマッピングすることをおすすめします。

  • 組織に複数の一意の ID がある場合は、attribute.as_user_identifier_number between 1 and 50 属性を使用してこれらの一意の組織属性をマッピングします。

    たとえば、組織でメールとプリンシパル名の両方を異なるアプリケーション間でユーザー ID として使用し、プリンシパル名がサードパーティの ID プロバイダで preferred_username として設定されている場合は、Workforce Identity 連携の属性マッピング（attribute.as_user_identifier_1=assertion.preferred_username など）を使用して Gemini Enterprise にマッピングできます。

次の例は、一般的な ID プロバイダに必要な属性マッピングを示しています。前述のように、属性マッピングを追加して、追加の固有識別子をサポートできます。

  • OIDC プロトコルを使用した Entra ID
    この例では、メールアドレスを使用してユーザーを一意に識別します。

    google.subject=assertion.email.lowerAscii()
google.groups=assertion.groups
google.display_name=assertion.given_name

  • SAML プロトコルを使用した Entra ID
    この例では、メールアドレスを使用してユーザーを一意に識別します。

    google.subject=assertion.attributes['http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress'][0].lowerAscii()
google.groups=assertion.attributes['http://schemas.microsoft.com/ws/2008/06/identity/claims/groups']
google.display_name=assertion.attributes['http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname'][0]

  • OIDC プロトコルを使用した Okta
    この例では、メールアドレスを使用してユーザーを一意に識別します。

    google.subject=assertion.email.lowerAscii()
google.groups=assertion.groups

  • SAML プロトコルを使用した Okta
    この例では、JWT のサブジェクト アサーションを使用してユーザーを一意に識別します。

    google.subject=assertion.subject.lowerAscii()
google.groups=assertion.attributes['groups']

省略可: Workforce Identity 連携の設定を確認する

Workforce Identity 連携の監査ロギング機能を使用して、ログインの成功と正しい属性マッピングを確認するには、次の操作を行います。

  1. データアクセス アクティビティの Security Token Service API の監査ログを有効にします。

    1. Google Cloud コンソールで、[監査ログ] ページに移動します。

      監査ログに移動

      このページを検索バーで検索する場合は、小見出しが「IAM と管理」の結果を選択します。

    2. 既存の Google Cloud プロジェクト、フォルダ、または組織を選択します。
    3. データアクセス監査ログを有効にします。
      1. 監査ログを有効にする方法の詳細な手順については、Logging のドキュメントをご覧ください。
      2. Security Token Service API で、管理読み取りの監査ログタイプを選択します。詳細については、Workforce Identity 連携のログの例をご覧ください。

  2. Workforce プールで詳細なロギングを有効にします。Microsoft Entra ID の Workforce Identity 連携拡張グループ機能では、詳細な監査ロギング情報は生成されません。

    1. [Workforce Identity プール] ページに移動します。

      [Workforce Identity プール] に移動

    2. テーブルでプールを選択します。

    3. [詳細な監査ロギングを有効にする] 切り替えボタンをクリックしてオンにします。

    4. [Save Pool] をクリックします。

  3. [プロバイダ] セクションで、プロバイダの [ログイン URL] をクリックし、Workforce プールのユーザーとして Google Cloud コンソールにログインします。

  4. ログイン時に生成された監査ログを確認します。

    1. [Workforce Identity プール] ページに移動します。

      [Workforce Identity プール] に移動

    2. テーブルで、ログインしたプールを選択します。

    3. [ログ] の横にある [表示] をクリックします。

    4. 監査ログページで、クエリから protoPayload.resourceName フィルタをクリアします。

    5. [クエリを実行] をクリックします。

  5. 監査ログで、ログイン タイムスタンプと一致する google.identity.sts.SecurityTokenService.WebSignIn メソッドを含むエントリを確認します。

  6. ログの metadata.mapped_attributes フィールドが、サードパーティの ID プロバイダの Workforce Identity 連携を構成するときに使用した属性と一致していることを確認します。

    例:

    "metadata": {
  "mapped_attributes": {
    "attributes.as_user_identifier_1": "alex@admin.altostrat.com"
    "google.subject": "alex@altostrat.com"
    "google.groups": "[123abc-456d, efg-h789-ijk]"
  }
},

制限事項

コネクタを使用してデータソースを接続し、データストアを作成する場合、次の制限が適用されます。

  • ドキュメントごとに許可される閲覧者は 3,000 人です。各プリンシパルは閲覧者としてカウントされます。プリンシパルはグループ ユーザーまたは個々のユーザーです。

  • Gemini Enterprise でサポートされているロケーションごとに、ID プロバイダのタイプを 1 つ選択できます。

  • ID プロバイダのタイプまたは Workforce プールを変更して ID プロバイダの設定を更新しても、既存のデータストアが新しい設定に自動的に更新されることはありません。新しい ID 設定を適用するには、これらのデータストアを削除して再作成する必要があります。

  • データソースをアクセス制御対象として設定するには、データストアの作成時にこの設定を選択する必要があります。既存のデータストアでこの設定をオンまたはオフにすることはできません。

  • サードパーティのアクセス制御を使用する検索アプリの UI 結果をプレビューするには、連携コンソールにログインするか、ウェブアプリを使用する必要があります。 アプリをプレビューするをご覧ください。

ID プロバイダに接続する

次のセクションでは、Google Cloud コンソールを使用して ID プロバイダに接続する方法について説明します。

始める前に

ID プロバイダを接続する前に、次の操作を行います。

  • 管理者に権限を付与します。

  • Workforce Identity 連携を使用してサードパーティの ID プロバイダを接続する場合は、Workforce Identity 連携を構成します。

ID プロバイダを接続する

Gemini Enterprise の ID プロバイダを指定してデータソースのアクセス制御を有効にする手順は次のとおりです。

  1. Google Cloud コンソールで、[Gemini Enterprise] ページに移動します。

    Gemini Enterprise

  2. [設定] > [認証] をクリックします。

  3. 更新するロケーションの [ID プロバイダを追加] をクリックします。

  4. [ID プロバイダを追加] をクリックして、ID プロバイダのタイプを選択します。
    [サードパーティ ID] を選択した場合は、データソースに適用する Workforce プールも選択する必要があります。

  5. [変更を保存] をクリックします。

ユーザーに権限を付与する

アプリへのアクセス、管理、共有には、Gemini Enterprise 企業ユーザー（roles/discoveryengine.agentspaceUser）ロールが必要です。

ID プロバイダのタイプ 説明
Google Identity
  • Google Identity を使用している場合は、アプリを使用するすべての従業員を含む Google グループを作成することをおすすめします。
  • Google Workspace 管理者の場合は、組織のすべてのユーザーをグループに追加するの手順に沿って、組織内のすべてのユーザーを Google グループに含めることができます。
  • ユーザーに Gemini Enterprise ユーザー（roles/discoveryengine.agentspaceUser）ロールを付与します。ロールの追加の詳細については、ユーザーに権限を付与するをご覧ください。
サードパーティの ID プロバイダ

ID プロバイダの設定変更が取り込みコネクタに与える影響

ID プロバイダや Workforce Identity 連携プールなどの ID 設定を変更しても、データの取り込みを使用する既存のデータストアは自動的に更新されません。新しい ID 設定を適用するには、影響を受けるデータストアを削除して再作成する必要があります。

次の表は、データストアの再作成が必要な ID 設定の変更をまとめたものです。

変更タイプ データストアの再作成が必要
Google Identity とサードパーティの ID プロバイダ間の切り替え はい
新しい Workforce Identity 連携プールに完全に変更 はい
現在の ID プロバイダ内の属性マッピングを編集 いいえ
同じ Workforce Identity 連携プール内の新しいプロバイダに切り替え。たとえば、Okta ではなく Entra を使用。 いいえ

ユーザー ID の変更

Gemini Enterprise は、ユーザーのチャット履歴、ノートブック、ユーザーが作成したエージェントをユーザーのプリンシパル ID に関連付けます。Workforce Identity 連携を使用する場合、プリンシパル識別子には、属性マッピングで google.subject に割り当てられた値が含まれます。次に例を示します。

principal://iam.googleapis.com/locations/global/workforcePools/POOL_ID/subject/SUBJECT_ATTRIBUTE_VALUE

サブジェクト値の変更による影響

google.subject にマッピングされている値がユーザーに対して変更されると、Gemini Enterprise はそのユーザーを新規ユーザーとして扱います。たとえば、Microsoft Entra ID でユーザーのユーザー プリンシパル名（UPN）またはメールアドレスが変更され、属性マッピングでその属性が使用されている場合に、この問題が発生します。プリンシパル ID は大文字と小文字が区別されるため、大文字と小文字の変更も変更と見なされます。

変更後は、次のようになります。

  • ユーザーは、以前のプリンシパル識別子に関連付けられているチャット履歴、ノートブック、エージェントにアクセスできません。
  • Gemini Enterprise は、以前のプリンシパル ID から新しいプリンシパル ID にデータを移行しません。
  • 以前のプリンシパル ID に付与されたライセンスと IAM ロールは、新しいプリンシパル ID には適用されません。

サブジェクト値の変更に備える

サブジェクト値の変更の影響を軽減するには、次の操作を行います。

認証エラーのトラブルシューティング

Gemini Enterprise にアクセスしたときに、無効な認証情報が報告される HTTP 401 エラーが発生した場合は、次のことを確認してください。

基本的な確認事項

  • ブラウザの状態: ブラウザのキャッシュと Cookie を削除するか、シークレット モードまたはプライベート ブラウジング ウィンドウからログインするようお客様に依頼します。
  • ログイン済みアカウント: ユーザーが ID プロバイダの構成で想定されているアカウントでログインしていることを確認します。Workforce Identity 連携を使用する場合、ユーザーの ID は属性マッピングと一致する必要があります。
  • デバイスの時計: ネットワーク タイム プロトコル（NTP）などを使用して、デバイスの時計が同期されていることを確認します。デバイスのクロック ドリフトにより、認証が失敗する可能性があります。

ネットワーク ポリシーと ID プロバイダ ポリシー

  • プロキシとファイアウォール: TLS トラフィックを検査するプロキシ、ファイアウォール、セキュア ウェブ ゲートウェイは、Authorization ヘッダーを削除または変更できます。これらのデバイスが Google ドメインへのリクエストを変更しないようにしてください。
  • ID プロバイダのアクセス ポリシー: ID プロバイダのアクセス ポリシー（Microsoft Entra ID の条件付きアクセス ポリシーなど）が、デバイスのコンプライアンス、IP アドレス範囲、または場所を理由にログインをブロックしているかどうかを確認します。
  • コンテキストアウェア アクセス: 組織で Google Cloud または Google Workspace でコンテキストアウェア アクセスを使用している場合は、IP ベースのアクセスレベルによって、Gemini Enterprise がユーザーに代わって行うリクエストがブロックされているかどうかを確認します。これらのリクエストはユーザーのネットワークではなく Google のサーバーから送信されるため、企業 IP 範囲と一致しません。Gemini Enterprise で使用される OAuth 2.0 クライアント ID を、IP ベースのアクセスレベルと組み合わせて OR 条件として許可するアクセスレベルを追加します。拒否されたリクエストは、組織の contextawareaccess.googleapis.com の監査ログに表示されます。
  • DNS の解決: DNS リゾルバが *.google.com や *.googleapis.com などの Google ドメインを正しく解決していることを確認します。

診断情報を収集する

エラーが解決しない場合は、エラーを再現しながら HAR（HTTP アーカイブ）ファイルとブラウザ コンソールログをキャプチャし、Cloud カスタマーケアにお問い合わせください。HAR ファイルには、Cookie やトークンなどの機密情報が含まれている場合があります。

次のステップ