Google Cloudの監査ログ一元化に向けた取り組み

こちらは ANDPAD Advent Calendar 2025 の16日目の記事です。

こんにちは、アンドパッドセキュリティチームの和田です。昨日の宜野座に引き続きセキュリティチームからの投稿になります。

ANDPADにおけるGoogle Cloud利用と課題
- 直面した課題：プロジェクト増加に伴うログ管理の複雑化
フォルダ階層構造と集約シンクの活用
まとめ
おわりに

今回はアンドパッドセキュリティチームが取り組んでいるクラウドセキュリティの中から、Google Cloudに関するログ管理の取り組みについて、「組織構造を活用した監査ログの一元化」をテーマにお話しできればと思います。

ANDPADにおけるGoogle Cloud利用と課題

過去の記事でも触れていますが、ANDPADではサービス提供を行うIaaS基盤として、AWSに加えてGoogle Cloudを利用しています。

ANDPADのAI機能である「豆図 AI キャプチャー機能」を始めとした様々なML Productをお客様に提供するための実行基盤として、Google Cloudのマネージドサービス（Vertex AI endpointなど）を積極的に活用しています。

直面した課題：プロジェクト増加に伴うログ管理の複雑化

AI/ML開発においては、PoCや本番環境など用途ごとにGoogle Cloudプロジェクトが頻繁に作成されます。

セキュリティチームとして、「誰がいつ何をしたか」を追跡するための監査ログ（Cloud Audit Logs）の保全が必要となりますが、以下の課題がありました。

設定漏れのリスク: プロジェクトが作成されるたびに、個別にログエクスポート設定を入れるのは運用負荷が高く、設定漏れのリスクがありました。
ログ分散による探索性の低下: 各プロジェクト内にログが留まると、特定のユーザが複数プロジェクトにまたがって何をしたかなどの横断的な調査が困難でした。

セキュリティチームではこの課題を解決するために、プロジェクト個別の設定に依存せず、Google Cloudの階層構造を利用して自動的にログを集約する構成を採用しました。

フォルダ階層構造と集約シンクの活用

Google Cloudのリソース管理は、ファイルシステムのディレクトリ構造に似た階層構造を持っています。具体的には、上から順に以下のようになっています。

リソース単位	概要
`Organization` (組織)	ルートノードにあたります。会社全体のリソースを一括管理する最上位の単位です。
`Folder` (フォルダ)	Organizationの下で、部門やチーム、環境（本番・開発など）ごとにリソースをグルーピングするための階層です。フォルダはさらに入れ子構造にすることも可能です。
`Project` (プロジェクト)	実際にVMやデータベースなどのリソースが作成される場所です。課金や権限管理の基本単位となります。

階層構造の特徴として、「上位のポリシーが下位に継承される」という点があります。

Projectごとに個別にセキュリティ設定するのではなく、上位のFolderやOrganizationレベルでポリシー（IAM権限やログ設定など）を適用することで、配下にある数十のプロジェクトに対して一貫したガバナンスを効かせることが可能になります。

今回はこの特徴を活かして、Folderレベルでログをインターセプトし、セキュリティ専用のプロジェクトへ転送する仕組みを構築しました。

全体アーキテクチャ

構成の概要は以下の通りです。

構成	概要
監査ログ集約用フォルダ	監視対象としたいプロダクトのプロジェクトをそれぞれの用途に応じたフォルダ配下に配置
集約シンク（Aggregated Sink）	各フォルダレベルでシンクを設定し、配下の全プロジェクトのログを取得
ログ集約バケット	セキュリティチームのみがアクセス可能なプロジェクトにLogging Bucketを用意し転送

この構成により、監査ログ集約用フォルダで監査ログ（データアクセス監査ログ）を有効化しておくことで、用途に応じたフォルダ内にプロジェクトを作成した段階で、監査ログの自動取得及び保全に必要な期間の監査ログ保管が開始されます。

またログ集約バケットを対象に各プロジェクトで共通で必要となるアクティビティ監視・セキュリティ監視の設定を行っているため、アクティビティ監視対象として追加されます。

アーキテクチャ変更による効果

この構成に変更したことで、以下のメリットを得られました。

スケーラビリティの確保

新しいプロジェクトを作成する場合でも、指定のフォルダ配下に作成するだけで監査ログ設定や共通で必要となるアクティビティ監視の設定が完了するため、セキュリティチームの作業ブロッカーがなくなりました。

保全性の向上

プロジェクトオーナーの権限では上位フォルダのシンク設定を変更できないため、ログの改ざんや停止を防ぐことができます。

調査の迅速化

全プロジェクトのログが1箇所のバケットに集まっているため、インシデント調査時にログエクスプローラ / BigQueryで横断検索が容易になりました。

またフォルダ階層構造の整理により、当初目的であった監査ログの保全以外にも副次的な効果がいくつかありました。

ログ保管コストの最適化

プロジェクトごとにログを保管・管理する場合、各所でストレージ料金が発生し、その総額が見えにくくなりがちです。また長期保管のために個別にエクスポート設定すると設定漏れも起きやすくなります。

今回ログを集約バケットに一元化したことで、監査ログは集約先に転送されるため、各プロジェクト側の _Default シンクでは除外設定することで、重複した保管コストを削減できました。

フォルダ単位のIAM管理による定常作業の削減

リソース階層を導入したことで権限管理（IAM）も楽になりました。

これまではプロジェクト作成のたびに権限付与が必要な場合がありましたが、現在は共通権限が必要なメンバーについてはFolderに対して権限を付与しています。

これにより、配下に新しいプロジェクトが作成されると自動的に権限が継承されるため、権限設定の定常作業を削減することができました。

実装の注意点

集約シンクは便利な機能ですが、データアクセス監査ログの扱いには注意が必要です。

アクティビティログは通常API呼び出し回数が人間による操作やデプロイ回数に依存するため、容量はそれほど大きくなりません。

一方、データアクセス監査ログは、Cloud Storageのオブジェクト読み取りやBigQueryのクエリ実行など、データの読み書きそのものを記録します。これを全てログとして残すとログの容量が爆発的に増加し、集約先バケットのストレージコストが高騰するリスクがあります。

意図しないコスト超過を防ぐため、技術的な実装とセットで以下のようなコスト管理のガードレールを設定することを強く推奨します。

Budget Alertの設定で集約先のログバケットで予算を設定し、想定よりもコストがかかっている場合に通知が飛ぶようにする（監査ログは特性上、保存期間に応じて徐々にコストが上がる傾向にあるため、定期的な見直しが必要）
除外フィルタの設定で、不要なログ（e.g. Datadog Agentの定期的なアクセスなど）を除外する

また集約シンクによるログのインターセプトにより、フォルダ以下のプロジェクトではデータアクセス監査ログは収集されなくなります。

そのため、プロジェクト個別でBigQueryのデータアクセス監査ログを用いた分析を行う場合は個別に除外フィルタの設定を行い、プロジェクトにログを収集したうえで、プロジェクトからログ集約バケットにログルーティングするなど工夫が必要です。

まとめ

今回はGoogle Cloudの「組織構造を活用した監査ログの一元化」について、フォルダ構成と集約シンクを活用した事例を紹介しました。

マルチクラウド環境におけるセキュリティは複雑になりがちですが、各クラウドプロバイダーのネイティブな機能をうまく活用することで、運用負荷を下げつつガバナンスを効かせることができると考えますので、参考になりましたら幸いです。

おわりに

アンドパッドのセキュリティチームでは単にセキュリティルールを策定して守らせるだけではなく、Terraformを用いたIaCでの実装やGoogle CloudのOrganization設計といったアーキテクチャの根幹に関わり、開発者が意識しなくても、自然とセキュアになるようなガードレールをエンジニアリングの力で構築しています。

現在はAWSに加えてGoogle Cloud上でのプロダクト開発が加速しており、マルチクラウド環境における高度なセキュリティ設計が求められる非常にやりがいのあるフェーズです！