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

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

印刷

通知 連載「セキュリティログ分析基盤活用入門」の新着をメールで通知

見るPost

Shareシェア

はてなブックマーク

SharePocket Button

取り込みデータの監視とエラーハンドリング手法

続きを読む

　一方、ログ分析における悩ましい問題として、システム管理者の気が付いたところで、いつの間にかログのフォーマットが変わっていることがあります。その要因はさまざまありますが、アプリケーションの改修や機器のソフトウェアバージョンアップによるものが主因です。

　アプリケーションログのフォーマットに変更が加わるケースに関しては、アプリケーション開発者がサービス機能の拡張に伴ってログ出力項目を追加したことを、ログ分析基盤の管理者に連携させないことで発生してしまうことが多くあります。その理由として、そこまで意識が回らなかったり、連携フローが手順化されていなかったりすることが挙げられます。

　機器のソフトウェアバージョンアップでは、ログ出力結果に変更が加わることが想定されていない場合が多く見受けられます。私自身も、バージョンアップの検証項目に「ログフォーマットが変わっていないこと」を盛り込むケースはあまり見たことがありません。そのため、どこまでの確認範囲をもって「ログフォーマットは変わっていない」と判断するかについても、またひと苦労です。

　セキュリティログ分析基盤で実行している検索クエリが正しく動作しているかどうかを監視することは非常に難しく、多くのログ基盤担当者の頭を悩ませているのではないでしょうか――。【1】「なぜログが発生していないのか」、【2】「正しくログが取り込めていないのか」、あるいは【3】「取り込んだログのフォーマットが変わってしまい検索クエリに掛からなくなってしまったのか」といった原因を特定できるように“取り込むデータの監視方法”にも考慮しておく必要があることを覚えておいてください。

　もし正しくログが取り込めていないことに気が付いた場合、ログの再取り込みができるようなアーキテクチャ設計にしておくことも大事です。バッチ処理でログを取り込んでいるケースは比較的容易にリトライできますが、「Syslog」「Netflow」、パケットデータなどのストリーム処理での取り込みの場合は、リトライが非常に難しくなります。また、ログの送信元によってはリトライできないケースも多くなりますが、KafkaやKinesisなどのメッセージキューイング機能の利用により、対策を講じることが可能になります。もしものときには助けになりますので、覚えておくといいかもしれません。

ビッグデータ解析基盤技術は応用できるのか

　ここまでセキュリティ業務におけるログ分析基盤のアーキテクチャについて説明してきました。よく耳にするプロダクトとしてSplunkやElastic Stackを例に、アーキテクチャ設計における考慮ポイントや各プロダクトの特徴にも触れました。

　アーキテクチャ観点では、これらが実は、IoTなどのセンサーデータを解析基盤に取り込みビジネスに貢献できる形で分析に活用する、ビッグデータ解析基盤技術の仕組みに似ていることに気が付きます。基本コンポーネントである「データ収集」「データ加工」「データ蓄積」「ユーザーインタフェース」の4つの機能を組み合わせた基盤である点は、ほぼ同じであるといえます。

　明確に定義されたものはないと思いますが、時系列データであるログは日々増加し続けるビッグデータの一種であると考えています。

　そこで最後に少し、ビッグデータ解析基盤技術のセキュリティログ分析への応用可能性について触れておきます。

ビッグデータ解析基盤とは

　これまでビッグデータ解析基盤では、「Apache Hadoop」のエコシステムを用いた分散データ処理技術が中心に扱われてきました。よく聞くキーワードには、「HDFS（Hadoop Distributed File System）」「YARN（Yet Another Resource Negotiator）」「Apache HBase」「NoSQL」「MapReduce」「Apache Hive」「Presto」「Apache Spark」などが出てくるのではないでしょうか。

　ビッグデータ解析基盤は、トランザクションベースのリレーショナルデータベースで厳格に管理されてきた売り上げや在庫データなどを分析に活用するため、大量のデータを分散してスケールアウト処理できるデータウェアハウスにバルクロードし、BI（ビジネスインテリジェンス）ツールから可視化できるようにしたものが始まりのようです。

　扱うデータや誕生のいきさつに違いはありますが、セキュリティログ分析基盤とビッグデータ解析基盤のアーキテクチャは非常に似通っています。オープンな技術に精通する企業では、トラフィックデータやログデータをHadoop基盤に展開し、機械学習技術も活用しながら、セキュリティにおける異常検知モデルの生成に取り組んでいるユースケースも見掛けるようになってきました。

　「Apache Metron」はまさに、オープンなビッグデータ技術を組み合わせて構築されたセキュリティ分析フレームワークです。2013年にはCisco Systemsが主体となって、「OpenSOC」という名前でスタートしています。ElasticsearchとHDFSに「Apache Storm」で加工されたセキュリティ関連データを保存し、Kibanaや「Zeppelin」で可視化するアーキテクチャを採用しています。

ビッグデータ解析基盤を応用する利点

　ビッグデータ解析基盤は、多くのビジネスニーズに応えられると期待されており、基幹システムから抽出した販売管理データの分析から始まり、ひいてはIoTセンサーデータの解析など、多くのユースケースが生まれています。利用する人が増えることで、新機能の開発が活発化されたり、利用者の増加に伴い“規模の経済”が働くことで、利用する上でのコストが低減したりすることが期待できます。

　セキュリティログ分析は直接利益を生む領域ではないため、なかなか前向きに投資できない企業が多いとみるものの、セキュリティログ分析基盤にビッグデータ解析基盤技術を応用することで、コスト面でのハードルを下げることにつなげられると考えています。

　リクルートでは、新しい技術要素はまず試してみて、ファクトをベースに適切に評価する文化が根付いており、クラウド型データウェアハウスサービスや次世代BIツールを組み合わせた技術的な評価も検討しています。ただし、Hadoopにしても「Google BigQuery」「Amazon Redshift」などの並列分散データベースにしても、SQLで処理を行うアーキテクチャがほとんどです。SQLはなくならない技術要素の一つであると考えているため、今後はSQLをベースとしたアーキテクチャについても、セキュリティログ分析基盤としての活用が増えていくことを期待しています。

SQLベースアーキテクチャとは

次回は、スキルセットや組織の人員構成、新技術の活用ポイント

　次回はいよいよ最終回です。今回紹介したプロダクトやアーキテクチャを採用してシステムを組んだ場合に求められる、スキルセットや組織の人員構成、さらにクラウドサービスやコンテナなど新技術の活用ポイントに触れます。

この連載を「連載記事アラート」に登録する New

筆者紹介

日比野 恒（ひびの ひさし）

リクルートテクノロジーズ ITソリューション本部 サイバーセキュリティ部 セキュリティオペレーションセンター1グループ所属

10年間、ITコンサルティング会社に在籍。インフラコンサルタントとして、主にネットワーク、データセンター、仮想基盤の設計や構築を担当。2015年以降、セキュリティアーキテクトとして、主に金融機関や公共機関に対して、セキュリティ対策製品の提案導入、「Elastic Stack」を用いたセキュリティ脅威分析基盤の開発を推進。2019年から現職において、次期ログ分析基盤のアーキテクチャ設計を担当。