Google Cloud でホストされているリソースへのアクセスは、Google Cloud の認証情報によって制御されています。データを安全に保ち、攻撃者から守るため、認証情報の扱いには十分な注意を払う必要があります。
すべての Google Cloud 認証情報を意図しないアクセスから保護することをおすすめします。このような認証情報の例として、以下が挙げられます。
サービスの認証情報:
デベロッパーのワークステーションまたは他のパソコンで作成および管理されるユーザー認証情報:
ブラウザ 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 を構成すると、境界内のリソースは境界内の他のリソースとのみ通信できるようになります。