ETL、BIサービスを組み込むセキュリティログ分析基盤の設計方針、サーバレスとフルマネージドがもたらす効果とは：セキュリティ組織にデータ民主化を――「次世代セキュリティDWH」大解剖（2）

マーケティング分析で用いられているデータ基盤サービスを活用した、リクルートの「次世代セキュリティDWH」の構築事例を中心に、最新のセキュリティログ基盤の動向を紹介する連載。今回は、どのような思想とこだわりを持ってシステムを設計したのか解説する。

[日比野恒，ITmedia]

　セキュリティ業務に特化したログ製品であるSIEM（Security Information and Event Management）やUEBA（User Behavior Analytics）ではなく、デジタルマーケティング領域やビッグデータ解析などで利用されることの多いDWH（データウェアハウス）を応用した「次世代セキュリティDWH」の構築事例を紹介する本連載「セキュリティ組織にデータ民主化を――『次世代セキュリティDWH』大解剖」。連載初回は、その背景やきっかけ、考え方について解説しました。

　第2回は、どのような思想とこだわりを持ってシステムを設計したのか、ETL（Extract、Transform、Load）サービスの「Cloud Data Fusion」と次世代BI（ビジネスインテリジェンス）サービス「Looker」を中心に解説します。

システムアーキテクチャの紹介

　システムの全体像やアーキテクチャ、各コンポーネントの役割について説明します。扱うデータにはセキュリティ業務で利用するセンシティブな情報が多く含まれているので、「Google Cloud」で実装したセキュリティにおける考慮ポイントについても触れます。

セキュリティDWHの概要

　大前提ですが、本システムはGoogle Cloud上に構築しています。前回も触れましたが、BigQueryを中心としたアーキテクチャで課題に挑んだことが主な要因です。また、BigQuery以外のコンポーネントもインフラの運用維持にかかる負担やトータルコストを抑えるために全てマネージドサービスの組み合わせによるサーバレスアーキテクチャで構成しているところもこだわったポイントです。

　BigQueryに格納するデータには、オンプレミス環境で生成されるログもあれば、クラウドサービスからAPIを使って取得しているログもあります。さまざまなフォーマットのログを異なるプロトコルを使ってデータ基盤に集めるためにCloud Data Fusionを利用しています。

　Cloud Data Fusionは、「Google Cloud Next'19」で発表されたローコードETLサービスであり、2018年にGoogleが買収したオープンソースソフトウェア（OSS）のCDAP（Cask Data Application Platform）がベースのマネージドサービスです。用途に応じてバッチ処理とストリーミング処理を使い分けることができます。

　オンプレミス環境のログは、Google製の「gsutil」ツールを使って「Cloud Storage」にアップロードし、「GCS Source Plugin」を使ってBigQueryに格納しています。クラウドサービスのログは「HTTP Source Plugin」を使ってAPIを実行することで直接格納する方式を採用しました。

　LookerはBigQueryに格納したデータを可視化、分析するために利用しています。SQLでクエリ文を書くことなくダッシュボードを作成できるので、ビジネスユーザーが新たな気付きをスピーディーに得られるよう設計しました。

セキュアな設計

　システム構成図をベースに「各コンポーネントがどのように連携しているのか」「どのようなセキュリティ思想で重要なデータを囲い込んでいるのか」を説明します。

　まず、取得したログが蓄積されるCloud StorageとBigQueryを厳重に守る必要があります。Google Cloudの「VPC Service Controls」を利用することでこの2つのリソースをサービス境界内で保護し、外部から不正アクセスできないように論理的な壁を構築しました。

　しかし、オンプレミス環境からCloud Storageにログをアップロードするgsutilツールとログ分析で利用するLookerは境界内のサービスにアクセスするように制御する必要があります。オンプレミス環境の出口やLookerが利用するIPアドレスだけVPC Service Controlsの許可リストに登録することで安全にデータにアクセスします。

　次にCloud Data Fusionですが、プライベートインスタンスとして作成することでVPC内に閉じた環境に構築できます。Cloud Data FusionはETL処理を実行するたび、「Apache Spark」のマネージドサービスである「Dataproc」のクラスタが起動します。「Private Google Access」を有効化しておくことでDataprocからCloud StorageやBigQueryにアクセスする際はVPC内に閉じた通信にすることができます。随所に安全なデータアクセスの工夫を施しました。

Cloud Data Fusionのパイプライン設計

　ここでは、パイプラインの作成単位、パイプライン開発方法、利用したプラグイン、性能チューニング方法など、Cloud Data Fusionの設計方針を深堀りします。

パイプラインの設計方針

　本システムの構築時点で約60本のパイプラインを作成しました。現在も順次取得対象のログ種別は増えています。同じクラウドサービスの監査ログでもイベント名ごとにログのフィールド構造が異なるケースがあるので、基本的にはログ種別単位で1つのパイプラインを作成し、パイプラインごとに格納先のBigQueryのテーブル（＝スキーマ）を作成しています。

　しかし、取得対象のログによっては1つのファイルの中に複数のログ種別が混ざってしまうケースがあります。特にJSONフォーマットのログはCSV／TSVフォーマットと異なり、イベントごとにフィールド構造が可変になっています。この場合は例外的に「Router Transformation Plugin」を使って条件分岐を作り、複数のログ種別を1つのパイプラインで処理しました。

　パイプラインを設計する上で一番気を付けたポイントは、処理失敗したときのエラーハンドリングのしやすさとデバッグのしやすさです。取り込むログ種別が増えることで管理対象のパイプライン数が増えるのは悩ましい問題ですが、無理に1つのパイプラインに処理をまとめるとデータのフローが複雑化し、結果的に運用負荷が高くなってしまう可能性があります。

　どのファイルのどのレコードで失敗したのか、なぜ失敗したのか、ログメッセージだけでは追えないことがあります。データは生きもの、失敗することを前提としたパイプライン設計が重要だと考えています。

パイプライン開発方法

　あらためまして、Cloud Data FusionはローコードETLサービスです。ETL処理のパイプラインをWebブラウザによるGUI操作で比較的簡単に開発できます。具体的なパイプライン開発ステップは下図のようになります。

　Draftsにある状態なら、パイプライン設定の修正は可能です。Draftsでプレビューすることでデプロイ前に簡易的な単体テストができますが、一度デプロイしてしまうとパイプライン設定の変更はできません。

　設定変更が必要な場合はDuplicate機能で同じ内容のパイプラインをDraftsにコピーするか、エクスポートしたJSONの設定ファイルをインポートしてパイプラインを再作成して差し替える必要があります。再作成での差し替えになり、実行履歴やログを追えなくなるので、少し使い勝手が悪いと思うこともあります。

　GUI操作で簡単に開発できる半面、GitHub連携などCI/CD（継続的インテグレーション／継続的デリバリー）には現状対応していません。競合製品では対応しているものも出てきているので、個人的には今後の機能拡張に期待しています。

　開発過程では紆余（うよ）曲折ありましたが、想定していたよりも多くの処理が実行できており、かなり楽に運用できていると感じています。苦労したポイントについては次回紹介する予定です。

　ちなみに現在は下記のプラグインを利用しています。今後利用を検討されている方の参考になれば幸いです。

Cloud Data Fusionの性能チューニング方法

　バッチウィンドウが決まっていてパイプラインの処理時間を短くしたい場合もあると思います。実行前にWorkerノードのCPUコア数やメモリ容量を追加するか、またはWorkerノードの台数を増やすことで拡張されたDataprocクラスタが起動します。スケールアウトを簡単に操作できるのもCloud Data Fusionの魅力の一つだと感じています。

　Cloud Storageから解凍済みのファイルを読み込む場合は、デフォルトで128MB単位にデータを分割し、Dataprocが並列分散処理をしてくれます。この動作によって、Workerノードの負荷が平準化され、より短い時間でパイプラインの処理が完了できることもうれしいポイントでした。

　筆者はこれまでOSSのETLツール「Logstash」をLinuxにインストールして利用することが多かったのですが、スケールアウト構成を取る際にはデータソースによって構成を変えたり、障害時のエラーハンドリングを想定して設計したりする必要があり、結構苦労していました。

　数TBのデータでも数時間で終了できる非常にスケーラブルなETLサービスだと分かったことがひょっとすると一番の収穫だったのかもしれません。

LookMLで実現する「ログデータの民主化」とは

　データ民主化を掲げているBIツールのLookerはビジネスユーザーにSQLを学習させることなく、ログ分析（アドホック分析やダッシュボード作成など）できる環境を提供します。Lookerのコアコンポーネント、独自言語「LookML」を用いることでどのように「ログデータの民主化」を実現しようとしたのかを解説します。

　Lookerは自身でデータを保持しません。データベースに格納されたデータを都度参照するので、Lookerが接続しているデータベースにSQLクエリを発呼してデータを取得します。

　グラフやダッシュボードを作成する前工程でLookMLを用いて、ビジネスユーザーにとって都合の良い形とタイミングでデータを加工して提供できます。具体的には、次のような処理を実装しました。

• フィールドの論理名（label）と説明（description）の付与による可読性の向上
• 値の含まれてない空フィールドやNullフィールドの非表示
• テーブルの結合（JOIN、UNION）
• フィールドに含まれる値から、さらなるフィールド抽出
• よく条件に利用するフィールド（WHERE句）のフィルター化
• よく表示に利用するフィールド（SELECT句）のラベリング

　ここから幾つか具体的な例を示しながら解説します。

フィールド論理名の付与による可読性向上

　セキュリティ業務では多種多様なログを相関分析することが多く、同じ意味合いのフィールドの揺らぎを統一化する必要性に迫られることがあります。

　例えば、同じファイアウォールでも複数メーカーの製品が導入されていて、同じ通信ログでもフォーマットが異なるものを同じように扱いたい場合があります。URLフィールドがAメーカーの製品では「url」、Bメーカーの製品では「path」となっているとグラフで表示する際に同じフィールドとして扱えません。

　LookMLを使うことで分析に利用しやすい名前に論理名を付与したり、そのフィールドの意味合いを説明するためのdescriptionを付与したりすることができます。

　データベースのテーブル設計するタイミングでどのような名前にするといいか。まだ取り込む予定のないログのことまで考えてきっちり決め切ることはほぼ不可能です。そのため、後からLookerという抽象化してくれる層を挟むことで物理的なテーブルの設計の制約を緩和してくれます。これによってデータ活用の柔軟性が高まります。

　またログ種別ごとにフィールド構造が異なるので、データベースのテーブルを分けていてもLookMLでUNIONすることでLookerの「Explore」から見たときに、あたかも1つのテーブルのようにデータを提供できます。

　アンチウイルスやEDR（Endpoint Detection and Response）のようにクライアントにインストールする製品ではOSバージョンや導入時期に合わせて複数のバージョンが混在することがあります。統一したくてもなかなか難しいのですが、ログ分析するときにはLookerが統一した画面を提供してくれるので、効率的な解析環境を構築できます。

フィールドに含まれる値からさらなるフィールド抽出

　フィールドからさらにフィールドを抽出するケースを見てみましょう。URLを例に説明します。Webアクセスログに含まれる「url」フィールドに含まれるURLからFQDN（Fully Qualified Domain Name）だけをフィールドとして抽出して活用したいケースがあったとします。

　ログをBigQueryのテーブルに格納するタイミングで、どのようにURLを活用するかが決まっていないと、ETLツールで処理できません。また、アドホックに分析するときだけ「FQDN」フィールドがあれば事足りるようなケースでは、テーブルにフィールドを用意するとストレージ容量が増えてしまいます。

　このような場合、LookerではSQLの「NET.HOST」関数を使って、「url」フィールドからFQDN部分をフィールド（dimension）として抜き出すことができます。

　URLのデコード処理など分析内容にかかわらず必要な処理は、前工程のETLツールで処理した上でデータベースのテーブルに格納します。このように前工程と後工程の都合の良いタイミング、好きなようにデータを扱えるのが筆者の求めた理想のログ分析基盤でした。今回のアーキテクチャではこの柔軟性を手に入れることができました。

最終回は、次世代セキュリティデータウェアハウスがもたらした効果とその先の展望

　パブリッククラウドのマネージドサービスをフル活用したサーバレスな設計になっているので、仮想マシンやコンテナの運用管理をする必要がなく、インフラエンジニアやデータエンジニアの負担がかなり軽減された印象を持たれたのではないでしょうか。

　多種多様かつ大容量なログデータを取り扱うログ分析基盤を少人数で運用維持しながらアジャイル的に進化させる上で必要なエッセンスを多く設計に取り入れたつもりです。全く同じものを構築する必要はありません。皆さんの環境や要件に照らし合わせて、少しでもヒントになりそうな要素があれば幸いです。

　次回はいよいよ最終回です。今回紹介し切れなかった苦労したポイントを交じえながら次世代セキュリティデータウェアハウスがもたらしたビジネス効果を紹介します。

筆者紹介

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

株式会社リクルート リスクマネジメント本部 セキュリティ統括室 セキュリティオペレーションセンター ソリューションアーキテクトグループ所属

10年間、ITコンサルティング会社に在籍。セキュリティアーキテクトとして、主に金融機関や公共機関に対して、セキュリティ対策製品の提案導入、Elastic Stackを用いたセキュリティ脅威分析基盤の開発を推進。2019年から現職において、次期ログ基盤のアーキテクチャ設計やクラウドにおけるセキュリティ実装方式の検討を担当。

『Elastic Stack実践ガイド[Logstash/Beats編]』（インプレス刊）の著者。

公認情報システムセキュリティ専門家（CISSP）、公認情報システム監査人（CISA）、情報処理安全確保支援士（登録番号：000999）を保有。