漏洩した GCP 認証情報の処理

Google Cloud Platform(GCP)認証情報により、GCP でホストされているリソースへのアクセスが制御されます。データを安全に保ち、攻撃者から守るため、認証情報の扱いには十分な注意を払う必要があります。

すべての GCP 認証情報を意図しないアクセスから保護する必要があります。このような認証情報には次のものがありますが、これらに限定されるものではありません。

Cloud Platform Console で作成および管理されるサービス認証情報:

  • サービス アカウントの秘密鍵(JSON および p12 ファイル)
  • API キー
  • OAuth2 クライアント ID のシークレット

デベロッパーのワークステーションで作成および管理されるユーザー認証情報:

  • Google Cloud SDK 認証情報 - gcloud info コマンドの実行によって報告され、User Config ディレクトリに格納されます。
  • ブラウザの Cookie - ブラウザによって異なりますが、通常はデベロッパー ワークステーションに格納されます。

認証情報が漏洩した恐れがある場合は、GCP アカウントへの影響を最低限に留めるために直ちに対処する必要があります。

GCP アカウントの保護のために直ちに行う手順

認証情報の取り消しと再発行

すべての認証情報タイプは取り消して再発行できます。認証情報の取り消しによって、サービス停止が発生しないように注意して作業を進めます。

通常は、最初に新しい認証情報を生成し、その認証情報を必要とするすべてのサービスとユーザーに push してから、最後に古い認証情報を取り消します。

サービス アカウントの秘密鍵の置換

Cloud Platform Console で「サービス アカウント」を検索し、影響を受けるサービス アカウントを探します。サービス アカウントの新しい鍵を作成し、古い鍵が使用されているすべての場所に新しい鍵を push してから、古い鍵を削除します。

API キーの再生成

Cloud Platform Console で「認証情報」を検索します。[認証情報を作成] ボタンを使用して新しい API キーを作成し、漏洩した API キーと同様に構成します。API キーの制限が一致する必要があります。そうでない場合は使用できないことがあります。古いキーが使用されているすべての場所に API キーを push してから、古いキーを削除します。

OAuth2 クライアント ID のシークレットのリセット

クライアント ID のシークレットを変更すると、シークレットのローテーションの間に一時的な停止が発生します。

Cloud Platform Console で「認証情報」を検索します。必要な OAuth2 クライアント ID を選択して編集します。[シークレットをリセット] ボタンをクリックし、新しいシークレットをアプリケーションに push します。

Google Cloud SDK 認証情報の削除

Google Cloud SDK 認証情報が漏洩したユーザーは、accounts.google.com にアクセスしてから接続先のアプリとサイトに移動し、接続しているアプリの一覧から Google Cloud SDK を削除する必要があります。

gcloud コマンドライン ツールを再び使用するとき、アプリケーションを再び承認するように自動的に求められます。

この操作は G Suite 管理者がユーザーに代わって行うこともできます。

ブラウザの Cookie の無効化

ブラウザの Cookie から情報が漏洩した恐れがある場合は、accounts.google.com でパスワードをすぐに変更する必要があります。これにより既存のすべての Cookie が無効になり、ユーザーはブラウザにログインし直すように求められます。

この操作は G Suite 管理者がユーザーに代わって行うこともできます。

未承認のアクセスとリソースを探す

漏洩した認証情報を取り消してサービスを復元した後で、GCP リソースに対するすべてのアクセスを確認する必要があります。

主に、Cloud Platform Console で影響を受けるすべての GCP プロジェクトのアクティビティ ログを調べて(「アクティビティ」を検索)、すべてのアクセス(特に漏洩した認証情報に関連するもの)が予期されたとおりであると確認します。

すべての未承認リソースの削除

予期されないリソースが存在しないようにします。たとえば VM、Google App Engine アプリ、サービス アカウント、Google Cloud Storage バケットなどのプロジェクトに関連付けられているリソースです。

すべての未承認リソースを特定できたら、それらのリソースをすぐに削除するかどうかを選択してください。これはコンピューティング スタイルのリソースでは特に重要です。データを密かに流出させたり、本番環境システムを侵害したりする可能性があるためです。

あるいは、未承認リソースを隔離して、自社内のフォレンジック チームや Google Cloud サポートによってフォレンジックを行うこともできます。

Google Cloud サポートへの問い合わせ

Google Cloud サポートにお問い合わせください。

一般的なおすすめの方法

認証情報とコードの分離

認証情報はソースコードとは別に管理および格納します。認証情報とソースコードを両方とも Github のようなソース管理サイトに誤って push してしまうことはよくあり、それによって認証情報が攻撃を受ける脆弱性が高まります。

サービス アカウントのベスト プラクティス

サービス アカウントのおすすめの方法に従います。

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...