運用維持コストを抑えられたか？ 次世代セキュリティDWHがもたらす効果と運用の泥臭い苦労話：セキュリティ組織にデータ民主化を――「次世代セキュリティDWH」大解剖（終）

マーケティング分析で用いられているデータ基盤サービスを活用した、リクルートの「次世代セキュリティDWH」の構築事例を中心に、最新のセキュリティログ基盤の動向を紹介する連載。最終回は、得られた効果、運用の泥臭い苦労話、今後の展望を紹介する。

[日比野恒，リクルート]

　マーケティング分析で用いられているデータ基盤サービスを活用した「次世代セキュリティDWH（データウェアハウス）」の構築事例を紹介する本連載「セキュリティ組織にデータ民主化を――『次世代セキュリティDWH』大解剖」も今回でいよいよ最終回です。

　連載第1回は、セキュリティ業務で利用するログ基盤に「BigQuery」「Looker」を採用した背景や“いきさつ”、どのような期待値があったのかを紹介しました。前回の第2回は、ローコードETL（Extract、Transform、Load）サービス「Cloud Data Fusion」とLookerの設計の考え方を中心に全体のシステムアーキテクチャについて解説しました。

　最終回は、導入してから約半年の間で得られた効果、運用フェーズにおける泥臭い苦労を総括として解説します。最後に今後の展望について少し触れます。

得られた効果

　第1回で「ログ基盤の抱える課題」として、次の3つの課題を紹介しました。

1. 運用維持コストにおける課題
2. データ活用におけるスキル格差の課題
3. DevOps人材確保における課題

　今回構築した次世代セキュリティDWHでこれらの課題がどの程度解決できたのかを紹介します。

ログ容量の増加に伴うコスト影響の極小化

　今回構築したシステム全体のコスト構造について説明します。課金対象の主なサービスはCloud Storage、Cloud Data Fusion、BigQuery、Lookerの4つです。Looker以外のサービスは利用したリソース分をGoogle Cloudの利用料として毎月請求されますが、Lookerは前払いで年間ライセンスを購入します。

　Lookerはベースとなるプラットフォームライセンスに、「Viewer」（ダッシュボード作成者用）10人、「Developer」（LookML開発者用）2人のユーザーライセンスが含まれます。足りない場合は追加で必要な役割のユーザーライセンスを購入する必要があります。

　これまで利用してきたSIEM（Security Information and Event Management）製品の課金体系と比べると、ログ容量のサイジング予想を外したとしてもストレージにかかるコストが非常に安価なので、コスト全体に与える影響が少なくて済みました。Cloud Storageは「Standard Storage」プランで1GBごとに月額0.023ドル、BigQueryは1GBごとに月額0.024ドルで、90日間更新されなければ、ほぼ半額の0.016ドルになります。

　また定常的な監視ではなくアドホックに分析しているので、クエリスキャン容量による課金体系は非常に都合が良く、こちらもコストメリットを感じています。スキャン容量は月1TBまで無料、1TBを超えてスキャンされたデータは1TBごとに月額6ドルのレートで課金されます。

　このスキャン容量を抑えるために設計や運用で次のように工夫しました。

• パーティション分割テーブルによるスキャン対象の絞り込み
• テーブルクラスタリングによる不要なデータのスキャンの省略
• カスタムコスト管理による制御とチューニング
• 「Cloud Monitoring」によるスキャンデータのモニタリング

　ログは時系列データです。ログのイベント発生日時フィールドで日別のパーティション分割テーブルを作成し、検索条件によく利用するフィールド（ユーザー名やIPアドレスなど）をテーブルクラスタリングに利用しています。ビジネスユーザーの分析作業にストレスを与えない範囲をうまくモニタリングしながら、カスタムコスト管理による制御をチューニングしています。

　ログ容量の増加によるコスト影響が「全くない」とは言いませんが、「1日に取り込んだログ容量」または「サーバの台数」による課金のSIEM製品と比べると、その影響は少なくて済むと考えています。またUEBA（User Behavior Analytics）製品に多い「利用している従業員数」による課金と比べても、メリットがあるといえます。

　コストに影響する大きなポイントはLookerのユーザー数の増加ですが、必ずしもデータを利用するメンバーがLookerにログインする必要はないと考えています。作成したダッシュボードのデータを「Googleドライブ」「Slack」にプッシュで配信できれば十分です。現時点では期待していたコスト計画通りに運用できていると考えています。

データ基盤に必要なエンジニアの技術スキルのハードルを下げられるのか

　「多くのSIEM製品では、監視ロジックを開発するためには専用のクエリ言語を習得する必要がある」と、これまでの連載でお伝えしました。

　Lookerではビジネスユーザーがクエリ言語を使わずにダッシュボードを作成できるようになっています。詳細については連載第2回を参照してください。SQLによる集計や加工処理は、事前にLookMLを用いて共通ロジックとしてコード化できるので、クエリ時点での属人的なロジックを排除できるようになりました。

　またLookMLのコードは「Git」の仕組みを用いて管理するので、過去の変更内容はコミットログから追えます。プルリクエスト／マージリクエストを使ってコードをレビューすることもできます。ソフトウェア開発の仕組みに乗っ取って運用できることにはメリットもありますが、その半面、別の意味で扱うメンバーの学習コストを上げてしまう可能性を考える必要もあります。

　LookMLを習得する学習コストについても考えておく必要があり、改めて「銀の弾丸はない」と思いました。先々の技術トレンドを理解しながら、自社組織で維持運用しやすい仕組みやツール、または技術を選定していくことが今後も重要だと考えています。

　今回のシステムでは、全てマネージドサービスを採用したことでインフラ運用にかかるコストをかなり抑えられたと考えています。半年間でのインフラに関する障害はなく、トラブルシューティングは定期的に発生する規約に沿っていない壊れたデータの取り込みエラー対応ぐらいです。

　このアーキテクチャでなければ、短期間かつ2人体制での開発と運用は難しかったと感じています。

苦労したポイント

　ここまでは良い面を中心に紹介しましたが、当然良いことばかりではありません。特にCloud Data Fusionの活用はチャレンジであり、「期待通りの効果が得られるのかどうか」はやってみなければ分からない要素が多かったと思います。ここからは、苦労したポイント、改善されるとうれしいポイントについて触れます。

トラブルシューティング時のデバッグ方法

　Cloud Data FusionはGUI操作で簡単にパイプラインを構築できるので、Pythonなどの開発スキルがなくても少人数で大規模なデータ基盤を開発、運用できます。インフラを運用する必要がなく、性能不足時におけるスケールアウトが簡単です。

　しかし、現時点では幾つか欠点も存在します。まずは想定していなかった内容のデータが流れてきた場合のトラブルシューティングに苦労しました。想定外のデータが流れてくるとパイプラインの処理自体が失敗するか、該当のプラグイン処理でエラー数がカウントアップします。開発中で発生した代表的なトラブルは下図の通りです。

　トラブル対応自体も大変でしたが、それよりもトラブル発生時の原因特定にかなり苦労しました。主な要因はデバッグ機能が弱く、「どのファイルの、どのレコードで処理が失敗したのか」「どのプラグインで失敗したのか、なぜ失敗したのか」をエラーログのメッセージだけでは追えないケースがありました。パイプラインの構成次第ですが、ログメッセージが非常に長くなることがあり、どこにエラー原因があるのかを解析しづらいケースやログメッセージには原因が明確に記載されないケースがありました。

　また、処理エラーになったイベントを全て「デッドレターキュー」に送ることができると、原因調査や再取り込みが容易になりますが、「Wrangler」プラグインを含む一部のプラグインにしかデッドレターキューに送る機能が付いていませんでした。そのため、CSVパース処理に「CSVParser」プラグインを利用していましたが、途中で構成を変更し、WranglerプラグインのCSVパース処理でパイプラインを再構成することになりました。今後、Cloud Data Fusionのデバッグ機能が充実することを期待しています。

　余談ですが、「Splunk」ではスキーマ構造を意識しなくてもログデータを蓄積できるので、取り込みにかかる作業負担は少ないといえます。逆にいえば、どんなデータでも取り込めてしまうので、データのバリデーションが効きません。そのため、クエリ時に欲しいデータが検索に正しく引っ掛からないリスクがあります。

　ETL処理を開発するにはそれなりの体力とスキルを要しますが、データソースを整えるきっかけを作ってくれる大事な役割があると筆者は考えています。

パイプライン開発がCI/CDに対応していない

　連載第2回でも少し触れましたが、現状CI/CD（継続的インテグレーション／継続的デリバリー）には対応していません。GUI操作で簡単に開発できる半面、パイプライン数が増えてくるとメンテナンス性が非常に悪くなります。

　2021年末に「Apache Log4j 2」の脆弱（ぜいじゃく）性対応のためにCloud Data Fusionで利用する「Dataproc」の起動イメージのバージョンを上げる必要がありました。こちらはパイプラインの再作成にはならなかったのですが、GUI操作で全パイプラインの「Image Version」の設定を変更しました。

　他にもジョブ同時実行数が多過ぎたためか、同じタイミングで起動するはずのパイプライン実行ジョブがまとめて失敗することが“まれ”にありました。Dataprocクラスタが起動する前に失敗していたので、「Pipeline Alert」によるエラーがSlackに通知されず、障害の認知までに時間を要することがありました。同時実行数を減らすことで暫定対処しましたが、この際にも多くのパイプラインでスケジュールを変更しました。

　GUI操作で一つ一つパイプライン設定画面を開き、設定を変更する作業の負荷は無視できない状態になりつつあります。プラグインの設定を変更する場合はパイプラインの再作成になります。設定変更前のパイプラインの実行履歴やログを引き継げないのは悩ましい問題だと感じています。

　パイプラインを運用していると想定していなかった障害が発生する場合があります。その都度、改善対応としてパイプライン設定を見直すことになります。パイプラインの設定を効率的に変更できる機能の追加にも期待しています。

今後の展望：クラウド型の次世代SIEM/UEBAサービスとの融合

　最後に、セキュリティ業務におけるログ基盤がどのような方向に向かうことが予想されるか、筆者なりの考えを解説します。

Exabeam、Securonix

　改めて、2年半前に思い付いた次世代セキュリティDWH構想ですが、この方向性は間違っていなかったと感じています。

　「Exabeam」「Securonix」は、この数年で勢いのあるセキュリティベンダーであり、クラウド型の次世代SIEM/UEBAサービスを提供しています。

　昨今、ゼロトラストセキュリティが注目されている通り、セキュリティの境界はネットワーク層ではなくなりつつあり、外部と内部の境目が曖昧になっています。外部攻撃検知のSIEMと内部不正検知のUEBAが同じプラットフォーム上で融合し始めている点も注目すべきポイントです。これまで内部の動きを見張るために利用していたログが外部から不正に入り込まれた際の潜伏活動の検知として利用できるケースもあると考えています。

　Securonixは、セキュリティ監視のために取り込んだログデータを「Snowflake」と連携させることで、スケーラブルなDWH上でより深い分析を可能にする製品を提供しています。この発想は次世代セキュリティDWHの思想に似ていると思っています。

Chronicle（Backstory）

　Googleには2019年にGoogle Cloudに加わったセキュリティ企業Chronicleの「Backstory」というクラウド型SIEMサービスがあります。GoogleのSIEMサービスということもあり、2019年のRSAカンファレンスで発表された当初からずっと注目していました。現在は「Chronicle」がサービス名となっています。

　Chronicleについては、2021年7月にLookerとBigQueryとの統合が発表されました（参考）。Chronicleが取り込んだログデータをBigQueryにエクスポートできるようになり、こちらもスケーラブルなDWH上でより深い分析が可能なカスタマイズ性の高い製品になりました。

　専用クエリ言語を用いずにSQLを使ったセキュリティログ分析ソリューションになっており、この点においても、われわれの考えていた世界観に非常に近い方に向かっていると感じました。Chronicleとの統合は今後検討していきたいテーマです。

終わりに

　本連載では3回に分けて、次世代セキュリティDWHの構築事例と題して、導入の背景や“いきさつ”、システムアーキテクチャと設計のこだわり、得られた効果と苦労について解説しました。

　このプロジェクトを通して、セキュリティ業務にもクラウドが浸透し始めていることを改めて実感しています。新しいサービスやアーキテクチャを採用することで進化する部分もあれば、一方でSQLのように変わらずに今でも現役であり続ける技術もあります。少なくとも自分が生きている間はSQLがなくならないだろうと感じました。

　Google Cloudのサービスを中心に構築したシステムを紹介した本連載では、なるべくサービスに依存しない本質的な部分に触れた内容を意識して執筆しました。少しでも皆さんの業務に役立つ内容になっていることを願っています。

筆者紹介

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

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

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

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

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