Workload Identity 連携を使用すると、Google Cloud の外部で実行されているアプリケーションが、外部 ID プロバイダの認証情報を使用してサービス アカウントの権限を借用できます。
Workload Identity 連携を使用すると、外部環境の認証メカニズムをアプリケーションで使用できるようになり、セキュリティを強化できます。また、サービス アカウント キーを置き換えることもできます。
Workload Identity 連携を安全に使用するには、次の脅威から保護するように構成する必要があります。
- なりすまし: 不正な行為者が Google Cloud リソースへの不正アクセスを試みるために、別のユーザーになりすます可能性があります。
- 権限昇格: 不正な行為者が、通常ではアクセス権を付与されないリソースにアクセスするために、Workload Identity 連携を利用する可能性があります。
- 否認防止: 不正な行為者が、追跡を困難にする外部認証情報を使用して、身元とアクションを隠蔽する可能性があります。
このガイドでは、Workload Identity 連携を使用するタイミングと、リスクを最小限に抑えるように構成する方法について説明します。
Workload Identity 連携を使用するタイミング
ベスト プラクティス:
アンビエント認証情報にアクセスできるアプリケーションで Workload Identity 連携を使用します。Workload Identity 連携でサポートされていないアンビエント認証情報を使用する場合は、追加のトークン交換を使用します。
ローテーションが必要な認証情報の数を減らす場合に Workload Identity 連携を使用します。
アンビエント認証情報にアクセスできるアプリケーションで Workload Identity 連携を使用する
多くの場合、Google Cloud 以外のクラウド プロバイダで実行されているアプリケーションはアンビエント認証情報にアクセスできます。これらは、アプリケーションが追加の認証なしで取得できる認証情報です。次に例を示します。
- AWS では、EC2 にデプロイされたアプリケーションがインスタンス プロファイルを使用してロールを想定し、一時的な認証情報を取得できます。
- Azure では、アプリケーションでマネージド ID を使用して、アクセス トークンを取得できます。
- GitHub Actions では、ワークフローでデプロイジョブの ID が反映された ID トークンを取得できます。
アンビエント認証情報が OpenID Connect（OIDC）トークン、SAML アサーション、または AWS 認証情報の場合は、アプリケーションがこれらの認証情報を有効期間の短い Google アクセス トークンと交換できるように Workload Identity 連携を構成できます。アンビエント認証情報が別の形式を使用している場合は、OIDC トークンまたは SAML アサーションと交換してから Workload Identity 連携で使用できます。
アプリケーションが Google Cloud にアクセスする必要があり、アンビエント認証情報にアクセスできる場合は、Workload Identity 連携を使用します。
Workload Identity 連携でサポートされていないアンビエント認証情報を使用する場合は、追加のトークン交換を使用する
アプリケーションがアンビエント認証情報にアクセスできても、認証情報のタイプが Workload Identity 連携でサポートされていないこともあります。その場合は、追加のトークン交換によって、アンビエント認証情報を Workload Identity 連携で使用できる認証情報に変換可能かどうかを確認します。
たとえば、アプリケーションが Active Directory 環境で実行されている場合は、Kerberos 認証情報にアクセスできる可能性があります。環境内に Active Directory フェデレーション サービス（AD FS）などの ID プロバイダがあり、Windows の統合認証がサポートされている場合は、これらの Kerberos 認証情報を使用して ID プロバイダの認証を行い、JWT 形式を使用する OAuth アクセス トークンを取得できます。このアクセス トークンと Workload Identity 連携を使用すると、アプリケーションで 2 回目のトークン交換を行い、有効期間の短い Google 認証情報を取得できます。
トークン交換を統合すると、複雑さが増し、追加の依存関係が生じる可能性もありますが、サービス アカウント キーの管理や保護を行う必要はなくなります。
ローテーションが必要な認証情報の数を減らす場合に Workload Identity 連携を使用する
多くの場合、OpenID または SAML ID プロバイダと統合するアプリケーションは、クライアント シークレット（または別の形式のシークレット）を使用して ID プロバイダを認証します。通常、このシークレットはアプリケーションの構成の一部として保存されます。このようなアプリケーションに Google Cloud へのアクセスを許可するには、次のいずれかを決定する必要があります。
- サービス アカウント キーを作成し、それを他のシークレットと一緒に保存する。
- 既存の ID プロバイダによって発行されたトークンを使用し、Workload Identity 連携を使用して Google 認証情報と交換する。
最初のオプションでは 2 つのシークレットが必要ですが、2 番目のオプションでは 1 つのシークレットのみが必要です。シークレットの数を減らすと、シークレットのローテーションが簡単になり、セキュリティも向上します。
なりすましの脅威からの保護
Workload Identity プールには ID やユーザー アカウントが含まれないため、Cloud Identity などのユーザー ディレクトリとは異なります。Workload Identity プールは、外部 ID プロバイダの ID をビューとして表し、IAM プリンシパルとして使用できるようにするものです。
Workload Identity プールとそのプロバイダの構成によっては、同じ外部 ID が複数の異なる IAM プリンシパルとして表されることや、複数の外部 ID が同じ IAM プリンシパルにマッピングされることがあります。このようなあいまいさを悪用して、不正な行為者がスプーフィング攻撃を行う可能性があります。
以下のセクションでは、不明確なマッピングを回避し、なりすましの脅威のリスクを軽減するベスト プラクティスについて説明します。
ベスト プラクティス:
GitHub または他のマルチテナント ID プロバイダと連携する場合に属性条件を使用します。専用のプロジェクトを使用して Workload Identity プールとプロバイダを管理します。
組織ポリシーの制約を使用して、他のプロジェクトでの Workload Identity プールのプロバイダの作成を無効にします。
Workload Identity プールごとに 1 つのプロバイダを使用して、サブジェクトの競合を回避します。
同じ ID プロバイダとの 2 回の連携を回避します。
ID プロバイダの OIDC メタデータ エンドポイントを保護します。
Workload Identity プール プロバイダの URL をオーディエンスとして使用します。
属性マッピングで不変の属性を使用します。
再利用できない属性を属性マッピングで使用します。
属性のマッピングの変更を許可しないでください。
安定性または信頼性を欠く属性に依存しないでください。
GitHub または他のマルチテナント ID プロバイダと連携する場合に属性条件を使用する
Workload Identity 連携は、ユーザー アカウントのディレクトリを維持しません。代わりに、クレームベースの ID を実装します。そのため、同じ ID プロバイダ（IdP）によって 2 つのトークンが発行され、それらのクレームが同じ google.subject 値にマッピングされている場合、2 つのトークンは同じユーザーを表しているとみなされます。トークンを発行した IdP を調べるために、Workload Identity 連携はトークンの発行元 URL を検証します。
GitHub や Terraform Cloud などの一部のプロバイダでは、すべてのテナントで単一の発行元 URL を使用しています。これらのプロバイダの場合、発行元の URL は、特定の GitHub または Terraform Cloud 組織ではなく、GitHub または Terraform Cloud 全体を表します。
これらの ID プロバイダを使用する場合は、Workload Identity 連携でトークンの発行元 URL をチェックし、トークンの発行元 URL が信頼できるソースから取得され、そのクレームが信頼できることを確認するだけでは不十分です。トークンが信頼できるテナント（GitHub または Terraform Cloud の場合は信頼できる組織）から発信されたことを確認するために、Workload Identity 連携属性条件を構成することをおすすめします。
詳細については、属性条件を構成するをご覧ください。
専用のプロジェクトを使用して Workload Identity プールとプロバイダを管理する
Workload Identity プールとプロバイダを複数のプロジェクトで管理する代わりに、1 つの専用プロジェクトで管理します。専用のプロジェクトを使用すると、次のことができます。
- Workload Identity 連携に信頼できる ID プロバイダのみを使用する。
- Workload Identity プールとプロバイダの構成へのアクセスを一元管理する。
- すべてのプロジェクトとアプリケーションの間で一貫した属性マッピングと条件を適用する。
組織のポリシーの制約を使用すると、専用のプロジェクトを使用して Workload Identity プールとプロバイダを管理できます。
組織ポリシーの制約を使用して、他のプロジェクトでの Workload Identity プール プロバイダの作成を無効にする
Workload Identity プールのプロバイダを作成する権限を持つユーザーは、Workload Identity プールとプロバイダを作成できます。これらは、専用プロジェクトで管理するものと重複している可能性があります。
新しい Workload Identity プールのプロバイダを作成しないようにするには、ルールを [すべて拒否] に設定して constraints/iam.workloadIdentityPoolProviders 組織ポリシー制約を使用します。
新しい Workload Identity プール プロバイダの作成をデフォルトで拒否するには、組織階層のルートでこれらの制約を適用します。特定の信頼できる AWS アカウントまたは OIDC プロバイダを許可するポリシー制約を適用して、Workload Identity プールとプロバイダの管理を許可するプロジェクトの例外を作成します。
Workload Identity プールごとに 1 つのプロバイダを使用して、サブジェクトの競合を回避する
Workload Identity 連携を使用すると、Workload Identity プールごとに複数のプロバイダを作成できます。ID を複数のプロバイダで管理していても、Google Cloud で実行されているワークロードでこの複雑さを隠したい場合は、複数のプロバイダを使用すると便利です。
複数のプロバイダを使用すると、サブジェクトが競合するリスクが生じます。競合が起きると、1 つのプロバイダの google.subject の属性マッピングが別のプロバイダの属性マッピングと同じ値を返します。これにより、複数の外部 ID が同じ IAM プリンシパルにマッピングされ、Cloud Audit Logs で外部 ID が区別できなくなります。
サブジェクトの競合を回避するには、Workload Identity プールごとに単一のプロバイダを使用します。複数のプロバイダと連携する必要がある場合は、複数の Workload Identity プールを作成し、各 ID プールで 1 つの Workload Identity プロバイダを使用します。
同じ ID プロバイダとの 2 回の連携を回避する
同じまたは類似した構成を使用する複数の Workload Identity プール プロバイダを作成することにより、同じ ID プロバイダと複数回連携できます。これらのプロバイダが同じ Workload Identity プールに属している場合、このような構成によってサブジェクトの競合が発生する可能性があります。プロバイダが異なる Workload Identity プールに属している場合、サブジェクトの競合は発生せず、同じ外部 ID が別の IAM プリンシパルとして表されます。
単一の外部 ID を複数の IAM プリンシパルにマッピングすると、特定の外部 ID がアクセスできるリソースを分析しやすくなります。このようなあいまいさにより、アクセス権を取り消す際のリスクも増大する可能性があります。管理者が 1 つのプリンシパルのアクセス権を取り消すこともありますが、別のプリンシパルの存在を意識せず、外部 ID で誤ってアクセスを保持してしまう場合があります。
あいまいさのリスクを最小限に抑えるため、同じ ID プロバイダとの連携は複数回しないでください。代わりに、単一の Workload Identity プールとプロバイダを作成し、属性のマッピングと条件を使用して、Google Cloud リソースへのアクセスを必要とするすべての外部 ID で使用できるようにします。
ID プロバイダの OIDC メタデータ エンドポイントを保護する
OpenID Connect プロバイダと連携する場合、Workload Identity 連携は、ID プロバイダから OIDC メタデータを定期的にダウンロードします。Workload Identity 連携では、IdP のメタデータと JSON Web Key Set（JWKS）を使用してトークンを検証します。
信頼性を確保するため、ID プロバイダとの通信は TLS を使用して保護されます。プロバイダが、TLS を終端するロードバランサまたはリバース プロキシの背後にデプロイされている場合、TLS 接続でロードバランサまたはリバース プロキシの信頼性は保証されますが、実際の ID プロバイダの信頼性は保証されません。
この設定が悪用され、中間者（MITM）攻撃が行われる可能性があります。不正な行為者がロードバランサを再構成し、別の鍵セットを提供する悪意のあるエンドポイントに JWKS リクエストを渡す可能性があります。JWKS を交換すると、不正な行為者の署名トークンが Workload Identity 連携によって有効と見なされ、他のユーザー ID のなりすましが可能になります。
JWKS スワップから保護するには、IdP を MITM 攻撃から保護するようにデプロイします。
Workload Identity プール プロバイダの URL をオーディエンスとして使用する
OpenID Connect プロバイダと連携する場合、Workload Identity 連携では、aud クレームでエンコードされたトークンのオーディエンスとプロバイダの許可されたオーディエンスの設定が一致するかどうか検証されます。同様に、SAML プロバイダと連携する場合、Workload Identity 連携では、想定されるオーディエンスに一致するオーディエンス制限が SAML アサーションで指定されているかどうか確認されます。
Workload Identity 連携のデフォルトでは、オーディエンスが Workload Identity プール プロバイダを一意に識別する URL https://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID と一致すると想定します。オーディエンスとしてこの URL を使用するようにトークンとアサーションを必須にすると、混乱した代理攻撃のリスクを軽減できます。このような攻撃では、不正な行為者が Workload Identity 連携ではなく、他の API のワークロード ID 連携を示すトークンまたは SAML アサーションを提供します。
ターゲットの Workload Identity プール プロバイダの URL をトークンまたはアサーションに含めることで、Workload Identity 連携用に発行されたトークンとアサーションのみをクライアントが使用できるようになります。
属性マッピングで不変の属性を使用する
サービス アカウントの権限借用を外部 ID に許可するには、サブジェクト、グループ、またはカスタム属性で外部 ID を参照する IAM バインディングを作成します。外部 ID のサブジェクト名、グループ、カスタム属性は、トークンの交換中に外部 ID プロバイダが Workload Identity 連携に渡す属性から取得されます。
一部の ID プロバイダでは、ユーザーが自分の属性の一部を変更できる場合があります。たとえば、ユーザーがメールアドレスやエイリアスを変更できる場合があります。IAM バインディングが変更可能な属性を参照している場合、ユーザーがユーザー プロファイルを変更すると、特定のリソースへのアクセス権を失うことがあります。さらに、不正な行為者が既存の IAM バインディングに合わせてユーザー属性を意図的に変更し、他のリソースへの不正アクセスが行われる可能性もあります。
このなりすましの脅威から保護するには、属性のマッピングをユーザーが変更できない属性に制限します。
再利用できない属性を属性マッピングで使用する
サービス アカウントの権限借用を外部 ID に許可してから、外部 ID プロバイダのユーザーを削除すると、サービス アカウントの IAM バインディングはそのまま残ります。
後で外部 ID プロバイダに新しいユーザーを追加し、以前に削除したユーザーと特定の属性（同じメールアドレスなど）を共有すると、Workload Identity 連携で既存ユーザーと新しいユーザーを区別できなくなります。その結果、古いユーザーだけを参照する IAM バインディングが新しいユーザーにも適用される場合があります。
このようなあいまいさを防ぐために、時間の経過とともに再利用できない属性（一意のユーザー ID など）のみに依存する属性マッピングを使用します。
会社のポリシーでメールアドレスなどの属性を再利用できる場合は、これらの属性を属性のマッピングで使用することは避けてください。代わりに、長期間一意であることが保証された属性を使用してください。
属性のマッピングの変更を許可しない
Workload Identity 連携では、属性マッピングを使用して、STS トークンに埋め込む必要がある外部 ID プロバイダによって指定された属性と、属性名の変換方法を選択します。属性マッピングの構成は、外部 ID プロバイダと Google Cloud 間の信頼関係を設定する重要なステップです。
属性のマッピングは、Workload Identity 連携を使用する際のセキュリティにとっても重要です。サービス アカウントの権限を借用するための連携プリンシパルまたはプリンシパル セットの権限を付与し、後から属性のマッピングを変更することで、サービス アカウントにアクセスできるユーザーを変更できます。
属性のマッピングを変更するには、iam.googleapis.com/workloadIdentityPoolProviders.update 権限が必要です。この権限を含むロールは次のとおりです。
- オーナー（
roles/owner） - IAM Workload Identity プール管理者（
roles/iam.workloadIdentityPoolAdmin）
不正な行為者が、属性のマッピングを変更する権限を付与されている場合は、ID を偽装してサービス アカウントへのアクセス権を取得する方法によりマッピング ルールを変更できる可能性があります。このような悪意のある変更を回避するため、属性のマッピングを変更する権限は、少数の管理者ユーザーにのみ付与してください。
Workload Identity プールを管理するための専用の Google Cloud プロジェクトを作成して、リソース階層で上位レベルのユーザーにこれらのロールが誤って割り当てられるリスクを軽減してください。
安定性または信頼性を欠く属性に依存しない
ID プロバイダは、属性を使用して認証済みユーザーに関する情報を伝えます。通常、これらの属性は信頼できるものであることが ID プロバイダによって保証されていますが、そうでない場合もあります。たとえば、外部 ID プロバイダは、OIDC トークンにユーザー名とユーザー ID の両方を埋め込む場合があります。どちらの属性もユーザーを一意に識別するものなので、交換可能なように思えるかもしれません。ただし、外部 ID プロバイダがユーザー ID の安定性と信頼性を保証する一方で、ユーザー名の変更を許可する場合もあります。
属性マッピングで依存している属性に安定性と信頼性がない場合、不正な行為者が外部 ID プロバイダで保管しているユーザー プロファイルに変更を加えて、ユーザー ID になりすます可能性があります。たとえば、不正な行為者が自分のユーザー名を、外部 ID プロバイダで最近削除されたものの、Google Cloud でサービス アカウントに引き続きアクセスできるユーザーのユーザー名に変更する可能性も考えられます。
このようななりすまし攻撃を防ぐには、属性マッピングで依存する属性を、外部 ID プロバイダが安定性と信頼性を保証しているものだけに限定するようにしてください。
否認防止の脅威からの保護
Google Cloud 上のリソースに影響する不審なアクティビティが判明した場合、Cloud Audit Logs は常に、アクティビティの発生時刻と関与したユーザーを特定するための重要な情報源になります。
アプリケーションで Workload Identity 連携を使用する場合、サービス アカウントの権限を借用します。Cloud Audit Logs では、アプリケーションによって実行されるすべてのアクティビティが権限借用されたサービス アカウントに関連付けられます。アクティビティにつながったイベントの完全なチェーンを再構築するには、Cloud Audit Logs のログを ID プロバイダのログと関連付けて、関係している外部 ID や、アクティビティが実行された理由を把握できるようにする必要があります。
このセクションでは、否認防止に関する監査証跡を保持するうえで有用なベスト プラクティスについて説明します。
IAM API のデータアクセス ログを有効にする
Compute Engine などのサービスでは、サービス アカウントの権限借用のシナリオを識別して把握できるように、Cloud Audit Logs に serviceAccountDelegationInfo セクションを追加しています。アプリケーションで Workload Identity 連携を使用する場合、このセクションには、サービス アカウントの権限借用に使用されたプリンシパルのサブジェクトが含まれます。
すべてのサービスで、Cloud Audit Logs になりすましの詳細を記録するわけではありません。否認防止に関する監査証跡を保持するには、Security Token Service API と Identity and Access Management API でデータアクセス ログを有効にして、すべてのなりすましイベントを記録する必要があります。Workload Identity 連携に使用される Workload Identity プールまたはサービス アカウントを含むすべての Cloud プロジェクトで、これらのログを有効にします。
これらのログを有効にすることにより、アプリケーションで Workload Identity 連携を使用して外部認証情報を交換し、サービス アカウントの権限を借用するすべての場合で、Cloud Audit Logs にエントリを追加できるようになります。
一意のサブジェクトのマッピングを使用する
Cloud Audit Logs のエントリの serviceAccountDelegationInfo セクションで使用されるプリンシパル サブジェクトは、google.subject の Workload Identity プール プロバイダの属性マッピングによって決まります。
不審なアクティビティを発見し、関与した外部 ID を特定する必要がある場合は、対応する google.subject の値によって外部 ID を検索できるようにする必要があります。
同様に、外部 ID が侵害され、その ID が Google Cloud リソースへのアクセスに使用されたかどうかを特定するには、その外部 ID に対応する Cloud Audit Logs のエントリを見つける必要があります。
Workload Identity プール プロバイダの属性マッピングを定義するときは、次のように google.subject の一意のマッピングを選択します。
- 外部 ID が 1 つの
google.subject値にのみマッピングされている。 google.subject値が 1 つの外部 ID にのみマッピングされている。- 外部 ID は
google.subject値で検索できます。
これらの一意性の条件を満たす属性マッピングを使用すると、google.subject 値で外部 ID を検索できます。また、その逆も可能です。
権限昇格の脅威からの保護
Workload Identity 連携を使用するときに最小権限の原則を適用するには、次の作業を行う必要があります。
- サービス アカウントの権限を借用できる外部 ID の数を制限する
- サービス アカウントでアクセスできるリソースを制限する
制限が緩すぎると、不正な行為者が外部 ID を使用して自分の権限を昇格し、本来アクセスできないリソースにアクセスしてしまう可能性があります。
以下のセクションでは、権限昇格の脅威からの保護に役立つベスト プラクティスについて説明します。
ベスト プラクティス:
アクセスする必要のあるリソースと同じプロジェクトにあるサービス アカウントを使用します。アプリケーションごとに専用のサービス アカウントを使用します。
プールのすべてのメンバーへのアクセス権の付与を回避します。
アクセスする必要のあるリソースと同じプロジェクトにあるサービス アカウントを使用する
クライアントがクライアント ライブラリまたは REST API を使用して Workload Identity 連携を使用する場合は、次の 3 ステップ プロセスを行います。
- 信頼できる ID プロバイダから認証情報を取得します。
- Security Token Service から取得したトークンと認証情報を交換します。
- Security Token Service のトークンを使用してサービス アカウントの権限を借用し、有効期間の短い Google アクセス トークンを取得します。
最後のステップでは、アクセスする必要があるリソースと同じプロジェクトにあるサービス アカウントを使用します。同じプロジェクトで管理されているサービス アカウントを使用すると、アクセスがより厳格に適用されるため、サービス アカウントが不要になったときに簡単に判断できます。
アプリケーションごとに専用のサービス アカウントを使用する
Workload Identity 連携を使用して同じプロジェクトのリソースにアクセスするアプリケーションが複数ある場合は、アプリケーションごとに専用のサービス アカウントを作成します。アプリケーション固有のサービス アカウントを使用すると、個々のアプリケーションが必要とするリソースへのアクセス権のみを付与することで、過剰な権限付与を回避できます。
プールのすべてのメンバーへのアクセス権の付与を回避する
外部 ID でサービス アカウントの権限を借用するには、事前にサービス アカウントに roles/iam.workloadIdentityUser ロールを付与する必要があります。このロールを付与する場合は、Workload Identity プールのすべてのメンバーに付与しないようにします。代わりに、特定の外部 ID や、特定の条件に一致する ID に付与します。
最初の段階では、Google Cloud リソースにアクセスする必要がある外部ユーザーの数は少ないことがあります。そのため、Workload Identity プールの属性条件と ID プロバイダの構成によって、Workload Identity 連携を使用する少数の外部 ID が許可されている場合があります。
後で新しいワークロードを Google Cloud にオンボーディングするときに、追加の外部 ID が許可されるように、ID プロバイダの構成または Workload Identity プールの属性条件の変更が必要になる場合があります。
特定の外部 ID のみに roles/iam.workloadIdentityUser ロールを付与することで、外部 ID に対する権限の付与を不必要に行うことなく、Workload Identity プールを安全に拡張できます。