investigating-gcp-incidents

GCP インシデントの調査

GCP の調査がどこまで完全になるかは、インシデント発生前にどの監査ログが有効化されていたかで決まります。最も深刻な誤りは、実際には「そのログカテゴリが一度も有効化されていなかった」のに、空のクエリ結果を「何も起きなかった」と解釈することです。まず可視性を確保し、その後で結論を出してください。

GCP の監査モデルは AWS とも Azure とも異なります。常に有効なカテゴリが 2 つ、ほとんどの場合無効なカテゴリが 2 つあり、その違いを把握しているかどうかで、範囲を定めた調査になるか、誤った問題なしの判断になるかが決まります。

使用する場面

• GCP プロジェクトまたは組織で侵害が疑われる場合の対応
• 漏えいまたは悪用されたサービスアカウントキーの調査
• Security Command Center、Event Threat Detection、または Chronicle のアラートの調査
• プロジェクトをまたいだプリンシパルのアクティビティの再構成
• 権限昇格が疑われる事案の後に、IAM ポリシーやリソースの変更範囲を特定する

使用しない場面

• インシデントが AWS で発生している場合 — investigating-aws-incidents を使用してください。Azure または Microsoft 365 / Entra の場合は、investigating-azure-incidents または investigating-m365-entra を使用してください
• GCP を調査するのではなく攻撃する場合 — exploiting-cloud-platforms を使用してください
• GKE クラスターの侵害に特化した場合 — まずここでクラウドプレーンの 観点から調査し、その後 defending-kubernetes を使用してクラスター プレーンを調査してください
• アラートがそもそもインシデントかどうかを判断する場合 — 先に triaging-security-alerts を使用してください

結論を出す前に可視性を確保する

GCP Cloud Audit Logs には 4 つのストリームがあり、デフォルト設定がすべてを左右します。

ストリーム	デフォルト	無効化できるか	記録される内容
Admin Activity	常に有効	いいえ — Logging API が無効でも書き込まれます	設定とメタデータの書き込み：IAM の変更、リソースの作成／削除
System Event	常に有効	いいえ	リソースに対して Google が開始したアクション
Data Access	無効（BigQuery を除く）	はい	読み取りとデータプレーンへのアクセス — 誰がバケット、シークレット、データセットを読み取ったか
Policy Denied	有効	いいえ（ストレージから除外することは可能）	ポリシーによって拒否されたアクセス — VPC-SC、組織ポリシー

必ず理解しておくべきことは、BigQuery 以外では Data Access ロギングがデフォルトで無効になっていることです。そのため、「攻撃者はシークレットを読み取ったか／バケットをダウンロードしたか／データセットを持ち出したか」という問いには、通常、Data Access ロギングが事前に有効化されていない限り、ログからは答えられません。「データの持ち出しは発生しなかった」と報告してはいけません。「Data Access ロギングが有効化されていなかったため、読み取りアクティビティを確認することも否定することもできません」と報告してください。これは異なる調査結果であり、正直な報告は一方だけです。

ストリームごとに保持期間も異なります。Admin Activity と System Event は _Required バケットに保存され、保持期間は 400 日で、変更できません。Data Access と Policy Denied は _Default に保存され、誰かが保持期間を延長したり、シンクでより長期のストレージに転送したりしていない限り、30 日間保持されます。履歴が存在すると決めつける前に、保持期間を確認してください。

# What audit config is actually in effect at the org / project level
gcloud organizations get-iam-policy ORG_ID --format=json | jq '.auditConfigs'
gcloud projects get-iam-policy PROJECT_ID --format=json | jq '.auditConfigs'

アクティビティの再構成

# Everything a principal did (Admin Activity is always present)
gcloud logging read \
  'protoPayload.authenticationInfo.principalEmail="[email protected]"' \
  --project=PROJECT_ID --freshness=30d --format=json

# IAM policy changes — the escalation signal
gcloud logging read \
  'protoPayload.methodName:"SetIamPolicy"' --freshness=30d --format=json

# Service-account key creation — persistence
gcloud logging read \
  'protoPayload.methodName="google.iam.admin.v1.CreateServiceAccountKey"' \
  --freshness=30d --format=json

メソッド名だけでなく、リクエストのフィールドを確認してください。authenticationInfo にはプリンシパルが含まれ、特に重要なのは、呼び出しがサービスアカウントへのなりすましを通じて、そのアカウントとして行われたかどうかです。requestMetadata.callerIp と callerSuppliedUserAgent から送信元を特定できます。サービスアカウント上で、予期しない ASN からの gcloud ユーザーエージェントが確認された場合は、強いシグナルです。

サービスアカウントと OAuth の悪用

サービスアカウントは永続的な認証情報を保持し、日常的に過剰な権限を付与されているため、ほとんどの GCP インシデントの中心となります。

• 偽装チェーン。 iam.serviceAccounts.getAccessToken と ...signJwt／...signBlob を使うと、あるプリンシパルが別のプリンシパルとして動作できます。チェーンをたどり、 誰が何を偽装したのか、終端の ID が起点より多くの権限を持っているかを確認してください。これは GCP における主要なラテラルムーブメントおよび権限昇格の手段です。
• 鍵の作成は永続化につながります。ユーザー管理の鍵は、パスワードのリセットや MFA の変更後も有効です。インシデント期間中に特権 SA に対して行われた CreateServiceAccountKey は、すべて調査結果として扱ってください。
• OAuth の付与と Workspace の境界。 ドメイン全体の委任を許可すると、GCP サービスアカウントが Google Workspace 全体で動作できるようになります。これにより、investigating-m365-entra のような ID 領域に踏み込むことになり、純粋な GCP の視点では見落としやすい点です。

Security Command Center を確認し、ゼロからやり直さない

Security Command Center が有効になっている場合、Event Threat Detection がすでにこれらの一部を関連付けている可能性があります。異常な IAM 権限の付与、サービスアカウントキーの悪用、データ流出のパターンが調査結果として表示されます。まず SCC の調査結果からタイムラインを作成し、それだけを信用せず、生の監査ログと照合してください。Standard ティアの SCC は Premium／Enterprise より機能が大幅に限られています。検知されているはずだと決めつける前に、どのティアがライセンスされているか確認してください。

退けるべき合理化

• 「ログにデータアクセスがないので、データは流出していません。」 データアクセスのログ記録はデフォルトでオフです。ログがないのは、ログ記録がないということであり、アクセスがなかったということではありません。可視性の不足を報告してください。
• 「その期間の Admin Activity が空なので、アカウントはアイドル状態でした。」 プリンシパルの表記とプロジェクトを確認してください。アクティビティは、触れられたリソースがあるプロジェクトに記録されます。それは、現在クエリしているプロジェクトとは限りません。
• 「たかだか30日前のことです。」 それは _Default バケットの場合です。Admin Activity の保持期間は400日です。該当する操作が IAM またはリソースの変更であれば、履歴は想定より長く残っています。
• 「サービスアカウントが呼び出したのだから、正規の自動化です。」 サービスアカウントは、まさに攻撃者が偽装する対象です。呼び出しが getAccessToken／偽装経由か、どのソースから行われたかを確認してください。
• 「SCC が検知しなかったのだから、起きていません。」 Standard ティアの SCC が検知するのは Premium の検知内容の一部にすぎず、データアクセスに依存する検知にはログの有効化が必要です。SCC が静かでも、問題がないとは限りません。

外部ソースを読む

公開されている勧告、仕様、ベンダーレポートを Markdown として取得します。

curl -sL "https://defuddle.md/<url>"      # scheme in the path is optional

これにより、ページの定型部分が取り除かれ、文章中心のページではトークン数が約78％削減されます。また、要約ではなく全文が返されるため、検索にかけられ、該当内容が見つからなかった場合も信頼できます。

これを使うべきではない場面が3つあります。JSON と API レスポンスは、可読性のための抽出処理で構造化データが壊れるため、生のまま取得してください。認証が必要なページや JavaScript で描画されるページは、匿名で取得されるため、直接取得してください。また、攻撃者のインフラ（フィッシングリンク、C2、マルウェアのホスティング）、クライアント所有のホスト、エンゲージメント URLは、絶対にこの経由で取得しないでください。リクエストがマシンから第三者へ送信され、稼働中の攻撃者インフラの場合は、運用者にこちらの存在を知らせてしまいます。

一部のサイトは抽出ツールをブロックし、ページではなくエラーの文字列を返します。たとえば freedesktop.org からの {"error":"Failed to fetch: 418 I'm a teapot"} です。これは取得が拒否されたことを示しており、ソースがその内容は存在しないと述べているわけではありません。そこから結論を出す前に、URL を直接再取得してください。

参考資料

• investigating-aws-incidents、investigating-azure-incidents — ほか2つのクラウドでも同じ手順を適用します
• defending-kubernetes — インシデントが GKE で発生した場合のクラスタープレーンの視点
• responding-to-incidents — ここで扱う内容の基礎となるインシデント対応全般の枠組み
• hardening-cloud-posture — このスキルで繰り返し問題となる、データアクセスのログ記録を有効にする方法