はじめに

Google Cloudにおける組織やチームで複数のプロジェクトを運用していると、監査ログやアクセスログの管理 が大きな課題になります。
特に、プロジェクトごとに個別でログシンクを設定している場合、といった問題が発生しやすくなります。

• 新しいプロジェクトの追加時に設定が必要
• 管理が分散し、転送漏れや設定ミスのリスクが高まる

本記事では、これらの課題を解決する 「集約ログシンク（Aggregated Log Sink）」 の仕組みと設定手順を解説します。
集約ログシンクを使えば、組織全体のログを一元的に転送・管理 でき、運用負荷を大幅に軽減できます。
本記事は以下のような方を対象としています。

• Google Cloud 環境を複数プロジェクトで運用している管理者・エンジニア
• 監査ログやセキュリティログを中央で管理したい方
• ログ転送設定を自動化・標準化したい方

集約ログシンクの概要

Google Cloud の 集約ログシンク は、組織で作成できるログ転送設定 です。
通常、監査ログなどは各プロジェクトごとにシンクを作成し、共通基盤プロジェクトへ転送する方法が一般的です。
しかしこの方法では、新しいプロジェクトを作成するたびにログ転送の設定が必要となり、運用の手間や管理コストが増大するという課題があります。
一方、集約ログシンクを利用すれば、組織配下のすべてのプロジェクトのログを一括で転送できるため、こうした手間や管理コストを大幅に削減できます。

Google Cloud コンソールでの設定手順

①共通基盤プロジェクト内にログシンク先のバケットを事前に作成しておく
※手順は割愛します。

②組織を選択
リソース管理で 組織 を指定。

③ログシンクを作成
「ロギング」の「ログルーター」から「シンクを作成」を選択

④シンクの宛先設定

• 「シンクの宛先」として「Cloud Storage バケット」 を選択
• 「Cloud Storage バケット」でプロジェクトのCloud Storage バケットを使用する」を選択
• シンクの宛先の末尾に設定されている「[BUCKET_ID]」を①で作成した共通基盤プロジェクトに作成したバケット名（ここではreq-bucket）に変更

⑤シンクに含めるログの選択の設定
「このorganizationおよびすべての子リソースにより取り込まれたログを含める」を選択

⑥包含フィルタの設定
ログシンクする対象に応じたログのフィルタを設定

補足：今回の例ではLogging「_Required」バケットのログをフィルタしています。
　　　以下の通り、デフォルトで設定されている「_Required」の包含フィルタをコピーしています。

⑦「シンクを作成」
以下のようなエラーを確認します。
次の手順でこのサービスアカウントに権限を追加するので、アカウント名を控えておいてください。

⑧共通基盤プロジェクトのIAMにサービスアカウントが作成されているため、Cloud Storageへの書き込み権限を付与する
該当のサービスアカウントのロールに「Storageオブジェクト作成者」を追加

⑨共通基盤プロジェクトのCloud Storageにログが転送されていることを確認
Cloud Storageにて以下の確認を行う

• 「req-bucket」配下に転送されたログに基づくフォルダ階層が自動で作成されていること
• 最下層のフォルダの日付をクリックし、ログが転送されていることが確認できること

【自動で作成される階層の補足】
req-bucket
　階層のトップにはバケット名が入ります。
log_type
　ログの種別のタイプが入ります。
　例：cloudaudit.googleapis.com/activity、cloudaudit.googleapis.com/system_event など
Service
　ログの種別のサービスが入ります。
　例：cloudaudit.googleapis.com/activity、cloudaudit.googleapis.com/system_event など
year/month/day
　ログエントリのタイムスタンプをもとに年/月/日で階層が作られます。

まとめ

本記事では、Google Cloud の 集約ログシンクを活用し、組織全体の監査ログを効率的に一元管理する方法 を紹介しました。
改めまして、以下の点を理解いただき、運用に役立てていただければ幸いです。

• 集約ログシンクを利用することで、組織配下のすべてのプロジェクトのログを一括転送可能
• プロジェクトごとにシンクを個別作成する必要がなく、運用負荷と管理コストを大幅に削減
• 組織・フォルダ・プロジェクトといった階層構造に応じて柔軟に設定でき、将来的な拡張にも対応しやすい
• 新規プロジェクト作成時の設定漏れ防止や、監査対応の統一化に効果的