セキュリティログ分析基盤の設計ポイント、アーキテクチャはどうあるべきか：セキュリティログ分析基盤活用入門（2）（1/2 ページ）

セキュリティ業務における「ログ」と、その分析基盤の活用について解説する連載。今回は、ログ分析基盤の設計ポイントを、アーキテクチャの観点から紹介します。

[日比野恒，リクルートテクノロジーズ]

　セキュリティ業務における「ログ」と、その分析基盤の活用について解説する本連載「セキュリティログ分析基盤活用入門」。前回は、ログを活用するセキュリティ業務やログの果たす役割を紹介しました。

　リクルートは、インシデントハンドリング、フォレンジックや脆弱（ぜいじゃく）性検査、マルウェア解析といった、多くの企業ではセキュリティ専業ベンダーにアウトソーシングする専門性の高いセキュリティ業務を内製化しています。2015年以降は「Recruit-CSIRT（Computer Security Incident Response Team）」として、自組織内でSOC（Security Operation Center）業務を行っており、その業務を遂行する上で、“ログ”は非常に重要な役割を果たしています。

　また前回は、商用のSIEM（Security Information and Event Management）製品では対応しづらいポイントについても少し触れました。既製品だけでは、自組織のIT環境やセキュリティ業務に合ったログシステムを採用することは意外と難しいと理解できたのではないでしょうか。今回は、多岐にわたるセキュリティ業務に対応していく上で考慮すべきログ分析基盤の設計ポイントを、アーキテクチャの観点から紹介します。

セキュリティログ分析基盤の基本コンポーネント

　まずは基本的なコンポーネントについて説明します。ログ分析基盤は、プロダクトによって多少の違いはありますが、原則的には「データ収集」「データ加工」「データ蓄積」「ユーザーインタフェース」の4つの機能で構成されます。

データ収集、データ加工、データ蓄積、ユーザーインタフェース

　それぞれの機能説明は以下の通りです。

データ収集

　各機器やソフトウェアが出力するログやネットワーク上を流れる「Packet（パケット）」から解析して得られたメタデータを収集する機能です。収集した各種ログを生データ（加工前）のまま保持することで、ログ基盤システム障害時や新たに加工処理を行いたいときなどにログの再取り込みを可能にし、バースト性のあるログ流入に対するキューイングの役割を担います。

　よく利用されるプロダクトには、「Apache Kafka」「Amazon Kinesis」があります。また、メッセージキューではなく、「Amazon S3」「Google Cloud Storage」といったオブジェクトストレージサービスを活用するケースもあります。

データ加工

　収集したログを分析に必要な形へ変換する機能です。データ加工ではExtract（取り出し）、Transform（変換）、Load（格納）の頭文字を取ったETLツールを用いて処理されることが多くあります。オープンソースでは、「Fluentd」「Logstash」「Apache Flume」がよく耳にするプロダクトといえるでしょう。加工処理は大きく2種類に大別され、「パース処理」と「エンリッチ処理」があります。

パース処理とエンリッチ処理

データ蓄積

　整形されたログを検索しやすく保持する機能です。オープンソースソフトウェア（OSS）の全文検索エンジンである「Elasticsearch」は大変人気を集めています。私もこれまでLogstashや「Beats」「Kibana」と合わせて、「Elastic Stack」としてログ分析基盤に利用してきました。商用の検索エンジンでは、「Splunk」が非常に有名です。

　ElasticsearchとSplunkは、テキスト処理しなければ分析に活用するのが難しい「非構造化データ」の取り扱いが得意なプロダクトであり、セキュリティログ分析基盤でのニーズがこの数年間で飛躍的に増えています。

ユーザーインタフェース

　蓄積されたログをセキュリティ業務に合わせた形で活用する、ユーザーインタフェース機能です。多くのツールでは、ログデータをグラフ化し、ダッシュボードとして監査業務や監視業務に利用します。

　さらに、監視業務では、アラート通知のための定型的な監視クエリを定期スケジュールで設定して実行したり、サブクエリを駆使したりするアドホックな分析を、ハンティング業務やフォレンジック業務では多用します。Splunkのように、分析時の検索クエリ内でデータをエンリッチ処理させるアーキテクチャを採用しているプロダクトもあります。

ログの加工処理はどのタイミングで行うのが最適なのか

　基本コンポーネントの「加工処理」について、もう少し突っ込んで解説します。この数年、よく話題に上がるSplunkとElastic Stackを用いて、加工処理に対する考え方の違いを考察します。よく比較される2つのプロダクトですが、両者には非常にユニークな違いが感じられるのではないかと思います。

　まずSplunkでは【1】ログ収集時、【2】検索クエリ時の2カ所で加工処理を行います。Splunkは、日単位でのログ蓄積容量（GB単位）で課金されるライセンス体系の製品であるため、蓄積前の収集時において、可能な限り無駄となるログイベントやログ項目は削っておかないとコストに大きく跳ね返ることになります。その削除処理を、ログ送信元に近い「Splunk Forwarder」で行います。

　次にエンリッチ処理は、元のログに対して分析に必要な追加データを付加する処理となるため、データストアに蓄積されるデータ容量を増やすことになります。そのため、Splunkは検索クエリ時の「Search Head」側でエンリッチ処理を行い、コスト効率の良い分析ができるような仕組みを取っています。SQLのSelect時のクエリでJOINするイメージに近いと思います。分析要件に応じて後から柔軟に加工ができるため、パイプを用いたサブサーチ機能と組み合わせて利用すると、ハンティング業務において非常に強力な武器となります。

Splunkのアーキテクチャ

　一方Elastic Stackは、Elasticsearchにログを蓄積するアーキテクチャです。スキーマレスなデータ保持が行えるため、多種多様なログ収集において、事前にログフォーマットを特定しづらいログ分析とは非常に相性が良いといえます。

　ところが、ベースは全文検索エンジンであり、検索結果を即時で返すことに重点が置かれているため、ハンティング業務やフォレンジック業務のように、アドホックにサブサーチを繰り返す使い方には最適とはいえません。「Google検索」をイメージすると分かりやすいかもしれません。検索ウィンドウに複数の単語を並べて検索対象を絞りますが、実行されるクエリは1回だけで、あとは一覧化された検索結果から欲しい情報を一つ一つ見ていくことになります。蓄積されているデータに対する定型クエリでは、リアルタイム性を発揮する特性から、SIEMのような監視業務がマッチします。

　さらにElasticsearchは、一度取り込んだデータを後から再加工することには適していません。これも、全文検索エンジンというアーキテクチャ故の特性といえます。そのため、Elastic Stackは原則として前工程でのETL処理となり、既にエンリッチされたログの容量でElasticsearchに蓄積されるため、ストレージ容量はより多く消費されることになります。

Elastic Stackのアーキテクチャ