Google Cloud でホストされているリソースへのアクセスは、Google Cloud の認証情報によって制御されています。データを保護し、攻撃から守るため、認証情報の扱いには十分な注意を払う必要があります。
すべての Google Cloud 認証情報を意図しないアクセスから保護することをおすすめします。このような認証情報としては次のものがありますが、これに限定されるものではありません。
サービスの認証情報:
デベロッパーのワークステーションや他の PC で作成され、管理されるユーザー認証情報:
ブラウザ Cookie
Google Cloud CLI の認証情報は、ユーザーのホーム ディレクトリに保存されます。Google Cloud CLI で gcloud
auth list コマンドを使用すると、一覧表示できます。アプリケーションのデフォルト認証情報は、デベロッパーのワークステーションに保存されます。ブラウザの Cookie はブラウザ固有のものですが、通常はデベロッパーのワークステーションに保存されます。
認証情報が漏洩したおそれがある場合は、Google Cloud アカウントへの影響を抑えるため、直ちに対処する必要があります。
認証情報の侵害を監視する
セキュリティ侵害をモニタリングする場合は、次の点を考慮してください。
権限昇格や複数のアカウントの作成など、アカウントの不審なアクティビティをモニタリングします。こうしたアクティビティは、Cloud Audit Logs、Policy Intelligence、Security Command Center を使用してモニタリングします。Security Command Center の以下のサービスと機能を使用します。
- Event Threat Detection は、管理者のアクティビティ、グループの変更、Identity and Access Management（IAM）権限の変更に基づいて脅威を特定します。
- Sensitive Actions Service は、組織、フォルダ、プロジェクトで悪意のある行為者によって行われ、ビジネスに被害を及ぼす可能性のあるアクションを追跡します。
- Cloud Infrastructure Entitlement Management（CIEM）（プレビュー版）は、ID のアクセスを管理し、構成ミスの調査結果を生成します。
ユーザー ログインは、Google Workspace と Cloud Identity でモニタリングできます。問題をより適切に追跡するには、ログを Cloud Logging にエクスポートすることを検討してください。
異常検出やシークレット スキャンなどのツールを使用して、コード リポジトリ内のシークレットをモニタリングします。
Cloud Monitoring または CIEM を使用して、サービス アカウント キーの使用状況に異常がないかモニタリングします。
セキュリティ オペレーション センター（SOC）にすぐに通知が届くようにし、認証情報が侵害された疑いがある場合は速やかに対応できるように、必要なハンドブック、ツール、アクセス権を確保してください。Security Command Center Enterprise ティアを使用して、ハンドブック、レスポンス ワークフロー、自動化されたアクションなどの SIEM と SOAR の機能を有効にします。また、詳細な分析を行うために Security Command Center を既存の SIEM と統合することや、Google Security Operations にログをインポートすることも可能です。
認証情報の侵害から 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 を承認するをご覧ください。
次のコマンドで認証情報を取り消します。
gcloud auth application-default revoke必要に応じて、
application_default_credentials.jsonファイルを削除します。オペレーティング システムによって場所が異なります。- Linux / macOS:
$HOME/.config/gcloud/ - Windows:
%APPDATA%\gcloud\
- Linux / macOS:
次のコマンドで認証情報ファイルを再作成します。
gcloud auth application-default login
管理者としてブラウザの Cookie を無効にする
ブラウザ Cookie から情報が漏洩したおそれがある場合は、Google Workspace 管理者がアカウントからユーザーをログアウトします。
また、パスワードをすぐに強制変更してください。
これらの操作によって既存のすべての Cookie が無効になり、ユーザーは再度ログインを求められます。
ユーザーとしてブラウザの Cookie を無効にする
ブラウザ Cookie から情報が漏洩したおそれがある場合は、Google アカウントからログアウトして、すぐにパスワードを変更してください。
この操作を行うと、既存の Cookie がすべて無効になります。次回 Google Cloud にアクセスするときに、再度ログインする必要があります。
未承認のアクセスとリソースを探す
侵害された認証情報を取り消してサービスを復元した後で、Google Cloud リソースへのすべてのアクセスを確認します。Logging または Security Command Center を使用できます。
Logging では、次の操作を行います。
Google Cloud コンソールで監査ログを調べます。
影響を受ける可能性のあるすべてのリソースを検索し、すべてのアカウント アクティビティ（特に、侵害された認証情報に関連するもの）が想定どおりかどうか確認します。
Security Command Center では、次の操作を行います。
Google Cloud コンソールで、Security Command Center の [検出] ページに移動します。
必要に応じて、Google Cloud プロジェクトまたは組織を選択します。
[クイック フィルタ] セクションで、適切なフィルタをクリックして、必要な検出結果を [検出結果クエリの結果] テーブルに表示します。たとえば、[ソースの表示名] サブセクションで [Event Threat Detection] または [Container Threat Detection] を選択した場合、選択したサービスの検出結果のみが結果に表示されます。
テーブルに、選択したソースに関する結果が表示されます。
特定の検出の詳細を表示するには、[
Category] の下にある検出結果の名前をクリックします。検出結果の詳細ペインが開き、検出結果の詳細のサマリーが表示されます。同じユーザーの操作によって発生した検出結果をすべて表示するには:
- [検出の詳細] ペインで、[プリンシパルのメール] の横にあるメールアドレスをコピーします。
- ペインを閉じます。
クエリエディタで、以下のクエリを入力します。
access.principal_email="USER_EMAIL"USER_EMAIL は、前にコピーしたメールアドレスに置き換えます。
Security Command Center には、指定したユーザーが行った操作に関連するすべての検出結果が表示されます。
すべての未承認リソースを削除する
侵害された認証情報によって予期しないリソース（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 を構成すると、境界内のリソースは境界内の他のリソースとのみ通信できるようになります。