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 リクエストの使用に対する認証を行う必要があります。デベロッパーは次のようなさまざまな方法で認証情報を表示できます。

ただし、攻撃者はエンドポイントを不正使用した後に、これらと同じ手法を使用する可能性があります。

攻撃者がデベロッパー ワークステーションなどのエンドポイントを不正使用する場合、主な脅威は、認証された 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 トラフィックのみがサポートされるリソースにアクセスできるようにします。サービス境界により、侵害された認証情報の有用性が制限されます。これは、環境の外部にある攻撃者が制御するエンドポイントから発信された制限付きサービスへのリクエストが、境界によってブロックされるためです。

Chrome Enterprise Premium を構成する

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

Chrome Enterprise Premium はユーザー中心のコントロールであり、定義された条件を満たさないユーザー API トラフィックを拒否します。VPC Service Controls はリソース中心のコントロールであり、リソースが通信できる境界を定義します。VPC Service Controls はすべてのユーザー ID とサービス アカウント ID に適用されますが、Chrome Enterprise Premium は組織内のユーザー ID のみに適用されます。Chrome Enterprise Premium と 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 コンソールと管理コンソールを管理している場合、インシデント中にレスポンスが遅延する可能性があります。

不正使用されたユーザー アカウントからアクセス権を削除するには、インシデント対応チームにはユーザー管理管理者などの管理コンソールの役割が必要です。gcloud CLI リソースで不審なアクティビティが発生したかどうかを評価するために、このチームには、すべてのプロジェクトのセキュリティ審査担当者や一元化されたログシンのログビューアなどの 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 分間無効にする必要があります。

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

次のステップ