デベロッパー ワークステーションを保護し、Google Cloud CLI OAuth ベアラー トークン、アプリケーションのデフォルト認証情報、ローカルキーなどの Google Cloud 認証情報の盗難や不正使用を防ぐためのベスト プラクティスについて説明します。
このドキュメントは、不正アクセスからクラウド リソースを保護する責任を負うセキュリティ チームまたはクラウド アーキテクトを対象としています。エンドポイントが侵害された後、デベロッパー認証情報の侵害による影響を事前に軽減し、環境を修復するために利用できる管理機能について説明します。
認証情報の漏洩リスク
正規のユーザー アカウントまたはサービス アカウントがすでにGoogle Cloud または gcloud CLI で認証されているエンドポイントへのアクセスを攻撃者が乗っ取ると、攻撃者が認証情報を侵害する可能性があります。その後、攻撃者が制御している別のエンドポイントにこれらのトークンをコピーして、正当な ID になりすますリクエストを行う可能性があります。侵害されたエンドポイントへの攻撃者のアクセス権を削除した後でも、攻撃者はコピーしたトークンを使用して、認証済みの API リクエストを継続して実行できます。このリスクを軽減するために、有効期間が短くコンテキスト アウェアな認証情報を使用して、システムへのアクセスを制御できます。
デベロッパー認証情報の概要
通常、次の Google Cloud 認証情報はデベロッパーのワークステーションにあります。
- gcloud CLI OAuth トークン
- アプリケーションのデフォルト認証情報
- サービス アカウント キー
- SSH 認証鍵
- ブラウザの Cookie
- Workforce Identity 連携アクセス トークン
以降のセクションでは、各認証情報のタイプがどのように保存され、使用されるかについて説明します。
gcloud CLI OAuth トークン
gcloud CLI は、OAuth 2.0 アクセス トークンを使用してGoogle Cloud APIs へのリクエストを認証します。OAuth フローは、使用する認証情報の種類によって異なりますが、通常はアクセス トークンやその他の認証情報にはローカルでアクセスできます。いずれの場合も、アクセス トークンはデフォルトで 60 分後に期限切れになりますが、有効期間の延長の制約の下では最大 12 時間持続できます。ただし、他の認証情報タイプは永続的である可能性があります。
ユーザー アカウントで 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 はこの鍵を使用してアクセス トークンを定期的にリクエストします。有効期間の長い秘密鍵は gcloud CLI 構成に保存され、サービス アカウント キーを無効にするか削除するまで有効です。
Compute Engine や Cloud Shell などの Google Cloud 環境内で gcloud CLI を実行すると、アプリケーションは自動的に認証情報を検索し、サービス アカウントとして認証できます。たとえば、Compute Engine では、gcloud CLI などのアプリケーションから、アクセス トークンのメタデータ サーバーに対してクエリを実行できます。Google は、アクセス トークンの作成に使用される署名秘密鍵を管理してローテーションします。有効期間が長い認証情報はアプリケーションに対して公開されません。
アプリケーションのデフォルト認証情報
アプリケーションのデフォルト認証情報は、アプリケーションがGoogle Cloud API で認証するために使用されます。開発者は、gcloud auth application-default login を実行してアプリケーションのデフォルト認証情報を生成できます。このコマンドは、クライアント ライブラリの OAuth 2.0 更新トークンとクライアント認証情報を含む平文の JSON ファイル($HOME/.config/gcloud/application_default_credentials.json または %APPDATA%\gcloud\application_default_credentials.json)を書き込みます。
任意のクライアント ライブラリまたはカスタム スクリプトで、これらの認証情報を使用してGoogle Cloud API を呼び出すことができます。
アプリケーションのデフォルト認証情報はプレーンテキストで保存されるため、ユーザーのコンテキストで実行されている信頼できないプロセスやスクリプトは、ファイルに直接アクセスしたり、gcloud auth application-default print-access-token などのコマンドを使用してアクティブなアクセス トークンを取得したりできます。
一般的なマルウェアは、application_default_credentials.json を収集するために ~/.config/gcloud/ ディレクトリを標的にすることがよくあります。
詳細については、アプリケーションのデフォルト認証情報をご覧ください。
サービス アカウント キー
サービス アカウント キーは、Google Cloud コンソールからダウンロードされる非公開の JSON キーファイルです。これらのキーは、アプリケーションがGoogle Cloud APIs で認証を行うために使用されます。サービス アカウント キーは次の場所に保存できます。
gcloud auth activate-service-accountの実行後の gcloud CLI 構成ディレクトリ- ローカル ファイル システム
- 内部コード リポジトリ
デベロッパー エンドポイントのサービス アカウント キーは 2 段階認証プロセスの対象ではなく、セッションの制限がなく、自動的に有効期限が切れることもありません。
サービス アカウント キーを盗んだ攻撃者は、サービス アカウント アクセス トークンを作成して、永続的なアクセスを維持できます。
詳細については、サービス アカウント キーを管理するためのベスト プラクティスをご覧ください。
SSH 認証鍵
SSH 認証鍵は、Compute Engine インスタンスでの認証に使用されます。開発者は gcloud compute ssh を使用して SSH 認証鍵を生成できます。このコマンドは、~/.ssh/google_compute_engine にローカル秘密鍵を生成します。SSH 認証鍵は有効期間が長いです。
攻撃者は、盗んだ SSH 鍵を使用して VM にアクセスし、メタデータ サーバーにクエリを実行して、割り当てられたサービス アカウント トークンを抽出できます。この攻撃は外部境界ファイアウォールをバイパスします。
SSH 認証鍵の代わりに、2 段階認証プロセスを使用した OS Login の使用を検討してください。詳しくは、リモート サーバー アクセスに 2 段階認証プロセスを適用するをご覧ください。
ブラウザ Cookie
ブラウザの Cookie は、 Google Cloud コンソールと Cloud Shell へのウェブ HTTP リクエストを認証します。ブラウザ Cookie は、ユーザーが Google Cloud コンソールにログインすると自動的に作成されます。
Cookie は、ローカル ワークステーションのブラウザのプロファイル ディレクトリに保存されます。たとえば、Google Chrome は Linux では ~/.config/google-chrome/、Windows では %LOCALAPPDATA%\Google\Chrome\User Data に Cookie を保存します。
ブラウザ Cookie は、ユーザーがログアウトしたとき、セッションのタイムアウトが発生したとき、または管理者が管理コンソールでユーザー セッションをリセットしたときにのみ無効になる、有効期間の長い認証情報です。
これらの Cookie を盗んだ攻撃者は、別のブラウザに Cookie をインポートして、アクティブなコンソール セッションをハイジャックし、認証をバイパスできます。 Google Cloud
セッション Cookie の盗難のリスクを軽減するには、Google Cloud サービスのセッション継続時間を設定します。
Workforce Identity 連携アクセス トークン
デベロッパーは Workforce Identity 連携を使用して外部 ID プロバイダで認証し、 Google Cloud リソースにアクセスできます。
フェデレーション ID でログインするには、デベロッパーはログイン構成ファイル(gcloud iam workforce-pools create-login-config コマンドで作成)を使用して gcloud CLI にログインします。外部 ID プロバイダで認証を行うと、Security Token Service は認証コードを有効期間の短い連携アクセス トークンと OAuth 更新トークンに交換します。
gcloud CLI は、認証情報のメタデータと更新トークンをローカル認証情報データベースに保存し、有効なアクセス トークンを gcloud CLI 構成ディレクトリにキャッシュに保存します。連携アクセス トークンは、設定された時間(デフォルトでは 60 分)後に期限切れになる有効期間の短い認証情報です。
エンドポイントを侵害した攻撃者は、アクティブなフェデレーション アクセス トークンを抽出するか、gcloud auth print-access-token を使用してワークフォース プリンシパルになりすます可能性があります。ワークフォース ID に権限借用権限がある場合、攻撃者はサービス アカウント アクセス トークンをリクエストして権限を昇格させることもできます。
リスクを軽減するには、Workforce Identity プールのセッション継続時間を構成して、必要な最小限の継続時間に設定し、外部 ID プロバイダの再認証とセッションのタイムアウトのポリシーに合わせて調整します。認証情報を保存および管理する方法については、Workload Identity 連携の使用に関するベスト プラクティスをご覧ください。
認証情報の漏洩による影響
OAuth トークンなどの認証情報によって攻撃者がアクセス権を継続または昇格できるため、攻撃者がエンドポイントを侵害できた場合、これらの認証情報は重要なターゲットとなります。
デベロッパーは、コードの記述とデバッグの際に自身の認証情報を表示することが必要な場合があります。たとえば、サポートされていないクライアント ライブラリを操作するときに、 Google Cloud サービスへの REST リクエストの認証を行う必要があります。デベロッパーは次のようなさまざまな方法で認証情報を表示できます。
- ローカル ファイル システムで gcloud CLI 構成ファイルを確認する
- Compute Engine メタデータ サーバーに対してクエリを実行する
gcloud auth print-access-tokenやgcloud auth listなどのコマンドを使用する
ただし、攻撃者はエンドポイントを侵害した後に上記の手法を使用する可能性があります。
攻撃者がエンドポイントを侵害した場合の主な脅威は、認証された ID の正規の認証情報を使用して、攻撃者が gcloud CLI コマンドや他のコードを実行できることです。さらに、攻撃者は認証情報を自分が制御している別のエンドポイントにコピーして、アクセスを継続する場合があります。この認証情報の盗難が発生すると、二次的な脅威が発生します。侵害されたエンドポイントへのアクセスを削除しても、攻撃者は有効期間の長い認証情報を使用して永続的なアクセス権を保持できます。
攻撃者がデベロッパー認証情報を侵害できた場合、次のアクションを行う可能性があります。
- 侵害されたユーザーまたはサービス アカウントになりすまします。侵害されたトークンを使用する API トラフィックは、侵害されたユーザーまたはサービス アカウントから送信されたものとしてログに記録されるため、ログで通常のアクティビティと悪意のあるアクティビティを区別することが困難になります。
- 永続的な OAuth 更新トークン(gcloud CLI またはアプリケーションのデフォルト認証情報から)またはサービス アカウントに関連付けられた秘密鍵を使用して、アクセス トークンを無期限にリクエストします。
- トークンはログインフロー後に付与されるため、ユーザーのパスワードまたは 2 段階認証プロセスによる認証をバイパスする可能性があります。
- 盗まれた SSH 認証鍵を使用して Compute Engine インスタンスにアクセスし、メタデータ サーバーにクエリを実行して、関連付けられたサービス アカウント トークンを盗みます。
- 盗まれたブラウザ Cookie を使用して、ユーザーのパスワードや 2 段階認証プロセスを必要とせずに、アクティブな Google Cloud コンソール セッションをハイジャックします。
- 盗まれたフェデレーション アクセス トークンを使用して、Workforce Identity プールに付与されたリソースにアクセスしたり、サービス アカウントの権限を借用して権限を昇格させたりします。
リスクを軽減するためのベスト プラクティス
以下のセクションで説明するコントロールを実装して、侵害されたデベロッパー認証情報のリスクを軽減します。エンタープライズ基盤のブループリントまたは Google Cloudのランディング ゾーンの設計で説明されているセキュリティのベスト プラクティスを実施している場合、すでにこれらのコントロールが実装されている可能性があります。
Google Cloud サービスのセッション継続時間を設定する
攻撃者が侵害されたトークンを悪用できる期間を短縮するには、 Google Cloudサービスのセッション継続時間を設定します。新規のお客様には、デフォルトのセッション継続時間 16 時間が自動的に適用されます。2023 年より前に Google Cloud組織を作成したお客様は、再認証を必要としないデフォルト設定になっている場合があります。この設定を確認して、セッション継続時間が 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 CloudAPI を保護するように、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 段階認証プロセスを細かく適用できません。Identity-Aware Proxy(IAP)Desktop または Google Chrome ベースの RDP プラグインを使用する場合は、次の操作を行います。
ユーザーのウェブ セッションに対して、Google サービスのセッション継続時間や 2 段階認証プロセスの設定などのきめが粗い制御を設定します。
[2 段階認証プロセス] で [信頼できるデバイスの登録を許可する] 設定を無効にします。
サービス アカウント キーの使用を制限する
認証にサービス アカウント キーを使用する場合、キーの値は、ダウンロードしたキーファイルとは別に、gcloud CLI 構成ファイルに保存されます。環境にアクセス可能な攻撃者は、gcloud CLI 構成からキーをコピーするか、ローカル ファイル システムまたは内部コード リポジトリからキーファイルをコピーする可能性があります。したがって、アクセス トークンの侵害を軽減する計画に加えて、ダウンロードしたサービス アカウント キーファイルの管理方法も検討してください。
より安全な代替の認証方法を確認して、サービス アカウント キーに依存するユースケースを削減または排除します。また、constraints/iam.disableServiceAccountKeyCreation と constraints/iam.disableServiceAccountKeyUpload の組織のポリシーの制約を適用して、サービス アカウント キーの作成を無効にします。
最小権限の原則を適用する
Identity and Access Management(IAM)ポリシーを設計する際には、最小権限を検討してください。最小限のスコープでタスクを実行するために必要なロールのみをユーザーに付与します。ロールの推奨事項を確認して適用し、環境で未使用のロールや過剰なロールを含む IAM ポリシーを回避します。
エンドポイントを保護する
攻撃者がエンドポイント(デベロッパー ワークステーションや Compute Engine インスタンスなど)への物理的なアクセスまたはリモート アクセスを行う方法を検討します。侵害された認証情報の脅威に対処する計画は重要ですが、攻撃者が信頼できるエンドポイントを侵害するリスクについても検討する必要があります。攻撃者が信頼できるエンドポイントにアクセスできれば、gcloud CLI コマンドや他のコードをエンドポイント自体で直接実行できます。
デベロッパー ワークステーションに対する包括的な保護についてはこのドキュメントでは扱いませんが、セキュリティ ツールとオペレーションがエンドポイントの保護と侵害の監視にどのように役立つかを評価してください。次のことを検討してください。
- デベロッパー ワークステーションの物理的なセキュリティは、どのように保護されていますか?
- ネットワーク侵害をどのように特定して対応していますか?
- ユーザーは SSH または RDP セッションへのリモート アクセスをどのように取得しますか?
- SSH 認証鍵やサービス アカウント キーなどの永続的な認証情報はどのように侵害される可能性がありますか?
- 有効期間が短い認証情報で置き換えることが可能な永続的な認証情報を使用しているワークフローはありますか?
- 他のユーザーのキャッシュに保存された gcloud CLI 認証情報を他人が読み取れる共有デバイスはありますか?
- ユーザーは、信頼できないデバイスから gcloud CLI で認証できますか?
- 承認されたトラフィックは、VPC Service Controls の境界内のリソースにどのように接続しますか?
セキュリティ オペレーションが上記の各質問に対処していることを確認します。
対応チームを調整する
インシデント対応を担当するセキュリティ チームが、 Google Cloud コンソールと管理コンソール全体に対して適切なアクセス権を持っていることを事前に確認します。 Google Cloud コンソールと管理コンソールを別々のチームが管理している場合、インシデント発生時に対応が遅れる可能性があります。
侵害を評価して対応するには、侵害された Google Cloud 認証情報に対応するをご覧ください。
認証情報の侵害を監視する
セキュリティ侵害をモニタリングする場合は、次の点を考慮してください。
異常検出やシークレット スキャンなどのツールを使用して、コード リポジトリ内のシークレットをスキャンします。
Cloud Audit Logs で、次のアラートを構成します。
iamcredentials.googleapis.comメソッド(GenerateAccessToken、GenerateIdToken、SignJwtなど)を使用して、サービス アカウント トークンの生成を監査するこれらのログでは、データアクセス ログを有効にする必要があります。
protoPayload.authenticationInfo.serviceAccountDelegationInfo.firstPartyPrincipal.principalEmail: ユーザーとサービス アカウントの権限借用の監査異常な ID アサーションに対する
sts.googleapis.com交換リクエスト
Security Command Center で、Event Threat Detection から次の脅威の検出結果をモニタリングします。
- 永続性: 新しい地域
- 永続性: 新しいユーザー エージェント
- 永続性: 新しい API メソッド
- 回避: 匿名化プロキシからのアクセス
- 権限昇格: 管理アクティビティに関する、サービス アカウントの異常な権限借用
- 権限昇格: 管理アクティビティに関する、サービス アカウントの異常な権限借用
- 初期アクセス: 漏洩したサービス アカウント キーの使用
- 永続性: サービス アカウント キーの作成
- 初期アクセス: 不審なログインのブロック
- 初期アクセス: アカウントの無効化(ハイジャック)
脅威ごとに、対応を支援する推奨される調査手順が提供されます。
ユーザー ログインは、Google Workspace と Cloud Identity でモニタリングできます。問題をより適切に追跡するには、ログを Cloud Logging にエクスポートすることを検討してください。
Chrome Enterprise Premium と VPC Service Controls のログをモニタリングして、盗まれたトークンによる境界外アクセス試行を検出します。
Cloud Monitoring を使用して、サービス アカウント キーの使用状況に異常がないかモニタリングします。
認証情報が侵害された疑いがある場合は速やかに対応できるように、セキュリティ オペレーション センター(SOC)にすぐに通知が届くようにし、必要なハンドブック、ツール、アクセス権を確保してください。また、詳細な分析を行うために Security Command Center を既存の SIEM と統合することや、Google Security Operations にログをインポートすることも可能です。