Workforce Identity 連携は、 Google Cloud 組織を外部 ID プロバイダ（IdP）と連携して、シングル サインオン（SSO）を有効にします。
これらのベスト プラクティスを適用すると、Workforce Identity 連携を効果的に使用し、セキュリティ リスクを最小限に抑えることができます。
適切なアーキテクチャを選択する
以降のセクションでは、要件に合った連携アーキテクチャを選択するための重要な要素について説明します。
フェデレーション アーキテクチャ パターンを選択する
次の 4 つのパターンは、 Google Cloud組織を外部 IdP と連携する一般的な方法を示しています。
- Cloud Identity 連携
- Workforce Identity 連携（同期なし）
- System for Cross-domain Identity Management（SCIM）を使用した Workforce Identity 連携
- ハイブリッド クラウド ID と Workforce Identity 連携
フェデレーションを行う前に、各パターンの利点と制限事項を考慮し、要件に一致するパターンを選択します。詳細については、ID 連携のアーキテクチャ パターンをご覧ください。
サービスごとの連携の使用状況
一般に、ユーザーごとではなく、サービスごとに連携の使用状況をパーティショニングすることをおすすめします。サービスごとに使用量をパーティショニングすると、全体的なデメリットが少なくなります。
複雑さを軽減するため、Cloud Identity または Workforce Identity 連携のいずれかを使用することをおすすめします。ただし、要件によっては、ハイブリッド パターンで説明されているように、両方を並行して使用する必要がある場合があります。
Cloud Identity 連携と Workforce Identity 連携を並行して使用する場合は、次の方法で使用状況をパーティショニングできます。
ユーザーによるパーティション分割: ユーザーを 2 つのコホートに分割します。1 つは Workforce Identity 連携を使用するコホート、もう 1 つは Cloud Identity 連携を使用するコホートです。
- メリット: 各ユーザーは、Google サービス全体で単一の ID と 1 つのログイン方法を使用します。
デメリット: ユーザーによるパーティショニングには、次のようなデメリットがあります。
IAM 許可ポリシーにはプリンシパル タイプの組み合わせを含める必要があり、Cloud Identity ユーザーと Workforce Identity 連携ユーザーに同じグループを使用できないため、アクセス グループの管理は複雑になる可能性があります。
Google Cloud コンソール、Gemini Enterprise、その他のツールでは、ユーザーのログイン方法に応じて異なる URL が使用されるため、異なるコホートのユーザーはリンクを共有できません。
異なるコホートのユーザーは、異なる機能セットにアクセスできる場合があります。
サービスでパーティショニングする:Google Cloud や Gemini Enterprise などの各サービスを構成して、Workforce Identity 連携ユーザーまたは Cloud Identity ユーザーにのみアクセス権を付与し、両方に付与しないようにします。
- メリット: 管理が簡素化され、さまざまなユーザーに対して一貫した機能セットが提供されます。
- デメリット: 一部の従業員には、Workforce Identity 連携を使用する ID と Cloud Identity を使用する ID の 2 つの ID を割り当てる必要がある場合があります。
サービスごとにパーティショニングすることをおすすめします。特に、Gemini Enterprise と NotebookLM Enterprise を他のサービスから分離することをおすすめします。Gemini Enterprise と Google Cloud コンソールは、異なるタスク用に設計された別々のツールです。ログイン プロセスの違いがユーザー エクスペリエンス全体に与える影響は最小限に抑える必要があります。
このパーティショニングを適用するには、組織のポリシー制約を使用します。
グループ ガバナンスを強化する
Workforce Identity 連携を効果的に使用するには、グループを使用してアクセスを管理し、それらのグループを管理するための明確なプロセスを確立する必要があります。
リソースにアクセスするユーザーの権限は、認証時に決定されません。代わりに、ユーザーが特定のリソースにアクセスしようとすると、そのリソースに適用されているポリシーに基づいてアクセスが評価されます。これらのポリシーには、次のものが含まれます。
- 1 つ以上の許可ポリシー
- 0 個以上の拒否ポリシー
- 0 個以上のプリンシパル アクセス境界ポリシー
ポリシーは、個々のプリンシパルまたはプリンシパル セットのアクセス権を定義します。
プリンシパル: プリンシパル ID で識別される認証済みユーザー。Workforce プリンシパル ID は次のようになります。
principal://iam.googleapis.com/locations/global/workforcePools/POOL_ID/subject/SUBJECTプリンシパル ID には次のものが含まれます。
POOL_ID: Workforce Identity プールを一意に識別します。SUBJECT: 特定のユーザーを一意に識別します。値と形式は、IdP と属性マッピングによって異なります。
プリンシパル セット: 特定の条件に一致するユーザー。Workforce Identity 連携は、グループベース（グループのメンバー）、属性ベース、ワイルドカード（すべてのユーザー）の 3 つのプリンシパル セットをサポートしています。
個々のプリンシパルにアクセス権を付与することは、特定の状況では有用ですが、次の問題によりスケーリングがうまくいかない傾向があります。
- プリンシパルを 1 つずつ追加すると、許可ポリシーが増加し、管理がますます難しくなります。
- 個別のアクセス管理では、許可ポリシーを頻繁に変更する必要があります。
- ポリシーは時間の経過とともに一貫性がなくなる可能性があります。
スケーラブルで効果的なアクセス管理には、グループベースのプリンシパル セットを使用すると、次のようなメリットがあります。
- 既存の ID ツールとプロセスを使用して、グループのメンバーを追加または削除することで、アクセスを管理できます。
- 許可ポリシーのサイズと複雑さを軽減します。
- 同じロールを持つユーザーが同じリソースにアクセスできるようにします。
グループを使用してアクセスを管理するには、外部 IdP を特定の方法で構成し、IdP がグループに課す制限を把握しておく必要があります。
以降のセクションでは、グループを効果的に使用し、IdP の上限を回避するためのベスト プラクティスについて説明します。
ベスト プラクティス:
さまざまな種類のグループを区別する。アクセス グループを使用してリソースへのアクセス権を付与します。
適用グループを使用してリソースへのアクセスを制限する。
組織グループとコラボレーション グループを使用してアクセスを管理しないでください。
Gemini Enterprise でのみ組織グループとコラボレーション グループを使用します。
さまざまなタイプのグループを区別する
以下に、組織で一般的に見られる 4 種類のグループについて説明します。
- アクセス グループ: Google サービスまたはGoogle Cloud リソースへのアクセス権の付与にのみ使用されます。アクセス グループは、職務を表し、これらの職務を遂行するために必要なロールの割り当てを簡素化します。
- 組織グループ: 組織の構造のサブセットを表すグループで、通常は人事データから取得されます。部門、指示系統、地理的位置、その他の組織内のグループに基づく場合があります。
- コラボレーション グループ: プロジェクトで共同作業したり、特定のトピックについて話し合ったりするワークグループ、プロジェクト メンバー、ユーザーを表します。メール配信に使用されることがあります。コラボレーション グループは多くの場合、アドホックなセルフサービス方式で作成されます。
- 適用グループ: 適用グループ（ポリシー グループとも呼ばれます）は、アクセスを制限するために使用されます。アクセスを許可するために使用されるアクセス グループとは対照的です。たとえば、プリンシパル アクセス境界、拒否ポリシー、多要素認証の適用などです。アクセス グループでは、メンバーがグループを自主的に脱退することを許可できます。ただし、執行グループへの参加は任意ではありません。
フェデレーションする必要があるグループは、使用する次のサービスによって異なります。
- Google Cloudの場合、アクセス グループと適用グループのみが必要です。
- Gemini Enterprise の場合は、アクセス グループ、適用グループ、データ取り込みベースのコネクタを使用する場合は特定の組織グループとコラボレーション グループが必要です。
Workforce Identity 連携を構成するときに、関係のないグループタイプを除外して、IdP のトークン上限を超えないようにします。このアプローチにより、IdP によって課せられた制限を超えるリスクを軽減し、グループの使用の一貫性を高めることができます。
アクセス グループを使用してリソースへのアクセス権を付与する
アクセスを効果的に管理するには、アクセス グループにマッピングされるプリンシパル セットを使用することをおすすめします。アクセス グループは、アクセスを提供するためだけに存在します。アクセス グループは、職務を表し、これらの職務を遂行するために必要なロールの割り当てを簡素化します。
アクセス グループを構成する手順は次のとおりです。
- IdP で、職務を表すアクセス グループを作成します。
- アクセス グループをプリンシパル セットにマッピングして、IAM で使用します。
- ポリシー バインディングを作成して、各職務に必要なリソースへのアクセス権をプリンシパル セットに付与します。
- 外部 IdP で、職務に基づいてグループにユーザーを追加または削除します。
アクセス権を付与するポリシーには、次のようなアクセス グループを使用します。
- IAM 許可ポリシー
- VPC Service Controls の上り（内向き）ルール
アクセス グループが十分にきめ細かいことを確認します。たとえば、次のグループは有効なアクセス グループを表します。
widget-sales-dashboard-readers: 特定の BigQuery データセットと関連するダッシュボードに対する読み取りアクセス権を付与します。dev-ssh-users: 開発環境の Compute Engine VM への OS Login アクセス権を付与します。一方、次のタイプのグループは、一般にアクセス グループとして使用するのに適していません。
cloud-adminsなどの広範な管理者グループは、どのワークロードまたは環境に適用されるかについて具体性に欠けることがよくあります。australia-fteなどの組織グループは、職務ではなく、チームや勤務地などのグループを表します。security-discussなどのコミュニケーション グループは、アクセス グループではなく、メーリング リストやコラボレーション用に設計されています。
アクセス グループをきめ細かく維持するには、 Google Cloudにオンボーディングするワークロードまたはプロジェクトごとに新しいアクセス グループのセットを作成します。これにより、アクセス グループの数を Google Cloudで実行するワークロードの数に合わせてスケーリングできます。
適用グループを使用してリソースへのアクセスを制限する
適用グループはアクセス グループに似ていますが、通常は次の点で異なります。
- メンバーがグループから自主的に脱退することを許可していません。
- ワークロードに固有のものではありません。
適用グループは、次のようなアクセスを制限するポリシーに使用します。
- IAM 拒否ポリシー
- プリンシパル アクセス境界
- 組織のポリシー
適用グループの例としては、users-in-restricted-locations、fedramp-low、mfa-users などがあります。通常、適用グループの数は少なく、ユーザーのグループ メンバーシップの合計数に影響する可能性は低いと考えられます。
組織グループとコラボレーション グループを使用してアクセスを管理しない
アクセスを効果的に管理するには、組織グループやコラボレーション グループではなく、アクセス グループと適用グループを使用します。
組織グループは、組織の構造のチームまたはサブセットを表し、通常は人事データから取得されます。これらのグループは、次の理由で Google Cloud リソースへのアクセス権の管理には適していません。
- チームの責任と構成は時間の経過とともに変化する可能性があります。たとえば、チームがワークロードを別のチームに引き継いだり、2 つのチームが統合されたりする場合があります。組織グループを使用してアクセスを管理する場合、これらの移行中にポリシーの変更がカスケードされることがあります。
- 組織グループのメンバーがリソースに対して同じアクセス権を必要とすることはほとんどありません。組織グループにアクセス権を付与すると、一部のメンバーに必要以上のアクセス権が付与されることがよくあります。
通常、コラボレーション グループはセルフマネージドであり、メンバーは他のメンバーの承認を得て参加するか、承認なしで参加できます。コラボレーション グループを使用してアクセス権を付与すると、権限の過剰付与や権限昇格につながる可能性があります。
組織グループとコラボレーション グループがアクセス管理に使用されないようにするには、Workforce Identity 連携に使用されるトークンまたはアサーションでこれらのグループ メンバーシップを除外するように IdP を構成します。
Gemini Enterprise でのみ組織グループとコラボレーション グループを使用する
組織グループとコラボレーション グループは Google Cloud リソースへのアクセス権の管理には適していませんが、Gemini Enterprise で必要になる場合があります。
- ACL の評価: データ取り込みベースのコネクタを使用して Gemini Enterprise を Microsoft 365 と統合すると、組織グループとコラボレーション グループを参照するアクセス制御リスト（ACL）を含むドキュメントが検出されることがあります。Gemini Enterprise がこれらのグループのユーザーのメンバーシップにアクセスできない場合、ユーザーがこれらのドキュメントにアクセスする権限があるかどうかを正しく評価できない可能性があります。
- ノートブックの共有: NotebookLM では、ユーザーがノートブックを共有できます。ユーザーがノートブックをコラボレーション グループと共有できるようにすると、個々のユーザーに共有を制限するよりも便利になることがよくあります。
組織グループとコラボレーション グループを Gemini Enterprise でのみ使用できるようにするには、IdP を次のように構成します。
- SCIM を使用して、組織グループとコラボレーション グループ、およびそのメンバーシップをプロビジョニングします。
- Workforce Identity 連携に使用されるトークンまたはアサーションで、組織グループとコラボレーション グループのメンバーシップを除外します。
Workforce Identity プールを管理する
Workforce Identity プールは、プリンシパル ID の名前空間を定義し、連携構成のコンテナとして機能します。ユーザー ディレクトリとは異なり、プールにはユーザーやグループに関する情報は保存されません。
ベスト プラクティス:
IdP ごとに 1 つのプールを使用します。一意で意味のあるプール名を選択します。
プールを特権リソースとして扱う。
フェデレーションをパートナーに拡張する際のリスクを考慮する。
IdP ごとに 1 つのプールを使用する
Workforce Identity プールは、プロジェクト レベルのリソースではなく、組織レベルのリソースです。この設計は、Workforce Identity プールが個々のプロジェクトやワークロードではなく、 Google Cloud 組織全体の認証を管理することを反映しています。
ほとんどの組織では、Workforce Identity プールの数は IdP の数と一致する必要があります。
- 組織で単一の IdP を使用して認証を管理する場合は、単一の従業員 ID プールを使用します。
- 組織で複数の IdP を使用している場合（買収など）、IdP ごとに 1 つの Workforce Identity プールを使用します。
Workforce Identity プールの数を制限すると、次のことを保証できます。
- 新しいワークロードを Google Cloudにオンボーディングするときに、Workforce Identity プールを作成または変更する必要はありません。
- IAM を使用すると、 Google Cloud 個々のユーザーがアクセスできるプロジェクトとリソースを制御できます。
一意で意味のあるプール名を選択する
プリンシパル ID をグローバルに一意にするため、Workforce Identity は Workforce Identity プール名をプリンシパル ID にエンコードします。Workforce Identity プールの名前を選択する際は、次の制約事項を考慮してください。
- 一意性: Google Cloud 全体で一意であり、他の組織によって所有されていない名前を選択します。
- 不変性: Workforce Identity プールの名前は変更できません。一時的な取り組みの名前は避け、時間の経過とともに意味が薄れない名前を選びます。
- ユーザー エクスペリエンス: ログイン構成によっては、ユーザーがログイン時にプール名を入力する必要がある場合があります。覚えやすい略称を選びます。
プールを高権限リソースとして扱う
Workforce Identity プールとプロバイダは、ユーザーのログイン方法を決定し、外部 IdP から ID とグループ メンバーシップを導出する方法を制御します。これらのコンポーネントは認証ロジックを制御するため、 Google Cloud 組織のセキュリティの中心となります。これらのコンポーネントが侵害されると、不正な行為者がスプーフィング攻撃を行う可能性があります。
スプーフィング攻撃を行うために、不正な行為者は次の操作を試みる可能性があります。
- 属性のマッピングの変更: 属性のマッピングを変更すると、不正な行為者が他のユーザーとして認証され、不正な特権アクセスを取得する可能性があります。
- 悪意のあるプロバイダの追加: プロバイダを追加すると、不正な行為者が組織の IdP をバイパスし、制御している別の IdP を使用して認証を行う可能性があります。
Workforce Identity プールとプロバイダは、次の保護を必要とするセキュリティ上重要なリソースです。
- 非連携ユーザーへのアクセスを制限する: 管理者権限を、緊急アクセス ユーザーを 1 人以上含む、少数の Cloud Identity または Google Workspace ユーザーに制限します。
- 管理ユーザーを保護する: すべての管理者ユーザーと緊急アクセス ユーザーに 2 段階認証プロセスを要求します。
- ジャストインタイム アクセス: Privileged Access Manager（PAM）を使用して、永続的なアクセス権を付与するのではなく、ジャストインタイムで管理者権限を付与します。
パートナーにフェデレーションを拡張する際にリスクを考慮する
Workforce Identity 連携を使用して外部 IdP と連携すると、信頼関係が確立されます。 Google Cloud 連携を使用すると、外部 IdP が次のアクションを実行します。
- セキュリティ要件を満たす多要素認証（MFA）を実施します。
- ユーザー ID とグループ メンバーシップに関する正確なアサーションを行う。
- ユーザーが迅速にオフボーディングされ、グループ メンバーシップに現在のロールが正確に反映されるようにする ID ガバナンス プロセスに従います。
Workforce Identity 連携では、外部 IdP によって行われたアサーションを検証するメカニズムが制限されています。具体的には、Workforce Identity 連携は、Cloud Identity と同じ方法で SSO 後の MFA をサポートしていません。
Workforce Identity 連携を使用して外部パートナーや請負業者が Google Cloud リソースにアクセスできるようにする前に、このレベルの信頼が適切かどうかを判断します。パートナーとその IdP がセキュリティ標準を常に満たしていると信頼できる場合を除き、パートナー アクセスに Workforce Identity 連携を使用しないでください。
Workforce Identity プール プロバイダを管理する
Workforce Identity プール プロバイダは、外部 IdP との連携関係を定義し、次の構成を含みます。
- シングル サインオンに使用する IdP。
- IdP によって提供されたトークンまたはアサーションからプリンシパル ID を取得するために使用する属性マッピング。
- 省略可: グループ メンバー情報の検索に使用する SCIM テナント。
ベスト プラクティス:
意味のあるプロバイダ名を選択します。IdP のアプリケーション ポータルを使用して個々のサービスを公開します。
プールごとに 1 つのプロバイダを使用して、サブジェクトの競合を回避します。
Google Cloud コンソールと Gemini Enterprise に同じプールとプロバイダを使用します。
テナント固有の発行元 URI を使用する。
OpenID Connect（OIDC）の暗黙的フローの使用を避ける。
意味のあるプロバイダ名を選択する
Workforce Identity プール プロバイダを作成するときに、名前を割り当てる必要があります。Workforce Identity プール名とは異なり、この名前はグローバルに一意である必要はなく、プリンシパル ID にエンコードされません。ただし、ログイン構成によっては、ユーザーがログイン時にプロバイダ名を入力する必要がある場合があります。ユーザー エクスペリエンスを向上させるため、entra や staff など、意味のある覚えやすい名前を選択してください。
oidc や saml などの名前は、ユーザーが知らない可能性があるため、使用しないでください。
IdP アプリケーション ポータルで個々のサービスを表示する
Microsoft Entra ID や Okta などの ID プロバイダは、ユーザーが割り当てられたアプリケーションを見つけてアクセスできるアプリケーション ポータルを提供します。ポータルを使用して、次の操作を行い、ユーザー エクスペリエンスを最適化します。
- 単一の Google Cloud リンクを表示するのではなく、関連する Google サービスを個別に表示するようにポータルを設定します。
- ユーザーが自動的にログインするようにリンクを設定します。
次の表に、Workforce Identity 連携をサポートする一般的な Google サービスと、自動ログインの URL を示します。
| アプリケーション | URL |
|---|---|
| Google Cloud Workforce Identity 連携コンソール（コンソール（連携）） | https://auth.cloud.google/signin/locations/global/workforcePools/POOL/providers/PROVIDER?continueUrl=https%3A%2F%2Fconsole.cloud.google |
| Gemini Enterprise | https://auth.cloud.google/signin/locations/global/workforcePools/POOL/providers/PROVIDER?continueUrl=https%3A%2F%2Fvertexaisearch.cloud.google%2Fhome%2Fcid%2FWEBAPP_ID |
| NotebookLM Enterprise | https://auth.cloud.google/signin/locations/global/workforcePools/POOL/providers/PROVIDER?continueUrl=https%3A%2F%2Fnotebooklm.cloud.google%2Fglobal%2F%3Fproject%3DPROJECT_NUMBER |
| IAP ウェブアプリ | アプリの URL（https://iap.example.com/ など） |
次のように置き換えます。
POOL: Workforce Identity プールの名前。PROVIDER: プール プロバイダ名。WEBAPP_ID: Gemini Enterprise ウェブアプリの ID。PROJECT_NUMBER: NotebookLM Enterprise プロジェクト番号。
プールごとに 1 つのプロバイダを使用して、サブジェクトの競合を回避する
Workforce Identity 連携を使用すると、複数のプロバイダを Workforce プールに追加できます。2 つ目のプロバイダを追加することは、移行中にユーザーが一時的に異なる IdP を使用して認証できるようにする場合に便利です。一時的な状況を除き、次の理由から複数のプロバイダを使用することは避けてください。
- サブジェクトの競合: 複数のプロバイダを使用すると、サブジェクトの競合のリスクが生じます。このような競合では、1 つのプロバイダの
google.subject属性マッピングが別のプロバイダと同じ値を返します。この競合により、複数の外部 ID が同じ IAM プリンシパルにマッピングされ、Cloud Audit Logs で区別できなくなります。 - IAP の互換性: IAP では、未認証のユーザーを IdP に自動的にリダイレクトするために、Workforce Identity プールに単一のプロバイダが必要です。プロバイダを追加すると、IAP はユーザーを認証できなくなります。
複数のプロバイダと連携する必要がある場合は、複数の Workforce プールを作成し、プールごとに 1 つのプロバイダを構成します。
Google Cloud コンソールと Gemini Enterprise で同じプールとプロバイダを使用する
Gemini Enterprise と Google Cloudの両方に Workforce Identity 連携を使用する場合は、ユーザーが再ログインせずに両方のサービスに同時にアクセスできるように、単一のプロバイダを使用します。属性マッピングが異なる個別のプロバイダを使用すると、ユーザーがログインするプロバイダによってリソースへのアクセス権が異なる状況が発生する可能性があります。
テナント固有の発行元 URI を使用する
プロバイダを構成するときに、IdP を一意に識別する発行元 URI を指定します。ただし、IdP の構成によっては、発行者 URI が組織のテナントに固有ではない場合があります。たとえば、Microsoft Entra ID 共通エンドポイント（https://login.microsoftonline.com/common/v2.0）などの汎用または共有の発行元 URI を使用すると、他の組織のユーザーが誤って Google Cloud組織に対して認証される可能性があります。
テナント間の意図しないアクセスを防ぐには、テナント固有の発行元 URI を使用します。IdP がテナント固有の発行元 URI を提供していない場合は、特定のテナントへのアクセスを制限するように属性条件を構成します。
OpenID Connect（OIDC）暗黙的フローの使用を避ける
OIDC プロバイダを構成する場合は、暗黙的フローよりも認可コードフローを優先します。OAuth 仕様のバージョン 2.1 では、暗黙的フローは非推奨となっています。トークンの漏洩や挿入に対して脆弱であるためです。認可コードフローを使用すると、トークンの傍受のリスクを軽減できます。
ユーザーの管理
Workforce Identity 連携を使用してユーザーを管理できます。Workforce Identity 連携は、次の手順でユーザーのトークンまたはアサーションからユーザーのプリンシパル識別子を取得します。
google.subjectの属性マッピングを適用して、サブジェクト識別子を決定します。サブジェクト識別子は、Workforce Identity プール内のユーザーを一意に識別する必要がありますが、 Google Cloud全体で一意である必要はありません。プリンシパル ID は、Workforce Identity プールを識別する接頭辞にサブジェクト ID を追加して導出します。結果のプリンシパル ID は Google Cloud 全体で一意であり、次の形式になります。
principal://iam.googleapis.com/locations/global/workforcePools/POOL_ID/\ subject/SUBJECT
Workforce Identity 連携を使用して認証されたユーザーがリソースにアクセスすると、IAM はプリンシパル ID を使用して許可ポリシーのロール バインディングを評価し、Cloud Audit Logs に記録します。
不変のサブジェクト識別子を使用する
ユーザーのサブジェクト識別子が変更されると、プリンシパル識別子も変更されます。その結果、 Google Cloud はそれらを同じユーザーとして認識しなくなります。
- 新しいプリンシパル ID が許可ポリシーにリストされているプリンシパル ID と一致しなくなったため、ユーザーは以前にアクセス権が付与されたリソースにアクセスできません。
- Cloud Audit Logs エントリには新しいプリンシパル ID のみが含まれ、古いプリンシパル ID を使用したログとの関連付けはできなくなります。
ユーザーのプリンシパル ID を安定させるには、google.subject の安定した値が得られる属性マッピングを使用します。
多くの IdP では、ユーザーの一意の数値または UUID 形式の識別子が自動的に生成されます。これらの識別子は一意で安定しているため、google.subject の候補として適しています。ただし、これらの識別子を google.subject として使用すると、長くてわかりにくいプリンシパル ID になる可能性があり、操作が難しくなることがあります。
google.subject の識別子を選択する際は、次の要件を優先度の高い順に考慮してください。
- 一意性: IdP でユーザーを一意に識別する値。
- ユーザビリティ: 値が意味のあるもの、または少なくとも IdP のユーザー ディレクトリで簡単に検索できるもの。
- 不変性: 値は不変です。少なくとも、管理者にのみ変更可能です。
サブジェクト識別子を再利用しない
多くの IdP は、特定のユーザー識別子に一意性制約を適用しますが、識別子の再利用は許可しています。たとえば、IdP では、同じユーザー名 bob を持つ 2 人のユーザーを作成できない場合があります。ただし、ユーザー アカウントを削除すると、IdP で新しいユーザー アカウントを作成して、そのアカウントにユーザー名 bob を再度割り当てることができる場合があります。bob
プロバイダの google.subject の属性マッピングが再利用可能なユーザー識別子を参照している場合、サブジェクトの競合が発生する可能性があります。Workforce Identity 連携では、google.subject が同じ場合、古いユーザーと新規ユーザーを区別できません。その結果、新規ユーザーが古いユーザー専用のリソースにアクセスできるようになる可能性があります。
サブジェクトの衝突を防ぐには、次のいずれかまたは両方を行います。
google.subjectを、IdP で再利用できないユーザー識別子にマッピングします。- IdP でユーザーを削除する場合は、
locations.workforcePools.subjects.deleteAPI を使用して、 Google Cloudでユーザーのデータを削除し、すべてのデータが削除されるまで、同じユーザー識別子がログインに使用されないようにブロックします。
Microsoft Entra ID: UPN をサブジェクト識別子として使用する
このベスト プラクティスは、Microsoft Entra ID を IdP として使用する場合にのみ適用されます。
Microsoft Entra ID を使用する場合、サブジェクト識別子として使用できる識別子は次のとおりです。
- ユーザー プリンシパル名（
upn） - オブジェクト ID（
oid） - メールアドレス（
proxyAddressesのメインのアドレス）
これらのオプションの中で、次の理由からユーザー プリンシパル名をサブジェクト識別子として使用することをおすすめします。
- すべてのユーザーにユーザー プリンシパル名があります。
- ユーザー プリンシパル名はユーザーを一意に識別します。
- ユーザー プリンシパル名は、意味がわかりやすく、扱いやすい傾向があります。
- ユーザー プリンシパル名にはドメイン名が埋め込まれており、ユーザーが関連付けられている Microsoft Entra ID テナントを一意に識別します。
- 組織によっては、ユーザー プリンシパル識別子の再利用を禁止または管理するポリシーが設定されている場合があります。
一方、ユーザーのオブジェクト ID とメールアドレスは、次の理由から適していません。
- オブジェクト ID（
oid）は不変ですが、GUID としてフォーマットされます。この形式では、人間が扱うのが難しく、意味もありません。 - メールアドレスは必須属性ではなく、すべてのユーザーに対して入力されているとは限りません。
どの識別子を選択する場合でも、識別子を小文字に強制変換するなどの変換を適用しないことをおすすめします。
グループを管理
Workforce Identity 連携は、次のソースからユーザーのグループ メンバーシップを特定できます。
- IdP によって提供される SAML アサーションまたは ID トークン。
- Microsoft Graph API（Microsoft Entra ID を IdP として使用している場合）。
- Workforce Identity プール プロバイダに関連付けられた SCIM テナント。
デフォルトでは、Workforce Identity 連携は SAML アサーションまたは ID トークンのみを使用します。
| ソース | Google Cloud | Gemini Enterprise |
|---|---|---|
| SAML または ID トークン | ||
| Microsoft Graph API | - | - |
| SCIM テナント | - | - |
IdP として Microsoft Entra ID を使用している場合は、追加属性機能を有効にできます。Workforce Identity 連携は、グループ メンバーシップのソースとして Microsoft Graph API のみを使用します。
| ソース | Google Cloud | Gemini Enterprise |
|---|---|---|
| SAML または ID トークン | - | - |
| Microsoft Graph API | ||
| SCIM テナント | - | - |
Gemini Enterprise を使用している場合は、SCIM テナントを使用するように Workforce Identity 連携を構成できます。これにより、次のように動作が変更されます。
- Gemini Enterprise は SCIM テナントのグループ メンバーシップを使用し、SAML アサーションまたは ID トークンのグループ メンバーシップ情報を無視します。
- Google Cloud は、SAML アサーションまたは ID トークンのグループ メンバーシップ情報を使用し、SCIM テナントのグループ メンバーシップ情報を無視します。
| ソース | Google Cloud | Gemini Enterprise |
|---|---|---|
| SAML または ID トークン | - | |
| Microsoft Graph API | - | - |
| SCIM テナント | - |
Workforce Identity 連携は、グループ メンバーシップごとに次の手順でプリンシパル ID を導出します。
- 次のいずれかの方法でグループ識別子を特定します。
- SAML アサーションまたは ID トークン:
google.groupsの属性マッピングを適用します。 - SCIM テナント:
google.groupのクレーム マッピングを適用します。 - Microsoft Graph API: プロバイダ構成の
extra-attributes-typeに従います。
- SAML アサーションまたは ID トークン:
プリンシパル ID は、Workforce Identity プールを識別する接頭辞にグループ ID を追加して導出します。結果のプリンシパル ID は Google Cloud 全体で一意であり、次の形式になります。
principalSet://iam.googleapis.com/locations/global/workforcePools/\ POOL_ID/group/GROUP_ID
Workforce Identity 連携を使用して認証されたユーザーがリソースにアクセスすると、IAM はこれらのプリンシパル ID を使用して、許可ポリシーのロール バインディングを評価します。
ベスト プラクティス:
不変のグループ識別子を使用する。アサーションまたはトークン内のグループ メンバーシップを減らします。
Microsoft Entra ID: グループ ID としてオブジェクト ID を使用する。
不変のグループ識別子を使用する
すべての IAM ポリシーは、プリンシパル ID でグループを参照します。IdP でグループの名前を変更して識別子を変更すると、Google Cloud はそのグループを同じグループとして認識しなくなります。
- 既存の IAM ロール バインディングは引き続き古いプリンシパル ID を参照するため、無効になります。
- グループの新しいプリンシパル ID が IAM ロール バインディングと一致しなくなるため、名前変更されたグループのメンバーはアクセス権を失います。
このような中断を防ぐには、IdP 生成の一意の ID などの安定した不変の値を使用するように属性とクレームのマッピングを構成します。表示名やメールアドレスは、組織の変更時に変更される可能性があるため、グループ識別子として使用しないでください。
アサーションまたはトークンのグループ メンバーシップを減らす
デフォルトでは、IdP は、Gemini Enterprise と Google Cloud リソースへのアクセスを管理するために必要な数よりも多くのグループ メンバーシップを SAML アサーションまたは ID トークンに含める場合があります。不要なグループ メンバーシップを含めると、次のような複数のリスクが生じます。
- アクセスの一部喪失: 多くの IdP では、トークンまたはアサーションに含めることができるグループ メンバーシップの数に上限が設定されています。ユーザーがこの上限を超えると（グループ超過）、IdP が一部のグループ メンバーシップを削除し、ユーザーが特定のリソースにアクセスできなくなる可能性があります。
- ログインの失敗: Workforce Identity 連携では、
google.groups属性マッピングで生成できるグループ メンバーシップのサイズと数が制限されます。これらの上限のいずれかを超えたユーザーはログインできません。 - グループの使用の一貫性の欠如: グループを Google Cloudに公開すると、特定のグループをGoogle Cloudで使用する予定がなくても、プロジェクト オーナーがそれらのグループを使用してリソースへのアクセスを管理する可能性があります。
次のアプローチは、これらのリスクを軽減し、アサーションまたはトークン内のグループ メンバーシップの数を減らすのに役立ちます。
グループタイプでフィルタする: Microsoft Entra ID などの一部の IdP では、アサーションまたはトークンに含めるグループを決定するフィルタを構成できます。構成と使用する予定のサービスに基づいて、関連性のないグループタイプを除外するようにフィルタを構成できます。
次の表に、使用する予定のサービスに応じて、アサーションまたはトークンに含める必要があるグループのタイプを示します。
グループの種類 Google Cloud Gemini（同期なし） Gemini（SCIM） アクセス グループ - 適用グループ - 組織内のグループ 不要 * - コラボレーション グループ 不要 * - * データ取り込みベースのコネクタを使用する場合にのみ必要です。
- Google Cloudへのアクセスを管理するには、アクセス グループと適用グループを含める必要があります。
- Gemini Enterprise へのアクセスを管理するために必要なフィルタは、SCIM を使用するかどうかによって異なります。SCIM を使用する場合、Gemini Enterprise はアサーションまたはトークンに含まれるグループ メンバーシップを無視するため、Gemini Enterprise 固有のグループを含める必要はありません。SCIM を使用しない場合は、Gemini Enterprise に必要なアクセス グループと適用グループを含める必要があります。データ取り込みベースのコネクタを使用する予定があるかどうかによっては、特定の組織グループとコラボレーション グループを含める必要もあります。
割り当て: Microsoft Entra ID などの一部の IdP では、トークンとアサーションのグループ メンバーシップを、割り当てられたグループ（明示的に証明書利用者構成に割り当てたグループ）に制限できます。
追加属性フィルタ: Microsoft Entra ID を使用していて、追加属性機能を有効にしている場合は、
--extra-attributes-filterフラグを使用してフィルタを指定できます。Workforce Identity 連携は、グループ メンバーシップをリクエストするときに、このフィルタを Microsoft Graph API に渡します。
フィルタをテストまたはトラブルシューティングするには、 Google Cloud コンソールのIdP トークンのデバッグ ツールを使用するか、詳細な監査ロギングを有効にします。
Microsoft Entra ID: グループ ID としてオブジェクト ID を使用する
このベスト プラクティスは、Microsoft Entra ID を IdP として使用する場合にのみ適用されます。
Microsoft Entra ID を使用する場合、グループ ID として使用できる ID には次のものがあります。
- オブジェクト ID（
oid） - メールアドレス
- 表示名
これらのオプションの中で、次の理由からグループ ID としてオブジェクト ID（oid）を使用することをおすすめします。
- すべてのグループにオブジェクト ID があります。一方、メールアドレスは省略可能なフィールドであり、Microsoft 365 グループに対してのみ入力される場合があります。
- オブジェクト ID は一意で変更できません。一方、グループの表示名は変更可能で、一意である必要はありません。
どの ID を選択する場合でも、ID を小文字に変換するなどの変換を適用しないことをおすすめします。
アクセス管理
アクセス制限とジャストインタイム（JIT）管理のベスト プラクティス。
ベスト プラクティス:
緊急アクセスに Cloud Identity ユーザーを使用する。特権アクセスに Cloud Identity を使用する。
組織のポリシーの制約を使用してフェデレーションを管理する。
プールのすべてのメンバーにアクセス権を付与しないでください。
セッションの長さを制限する。
セッションの長さを JIT アクセスの要件に合わせます。
緊急アクセスに Cloud Identity ユーザーを使用する
Google Cloud 環境への継続的なアクセスを確保するために、環境ごとに緊急アクセス ユーザーを作成します。
緊急アクセス ユーザーは、サービスが誤って構成されている、侵害されている、または正常に動作していない場合に、 Google Cloud 環境へのアクセスを提供します。緊急アクセス ユーザーは非常に高い権限を持っています。緊急アクセス ユーザーの認証に Workforce Identity 連携を使用すると、次のリスクが生じます。
- Workforce Identity プール プロバイダの構成を誤ると、ロックアウトされる可能性があります。
- 外部 IdP に影響するサービスの中断により、最も必要なときに緊急アクセス ユーザーを使用できなくなる可能性があります。
- 外部 IdP が侵害されると、不正な行為者が緊急アクセス ユーザーとして認証され、 Google Cloudリソースへの広範なアクセス権を取得する可能性があります。
これらのリスクを軽減するには、他のユーザーに Workforce Identity 連携を使用している場合でも、緊急アクセス ユーザーに Cloud Identity または Google Workspace を使用します。
- Cloud Identity で緊急アクセス ユーザーを作成します。
- これらのユーザーをシングル サインオンから除外し、ユーザー名とパスワードを使用して認証できるようにします。
- セキュリティ キーを使用した 2 段階認証プロセスに登録して、これらのユーザーを保護します。
緊急アクセス ユーザーの詳細については、 Google Cloudへの継続的なアクセスに関するベスト プラクティスをご覧ください。
特権アクセスに Cloud Identity を使用する
特権ユーザーは、 Google Cloud環境に幅広くアクセスできます。このようなユーザーの例を次に示します。
- 組織管理者ロール（
roles/resourcemanager.organizationAdmin）を持つユーザー - セキュリティ管理者ロール（
roles/iam.securityAdmin）または Google Cloud リソース階層の大部分で許可ポリシーを変更できる同様のロールを持つユーザー
Workforce Identity 連携を権限の高いユーザーに使用する場合、外部 IdP の構成ミスや侵害は、 Google Cloud リソースのセキュリティに影響する可能性があります。特に、外部 IdP が侵害されると、不正な行為者が特権ユーザーとして認証され、 Google Cloud リソースへの広範なアクセス権を取得する可能性があります。
これらのリスクを軽減するには、権限の高いユーザーに Cloud Identity を使用します。
- Cloud Identity で高度な権限を持つユーザーを作成します。
- セキュリティ キーを使用した 2 段階認証プロセスに登録して、これらのユーザーを保護します。
- Cloud Identity を外部 IdP とフェデレーションしている場合は、これらのユーザーに対して追加の SSO 検証と 2 段階認証プロセスを有効にします。
IdP がすでに多要素認証を適用している場合、追加の SSO の確認は冗長であるように見える場合がありますが、この設定は IdP が不正使用された場合にユーザーを保護できます。追加の SSO 検証は Cloud Identity でサポートされている機能ですが、Workforce Identity 連携では使用できません。
組織のポリシーの制約を使用してフェデレーションを管理する
緊急時や高度な権限でのアクセス以外の目的で Cloud Identity を使用する場合は、サービスごとに Cloud Identity 連携と Workforce Identity 連携の使用状況をパーティショニングします。このプラクティスを適用するには、カスタム組織のポリシーの制約を使用して、特定のプロジェクトで許可されるプリンシパル タイプを制限します。
たとえば、次の操作を行うと、Workforce Identity 連携を Gemini Enterprise に制限できます。
MemberTypeMatches関数を使用する Gemini Enterprise プロジェクトにカスタム組織のポリシーの制約を適用して、許可されるプリンシパル タイプをiam.googleapis.com/WorkforcePoolPrincipalとiam.googleapis.com/WorkforcePoolPrincipalSetに制限します。これらは、Workforce Identity 連携で使用されるプリンシパル タイプです。- 他のすべてのプロジェクトでは、
iam.googleapis.com/WorkforcePoolPrincipalとiam.googleapis.com/WorkforcePoolPrincipalSetを除くすべてのプリンシパル タイプを許可する制約を適用します。
カスタム組織ポリシーの制約を使用すると、一貫性を確保し、誤ったプリンシパル タイプが誤って使用されるのを防ぐことができます。
プールのすべてのメンバーにアクセス権を付与しない
Workforce Identity 連携は、次の形式のワイルドカード プリンシパル ID をサポートしています。
principalSet://iam.googleapis.com/locations/global/workforcePools/
POOL_ID/*
この識別子は、IdP がGoogle Cloudへの認証を許可するすべてのユーザーと一致します。
このワイルドカード識別子を使用して権限を付与しないでください。IdP のユーザーベースが拡大すると、ワイルドカード プリンシパル ID を使用してアクセス権を付与すると、過剰な権限付与につながります。
代わりに、IdP でアクセス グループを作成し、これらのグループを使用してリソースへのアクセスを管理します。このアプローチにより、アクセスは認証の成功ではなく、意図的なグループ メンバーシップによって制御されるため、過剰な権限付与のリスクが軽減されます。
セッションの長さを制限する
ユーザーがログインすると、Workforce Identity 連携がセッションを開始します。セッションでは、ユーザーは次の操作を行うことができます。
- コンソール（連携）、Gemini Enterprise、または Workforce Identity 連携をサポートするその他のポータルを使用し、それらの間を移動します。
- IAP で保護されたウェブ アプリケーションを使用する。
- 連携更新トークンと連携アクセス トークンを取得します（たとえば、
gcloud auth loginを実行します）。
セッションは、次のいずれかが発生するまで有効です。
- セッションの長さが、Workforce Identity プールで定義された上限に達した。
- セッションの長さが、ユーザーの SAML アサーションの
SessionNotOnOrAfter属性で定義されている上限に達した場合（存在する場合）。 - ユーザーがログアウトします。
セッションの有効期間を長くすると、トークンが盗まれるリスクが高まり、グループ メンバーシップ情報が古くなる可能性があります。
- IdP で権限が取り消されると、ユーザーは意図したよりも長くアクセス権を保持する可能性があります。
- ユーザーは、再認証して新しいセッションを確立するまで、新しく付与されたアクセス権を行使できない場合があります。
これらのリスクを軽減するには、セッションの長さを制限して、ユーザーが 1 日に少なくとも 1 回は再度ログインする必要があるようにします。
セッションの長さを JIT アクセスの要件に合わせる
特権アクセスを管理するために、IdP はメンバーが一時的に有効にできるジャストインタイム（JIT）グループをサポートしている場合があります。ジャストインタイム グループを使用して Google Cloud または Gemini Enterprise への特権アクセスを管理すると、次のリスクが生じる可能性があります。
- 遅延アクティベーション: ユーザーがジャストインタイム グループ メンバーシップを有効にしているときに、Workforce Identity 連携セッションがアクティブな場合、メンバーシップの変更はユーザーがログアウトして再度ログインするまで有効になりません。また、Workforce Identity プール プロバイダが SCIM を使用している場合、グループ メンバーシップの変更がプロビジョニングされるまで、メンバーシップの変更は有効になりません。
- 遅延した取り消し: グループ メンバーシップの有効期限が切れても、ユーザーがログアウトして再度ログインするか、SCIM を使用してグループ メンバーシップの変更がプロビジョニングされるまで、ユーザーは特権アクセスを失いません。セッションの長さによっては、この遅延によってメンバーシップの有効期限の目的が損なわれる可能性があります。
これらのリスクを軽減するには、Workforce Identity プールのセッションの長さを十分に短く構成します。
アクティビティをモニタリングする
Google Cloudのリソースに影響する不審なアクティビティが判明した場合、Cloud Audit Logs は、アクティビティの発生時刻と関与したユーザーを特定するための重要な情報を提供します。
データアクセス ログを有効にする
Workforce Identity 連携では、ログインとトークン交換のアクティビティを追跡できるログを生成できます。Security Token Service API は、次のメソッドを含むこれらのログを書き込みます。
google.identity.sts.SecurityTokenService.WebSignIngoogle.identity.sts.SecurityTokenService.WebSignOutgoogle.identity.sts.v1.SecurityTokenService.ExchangeTokengoogle.identity.sts.v1beta.SecurityTokenService.ExchangeToken
ログインとトークン交換アクティビティに関連するすべてのログはデータアクセス ログとして分類され、デフォルトで無効になっています。これらのログをキャプチャするには、Google Cloud 組織全体で Security Token Service API のデータアクセス ログを有効にします。ログインログの詳細度をさらに上げるには、詳細な監査ロギングを有効にします。
認証関連の他のアクティビティを追跡するには、次のログを有効にして使用することをおすすめします。
- IAM SCIM 監査ログ
- サービス アカウント認証情報の監査ログ
- Cloud Identity と Google Workspace のログイン監査ログ
次のステップ
- Workforce Identity 連携の概要を確認します。
- プールとプロバイダを管理する方法を学習する。