GCP（Google Cloud）では、Googleアカウントの不正ログインだけでなく、サービスアカウント鍵、APIキー、OAuthクライアント、CI/CDトークンなどの認証情報漏えいを起点として、VMの不正作成、IAM権限の追加、データへの不正アクセス、暗号資産マイニング、不正なAPI利用などへ発展することがあります。

特にクラウド環境では、攻撃者が短時間のうちに大量のリソースを作成したり、別リージョンへ展開したり、権限を追加して永続化したりする可能性があります。そのため、単に不審なVMやユーザーを削除するだけでは不十分です。

重要なのは、攻撃者の現在のアクセスを止めながら、Cloud Audit LogsやIAM変更履歴、ディスク・ネットワーク・データアクセスの証拠を失わないことです。

また、侵害されたサービスアカウント鍵やAPIキーを無効化しても、別の認証情報やIAM権限、OAuth、Workload Identity Federation、SSH鍵などが残っていれば再侵入される可能性があります。

そこで本記事では、GCPで不正アクセスや認証情報漏えいが疑われたときに最初に行う封じ込め、証拠保全、Cloud Audit Logs・IAM・Compute Engine・GKE・Cloud Storageなどの調査、根絶・復旧、請求対応、再発防止について解説します。

GCPで不正アクセスが疑われる主なサイン

GCPでは、通常の運用変更と攻撃者による操作が同じ管理APIを通じて行われることがあります。そのため、単一のアラートではなく、IAM・リソース・請求・データアクセスを横断して確認します。

見覚えのないOwner・IAM権限が追加されている

プロジェクトや組織に、心当たりのないユーザー、グループ、サービスアカウントが追加されている場合は、高優先度で確認します。

特に、roles/owner、roles/editor、IAM管理権限、サービスアカウント操作権限など、権限変更や横展開につながるロールが付与されている場合は注意が必要です。

サービスアカウント鍵やAPIキーが不審に作成されている

攻撃者は、侵害したGoogleアカウントから別のサービスアカウント鍵を作成し、長期利用可能な認証情報として残す場合があります。

また、漏えいしたAPIキーを使って従量課金APIを大量利用されるケースもあります。

Compute EngineやGKEなどのリソースが突然増えている

短時間で多数のVM、GPUインスタンス、GKEノードプール、Cloud Runサービスなどが作成されている場合、不正なマイニングや踏み台用途が疑われます。

請求額やAPI利用量が急増している

通常利用していないリージョン・SKU・APIでコストが急増している場合は、リソースの作成主体と利用時間帯を確認します。

Cloud Storage・BigQueryなどで大量アクセスがある

攻撃者の目的が不正課金ではなく情報窃取の場合、Cloud Storageの大量ダウンロードやBigQueryの大量クエリ・Export、Secret Managerへのアクセスなどが発生することがあります。

ログ・セキュリティ設定が変更されている

Cloud Loggingのシンク、除外設定、保持期間、Security Command Center、組織ポリシーなどが意図せず変更されている場合は、痕跡隠しを疑います。

GCPで不正アクセスが疑われたとき最初に行うこと

初動では、「攻撃者を止めること」と「調査に必要な証拠を残すこと」を並行させます。

インシデントとして宣言し変更を統制する

不正アクセスが疑われる場合は、通常の障害対応として処理せず、セキュリティインシデントとして扱います。

対応担当者、承認者、記録担当者を決め、以後のIAM変更、鍵無効化、VM停止、Firewall変更などを時刻付きで記録してください。

クリーンな管理端末を用意する

サービスアカウント鍵やGoogleアカウントが漏えいした原因が開発端末のマルウェアだった場合、同じ端末から新しい認証情報を発行すると再び盗まれる可能性があります。

可能であれば、普段の開発環境とは分離した管理端末・別の管理アカウントから対応します。

侵害された認証情報を停止する

漏えいが疑われる認証情報によって対応方法は異なります。

サービスアカウントJSON鍵が漏えいした場合、Gitリポジトリからファイルを削除するだけでは対処になりません。認証情報自体を無効化する必要があります。

不正リソースを隔離する

不正なVM、GKEワークロード、Cloud Runサービスなどが稼働している場合は、外部通信や公開経路を制限します。

ただし、調査が必要な場合は、直ちに削除するのではなく、ディスクスナップショットや設定、ログなどを先に保全します。

Cloud Audit Logsなどを保全する

Cloud Audit Logs、Security Command Center、Cloud Loggingなどは、誰がどのAPIを使い、どのリソースを変更したかを追跡する重要な情報源です。

GCPで消さずに保全すべき証拠

攻撃者が作成したVM、IAM、サービスアカウント、Firewallルールなどをすぐに消すと、侵入経路や影響範囲を確認できなくなる場合があります。

Cloud Audit Logs

Admin Activityを中心に、Data Access、System Event、Policy Deniedなど、利用しているログを保全します。

ログの保持期間が短い場合は、別のログプロジェクトや保全用のログバケットへ退避することも検討します。

IAMポリシー

組織、フォルダ、プロジェクト、サービスアカウント単位で、現在のIAMポリシーを取得します。

直接付与だけでなく、Googleグループ経由や条件付きIAMも確認対象です。

Cloud Asset Inventory

インシデント前後のリソース構成、IAM、ネットワーク設定を比較できるよう、Cloud Asset Inventoryを用いて状態を記録します。

Compute Engineのディスク・設定

不審なCompute Engineインスタンスでは、ディスクスナップショット、メタデータ、起動スクリプト、OS Login、SSH鍵、サービスアカウント設定などを保全します。

GKEの監査・ワークロード情報

GKEでは、監査ログ、Pod定義、イメージダイジェスト、RBAC、Admission設定、ノード構成、Workload Identityなどを確認します。

ネットワークログ

VPC Flow Logs、Cloud NAT、Firewall、Load Balancing、Cloud Armorなどのログが利用可能なら、侵害時刻周辺を保全します。

ストレージ・DB・Secret Managerのアクセス履歴

Cloud Storage、BigQuery、Cloud SQL、Secret Managerなど、重要データへアクセスできるサービスは、読み取り・エクスポート・権限変更の痕跡を確認します。

GCPのIAM・認証情報で確認すべき不正操作

クラウド侵害では、最初に奪った認証情報から別の永続的な認証手段を作られることがあります。

Cloud Audit Logsでは、たとえば次のような操作名を中心に検索します。

• SetIamPolicy
• CreateServiceAccount
• CreateServiceAccountKey
• UploadServiceAccountKey
• CreateProject
• CreateInstance
• CreateNetwork
• EnableService

ただし、実際のメソッド名はサービスによって異なるため、principal、送信元IP、User-Agent、APIメソッド、時刻を組み合わせて相関します。

Compute Engine・GKE・Cloud Runで確認すべき痕跡

Compute Engine

見覚えのないVM、特にGPUを搭載した高額なインスタンスや、普段利用しないリージョンのインスタンスが作成されていないか確認します。

あわせて、外部IP、SSH/RDP公開、起動スクリプト、Metadata、サービスアカウント、Firewallルールを確認してください。

GKE

GKEでは、見覚えのないPod、Deployment、DaemonSet、CronJob、Service、Ingress、RBAC、ClusterRoleBindingなどを確認します。

コンテナイメージについては、イメージ名だけでなくダイジェストも記録します。

Cloud Run・Cloud Functions

不審なサービス・Function・Jobが追加されていないか、公開設定、サービスアカウント、環境変数、Secret Manager参照、デプロイ元を確認します。

GCPでデータ持ち出しを確認する方法

不正アクセスでは、リソース作成だけでなく情報窃取も確認する必要があります。

Cloud Storageの大量ダウンロード

通常と異なる主体・時間帯・IPからのオブジェクト取得、公開設定変更、一括ダウンロードなどを確認します。

BigQueryの大量クエリ・Export

不審なクエリ、EXPORT、結果保存先、ジョブ実行主体を確認します。

Secret Managerへのアクセス

Secret ManagerにはDBパスワードやAPIトークンなど高価値な秘密情報が保存されている場合があります。

不審なアクセスが確認された場合は、そのシークレット自体のローテーションも必要です。

Cloud SQLの不審接続・Export

DBユーザー追加、権限変更、バックアップ・エクスポート、不審な接続元を確認します。

Artifact Registryのイメージ取得

コンテナイメージにはアプリケーションコードや設定が含まれるため、不審なpullやpushも確認対象です。

GCPの不正アクセスを根絶して安全に復旧する方法

封じ込め後は、攻撃者のアクセス手段を完全に除去したうえで復旧します。

侵害経路を特定する

代表的な侵入経路には、次のようなものがあります。

• GitリポジトリへコミットされたサービスアカウントJSON鍵
• 漏えいしたAPIキー
• フィッシングされたGoogleアカウント
• 侵害された開発端末
• 過剰なIAM権限
• 外部公開された管理ポート
• 脆弱なWebアプリケーション
• CI/CD環境のトークン漏えい

認証情報を体系的にローテーションする

対象はパスワードだけではありません。

• サービスアカウント鍵
• APIキー
• OAuthクライアントシークレット
• CI/CDトークン
• DB認証情報
• Secret Manager内のシークレット
• SSH鍵

IAMと永続化を除去する

不正principal、サービスアカウント、鍵、WIF設定、SSH鍵、Cloud Scheduler、Cloud Run Jobs、起動スクリプト、Kubernetes RBACなどを横断して見直します。

信頼できる状態から再構築する

侵害されたVMやコンテナは、単に悪性ファイルを削除して再利用するより、検証済みのイメージやIaCから再構築する方が安全です。

バックアップを戻す場合も、侵害前の健全な時点であることを確認してください。

GCPで不正課金が発生した場合の対応

不正なVM作成やAPI利用がある場合は、技術対応と並行してBillingの確認を進めます。

通常利用していないGPU、Compute Engine、AI/ML APIなどのコストが急増していないか確認してください。

予算アラートは通知を目的とする設定であり、必ずしもリソース利用を自動停止するものではありません。不正利用が継続している場合は、影響範囲を確認しながら対象リソースやAPIの停止・制限を行います。

Google Cloudサポートへ連絡する場合は、発見日時、影響プロジェクト、不正操作の概要、請求増加の時間帯、実施した封じ込め、保全済みログなどを整理すると説明しやすくなります。

GCPの不正アクセスでやってはいけないこと

攻撃者が作ったリソースを証拠保全前に削除する

不正VMやサービスアカウントを先に消すと、攻撃者の行動や侵入経路を調べられなくなる場合があります。

サービスアカウント鍵をGitから削除しただけで終える

一度公開された鍵は、第三者がすでにコピーしている可能性があります。リポジトリからの削除と、鍵自体の失効は別の対応です。

パスワード変更だけで復旧完了とする

攻撃者がOAuth、サービスアカウント鍵、IAM、WIFなど別の経路を残していれば再侵入される可能性があります。

侵害された開発端末から新しい鍵を発行する

端末上の情報窃取マルウェアが原因だった場合、新しい鍵まで再び盗まれる可能性があります。

IAMだけを見てデータアクセスを確認しない

権限侵害だけでなく、Cloud Storage、BigQuery、Secret Manager、Cloud SQLなどで実際にデータが閲覧・取得されていないか確認する必要があります。

GCPの不正アクセスを再発防止する方法

管理者アカウントにフィッシング耐性MFAを導入する

管理者アカウントは日常利用アカウントと分離し、可能ならパスキーやセキュリティキーなどフィッシング耐性の高い認証を利用します。

Owner・Editorの常用を避ける

必要な操作だけを許可する最小権限へ移行し、期限付き・条件付きアクセスも検討します。

サービスアカウント鍵を減らす

ユーザー管理の長期鍵を減らし、可能な環境ではWorkload IdentityやWorkload Identity Federationなど鍵を直接配布しない仕組みを優先します。

APIキーを制限する

APIキーは、利用API、アプリケーション、IPなどを必要に応じて制限し、無制限のキーを残さないようにします。

組織ポリシーを活用する

外部IP、公開バケット、サービスアカウント鍵作成、ドメイン外IAMなど、組織で禁止したい設定をポリシーで制約します。

監査ログを中央集約する

重要プロジェクトの監査ログを別の管理用ログプロジェクトへ集約し、侵害対象プロジェクトの管理者だけでは削除しにくい構成にします。

請求・IAM変更を常時監視する

IAM付与、サービスアカウント鍵作成、外部公開、異常なAPI利用量、予算急増などをアラート化します。

GCPの不正アクセスを詳しく調査する方法

漏えいした認証情報が明確で、利用範囲も限定され、Cloud Audit Logs上でも影響範囲を十分に確認できる場合は、社内のインシデント対応チームで完結できるケースもあります。

一方で、未知のOwnerが追加されている、複数プロジェクトへ横展開されている、サービスアカウント鍵の漏えい時期が分からない、Compute EngineやGKEへ侵入されている、データ持ち出しの可能性がある場合は、専門的な調査が必要になることがあります。

侵入経路

Googleアカウントのフィッシング、サービスアカウント鍵漏えい、CI/CDトークン、公開サービスの脆弱性、開発端末侵害などを切り分けます。

侵害された認証情報

どの認証情報が、いつから、どのサービスで悪用されていた可能性があるのかを確認します。

IAM・リソース変更の時系列

Cloud Audit Logsを中心に、権限追加、サービスアカウント作成、VM作成、Firewall変更などを時系列化します。

データアクセス・持ち出し

Cloud Storage、BigQuery、Cloud SQL、Secret Managerなどへのアクセスを調べ、機密データや認証情報が閲覧・取得された可能性を確認します。

攻撃者の永続化

IAM、サービスアカウント、OAuth、WIF、SSH鍵、Cloud Run Jobs、Scheduler、Kubernetes RBACなど、攻撃者が再侵入するための設定が残っていないか確認します。

再構築・復旧範囲

侵害されたVMやコンテナをどこまで再構築すべきか、どの認証情報をローテーションすべきかを整理します。

GCPで不正アクセス・データ流出が疑われる場合はフォレンジック調査会社に相談する

サービスアカウント鍵の漏えいだけが確認され、利用箇所と影響範囲が明確で、Cloud Audit Logsから不正利用がなかったことを十分に確認できる場合は、必ずしも外部調査が必要とは限りません。

一方で、未知のOwnerや管理者権限が追加されている、複数プロジェクトで不審なリソースが作成されている、請求が急増している、Cloud StorageやBigQueryからデータが持ち出された可能性がある場合は、侵入経路と影響範囲を正確に把握する必要があります。

不正VMやIAM、ログを確認する前に削除してしまうと、攻撃者がいつ侵入し、どの認証情報を使い、どのリソースへアクセスし、どのデータを閲覧・取得した可能性があるのかを調べるための証拠が失われる場合があります。

不正アクセスの兆候を確認した場合、フォレンジック調査会社への相談をお勧めします。フォレンジック調査会社では、Cloud Audit Logs、IAM変更履歴、Compute EngineやGKEの証跡、ネットワークログ、データサービスへのアクセス履歴などを組み合わせ、侵入経路、攻撃者の操作、影響範囲、情報漏えいの可能性を詳しく調査できます。

こうした専門的な調査を通じて、どの認証情報をローテーションすべきか、どのリソースを再構築すべきか、データ漏えいに関する報告や通知が必要か、Google Cloudや関係部署へ何を説明すべきかを整理しやすくなります。

おすすめのフォレンジック調査会社

公式サイトデジタルデータフォレンジック

編集部が厳選したおすすめのフォレンジック調査会社は、デジタルデータフォレンジックです。

デジタルデータフォレンジックは、累計4万7千件以上の豊富な相談実績を持ち、全国各地の警察・捜査機関からの相談実績も409件以上ある国内有数のフォレンジック調査サービスです。

24時間365日の相談窓口があり、緊急時でも安心です。相談から見積りまで無料で対応してくれるので、フォレンジック調査の依頼が初めてという方もまずは気軽に相談してみることをおすすめします。

【厳格調査】デジタルデータフォレンジックの評判は？口コミや評価、料金体系からサービスを調査

2024.3.5

フォレンジックとは「パソコンやHDD、スマートフォンなどのデジタル端末に残されたログやデータ類を抽出し、サイバーセキュリティ調査や法的紛争支援などを行う」技術です。 その中でも【

【2026年版】ハッキング調査会社を見分けるポイント6選！費用相場や悪徳業者の特徴も解説

2024.3.5

「パソコンが遠隔操作され、詐欺にあったかもしれない…」 「会社のパソコンのログを確認したら、未知のIPアドレスから不正アクセスを受けた痕跡を見

まとめ

GCPで不正アクセスや認証情報漏えいが疑われた場合は、単に不審なVMやユーザーを削除するのではなく、攻撃者のアクセスを封じ込めながら証拠を保全することが重要です。

まず、Googleアカウント、サービスアカウント鍵、APIキー、OAuth、CI/CDトークンなど、侵害された可能性のある認証情報を確認し、必要に応じて失効・ローテーションします。

同時に、Cloud Audit Logs、IAM、Cloud Asset Inventory、Compute Engine、GKE、VPC、Cloud Storage、BigQuery、Secret Managerなどのログや設定を保全し、「誰が・いつ・どの認証情報で・どのリソースへ・何をしたのか」を時系列で確認してください。

また、攻撃者がOwnerやサービスアカウント鍵、WIF、OAuth、SSH鍵などを使って永続化している可能性があるため、最初に見つかった侵害経路だけを塞いで終了しないことが重要です。

未知の管理者権限、複数プロジェクトへの横展開、不正課金、データ持ち出し、ログ改ざんなどが疑われる場合は、重大インシデントとして扱い、証拠保全と影響範囲調査を優先してください。