Google Cloud 認証情報の不正使用への対応

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

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

サービスの認証情報:
デベロッパーのワークステーションや他の PC で作成され、管理されるユーザー認証情報:
- Google Cloud CLI 認証情報
- アプリケーションのデフォルト認証情報
- ブラウザ Cookie

Google Cloud CLI の認証情報は、ユーザーのホームディレクトリに保存されます。Google Cloud CLI で gcloud auth list コマンドを使用すると、一覧表示できます。アプリケーションのデフォルト認証情報は、デベロッパーのワークステーションに保存されます。ブラウザ Cookie はブラウザ固有のものですが、通常はデベロッパーワークステーションに格納されます。

認証情報が漏洩したおそれがある場合は、Google Cloud アカウントへの影響を抑えるため、直ちに対処する必要があります。

認証情報の侵害を監視する

セキュリティ侵害をモニタリングする場合は、次の点を考慮してください。

権限昇格や複数のアカウントの作成など、アカウントの不審なアクティビティをモニタリングします。こうしたアクティビティは、Cloud Audit Logs と Event Threat Detection を使用してモニタリングします。Compute Engine 監査ログと Google Kubernetes Engine（GKE）監査ログの管理者アクティビティに基づいてアラートを構成します。Event Threat Detection は、管理者のアクティビティ、グループの変更、Identity and Access Management（IAM）権限の変更に基づいて脅威を特定します。
ユーザーログインは、Google Workspace と Cloud Identity でモニタリングできます。問題をより適切に追跡するには、ログを Cloud Logging にエクスポートすることを検討してください。
シークレットスキャンなどのツールを使用して、コードリポジトリ内のシークレットをモニタリングします。
Cloud Monitoring を使用して、サービスアカウントキーの使用状況に異常がないかモニタリングします。

セキュリティオペレーションセンター（SOC）にすぐに通知が届くようにします。Security Command Center をお使いの SIEM と統合したり、Cloud Logging からお使いの SIEM にログをエクスポートできます。また、Chronicle からログをインポートして、詳細な分析を行うこともできます。

認証情報が侵害された疑いがある場合に迅速に対応できるように、必要なハンドブック、ツール、アクセス権を SOC に付与してください。

認証情報の侵害から Google Cloud リソースを保護する

認証情報が侵害された場合にリソースを保護するには、できるだけ早く次の手順を実施してください。

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

認証情報が漏洩したおそれがある場合は、認証情報を取り消して再発行します。認証情報の取り消しによって、サービスが停止しないように注意して作業を進めます。

一般に、認証情報を再発行するには、新しい認証情報を生成し、その認証情報を必要とするすべてのサービスとユーザーに push してから、古い認証情報を取り消します。

以降のセクションでは、認証情報の種類ごとに具体的な手順を説明します。

サービスアカウントキーを置き換える

Google Cloud コンソールで、[サービスアカウント] ページに移動します。

[サービスアカウント] に移動
影響を受けるサービスアカウントを特定します。
サービスアカウントに新しいキーを作成します。
古いキーが使用されているすべての場所に新しいキーを push します。
古いキーを削除します。

詳細については、サービスアカウントの作成と管理をご覧ください。

API キーを再生成する

Google Cloud コンソールで、[認証情報] ページに移動します。

[認証情報] に移動
[認証情報を作成] ボタンを使用して新しい API キーを作成します。侵害された API キーと同様に新しい API キーを構成します。API キーの制限が一致する必要があります。一致していないと、使用できないことがあります。
古いキーが使用されているすべての場所に API キーを push します。
古いキーを削除します。

詳細については、API キーの使用をご覧ください。

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

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

Google Cloud コンソールで、[認証情報] ページに移動します。

[認証情報] に移動
侵害された OAuth2 クライアント ID を選択して編集します。
[シークレットをリセット] をクリックします。
新しいシークレットをアプリケーションに push します。

詳細については、OAuth 2.0 の設定と OAuth 2.0 を使用した Google API へのアクセスをご覧ください。

管理者として Google Cloud CLI 認証情報を削除する

Google Workspace 管理者として、接続されているアプリのリストから Google Cloud CLI へのアクセス権を削除します。詳細については、サードパーティアプリケーションへのアクセスの表示と削除をご覧ください。

ユーザーが Google Cloud CLI に再びアクセスすると、アプリケーションを再認証するよう自動的に求められます。

ユーザーとして Google Cloud CLI 認証情報を削除する

Google アカウントにアクセスできるアプリのリストを開きます。
接続されているアプリのリストから Google Cloud CLI を削除します。

Google Cloud CLI を再度使用すると、アプリケーションを再承認するように求められます。

管理者としてアプリケーションのデフォルト認証情報を取り消す

アプリケーションのデフォルト認証情報が侵害された可能性がある場合は、これを取り消すことができます。この手順により、認証情報ファイルが再作成されるまで、一時的に停止する可能性があります。

Google Workspace 管理者として、ユーザーの接続中アプリの一覧から Google 認証ライブラリへのアクセス権を削除します。詳細については、サードパーティアプリケーションへのアクセスの表示と削除をご覧ください。

ユーザーとしてアプリケーションのデフォルト認証情報を取り消す

作成したアプリケーションのデフォルト認証情報が侵害された可能性がある場合は、これを取り消すことができます。この手順により、認証情報ファイルが再作成されるまで、一時的に停止する可能性があります。この手順は、侵害された認証情報のオーナーのみが実行できます。

Google Cloud CLI をインストールして初期化します（まだ行っていない場合）。
サービスアカウントではなく、ユーザー ID を使用して gcloud CLI を承認します。
```
 gcloud auth login
```
詳細については、[gcloud CLI の承認](/sdk/docs/authorizing)をご覧ください。
次のコマンドで認証情報を取り消します。
```
  gcloud auth application-default revoke
```
必要に応じて、application_default_credentials.json ファイルを削除します。オペレーティングシステムによって場所が異なります。
- Linux / macOS: $HOME/.config/gcloud/
- Windows: %APPDATA%\gcloud\
次のコマンドで認証情報ファイルを再作成します。
```
 gcloud auth application-default login
```

管理者としてブラウザの Cookie を無効にする

ブラウザ Cookie から情報が漏洩したおそれがある場合は、Google Workspace 管理者がアカウントからユーザーをログアウトします。

また、パスワードをすぐに強制変更してください。

これらの操作によって既存のすべての Cookie が無効になり、ユーザーは再度ログインするよう求められます。

ユーザーとしてブラウザの Cookie を無効にする

ブラウザ Cookie から情報が漏洩したおそれがある場合は、Google アカウントからログアウトして、すぐにパスワードを変更してください。

この操作を行うと、既存の Cookie がすべて無効になります。次に Google Cloud にアクセスするときに、再度ログインする必要があります。

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

侵害された認証情報を取り消してサービスを復元した後で、Google Cloud リソースへのすべてのアクセスを確認します。

Google Cloud コンソールで監査ログを調べます。

[ログエクスプローラ] に移動
影響を受ける可能性のあるすべてのリソースを検索し、すべてのアカウントアクティビティ（特に、侵害された認証情報に関連するもの）が想定どおりかどうか確認します。

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

侵害された認証情報によって予期しないリソース（VM、App Engine アプリ、サービスアカウント、Cloud Storage バケットなど）がアクセスされていないことを確認します。

未承認リソースをすべて特定したら、それらのリソースをすぐに削除するかどうかを判断します。Compute Engine リソースの場合、侵害されたアカウントを悪用され、データの流出や本番環境システムの侵害が発生する可能性があるため、この操作は特に重要です。

あるいは、未承認リソースを隔離して、自社内のフォレンジックチームが詳細な分析を行えるようにすることもできます。

Cloud カスタマーケアへのお問い合わせ

調査と対策の手順に必要な Google Cloud のログとツールを見つけるのにサポートが必要な場合は、カスタマーケアにお問い合わせのうえ、サポートケースを開いてください。

認証情報の侵害を回避するためのベストプラクティス

このセクションでは、認証情報の侵害を避けるためのベストプラクティスについて説明します。

認証情報とコードの分離

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

GitHub またはその他のパブリックリポジトリを使用している場合は、シークレットスキャンなどのツールを実装できます。このツールを使用すると、GitHub リポジトリに公開されたシークレットに関する警告が表示されます。キーが GitHub リポジトリに commit されないようにするには、git-secrets などのツールの使用を検討してください。

Secret Manager や Hashicorp Vault などのシークレット管理ソリューションを使用して、シークレットの保存、定期的なローテーション、最小権限の適用を行います。

サービスアカウントのベストプラクティスを実装する

サービスアカウントを保護するには、サービスアカウントを操作するためのベストプラクティスを確認してください。

セッション時間を制限する

定期的な再認証を強制的に実施するには、Google アカウントと Google Cloud アカウントでセッションがアクティブとなる時間を制限します。詳しくは以下をご覧ください。

VPC Service Controls でアクセスを制限する

認証情報の侵害による影響を限定するには、VPC Service Controls を使用したサービス境界を作成します。VPC Service Controls を構成すると、境界内のリソースは境界内の他のリソースとのみ通信できるようになります。