Google Cloud CLI の OAuth トークンの侵害による影響を緩和するためのベストプラクティス

Last reviewed 2024-02-15 UTC

このドキュメントでは、gcloud CLI で使用される OAuth トークンを攻撃者が侵害した場合の影響を軽減する方法について説明します。

正規のユーザーアカウントまたはサービスアカウントがすでに gcloud CLI で認証されているエンドポイントへのアクセスを攻撃者が乗っ取ると、攻撃者がこれらの OAuth トークンを侵害する可能性があります。その後、攻撃者が制御している別のエンドポイントにこれらのトークンをコピーして、正当な ID になりすますリクエストを行う可能性があります。侵害されたエンドポイントへの攻撃者のアクセス権を削除した後でも、攻撃者はコピーしたトークンを使用して、認証済みの API リクエストを継続して実行できます。このリスクを軽減するために、有効期間が短くコンテキストアウェアな認証情報を使用して、システムへのアクセスを制御できます。

このドキュメントは、不正アクセスからクラウドリソースを保護する責任を負うセキュリティチームまたはクラウドアーキテクトを対象としています。このドキュメントでは、エンドポイントが侵害された後、gcloud CLI OAuth トークンの侵害による影響を事前に軽減し、環境を修復するために利用できる管理機能について説明します。

概要

この脅威の仕組みを理解するには、gcloud CLI で OAuth 2.0 認証情報が保存される仕組みと、攻撃者が認証情報を侵害した場合に、その認証情報がどのように悪用されるかを理解する必要があります。

gcloud CLI によって保存される認証情報の種類

gcloud CLI では、OAuth 2.0 アクセストークンを使用して Google Cloud APIs へのリクエストを認証します。OAuth フローは、使用する認証情報の種類によって異なりますが、通常はアクセストークンやその他の認証情報にはローカルでアクセスできます。いずれの場合も、アクセストークンは 60 分後に期限切れになりますが、他の認証情報タイプは永続的であることがあります。

ユーザーアカウントで gcloud CLI を承認すると、gcloud CLI は 3-legged OAuth 同意フローを開始し、ユーザーに代わって Google Cloud APIs にアクセスします。ユーザーが同意フローを完了すると、gcloud CLI がアクセストークンと更新トークンを受け取ります。更新トークンにより、新しいアクセストークンをリクエストできるようになります。デフォルト設定では、有効期間が長い更新トークンは有効期限の条件が満たされるまで保持されます。

サービスアカウントで gcloud CLI を承認すると、gcloud CLI が Two-legged OAuth フローを開始し、サービスアカウント ID として Google Cloud API にアクセスします。秘密鍵ファイルからサービスアカウントを有効にすると、この鍵を使用してアクセストークンが定期的にリクエストされます。有効期間の長い秘密鍵は gcloud CLI 構成に保存され、サービスアカウントキーを削除するまで有効です。

Compute Engine や Cloud Shell などの Google Cloud 環境内で gcloud CLI を実行すると、アプリケーションは自動的に認証情報を検索し、サービスアカウントとして認証できます。たとえば、Compute Engine では、gcloud CLI などのアプリケーションから、アクセストークンのメタデータサーバーに対してクエリを実行できます。Google は、アクセストークンの作成に使用される署名秘密鍵を管理してローテーションします。有効期間が長い認証情報はアプリケーションに対して公開されません。

Workload Identity 連携で認証すると、アプリケーションは外部 ID プロバイダの認証情報に基づいて認証され、連携した有効期間が短いアクセストークンを受け取ります。外部 ID プロバイダによって使用される有効期間の長い認証情報を保存および管理する方法については、Workload Identity 連携の使用に関するベストプラクティスをご覧ください。

侵害された OAuth トークンを攻撃者が使用する仕組み

OAuth トークンなどの認証情報によって攻撃者がアクセス権を継続または昇格できるため、攻撃者がエンドポイントを侵害できた場合、これらの認証情報は重要なターゲットとなります。

デベロッパーは、コードの記述とデバッグの際に自身の認証情報を表示することが必要な場合があります。たとえば、サポートされていないクライアントライブラリを操作するときに、Google Cloud サービスへの REST リクエストの使用に対する認証を行う必要があります。デベロッパーは次のようなさまざまな方法で認証情報を表示できます。

ローカルファイルシステムで gcloud CLI 構成ファイルを確認する
Compute Engine メタデータサーバーに対してクエリを実行する
gcloud auth print-access-token や gcloud auth describe IDENTITY などのコマンドを使用する

ただし、攻撃者はエンドポイントを侵害した後に上記の手法を使用する可能性があります。

攻撃者がデベロッパーワークステーションなどのエンドポイントを侵害した場合の一次的な脅威は、認証された ID の正規の認証情報を使用して、攻撃者が gcloud CLI コマンドや他のコードを実行できることです。さらに、攻撃者は OAuth トークンを自分が制御している別のエンドポイントにコピーして、アクセスを継続する場合があります。このような認証情報の盗難が発生した場合、侵害されたエンドポイントへのアクセスを削除しても、攻撃者が有効期間の長い OAuth トークンを使用して永続的なアクセス権を保持できるという二次的な脅威があります。

OAuth トークンを侵害できた攻撃者は、次のアクションを行う可能性があります。

攻撃者は、侵害されたユーザーまたはサービスアカウントになりすます可能性があります。侵害されたトークンを使用する API トラフィックは、侵害されたユーザーまたはサービスアカウントから送信されたものとしてログに記録されるため、ログで通常のアクティビティと悪意のあるアクティビティを区別することが困難になります。
攻撃者は、ユーザーに関連付けられた永続的な更新トークン、またはサービスアカウントに関連付けられた秘密鍵を使用して、アクセストークンを無期限に更新できる可能性があります。
トークンはログインフロー後に付与されるため、攻撃者はユーザーのパスワードまたは 2 段階認証プロセスによる認証をバイパスする可能性があります。

リスクを軽減するためのベストプラクティス

以下のセクションで説明するコントロールを実装して、侵害された gcloud CLI トークンのリスクを軽減します。エンタープライズ基盤のブループリントまたは Google Cloud のランディングゾーンの設計で説明されているセキュリティのベストプラクティスを実施している場合、すでにこれらのコントロールが実装されていると思われます。

Google Cloud サービスのセッション継続時間を設定する

攻撃者が侵害されたトークンを悪用できる期間を短縮するには、Google Cloud サービスのセッション継続時間を設定します。デフォルトでは、システムが認証後に付与する更新トークンは有効期間が長い認証情報であり、gcloud CLI セッションでは再認証は必要ありません。セッション継続時間が 1～24 時間の再認証ポリシーを構成するには、この設定を変更します。定義されたセッション継続時間が経過すると、再認証ポリシーによって更新トークンが無効になり、ユーザーはパスワードまたはセキュリティキーを使用して gcloud CLI を定期的に再認証する必要があります。

Google Cloud サービスのセッション継続時間は、Google Workspace サービス全体でログインするためのウェブセッションを制御する Google サービスのセッション継続時間とは異なりますが、Google Cloud の再認証は制御しません。Google Workspace サービスを使用する場合は、両方のセッション継続時間を設定します。

VPC Service Controls を構成する

環境全体で VPC Service Controls を構成して、定義した境界内で発生した Google Cloud API トラフィックのみがサポートされるリソースにアクセスできるようにします。サービス境界により、侵害された認証情報の有用性が制限されます。これは、環境の外部にある攻撃者が制御するエンドポイントから発信された制限付きサービスへのリクエストが、境界によってブロックされるためです。

BeyondCorp Enterprise を構成する

Google Cloud コンソールと Google Cloud APIs を保護するように、BeyondCorp Enterprise ポリシーを構成します。IP ベースのアクセスや相互 TLS の証明書ベースのアクセスなど、すべての API リクエストで評価される属性を選択的に許可するように、BeyondCorp Enterprise のアクセスレベルとバインディングを構成します。侵害された認証情報を使用するが、BeyondCorp Enterprise ポリシーで定義されている条件を満たしていないリクエストは拒否されます。

BeyondCorp Enterprise はユーザー中心のコントロールであり、定義された条件を満たさないユーザー API トラフィックを拒否します。VPC Service Controls はリソース中心のコントロールであり、リソースが通信できる境界を定義します。VPC Service Controls はすべてのユーザー ID とサービスアカウント ID に適用されますが、BeyondCorp Enterprise は組織内のユーザー ID のみに適用されます。BeyondCorp Enterprise と VPC Service Controls を併用すると、攻撃者が制御する環境外のマシンにある漏洩した認証情報の有効性が低下します。

リモートサーバーアクセスに 2 段階認証プロセスを適用する

デベロッパーが SSH を使用して Compute Engine リソースにアクセスできるようにする場合は、2 段階認証プロセスを使用した OS Login を構成します。これにより、ユーザーがパスワードまたはセキュリティキーで再認証を行う必要がある追加のチェックポイントが適用されます。侵害された OAuth トークンを持つが、パスワードまたはセキュリティキーがない攻撃者は、この機能によってブロックされます。

Compute Engine 上の Windows インスタンスへのリモートデスクトッププロトコル（RDP）アクセスでは OS Login サービスがサポートされていないため、RDP セッションで 2 段階認証プロセスを細かく適用できません。IAP Desktop や Google Chrome ベースの RDP プラグインを使用する場合は、きめが粗い制御（Google サービスのセッション正続時間や、ユーザーのウェブセッションの 2 段階認証プロセス設定など）を設定し、2 段階認証プロセスの [信頼できるデバイスの登録を許可する] の設定を無効にします。

サービスアカウントキーの使用を制限する

認証にサービスアカウントキーを使用する場合、キーの値は、ダウンロードしたキーファイルとは別に、gcloud CLI 構成ファイルに保存されます。環境にアクセス可能な攻撃者は、gcloud CLI 構成からキーをコピーするか、ローカルファイルシステムまたは内部コードリポジトリからキーファイルをコピーする可能性があります。したがって、アクセストークンの侵害を軽減する計画に加えて、ダウンロードしたサービスアカウントキーファイルの管理方法も検討してください。

より安全な代替の認証方法を確認して、サービスアカウントキーに依存するユースケースを削減または排除し、組織のポリシー制約 iam.disableServiceAccountKeyCreation を適用して、サービスアカウントキーの作成を無効にします。

最小権限の原則を検討する

IAM ポリシーを設計する際には最小権限を検討してください。最小限のスコープでタスクを実行するために必要なロールをユーザーに付与します。必要のないロールは付与しないでください。ロールの推奨事項を確認して適用し、環境で未使用のロールや過剰なロールを含む IAM ポリシーを回避します。

エンドポイントを保護する

攻撃者がエンドポイント（デベロッパーワークステーションや Compute Engine インスタンスなど）への物理的なアクセスまたはリモートアクセスを行う方法を検討します。侵害された OAuth トークンの脅威に対処する計画は重要ですが、そもそも攻撃者が信頼できるエンドポイントを侵害できる仕組みの脅威に対応する方法についても検討する必要があります。攻撃者が信頼できるエンドポイントにアクセスできれば、gcloud CLI コマンドや他のコードをエンドポイント自体で直接実行できます。

デベロッパーワークステーションに対する包括的な保護についてはこのドキュメントでは扱いませんが、セキュリティツールとオペレーションがエンドポイントの保護と侵害の監視にどのように役立つかを評価してください。次のことを検討してください。

デベロッパーワークステーションの物理的なセキュリティは、どのように保護されていますか？
ネットワーク侵害をどのように特定して対応していますか？
ユーザーは SSH または RDP セッションへのリモートアクセスをどのように取得しますか？
SSH 認証鍵やサービスアカウントキーなどの他の永続的な認証情報はどのように侵害される可能性がありますか？
有効期間が短い認証情報で置き換えることが可能な永続的な認証情報を使用しているワークフローはありますか？
他のユーザーのキャッシュに保存された gcloud CLI 認証情報を他人が読み取れる共有デバイスはありますか？
ユーザーは、信頼できないデバイスから gcloud CLI で認証できますか？
承認されたトラフィックは、VPC Service Controls の境界内のリソースにどのように接続しますか？

セキュリティオペレーションが上記の各質問に対処していることを確認します。

対応チームを調整する

インシデント対応を担当するセキュリティチームが、Google Cloud コンソールと管理コンソール全体に対して適切なアクセス権を持っていることを事前に確認します。Google Cloud コンソールと管理コンソールを別々のチームが管理している場合、インシデント発生時に対応が遅れる可能性があります。

侵害されたユーザーアカウントからアクセス権を削除するには、インシデント対応チームにユーザー管理管理者などの管理コンソールのロールが必要です。Google Cloud リソースで不審なアクティビティが発生したかどうかを判断するために、このチームには、すべてのプロジェクトのセキュリティ審査担当者や一元的なログシンクのログ閲覧者などの IAM ロールも必要になる場合があります。セキュリティチームに必要なロールは、環境の設計と運用によって異なります。

セキュリティインシデント発生後の修復のベストプラクティス

エンドポイントが侵害された場合、インシデント管理計画の一環として、侵害されたエンドポイントの一次的な脅威に対応する方法と、トークンの侵害の二次的な脅威によって発生している可能性のある進行中の被害を軽減する方法を確認します。攻撃者がデベロッパーのワークステーションに常にアクセスできる場合、正当なユーザーの再認証後にトークンを再度コピーする可能性があります。gcloud CLI トークンが侵害された可能性がある場合は、Cloud カスタマーケアでチケットを作成し、次のセクションの推奨事項を実施します。これらのアクションは、Google Cloud 組織におけるこのようなイベントの影響を制限するのに役立ちます。

このセクションの推奨事項は、Google Cloud 認証情報の不正使用への対応に関する一般的なガイダンスと重複していますが、特に、侵害されたエンドポイントからコピーされた gcloud CLI トークンの脅威に焦点を当てています。

Google Cloud セッション管理を使用して、すべてのユーザーアカウントのアクティブなトークンを期限切れにする

Google Cloud セッション管理をまだ適用していない場合は、直ちに短い再認証頻度で有効にしてください。この管理により、すべての更新トークンは定義された期間の終わりで期限切れになるため、攻撃者が侵害されたトークンを使用できる期間が制限されます。

侵害されたユーザーアカウントのトークンを手動で無効にする

侵害された可能性のあるユーザー ID については、認証情報の不正使用への対応のガイダンスをご覧ください。特に、セキュリティチームがユーザー ID の OAuth トークンの侵害に対処するには、gcloud CLI 認証情報を削除することが最も効果的な方法です。gcloud CLI の更新トークンとアクセストークンを直ちに無効にして、ユーザーにパスワードまたはセキュリティキーによる再認証を適用するには、接続されているアプリケーションのユーザーのリストから gcloud CLI を削除します。

個々のユーザーは、個人アカウントの gcloud CLI 認証情報を削除することもできます。

ユーザーの停止、ユーザーのパスワードのリセット、ログイン Cookie のリセットなどの他の方法は、侵害された OAuth トークンの脅威に対する明確な対処ではありません。通常、これらの方法はインシデント対応では役立ちますが、攻撃者がすでに制御しているアクセストークンは無効にはなりません。たとえば、調査中にユーザーを停止することを選択したが、gcloud CLI トークンを取り消さなかった場合、アクセストークンの有効期限が切れる前に停止中のユーザーが復元されると、アクセストークンが引き続き有効となることがあります。

多数のユーザーアカウントのトークンをプログラムで無効にする

侵害の疑いがあるが、影響を受けたユーザーを特定できない場合は、再認証ポリシーよりも迅速に組織のすべてのユーザーのアクティブなセッションを取り消すことを検討してください。

この方法は、正当なユーザーに混乱をもたらし、ユーザー認証情報に依存する長時間実行プロセスを終了する可能性があります。この方法を採用する場合は、事前に実行するセキュリティオペレーションセンター（SOC）用のスクリプトソリューションを準備し、数人のユーザーでテストします。

次のサンプルコードでは、Workspace Admin SDK を使用して、gcloud CLI にアクセスできる Google Workspace アカウントまたは Cloud Identity アカウントすべてのユーザー ID を識別します。ユーザーが gcloud CLI を承認していた場合、スクリプトは更新トークンとアクセストークンを取り消し、パスワードまたはセキュリティキーを使用した再認証を適用します。Admin SDK API を有効にしてこのコードを実行する手順については、Google Apps Script クイックスタートをご覧ください。

/**
 * Remove access to the Google Cloud CLI for all users in an organization
 * @see https://developers.google.com/admin-sdk/directory/reference/rest/v1/tokens
 * @see https://developers.google.com/admin-sdk/directory/reference/rest/v1/users
 * @see https://developers.google.com/apps-script/guides/services/advanced#enabling_advanced_services
 */

function listUsersAndInvalidate() {
  const users = AdminDirectory.Users.list({
    customer: 'my_customer' // alias to represent your account's customerId
    }).users;
  if (!users || users.length === 0) {
    Logger.log('No users found.');
    return;
  }
  for (const user of users){
    let tokens = AdminDirectory.Tokens.list(user.primaryEmail).items
    if (!tokens || tokens.length === 0) {
      continue;
    }
    for (const token of tokens) {
      if (token.clientId === "32555940559.apps.googleusercontent.com") {
        AdminDirectory.Tokens.remove(user.primaryEmail, token.clientId)
        Logger.log('Invalidated the tokens granted to gcloud for user %s', user.primaryEmail)
      }
    }
  }
}

サービスアカウントの認証情報の無効化とローテーションを行う

ユーザー ID に付与されているアクセストークンとは異なり、サービスアカウントに付与されているアクセストークンを管理コンソールや gcloud auth revoke などのコマンドで無効化することはできません。また、Google Cloud セッション管理で指定したセッション継続時間は、Cloud Identity ディレクトリまたは Google Workspace ディレクトリのユーザーアカウントに適用されますが、サービスアカウントには適用されません。したがって、サービスアカウントの侵害に対するインシデント対応で、永続鍵ファイルと有効期間の短いアクセストークンの両方に対処する必要があります。

サービスアカウントの認証情報が侵害された場合は、サービスアカウントを無効にして、サービスアカウントキーを削除し（存在する場合）、その後 60 分経過後にサービスアカウントを有効にします。サービスアカウントキーを削除すると、有効期間が長い認証情報が無効になるため、攻撃者は新しいアクセストークンをリクエストできなくなりますが、すでに付与されているアクセストークンは無効になりません。60 分間の有効期間内でのアクセストークンの悪用を防ぐには、サービスアカウントを 60 分間無効にする必要があります。

または、サービスアカウントを削除して置き換えて、有効期間が短い認証情報と有効期間が長い認証情報をすべてすぐに取り消すこともできますが、アプリケーションでサービスアカウントを置き換える際に、大がかりな作業が必要になる場合があります。

次のステップ

Google Cloud 認証情報の不正使用に対処する
gcloud CLI を承認する
サービスアカウントとして認証する
Google Cloud に関するリファレンスアーキテクチャ、図、ベストプラクティスを確認する。Cloud アーキテクチャセンターをご覧ください。

Google Cloud CLI の OAuth トークンの侵害による影響を緩和するためのベスト プラクティス

概要

gcloud CLI によって保存される認証情報の種類

侵害された OAuth トークンを攻撃者が使用する仕組み

リスクを軽減するためのベスト プラクティス

Google Cloud サービスのセッション継続時間を設定する

VPC Service Controls を構成する

BeyondCorp Enterprise を構成する

リモート サーバー アクセスに 2 段階認証プロセスを適用する

サービス アカウント キーの使用を制限する