Cloud Logging のログバケットロック解説

はじめに

企業活動において、システムやアプリケーションから生成されるログは、障害調査、セキュリティ監査、利用状況の分析など、多岐にわたる目的で活用される重要な情報資産です。特に、規制遵守や法的要件が厳しい業界においてはログの保持期間という要件が必ずあります。

Cloud Loggingは、Google Cloud上のサービスやアプリケーション、さらにはオンプレミス環境からのログを一元的に収集、保存、分析、アラート通知するためのフルマネージドサービスです。その中でもログバケットは、収集したログを効率的に管理・保存するための基本的な単位となります。そして、このログバケットに対して「ロック」をかけることで、保存されたログの不変性を保証し、コンプライアンス要件への対応やデータ保護を一層強化できるのです。

今回はCloud Loggingのログバケットについて、他の方法などと比較しながら解説してきます。

概要

Cloud Logging とログバケット

まず、ログバケットロックの話題に入る前に、Cloud Loggingとログバケットの基本的な役割についてです。

Cloud Loggingは、Google Cloudのさまざまなサービスから出力される監査ログやアプリケーションログ、さらにはカスタムログなどを集約し、リアルタイムでのモニタリング、検索、分析、そして長期保存を可能にするサービスです。例えば、Compute Engineインスタンスのシステムログ、Cloud Functionsの実行ログ、Google Kubernetes Engineのコンテナログなどが自動的に収集されます。また、Loggingエージェントを利用することで、オンプレミス環境や他のクラウド環境のサーバーからもログを収集可能です。

そして、これらの収集されたログが保存される場所が「ログバケット」です。このログバケットに格納されているログがCloud Loggingのログエクスプローラに表示されます。
ログバケットは、保持期間やアクセス制御を設定可能です。保持期間は1~3650日の期間で指定でき、デフォルトは30日間です。30日を越えて保存されたログデータは課金対象となります(後述の_Requiredは例外で課金対象外)。

Cloud Loggingには、デフォルトでいくつかのログバケットが用意されています。

• _Required: 主に監査ログが保存され、保持期間は400日固定。変更・削除不可。
• _Default: _Required に格納されないログが格納される。保持期間は30日。削除不可。変更可能。

これらに加えて、ユーザーが特定の目的のために独自にバケットを作成可能です。

ログシンク

ログバケットはログを格納する入れものであり、そこにログを格納するのはログシンクと呼ばれる機能で行ないます。 Google Cloudプロジェクトで発生したログを適切な宛先に転送するサービスです。

宛先は以下がサポートされています。

• Cloud Loggingバケット
• BigQuery
• Pub/Sub
• Cloud Storageバケット
• 他のGoogle Cloudプロジェクト

デフォルトでは以下の2つのシンクが用意されいます。

• _Required: 監査ログを_Requiredログバケットに転送するためのシンク。変更・削除・無効不可。

LOG_ID("cloudaudit.googleapis.com/activity") OR
LOG_ID("externalaudit.googleapis.com/activity") OR
LOG_ID("cloudaudit.googleapis.com/system_event") OR
LOG_ID("externalaudit.googleapis.com/system_event") OR
LOG_ID("cloudaudit.googleapis.com/access_transparency") OR
LOG_ID("externalaudit.googleapis.com/access_transparency")

• _Default: 監査ログ以外を _Defaultログバケットに転送するためのシンク。削除不可。変更・無効可能。

NOT LOG_ID("cloudaudit.googleapis.com/activity") AND
NOT LOG_ID("externalaudit.googleapis.com/activity") AND
NOT LOG_ID("cloudaudit.googleapis.com/system_event") AND
NOT LOG_ID("externalaudit.googleapis.com/system_event") AND
NOT LOG_ID("cloudaudit.googleapis.com/access_transparency") AND
NOT LOG_ID("externalaudit.googleapis.com/access_transparency")

バケットロック

次は本題である「ログバケットロック」です。ログバケットロックとは、その名の通り、ログバケットに対してロックをかけ、保存されているログエントリの不変性を保証するための機能です。一度ロックされたバケット内のログは、 指定された保持期間が終了するまで、いかなるユーザー（たとえプロジェクトのオーナーであっても）も変更したり削除したりできなくなります。

ログエントリの変更や削除が不可能になるため、保持ポリシー（ログをどれくらいの期間保存するかという設定）を、現在設定されている期間よりも短縮できなくなります。さらに、ロックされたログバケット自体を削除できません。ログの不変性を厳格に守ることができるようになります。

ログバケットロックを実際に使ってみる

今回はログバケットを新たに作成しそれにロックをかけていきます。

まずは、適当にログバケットを作成します。

# location は理由がない限りは global がいいです。テストなので期間は短めに設定しています。
gcloud logging buckets create test-bucket --location=global --enable-analytics --retention-days 1

次に先程作ったバケットへのログシンクの設定を行ないます。

# cloud runのrequestsのみを収集するログシンクを作成します。
gcloud logging sinks create test-sink logging.googleapis.com/projects/プロジェクト名/locations/global/buckets/test-bucket --log-filter="log_id(\"run.googleapis.com/requests\")"

そしてようやくバケットロックです。

gcloud logging buckets update test-bucket --location=global --locked

執筆時点ではコンソールからロックをかけられないですが、コンソールからロックがかかっていることは確認できます。

削除できないことも確認できます。

注意事項

執筆のために調査していて気付いた注意事項です。

バケットロックのドキュメントには以下のように書かれています。

更新されないようにバケットをロックすると、バケットの保持ポリシーもロックされます。保持ポリシーがロックされると、バケット内のすべてのログエントリがバケットの保持期間を満了するまでバケットを削除できません。

この文言の場合、そもそもログがなければバケットを削除できるかと思ったのですが、削除できませんでした。というか、保持期間過ぎても削除できなかったので、執筆時点では削除はサポートされていないと考えてよさそうです。

検証するさいにはお気を付けください。

他のGoogle Cloudサービスとの比較

ログの保存というのは他のGoogle Cloudサービスでも可能です。他のサービスでのログ保持について説明してきます。

Cloud Storage との連携

Cloud Loggingのログシンクにより、ログバケットに収集されたログをCloud Storageバケットに定期的にエクスポートできます。特に超長期のアーカイブや他の分析ツールでの利用を目的とする場合に便利です。 そして、Cloud Storageにも保持ポリシーとバケットのロック機能があります。

Cloud Storageバケットロックは、以下のような場合に使用します。

• Cloud Loggingの最大保持期間（現在は10年）を超えるアーカイブが必要な場合。
• ログデータを他のシステムやサードパーティのアーカイブソリューションと連携させたい場合。
• ログデータを異なるストレージクラス（例えば、低頻度アクセス向けのNearline StorageやColdline Storage）に移動させてコストを最適化させたい場合。
• データアクセス監査ログなどをCloud Loggingのログエクスプローラに流したくないけど、ログを保全したい場合。

そのため、アクティブに検索や分析する期間のログはCloud Loggingのバケットで管理し、それ以降のアーカイブ用途のログはCloud Storageにエクスポートしてロックをかける、といった構成はよくあるパターンです。

BigQuery との連携

Cloud Loggingのログは、BigQueryにエクスポートして高度な分析することも一般的です。BigQueryは、ペタバイト規模のデータに対しても高速なSQLクエリを実行できるデータウェアハウスサービスです。

BigQueryではアクセス制御をテーブルだけでなく行や列レベルでも行なえますが、データの不変性を担保できません。あくまで分析用の面が強くコンプライアンス目的のログ保全には不向きです。

各サービスの比較表

サービス	ログの不変性担保(ロック機能)	最大保持期間	分析しやすさ	データ保存料金(2025年06月09日時点)
Cloud Logging ログバケット	○	10年(3650日)	○	＄0.01/GiB
Cloud Storage	○	100年	△	Archive Storageの場合 $0.0025/Gib (Standard の場合 $0.023/Gib)
BigQuery	×	×	◎	$0.02/GiB(物理ストレージ)

運用上の考慮事項とベストプラクティス(by 生成AI)

こういうセクションがあるといいなって思ったので、このセクションは生成AIに生成して頂きました。

ログバケットロックは非常に強力な機能ですが、その不可逆性ゆえに、導入と運用には慎重な計画が求められます。ここでは、効果的かつ安全にログバケットロックを活用するための考慮事項とベストプラクティスをいくつか紹介します。

1. ロックする対象とタイミングを慎重に検討する: 全てのログバケットを無差別にロックする必要はありません。まずは、自社のコンプライアンス要件、セキュリティポリシー、そしてログの重要度を評価し、どのログ（どのバケット）に対してロックが必要なのかを特定しましょう。例えば、監査ログや機密情報へのアクセスログなど、特に保護すべきログを格納する専用のユーザー定義バケットを作成し、それにロックを適用するのが一般的です。_Default バケットにロックをかけることも可能ですが、多種多様なログが集約されるため、保持期間やコストへの影響をより慎重に評価する必要があります。

2. 保持期間の設計は入念に: 前述の通り、ロックされたバケットの保持期間は短縮できません。したがって、ロックを適用する前に、法的要件、業界標準、社内規定などを総合的に考慮し、必要十分な保持期間を設定してください。迷った場合は、少し長めに設定しておく方が安全ですが、それがストレージコストに与える影響も忘れてはいけません。保持期間は、バケット作成時またはロック適用前に設定します。

3. IAM権限の最小化: ログバケットのロック設定 (logging.buckets.update 権限)や、保持ポリシーの変更 (logging.settings.update 権限など)を行えるIAMプリンシパル（ユーザーやサービスアカウント）は、必要最小限に絞り込むべきです。これにより、誤操作や意図しないロック設定のリスクを低減できます。職務分離の原則に従い、ログ管理の責任者とロック設定の権限者を分けることも検討に値します。

4. テスト環境での十分な検証: 本番環境の重要なログバケットにいきなりロックを適用するのではなく、まずはテストプロジェクトや検証用のバケットでロックの挙動、影響範囲、関連する運用手順（ログの検索、エクスポート、アラート設定など）を十分にテストしてください。特に、ロック後の保持期間の変更（延長のみ可能）や、バケット削除が不可能になる点を実際に確認しておくことが重要です。

5. ロック解除ができないことへの対策を理解しておく: ログバケットロックは解除できません。もし、ロックされたバケットの設定（例えば保持期間）がビジネス要件やコンプライアンス要件と乖離してしまい、どうしても変更が必要になった場合、既存のロックを解除するという直接的な手段はありません。考えられる代替策としては、新しい設定で別のログバケットを作成し、今後のログはその新しいバケットにルーティングするようにシンクの設定を変更することです。ただし、この方法では、過去に古いバケットに保存されたログは移動できませんし、古いバケットのロックもそのまま残ります。このような事態を避けるためにも、初期設定が非常に重要になります。

6. ドキュメント化と関係者への周知: どのバケットがロックされており、その保持期間が何日であるか、そしてなぜその設定になっているのかを明確にドキュメント化し、関連するチームメンバー（開発者、運用者、セキュリティ担当者、コンプライアンス担当者など）に周知することが重要です。これにより、誤解に基づく操作ミスを防ぎ、円滑なログ管理運用体制を維持できます。

これらのベストプラクティスを遵守することで、ログバケットロックのメリットを最大限に引き出しつつ、潜在的なリスクを管理できるでしょう。

まとめ

今回は、Google CloudのCloud Loggingが提供するログバケットロック機能について説明しました。

ログバケットロックはCloud Storageへのエクスポートに比べ、とてもお手軽で使いやすい反面、金額面ではCloud StorageのArchiveストレージよりも高くなっています。 基本はCloud Storageでログ保全になりますが、気軽な手段として覚えておいて損はないです。