セキュリティログ分析基盤におけるクラウド活用、組織体制、メンバー育成のポイント：セキュリティログ分析基盤活用入門（終）（1/2 ページ）

セキュリティ業務における「ログ」と、その分析基盤の活用について解説する連載。最終回は、クラウド活用、組織体制、メンバー育成のポイントを紹介します。

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

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

　最終回となる今回は、「クラウドサービスを用いることで、セキュリティログ分析業務においてどのようなメリットがもたらされるのか」について、前回紹介した「Splunk」や「Elastic Stack」にも触れながら、その検討ポイントを含めて解説します。また、「セキュリティログ分析業務を継続的に発展させていくためには、どのように組織体制やメンバー育成を考えるべきか」についても解説します。

　なお、本稿で紹介するサービスの仕様や価格は、2019年12月現在の情報ですので、あらかじめご了承ください。

クラウドサービスやコンテナ技術の活用方法とは

　ログ分析基盤は、データ取得対象であるログソースに近い場所に構築することがセオリーです。その理由として、ネットワークに与える負荷、伝送遅延、システム構成のシンプル化などが挙げられます。昨今のITシステム環境は少しずつ、SaaSの利用や「Amazon Web Services（AWS）」「Microsoft Azure」などのクラウドサービスのIaaSを用いたシステム構築が増えており、必ずしもオンプレミス環境のデータセンター内にログ分析基盤を持つことが最適とはいえないケースも出てきています。

　まずは「どのようなケースにおいて、セキュリティログ分析基盤にクラウドサービスが適用できるのか」を見ていきましょう。

クラウド環境上でログを保持する2つのメリット

　クラウド環境上でログを保持することで得られるメリットとして、本番のログを用いてログ加工処理の開発や分析クエリのテストが実施できる点が挙げられます。オンプレミス環境のログ分析基盤では、多くの場合、開発環境やテスト環境に本番のログを取り込むことが困難です。本番環境だけで運用しているケースも存在します。

　コスト都合で開発環境やテスト環境を用意できないことも多いかと思いますが、クラウドサービスを利用することで開発やテストの容易さを手に入れることができ、ログ分析基盤の運用性を高められることはメリットの一つと捉えています。

　また、ログをフォレンジック業務で使う場合、インシデント発生時に過去の事象をログから追跡できるよう、完全性を保ちながら長期保存することが一般的です。とはいえ、その具体的な期間については明確なルールがあるわけではないので、各企業の業務要件に応じて、セキュリティガイドラインで規定していることが通例のようです。

　例えば、PCI DSS Ver3.2 要件10.7では「監査証跡の履歴を少なくとも1年間保持し、少なくても3カ月間はすぐに分析できる状態にしておく」ことが義務付けられている一方、刑事訴訟法 第197条 第3項では30日、サイバー犯罪に関する条約 第16条 第2項では90日を保存期間の目安とする記述があります。

クラウド型データウェアハウスとBIツールの活用

　クエリ頻度の低いログをログ分析基盤ですぐに検索できる状態に長期間保持することは、高価なストレージ装置にかかるコストを考えると、データセンターのラック費用や電気代、故障時に備えた保守費を合わせると費用対効果に見合わなくなります。

　このストレージの維持費を踏まえて、活用するクラウドサービスを見ていきましょう。

　これまでの連載で紹介したSplunkは、スキーマ定義の難しい多種多様な非構造フォーマットのログに対して、Splunkサーチ処理言語である「SPL（Search Processing Language）」によるサブサーチを用いることで、grepコマンドのようなパイプ「|」でログを絞り込みます。これがハンティング業務やフォレンジック業務において、セキュリティログ分析ツールとして大きな効果をもたらします。

　一方で、Splunkのライセンスは日単位の取り込み容量（GB）でかかるため、ライセンスコストは変わりませんが、ストレージの維持費がセキュリティユースケースにおけるSplunkユーザーの頭を悩ませている課題の一つと考えています。

　そこでクラウドサービスとしては、「Google Cloud Platform（GCP）」のデータウェアハウスサービス「BigQuery」が活用できると考えています。

　BigQueryは、クエリされたデータ容量による課金（1TB当たり月額5ドル、毎月1TBは無料）と蓄積しているデータのストレージ容量による課金（1GB当たり月額2セント、90日間更新されていないデータの場合は半額の月額1セント）となっています。また、検索対象のデータ容量に依存することなく、迅速に検索結果を返せるように、ストレージ層とコンピュート層が分離され、カラム型データストアとして実装されています。90日を超えるフォレンジック用途のログをより低コストで維持でき、さらには業務要件にマッチするスピードで検索結果が得られます。

　短期的なデータを用いて行う、ハンティング業務や監視業務はオンプレミス環境のSplunkを、90日を超えるクエリ頻度の低いフォレンジック業務はクラウドサービスBigQueryを利用するというような、セキュリティログ分析業務に応じて、ハイブリッドに使い分けることを検討してみる価値は十分にあると考えています。

　そのまた一方で、この使い分けにおいても課題があります。

　BigQueryはSQLベースの検索クエリを実行し、欲しい結果が迅速に得られるアーキテクチャです。SplunkユーザーでSPLに慣れているメンバーの中には、SQLが苦手という方も珍しくありません。

　また、SPLとSQLのいずれの言語においても、利用者によるスキルのばらつきが出てきます。セキュリティログ分析の運用を続けていると、クエリ管理が非常に難しくなってきます。例えば、同じ運用業務を行っているのに、クエリについては各メンバーが作ったもので運用されていたり、スキルの高い熟練者が書いた長文クエリについては、若手メンバーにとっては「何が実行されているのか理解できず、クエリの改修ができない」ブラックボックス状態になったりとさまざまな課題を抱えることがあります。

　そこでリクルートテクノロジーズのサイバーセキュリティ部では、「次世代BI（Business Intelligence）ツール」と呼ばれる「Looker」に注目しています。Lookerは、自前でデータベースを持たないSaaS型のBIサービスで、多くのデータベースやデータウェアハウスに対応しています。BigQueryもその一つです。

　BigQueryに対してDB接続を行い、「LookML」と呼ばれる独自のモデリング言語を用いて、SQLでデータを検索し、ダッシュボードのグラフで結果を可視化します。

　LookMLを用いることで高度なSQLの学習コストを低減すると同時に、クエリ結果を汎用（はんよう）化することでクエリの属人化を排除できるような仕組みを採っています。Lookerは、SQLを運用管理する難易度を低下させることに寄与すると考えています。

AWS環境におけるセキュリティログ分析

　ここまではオンプレミス環境のログに対するクラウドサービスの活用について、1つのユースケースを紹介してきました。一方、ここ数年でAWSをはじめとするクラウド環境でのシステム構築が増えてきました。クラウド側でシステムが構築されると、当然セキュリティログ分析基盤もログソースに近いクラウド内に構築することになります。次は、AWSを例にクラウド環境におけるセキュリティログ分析基盤についても少し触れたいと思います。

　AWSでは、各サービスに対する操作をAPIベースで実装しているため、API監査ログを「AWS CloudTrail」で記録します。APIベースの操作にならないログには「Amazon EC2内の各種ログ」「Elastic LoadBalancer（ELB）のアクセスログ」「AWS WAFのフルログ」「Amazon RDSのSQL監査ログ」「Amazon VPCフローログ」「Amazon Route 53のDNSクエリ」「Amazon Guard Dutyの検知ログ」などがあります。いずれのログも「Amazon S3」もしくは「Amazon CloudWatch Logs」に格納することができます。CloudWatch Logsに格納されているログは「CloudWatch Logs Insights」を用いると、簡単なクエリの実行や簡易的なグラフによる可視化ができます。

　また、分析要件次第になりますが、S3に格納されたログは「Amazon Athena」「Amazon Redshift」「Amazon QuickSight」「Amazon Elasticsearch Service」の分析サービスを用いることで、セキュリティログ分析基盤を構築することも可能です。

　分析のリアルタイム性を重視する場合はAmazon Elasticsearch Serviceを、運用コストを重視する場合はAthenaやQuickSightを、それぞれ組み合わせて利用することが多いです。Athenaでのクエリ性能を上げたり、クエリ課金を抑制したりするために、「AWS Lambda」「Amazon Kinesis Data Firehose」「AWS Glue」のチューニングで苦慮されているケースを多く見掛けます。この領域は、まだまだ解がなく、試行錯誤を繰り返していると感じています。

　コンテナ技術の活用例として、以前「AWS Fargate」をセキュリティログ分析基盤に組み込んでみた経験があります。当時はS3に蓄積したログをElasticsearchに投入する上でETL（Extract、Transform、Load）処理を行う「Logstash」をコンテナ化しましたが、Disk QueueやDead Letter Queueをコンテナ内にファイルで持ってしまうため、ステートレスな思想にマッチさせることはできず廃案にしました。しかしながら、新しい技術をうまく活用して、少しでも運用しやすい基盤を作る工夫は大事にしています。