集約ログに対して、ログベースのアラートを設定してみる
こんにちは、すらぼです。今回は Google Cloud の組織集約ログに対して、ログベースのアラートを設定する方法を試してみました。ただ、その中でうまくいく方法/うまくいかない方法があったので、紹介します。
はじめに
複数の Google Cloud プロジェクトを横断して管理する組織では、セキュリティ監視の観点からログの一元管理が重要になります。ただ、その中で集約したログに対して「ログベースのアラート」を設定したいケースがあります。
例えば、以下のようなケースです。
- 組織全体で、強力な権限（オーナーや管理者ロール）が付与されたときに通知を受け取る
- 複数プロジェクトにまたがるシステムのログを横断的に監視したい
これらのケースでは、組織やフォルダレベルでの集約ログに対するアラート設定が有効な手段となります。
ただ、集約シンクの転送先の設定によってはアラートが正常に発火しないパターンがあったため、うまくいく/うまくいかないパターンをそれぞれ紹介していきます。
やりたいこと
今回は「集約ログプロジェクトで、集約したログに対してログベースのアラートを設定する」を実現します。
実装のイメージとポイント
まず結論として、うまくいくパターンの実装は以下のとおりです。
- ログ集約用のプロジェクトを作成する
- 集約シンクの転送先を「プロジェクト」に設定する
- 転送先のプロジェクトで、バケットに保存する再転送シンクを作成する
- 転送先のプロジェクトでログベースのアラートを設定する
このとき、『2. 集約シンクの転送先を「プロジェクト」に設定する』と『3. 転送先のプロジェクトで、バケットに保存する再転送シンクを作成する』がポイントです。
この部分について、少し解説します。
うまくいかない方法
まず、集約シンクの転送先として「バケット」（ログバケット）に直接設定するケースが多々あると思います。
しかし、ログバケットを転送先に設定すると、転送先プロジェクトではログベースのアラートが発火しません。
うまくいかないパターン: ログバケットに直接転送する
転送先を「バケット」にした場合、ログはそのバケットに保存されますが、転送先プロジェクトではこのログが監視対象として認識されません。そのため、ログベースのアラートが機能しない状態になります。
うまくいく方法
以下の2点を押さえることで、集約先のプロジェクトでログベースのアラートが正常に発火するようになります。
- 集約シンクの転送先を「バケット」ではなく「プロジェクト」に設定すること
- 転送先のプロジェクトで、集約用のバケットへ再転送するシンクを作成すること
うまくいくパターン: 転送先をプロジェクトに指定し、転送先プロジェクトで再ルーティングする
集約シンクの転送先を「プロジェクト」にし、転送されたログが転送先プロジェクトのバケットに再ルーティングすることでプロジェクトのログとして認識されます。この状態でログベースのアラートを設定することで、組織全体のログに対してアラートを発火させることができます。
なぜプロジェクトでうまくいくのか
ログベースのアラートが発火するには、公式ドキュメントに以下の条件が明記されています。
ログベースのアラート ポリシーはプロジェクトで定義され、次の条件に該当する場合にログエントリをスキャンします。
（中略）
- ログエントリの発生元プロジェクトのシンク、またはログエントリのルーティング先プロジェクトのシンクにより、ログエントリがログバケットにルーティングされる。
たとえば、プロジェクト A でログエントリが発生したとします。プロジェクト A のログシンクによってログエントリがログバケットにルーティングされると、プロジェクト A で定義されたログベースのアラート ポリシーでログエントリがスキャンされます。
2 つ目の例として、プロジェクト X でログエントリが発生し、プロジェクト X のログシンクによってログエントリがプロジェクト Y にルーティングされたとします。プロジェクト Y のシンクによってログエントリがログバケットにルーティングされると、プロジェクト X とプロジェクト Y で定義されたログベースのアラート ポリシーでログエントリがスキャンされます。https://docs.cloud.google.com/logging/docs/alerting/monitoring-logs?hl=ja#lba
シンプルに言えば、「ログをルーティングしたとき」にログエントリがアラートポリシーによってスキャンされると言えそうです。
つまり、 「集約プロジェクト内でログをルーティングする」 ということが、集約プロジェクトで全てのログに対してログベースのアラートポリシーを作るために満たすべき条件になります。
また、ログの転送に関する条件として、公式ドキュメントには次の表記があります。
Google Cloud プロジェクト
宛先プロジェクトのログシンクでログエントリを再ルーティングする場合、またはインターセプト集約シンクを作成した場合は、この宛先を選択します。シンクの宛先であるプロジェクトのログシンクは、プロジェクトを除くサポートされている任意の宛先にログエントリを再ルーティングできます。
注: ログエントリが再ルーティングされる宛先は、このタイプのみです。
https://docs.cloud.google.com/logging/docs/routing/overview?hl=ja#destinations
前述の「集約プロジェクト内でログをルーティングする」という条件を満たすには、宛先のプロジェクトで再度ログルーターを通す必要があります。
公式ドキュメントの記述から、この条件を満たすことができる宛先タイプは Google Cloud プロジェクト のみ であるため、宛先は Google Cloud プロジェクトにする必要があります。
以上の理由から、2つの条件を満たす実装は以下のような形になります。
- 集約シンクの転送先を「バケット」ではなく「プロジェクト」に設定すること
- 転送先のプロジェクトで、集約用のバケットへ再転送するシンクを作成すること
実際にやってみる
実際の画面を確認しながら手順を紹介します。
集約シンクを作る
まず、組織レベルで集約シンクを作成します。
転送先のタイプは「ログバケット」ではなく「プロジェクト」を選択し、ログ集約プロジェクトを指定することに注意してください。
組織レベルでは「Google Cloud プロジェクト」を指定する
プロジェクト側でシンクを作る
次に、ログ集約プロジェクト内でシンクを作成し、ログバケットへの再転送を設定します。
ログ集約プロジェクトでは「Logging バケット」を指定する
ログベースのアラートを作る
最後に、ログ集約プロジェクトで ログベースのアラートを設定します。ここで設定したフィルタに合致するログが転送されてきた際にアラートが発火します。
また、全てのプロジェクトが1つのアラートで検知されるため、アラートの Extract log labels 機能を利用して、プロジェクトIDをラベルに適用しておきます。
Display name: project_id
Log field name: resource.labels.project_id
動作確認
動作確認として、実際にアラートが発火するログを発行させてみました。今回はアラートの通知先にメールを設定したので、アラートが発火すると以下のようなメールが届きます。
画像の Project で記載されているのがアラートを設定したプロジェクトになります。
また、project_id の横に記載されているのが、 Extract log labels によって抽出されたラベルになります。アラートを設定したプロジェクトではなく、 ログが発生したプロジェクト がここに表示されています。
以上で、実際に他のプロジェクトからのログに対するログベースのアラートを設定することができました。
まとめ
本記事では、Google Cloud の組織集約ログに対してログベースのアラートを設定する方法をご紹介しました。
ログベースのアラートを集約プロジェクトで設定することは比較的よくあるユースケースかと思います。ただ、自分がいざ実装しようとしたとき、転送先を単純にバケットに設定してしまうと発火しないという制限事項により、かなりハマってしまいました。ログ周りは思ったより奥が深いですね…。
この記事が誰かの助けになれば幸いです。以上、すらぼでした。
参考資料
