実践セキュリティ監視基盤構築(11): セキュリティ監視基盤のアーキテクチャ（実装）

この記事はアドベントカレンダー実践セキュリティ監視基盤構築の11日目です。

本日は、これまでの設計の議論に基づき、Google Cloud上でどのようにセキュリティ監視基盤を構築するかを説明します。

アーキテクチャの全体像

アーキテクチャの設計では、ログ収集、ログ変換・取込、アラート検知、アラート対応の4つのプロセスが必要です。これらを統合してセキュリティ監視基盤を構築します。今回は外部サービスからログを取得する前提で構築していますが、組織内のアプリケーションのログも同時に取得したい場合は、適宜拡張可能です。基本的には、ログ収集とログ変換・取込の中間にあるデータレイクのCloud Storageにログを集約し、そこから全体のパイプラインに乗せる形がシンプルでおすすめです。

ログの調査・分析にはBigQueryを利用します。今回の説明では、BigQueryに直接クエリを発行してログの調査・分析を行うことを前提としていますが、BIツールを使ってダッシュボードを作成するなどの活用も考えられます。これも必要に応じて拡張可能です。

外部サービスからはAPIなどでセキュリティ監視基盤からログを取得する部分を実装するログ収集の他に、Cloud StorageやBigQueryへ直接ログを出力する機能を持つ外部サービスとの連携も想定しています。また、外部サービスからのアラートも同様にアラート対応の処理へ投入することを想定しています。外部サービスの連携機能を活用することで、全体の構築コストを抑えることができます。

各コンポーネントの詳細

それでは各コンポーネントの構成について見ていきましょう。

ログ収集

ログ収集は、外部サービスから能動的に取得するプル型のログ取得を想定しています。外部サービスのログ取得APIを定期的に呼び出してログを取得し、Cloud Storageに保存します。ログ取得のためのAPI呼び出しはCloud Run Jobを利用します。Cloud Runはサーバレスでスケーラブルなコンテナ実行環境であり、外部サービスのAPI呼び出しを定期的に行うためのジョブを実行するのに適しています。Google CloudではCloud Functionsも提供されていますが、ログ変換・取込の部分でCloud Runが必要となるため、一貫性を持たせるためにCloud Runを利用することにしました。これは実装する際の要件に合わせて適宜変更可能です。

具体的なログ取得の実装は後述しますが、このコンポーネントの特徴として外部サービスごとに異なるログ取得APIを呼び出す必要があります。APIによる取得はサービスごとにフォーマットやスキーマが異なるだけでなく、ログ到着までの保証時間やログの量も異なります。そのため、サービスごとにロジックを完全に分離し、呼び出しのタイミングも分ける必要があります。

この図ではCloud Run Jobの呼び出しにCloud Scheduler + Workflowsを使っていますが、これはCloud Runの呼び出しタイミングと呼び出し時のパラメータを個別に設定できるようにするためです。Cloud Schedulerが実行時タイミングを制御し、WorkflowsがCloud Run Jobの呼び出しパラメータを制御します。Cloud Run Jobに実装されたプログラムをパラメータによって取得するサービスを切り替えることで、柔軟にログ取得のロジックを変更できるようになります。

代替手段としては、取得する対象サービスの種類ごとにプログラムを作成しCloud Run Jobでデプロイする方法もあります。この場合はWorkflowsが不要となり、Cloud Schedulerで直接Cloud Run Jobを呼び出すことになります。構成としてはそちらの方がシンプルですが、管理するプログラムが増えてメンテナンスの手間が増えてしまうため、今回は一つのプログラムで複数のサービスを取得できるように設計しました。

ログ収集の実装のコツは、Cloud Storageにデータを保存する際にログのフォーマットを整えるなどの余計なことを一切しないことです。このコンポーネントの責務はログを取得して保存することのみであり、ログの内容についての制御はログ変換・取込のコンポーネントで行います。これによって、安定した形でログの保全までができるようにします。

ログ変換・取込

ログ変換・取込はCloud Storageに保存されたログをBigQueryに取り込む処理を行います。この処理もCloud Runで実装します。Cloud Storageにログがオブジェクトとして保存されると、Cloud StorageはそのイベントをPub/Subに通知します。Cloud RunはPub/Subに対してサブスクライブしており、ログの保存イベントを受け取るとCloud Storageからオブジェクトを取得して、BigQueryにログを取り込む処理を行います。

このコンポーネントの責務はログをBigQueryに取り込むだけでなく、スキーマを必要に応じて調整することです。セキュリティ監視において利用するログは、そのほとんどがスキーマを自分たちでコントロールできません。したがって、ログのスキーマやデータをコントロールする必要があり、そのためのポイントの一つがこのコンポーネントです。スキーマやデータの調整は大きく分けて2つの観点があります。

• BigQueryに投入可能にするための調整: BigQueryは構造化されたレコードも作成できるため、JSONのような構造データをそのまま取り込むことができます。しかし、外部サービスから取得したログはそのままではBigQueryに取り込むことができないものもあります。例えば、フィールド名に禁止文字が使われている、フィールドの型がレコードによって異なる、などの問題があります。このようなログをBigQueryに取り込むためには、ログのスキーマやデータを変更するなどの調整が必要です。
• ログの内容の正規化: セキュリティ監視基盤で利用するログはスキーマがバラバラであり、フィールドごとの値の意味や形式も異なります。これは複数種類のログを結合して分析する際、突合がうまくいかなかったり、意味のある分析ができないという問題があります。そのため、必要に応じてログの内容を正規化する処理が必要です。ただし、完全に統一されたスキーマに変更することは難しいため、一部の必要な情報のみを正規化するなどの工夫が必要です。

アラート検知

アラート検知もログ収集と同様にCloud Run JobをCloud SchedulerとWorkflowsで定期的に実行する形で実装します。アラート検知はBigQueryに定期的にクエリを発行し、取得したログデータからアラートとなりうる事象を発見します。検知したあとはPub/Subへそのアラート情報を投入し、アラート対応の処理へと引き継ぎます。

アラート検知の場合、検知したい事象に応じてクエリを変更する必要があります。単純一致検索の場合はあまり気にする必要はありませんが、期間集計や相関分析の場合、どの程度の期間を対象とするべきかは事象によって異なります。BigQueryを利用する場合、クエリによってスキャンされるデータ量に応じてコストが発生するため、無闇にクエリを発行するのは避けるべきです。そのため、クエリに応じて実行頻度を調整するなどの工夫が必要です。そのことから、ここでもCloud SchedulerとWorkflowsを利用して、異なるパラメータとクエリを個別に指定したスケジュールで実行できるようにしています。Cloud Run Jobもログ収集と同じく、プログラムが多くなるとメンテナンスが負担になるため、一つのプログラムで複数の事象に対応できるようにしています。

アラート対応

最後のアラート対応はPub/Subで送られてきたアラート情報、あるいは外部サービスから直接送られてきたアラートを取り込んで処理します。Google Cloudの外になるためここでは記載していませんが、必要に応じて各種サービスと連携します。対応で実践的にとれるアクションは概ね以下のとおりです。

• アラートの通知: Slackやメールなどの通知ツールを利用して、アラートを通知します。通知の方法や宛先をアラートの内容や緊急度に応じて変更できるようにしておくことで、対応者の振り分けや対応の迅速化が期待できます。
• アラートの関連情報の収集: アラートに出現したユーザ、ホスト、ネットワーク、ファイルなどの関連情報を収集します。アラートは実際の影響度を計り対応の優先度を決めるトリアージが必要になりますが、その際に必要となる情報を収集しておくことで、迅速な対応が可能になります。具体的には外部サービスで提供されているセキュリティ関連の情報を取得したり、BigQueryに格納されているログデータを参照するなどの方法が考えられます。
• アラートの管理: チケットシステムなどを利用し、アラートの状態や対応状況を管理します。アラートの状態を管理することで、アラートの対応進捗を追跡したり、アラートを集約させたりすることができます。

このコンポーネントは、組織独自のポリシーや手順に応じて取るべきアクションやその条件が変わってきます。

まとめ

今回はGoogle Cloudを利用してセキュリティ監視基盤を構築する際のアーキテクチャについて紹介しました。次回以降は具体的な実装の方法やアプローチについて解説していきたいと思います。