gcloud logging read を使用して cloudaudit.googleapis.com にフィルタリングを行うか、Logs Explorer で同じクエリを実行し、結果を JSON としてダウンロードします。
gcloud logging read 'logName:"cloudaudit.googleapis.com" AND timestamp>="2026-10-19T00:00:00Z" AND timestamp<"2026-10-20T00:00:00Z"'
--project=my-project --format=json > gcp_audit_1019.json
管理アクティビティ監査ログは常にオンで、400日間保持されます。データアクセスログはデフォルトでオフですが、BigQuery を除いて有効化されると30日間保持されます。
Cloud Audit Logs は、Google Cloud プロジェクトで誰が何を変更したかを記録します:IAM の付与、新しいサービスアカウントキー、ファイアウォールの変更、異常な地域での VM の起動。Prime Core には Google Cloud 監査ログのための 140 の検出ルールがあり、74 の MITRE ATT&CK 技法にマッピングされています。その中には、クラウドアカウントの悪用 (T1078.004) や、新しいサービスアカウントキーなどの余分な資格情報 (T1098.001) 、およびログ自体の改ざん (T1562.008) が含まれます。
始める前に
必要な監査ログを知っておいてください。
| タイプ | デフォルトでオンか? | 保持期間 | 内容 |
|---|---|---|---|
| 管理アクティビティ | 常にオン、無効化不可 | 400日 | 設定と IAM の変更 |
| システムイベント | 常にオン | 400日 | Google システムがリソース上で行った操作 |
| データアクセス | いいえ (BigQuery を除く) | 30日 | データおよびメタデータの読み取り |
| ポリシーによる拒否 | Yes | 30日 | セキュリティポリシーによってブロックされたリクエスト |
「このバケットを誰が読んだのか?」が質問であり、データアクセスログが有効化されたことがない場合、Cloud Logging には答えがありません。
権限。 Logs Viewer (roles/logging.viewer) では管理アクティビティ、システムイベント、ポリシーによる拒否がカバーされています。データアクセスログにはプライベートログビューア (roles/logging.privateLogViewer) が必要です。
スコープ。 監査ログはプロジェクトごとに存在します。組織およびフォルダーレベルのアクティビティは独自のログがあります。–organization=<ORG_ID> または –folder=<FOLDER_ID> を使用してクエリを実行します。
オプション1: Logs Explorer
コンソールを開き Logging → Logs Explorerに移動し、logName:”cloudaudit.googleapis.com” を入力し、時間範囲を設定してクエリを実行し、結果を JSON としてダウンロードします。ダウンロードには制限があります。大きな範囲の場合、gcloud を使用してください。
オプション2: gcloud logging read
上記のコマンドが基本形式です。3つの詳細が時間を節約します。
必ずフィルタに時間範囲を入れること。 タイムスタンプの条件なしでは、gcloud logging read は黙って自身を最終日のみに制限します (デフォルトの –freshness は 1d)。それはほとんどの人を驚かせます。
必要に応じて制限を引き上げる。 大きなウィンドウの場合、–limit=100000 (または適切な値) を追加します。
アップロード用に平坦化。 出力は 1 つの JSON 配列です。それを 1 行ごとに 1 つのエントリーに変換します:
jq -c '.[]' gcp_audit_1019.json > gcp_audit_1019.jsonl
狭めたフィルターが役立つ場合:
# 管理アクティビティのみ
logName="projects/my-project/logs/cloudaudit.googleapis.com/activity"
# 新しいサービスアカウントキー
protoPayload.methodName="google.iam.admin.v1.CreateServiceAccountKey"
# 単一のアイデンティティが行ったすべての操作
protoPayload.authenticationInfo.principalEmail="suspicious-sa@my-project.iam.gserviceaccount.com"
オプション3: シンクからの大量履歴
組織が監査ログをシンクを通じて Cloud Storage または BigQuery にルーティングする場合、そのコピーは上記のバケットよりも後に行く可能性があります。gcloud storage cp を使用してファイルを引き出すか、BigQuery をクエリして結果を JSON としてエクスポートします。
注目すべきこと
| メソッドまたはフィールド | なぜ重要なのか |
|---|---|
| CreateServiceAccountKey | 攻撃者が取り去ることができる長期的な認証情報 |
| SetIamPolicy | ロール付与; 特に roles/owner、roles/editor、allUsers に注意 |
| UpdateSink、DeleteSink、新しい除外 | 誰かがログをリダイレクトまたは静かなものとしている |
| 通常ではない地域での v1.compute.instances.insert | 古典的な暗号通貨マイニングの足跡 |
| ステータスコード 7 (PERMISSION_DENIED) によるバースト | 何ができるかを試す盗まれた認証情報 |
LogTotal でのアップロード、消毒、レビュー
- アップロード。 開く logtotal.com に .jsonl ファイルをドラッグ。
- 消毒。 [what gets masked: principal emails, project IDs, IPs, resource names]. Look it over before you continue.
- レビュー。
うまくいかないとき
| 症状 | 可能性のある原因 | Fix |
|---|---|---|
| 直近の 24 時間だけ戻ってくる | フィルタにタイムスタンプが含まれていないので、–freshness=1d が適用されている | フィルタにウィンドウを入れる |
| データアクセスのエントリーがない | データアクセスログが一度も有効化されていない | 予想通り。それらを将来的に有効にする |
| ログ読み取りで PERMISSION_DENIED | データアクセス用のプライベートログビューアが欠けている | roles/logging.privateLogViewer を要求する |
| 結果が途切れる | デフォルトまたは明示的な –limit に到達した | –limit を引き上げるか、ウィンドウを分割する |
| 組織レベルの変更が見つからない | プロジェクトをクエリした | –organization を使用する |
FAQ
Google Workspace のログはここにありますか?
組織が Google Cloud と Workspace データを共有している場合、そしてその場合は組織レベルでのみ。
GKE についてはどうですか?
GKE の Kubernetes 監査ログも Cloud Audit Logs に書き込みます。