GCEの不正アクセス調査方法｜Google Cloud監査ログ・IAM・SSH点検

Google CloudでCompute Engine（GCE）インスタンスを運用していると、「身に覚えのないCPU負荷の急上昇が発生した」「Cloud Billingで予期せぬ高額請求のアラートが届いた」「不審なIPアドレスからのアクセスが疑われる」といった事態に直面することがあります。

このような異常に遭遇した際、慌ててインスタンスをいきなり削除したり再起動したりすると、侵入者が残した重要な痕跡（フォレンジック情報）が消えてしまう危険があります。まずはGoogle Cloudの管理コンソール側から、クラウド基盤の監査ログや設定変更履歴を客観的に点検し、何が起きているのかを把握することが大切です。

この記事では、Google Cloudの監査ログ（Cloud Audit Logs）の仕組み、ログエクスプローラ（Logs Explorer）を使った実践的な検索クエリ、IAMポリシーの権限改ざん追跡、VPCファイアウォールルールの確認手順を体系的に解説します。クラウド基盤側で見える範囲とOS内部で見える範囲の境界線も明確に整理しますので、迅速な初動対応にお役立てください。

この記事で行うこと
前提条件・対象読者
1. Quick Reference：Google Cloud側の不正アクセス点検早見表
2. Google Cloudの監査ログ（Cloud Audit Logs）の仕組みと違い
3. 手順1：ログエクスプローラ（Logs Explorer）で不審な操作を特定する
4. 手順2：IAMポリシー変更履歴と不審な権限付与の点検
1. プロジェクト全体のIAMポリシー変更を検索する
2. 変更差分（policyDelta）の読み解き方
  1. 着目ポイント
5. 手順3：VPCファイアウォールルールの改ざん点検
6. 手順4：Cloud Billing・予算アラートでの不正利用（クリプトジャッキング等）点検
1. 請求情報の異常値を早期に発見するポイント
  1. 確認すべき項目
2. 予算アラートの設定状態を確認する
7. クラウド基盤側で「確認できること」と「確認できないこと」
よくある質問（FAQ）
まとめ
次に読むおすすめ記事
参考情報

この記事で行うこと

Cloud Audit Logsの4つのログ種別と初期有効状態、保持期間を理解する
ログエクスプローラでGCEの操作履歴（起動、停止、削除、メタデータ変更）を検索する
不正なSSH公開鍵の追加やサービスアカウントキー作成の痕跡をクエリで抽出する
IAMポリシー変更履歴を点検し、外部アカウントへの不審な権限付与がないか調べる
VPCファイアウォールルールの改ざん状況と不正なポート開放を特定する
クラウド基盤側で確認できることと、OS内部に入らないと確認できないことの境界を把握する

前提条件・対象読者

Google Cloud上でCompute Engineインスタンスを個人開発や本番環境で運用している方
インスタンスの不審な挙動や料金急増に気づき、不正アクセスの有無を調査したい方
Google Cloudのログエクスプローラで実践的なクエリを使って調査を進めたい方
必要な権限：Google Cloudプロジェクトに対する「ログ閲覧者（roles/logging.viewer）」「Compute閲覧者（roles/compute.viewer）」または「閲覧者（roles/viewer）」以上の権限

1. Quick Reference：Google Cloud側の不正アクセス点検早見表

まずは、Google Cloud管理コンソール側で点検すべき主要項目と、ログエクスプローラでの検索クエリを一覧表でまとめました。

点検対象	調査する主な目的・攻撃兆候	主なログ種別	ログエクスプローラでの検索キー
GCEインスタンス操作	不審なVMの作成、停止、削除、スペック変更	管理アクティビティ	protoPayload.serviceName=”compute.googleapis.com” resource.type=”gce_instance”
SSH公開鍵の不正追加	インスタンスやプロジェクトへの公開鍵埋め込み	管理アクティビティ	protoPayload.methodName: setMetadata または setCommonInstanceMetadata
サービスアカウントキー	不審な秘密鍵の発行による外部からのAPI悪用	管理アクティビティ	resource.type=”service_account” protoPayload.methodName=”google.iam.admin.v1.CreateServiceAccountKey”
IAMポリシー変更	外部アカウントへのオーナーや編集者権限の付与	管理アクティビティ	protoPayload.serviceName=”cloudresourcemanager.googleapis.com” protoPayload.methodName=”SetIamPolicy”
ファイアウォール改ざん	SSH（22）や全ポートの0.0.0.0/0開放	管理アクティビティ	protoPayload.serviceName=”compute.googleapis.com” protoPayload.methodName: compute.firewalls の insert, patch, update
通信トラフィック	不審な外部IPからの侵入や大量データ送信	VPC FWログ	resource.type=”gce_subnetwork” log_id(“compute.googleapis.com/firewall”)

2. Google Cloudの監査ログ（Cloud Audit Logs）の仕組みと違い

Google Cloudにおける不正アクセス調査の主軸となるのが「Cloud Audit Logs（クラウド監査ログ）」です。Google Cloudリソースに対する「誰が（Who）」「いつ（When）」「どこから（Where）」「何をしたか（What）」を網羅的に記録します。

監査ログは性質に応じて以下の4種類に分類されます。それぞれのデフォルト有効状態と費用、保持期間の違いを把握しておくことが初動調査の前提となります。

ログの種類	記録対象となる操作内容	デフォルト状態	料金	標準保持期間
管理アクティビティ (Admin Activity)	VM作成、IAM変更、メタデータ更新、ファイアウォール変更などの構成操作	有効（無効化不可）	無料	400日間
データアクセス (Data Access)	Cloud Storageオブジェクトの読み書き、BigQueryクエリ実行、ユーザーデータの参照	原則無効（一部例外あり）	有料	30日間
システムイベント (System Event)	Google側の自動保守や自動スケーリングなど、システム起因の構成変更	有効（無効化不可）	無料	400日間
ポリシー拒否 (Policy Denied)	IAM権限不足やVPC Service Controls違反によるアクセス拒否イベント	有効	有料	30日間

個人開発や小規模な運用環境において最も心強いのは、攻撃者がインスタンスを作成したり権限を改ざんしたりする管理操作（管理アクティビティログ）が、特別な事前設定を行っていなくてもデフォルトで有効化されており、無料で過去400日分保持されているという点です。

ログエントリの内部構造では、protoPayload というフィールドの中に AuditLog オブジェクトが格納されます。ここに含まれる authenticationInfo.principalEmail（操作者のメールアドレス）や requestMetadata.callerIp（操作元の接続IPアドレス）を確認することで、誰がどこからAPIを実行したのかを突き止められます。

3. 手順1：ログエクスプローラ（Logs Explorer）で不審な操作を特定する

Google Cloudコンソールにログインし、ナビゲーションメニューから「ロギング」>「ログエクスプローラ」を開きます。画面上部のクエリビルダーを「クエリを表示」状態（テキスト入力モード）に切り替えてクエリを実行します。

ログエクスプローラ操作時の3大前提ルール（検索前の必須確認）

クエリを実行して正しく調査結果を得るために、以下の3つの操作ルールを必ず確認してください。

1. 画面右上の「時間範囲」を広げる（最重要）

ログエクスプローラを開いた直後は、時間範囲が「直近1時間」や「直近6分間」などごく短い期間に自動設定されていることがよくあります。この状態のままクエリを実行すると、直近数分間に操作したログしか検索されず、結果が「0件の結果」となってしまいます。不審な操作を洗い出す際は、画面右上にある時間範囲のドロップダウンをクリックし、「過去7日間」「過去14日間」「過去30日間」、または不審な挙動に気づいた日を含むカスタム期間に必ず広げてください。

2. クエリ貼り付け後は必ず「クエリを実行」を押下する

クエリ入力欄に検索文を貼り付けたり修正したりすると、タイムライン上部に「このクエリが更新されました。実行すると、一致するエントリが表示されます。[クエリを実行]」という青い案内枠が表示されます。画面右上の青い「クエリを実行」ボタン、または案内枠内のボタンを押下して初めて検索処理が実行されます。

3. 「0件の結果」が表示された場合の判断基準

監査ログ（不正なVM操作、公開鍵追加、サービスアカウントキー作成等）：時間範囲を「過去30日間」などに広げた上で「0件の結果」と表示された場合、その期間中に該当する不審な管理操作は一切行われていないことを意味します（不正アクセスの痕跡なし＝正常・シロの判定）。
VPCファイアウォールログ：後述する log_id("compute.googleapis.com/firewall") を検索して0件になる場合、Google Cloudではファイアウォールルールのログ記録が初期状態で「無効（オフ）」になっているためです。事前にVPCファイアウォール設定でログを明示的に有効化していなければログ自体が生成されません。

「確認すべき重要フィールド」は画面のどこにあるか？

クエリを実行してログが1件以上ヒットした場合、タイムライングラフの下に「重大度」「日時」「概要」が並ぶログエントリ一覧が表示されます。各ログの詳しい内部情報は以下の手順で確認します。

ログ一覧にある各行の左端に表示されている「>」（展開アイコン / 右向き三角マーク）をクリックします。
ログの詳細データがJSONツリー形式で縦に展開されます。
ツリー内の protoPayload の左側にある三角マークをクリックして展開します。
protoPayload の直下に authenticationInfo（操作者のアカウント）、methodName（実行された操作）、requestMetadata（接続元IPアドレスなど）が階層順に表示されます。
なお、検索結果が「0件の結果」の場合はログ行そのものが存在しないため、これらのフィールドも画面上には表示されません。

GCEインスタンスに対する不審な管理操作を抽出する

身に覚えのないインスタンスが立ち上がっていないか、または既存のインスタンスが停止・削除されていないかを調査します。

log_id("cloudaudit.googleapis.com/activity")
resource.type="gce_instance"
protoPayload.serviceName="compute.googleapis.com"
protoPayload.methodName=~"compute.instances.(insert|delete|start|stop|reset|setMachineType)"

クエリを実行したら、一覧に表示された各ログを展開し、以下の項目を点検します。

確認すべき重要フィールド

protoPayload.authenticationInfo.principalEmail：その操作を実行したアカウント。自分が普段使っているGoogleアカウント以外の見知らぬメールアドレスや、作成した覚えのないサービスアカウントが記録されていないか確認します。
protoPayload.requestMetadata.callerIp：APIリクエストが送信されたIPアドレス。自分がアクセスした地域・プロバイダ以外の海外IPなどから実行されていないか確認します。
protoPayload.resourceName：対象となったGCEインスタンスの名前。
timestamp：実行された日時（UTC表記またはローカル時間表記に注意して照合します）。

SSH公開鍵の不正追加（メタデータ改ざん）を抽出する

GCEでは、OS Login機能を使用していない場合、インスタンスやプロジェクトの「メタデータ」に公開鍵を書き込むことで、SSHアクセス権限を付与できる仕組みになっています。攻撃者がGoogle Cloudの権限を奪取した際、バックドアとして独自のSSH公開鍵をメタデータに注入する手口（MITRE ATT&CK T1098.004）が多用されます。

インスタンス単位、およびプロジェクト全体のメタデータ変更を洗い出すクエリは以下の通りです。

log_id("cloudaudit.googleapis.com/activity")
protoPayload.serviceName="compute.googleapis.com"
(protoPayload.methodName="v1.compute.instances.setMetadata" OR protoPayload.methodName="v1.compute.projects.setCommonInstanceMetadata")

ログが見つかった場合は、protoPayload.request.metadata.items を確認します。キー名が ssh-keys になっている項目の中に、見覚えのないユーザー名や公開鍵文字列が含まれていないかを徹底的に点検してください。

不審なサービスアカウントキーの作成を抽出する

攻撃者がプロジェクト内のサービスアカウントを悪用して外部から恒久的にAPIアクセスを維持するために、新しい秘密鍵（サービスアカウントキー）を発行することがあります。

サービスアカウントキーの作成履歴を検出するクエリは以下の通りです。

resource.type="service_account"
log_id("cloudaudit.googleapis.com/activity")
protoPayload.methodName="google.iam.admin.v1.CreateServiceAccountKey"

このログがヒットした場合、誰が（principalEmail）、どのサービスアカウントに対してキーを発行したのかを確認します。もし自身で発行した記憶がないキーが存在する場合、キーの識別子（キーID）をメモした上で、直ちにIAM画面から該当キーを無効化・削除する必要があります。

4. 手順2：IAMポリシー変更履歴と不審な権限付与の点検

攻撃者がプロジェクトの制御権を強固にするため、第三者のGoogleアカウントをプロジェクトのメンバーに追加し、「オーナー（roles/owner）」や「編集者（roles/editor）」といった強力なロールを付与している可能性があります。

プロジェクト全体のIAMポリシー変更を検索する

プロジェクトレベルのIAMポリシーが更新された履歴を抽出するクエリは以下の通りです。

log_id("cloudaudit.googleapis.com/activity")
resource.type="project"
protoPayload.serviceName="cloudresourcemanager.googleapis.com"
protoPayload.methodName="SetIamPolicy"

変更差分（policyDelta）の読み解き方

ヒットしたログを展開し、protoPayload.serviceData.policyDelta.bindingDeltas を確認します。ここには変更前のポリシーから何が追加・削除されたかが記録されています。

着目ポイント

action: "ADD"：新しく権限が付与されたことを示します。
role：付与された権限（roles/owner, roles/editor, roles/compute.admin など）。
member：権限を受け取った対象（user:suspicious@gmail.com や serviceAccount:... など）。

自身が意図して付与したものではないアカウントが追加されている場合は、アカウント情報が侵害されている証拠となります。

5. 手順3：VPCファイアウォールルールの改ざん点検

GCEインスタンスへの外部侵入を許す典型的な原因の一つが、ファイアウォールルールの不用意な開放です。本来は特定の拠点からのみ許可すべきSSH（TCP 22）や管理ポートが、全世界（0.0.0.0/0）に対して開かれていないかを調査します。

ファイアウォールルールの変更ログを抽出する

ファイアウォールルールが新しく作成されたり、既存のルールが編集されたりした履歴を検索するクエリです。

log_id("cloudaudit.googleapis.com/activity")
protoPayload.serviceName="compute.googleapis.com"
protoPayload.methodName=~"compute.firewalls.(insert|patch|update)"

ログ内の protoPayload.request を展開し、sourceRanges に 0.0.0.0/0 が指定されていないか、allowed に意図しないポート番号が含まれていないかを確認します。

ファイアウォールルール一覧での直接点検

ログの確認と並行して、コンソールの「VPCネットワーク」>「ファイアウォール」画面を開き、現行のルール一覧を目視で点検します。

点検すべき危険な設定パターン

送信元が 0.0.0.0/0 または ::/0 で、プロトコル・ポートが tcp:22（SSH）を許可している
送信元が 0.0.0.0/0 で、プロトコル・ポートが tcp:3389（RDP）を許可している
送信元が 0.0.0.0/0 で、データベースポート（tcp:3306, tcp:5432, tcp:6379, tcp:27017 等）を直接許可している
「すべてのトラフィックを許可（all）」するルールが最優先度で設定されている

VPCファイアウォールルールロギングによる着信履歴の確認

もし各ファイアウォールルールで「ログ（ロギング）」を有効に設定している場合、実際にどの外部IPから通信が試みられ、許可または拒否されたかを以下のクエリで追跡できます。

resource.type="gce_subnetwork"
log_id("compute.googleapis.com/firewall")
jsonPayload.disposition="ALLOWED"
jsonPayload.connection.dest_port=22

このログには、接続元のIPアドレス（jsonPayload.connection.src_ip）や接続日時が記録されます。なお、ファイアウォールロギングは通信量に応じてログ取り込み料金が発生するため、調査が必要な特定のルールに絞って有効化するのが基本です。

6. 手順4：Cloud Billing・予算アラートでの不正利用（クリプトジャッキング等）点検

Google Cloud上の不正アクセスにおいて、極めて発生頻度が高いのが「クリプトジャッキング（不正マイニング）」です。攻撃者は奪取したプロジェクト権限やAPIキーを使い、高価なGPUインスタンス（NVIDIA A100/H100搭載VM等）や大規模なCPUインスタンスを世界各地のリージョンで上限まで作成し、仮想通貨の発掘を行います。

請求情報の異常値を早期に発見するポイント

Google Cloudコンソールの「お支払い（Billing）」>「レポート」を開きます。

確認すべき項目

グループ条件を「サービス」に設定し、Compute Engineの費用が前日・前週比で急激に跳ね上がっていないか確認する
グループ条件を「リージョン」に設定し、普段利用していない海外リージョン（us-central1, europe-west4, asia-southeast1等）でコストが発生していないか確認する
グループ条件を「SKU」に設定し、高価なGPU（NVIDIA Tesla/A100等）や高コア数CPUの課金が発生していないか確認する

予算アラートの設定状態を確認する

「お支払い」>「予算とアラート」を開き、月次の想定利用額（例: 3,000円、5,000円など）に対して予算アラートが適切に設定されているかを確認します。アラートを設定しておくことで、攻撃者が大量のインスタンスを立ち上げた際、閾値（50%、90%、100%など）を超えた時点でメール通知を受け取り、被害の拡大を早期に食い止めることができます。

7. クラウド基盤側で「確認できること」と「確認できないこと」

調査を進める上で最も重要なのが、Google Cloudの管理コンソール（Cloud Audit Logs等）で「何がわかり、何がわからないのか」という責任共有モデルとログの境界線を正しく理解しておくことです。

【クラウド基盤側（Google Cloud管理プレーン）】
  ◎ 確認できること：
     * VMインスタンスの作成・削除・スペック変更
     * インスタンスやプロジェクトのメタデータ変更（SSH公開鍵の追加）
     * サービスアカウントキーの発行・削除
     * IAMロールの付与・剥奪
     * ファイアウォールルールの作成・変更・パケット通過（FWログ有効時）
     * APIリクエストを実行したGoogleアカウントと接続元IP
  =============================================================
  × 確認できないこと（境界線）：
     * SSHログインに成功した後のLinux内部でのコマンド実行
     * OS内で作成・改ざんされたファイルやWebシェル
     * OS内部で常駐・実行されている不審なプロセス
     * OS内のローカルユーザー作成（useradd等）
     * NginxやApacheなどのWebサーバーに対するHTTPリクエスト詳細
【OS・ゲスト環境側（Linuxデータプレーン）】

Google Cloudの監査ログは、あくまで「Google CloudのAPIに対する操作」を記録するものです。

たとえば、インスタンスのメタデータにSSHキーが追加されたことはCloud Audit Logsで確実に記録されます。しかし、そのSSHキーを使って攻撃者がLinuxにログインした後、どのようなコマンドを実行し、どのファイルを改ざんしたかは、Google Cloudコンソール上からは一切わかりません。

したがって、クラウド基盤側の調査で不審な操作や設定変更が確認された場合、あるいはインスタンスのCPU負荷が異常に高い場合は、必ずインスタンス内部（Linux OS）に直接ログインし、OSレベルのログやプロセス、ファイル改ざんを詳細に調査する作業が不可欠となります。

よくある質問（FAQ）

Q1：無料枠の範囲内でもCloud Audit Logsを使った調査はできますか？

はい、十分可能です。不正アクセスの調査で最も重要となる「管理アクティビティ（Admin Activity）監査ログ」および「システムイベント監査ログ」は、Google Cloudによって無料で提供されており、保持期間も400日間と非常に長いため、追加費用なしで過去の操作履歴を網羅的に検索できます。ただし、データアクセスログやVPCファイアウォールログは有料となるため、必要な期間やリソースを絞って利用することをおすすめします。

Q2：GCEインスタンスにSSH接続されたこと自体は監査ログに残りますか？

接続方法によって異なります。OS LoginやIdentity-Aware Proxy（IAP）を経由してSSH接続した場合は、Google CloudのAPIを経由するため接続ログが記録されます。一方、インスタンスのパブリックIPのポート22に直接SSH接続した場合、Google Cloudの管理プレーンを経由しないため、Cloud Audit Logsには接続の成否や実行内容は記録されません。この場合は、OS内部の /var/log/auth.log や journalctl -u ssh を調査する必要があります。

Q3：身に覚えのないサービスアカウントキーが見つかった場合はどうすればよいですか？

直ちに該当のキーを無効化または削除してください。コンソールの「IAMと管理」>「サービスアカウント」を開き、対象のサービスアカウントを選択して「キー」タブから該当のキーを削除します。また、そのキーが悪用されて他のリソース（Cloud Storageバケットの読み取りやCompute Engineの操作など）が操作されていないか、キーが作成された日時以降の監査ログを追跡して被害状況を確認してください。

Q4：OS Loginを有効にしていればメタデータへのSSHキー追加は無力化できますか？

はい、無力化できます。プロジェクトまたはインスタンスでOS Login（enable-oslogin=TRUE）を有効に設定している場合、Compute Engineはメタデータ内の ssh-keys を無視し、IAMの権限（roles/compute.osLogin または roles/compute.osAdminLogin）とGoogleアカウントに紐付く鍵情報だけで認証を行います。攻撃者がメタデータに鍵を追加してバックドアを作ろうとしてもログインできないため、非常に有効な多層防御策となります。

Q5：ログエクスプローラでクエリを実行しても「0件の結果」になります。正常ですか？

はい、攻撃検知用の監査ログクエリ（インスタンスの不正作成、SSH公開鍵の追加、サービスアカウントキーの作成、IAM権限付与など）において、時間範囲を「過去7日間」や「過去30日間」に広げた上で「0件の結果」となった場合は、該当する不正な管理操作が一切行われていない安全な状態（シロ）を意味します。ただし、画面右上の時間範囲が「直近6分間」など極端に狭くなっていないか、クエリ貼り付け後に青い「クエリを実行」ボタンを押下したかを必ず確認してください。また、VPCファイアウォールログは初期状態で無効化されているため、設定をオンにしていない場合は常に0件となります。

Q6：解説にある「確認すべき重要フィールド」は画面のどこで見られますか？

ログエクスプローラでクエリを実行し、該当するログが1件以上一覧に表示されている状態で確認できます。各ログエントリ行の左端にある「>」（展開アイコン）をクリックするとJSONツリーが開きます。その中の protoPayload をクリックして展開すると、操作者のメールアドレス（authenticationInfo.principalEmail）や接続元IP（requestMetadata.callerIp）、実行メソッド（methodName）などの詳細フィールドが確認できます。なお、検索結果が0件の場合はログ行自体が表示されないため、フィールドも画面上には現れません。