SOCがSplunkログ基盤の移行先にAWSを検討したワケ：セキュリティログ基盤クラウド化検討大解剖（1）

リクルートのSOCによるログ基盤クラウド化検討プロジェクトの概要や失敗談、そこから得た学びを紹介する連載。初回は、背景や概要、AWSで検証した理由などについて。

[田村由佳，リクルート]

お詫びと訂正（2021年3月11日13時20分）

本稿公開時にタイトルに「AWSに移行すると決めた」とありましたが、正しくは「移行先としてAWSを検討した」ですので、タイトルを訂正します。誤解を生む表現となってしまい、読者ならびに関係者の方々にお詫び申し上げます（編集部）。

　リクルートのセキュリティオペレーションセンター（SOC）所属の田村です。リクルート入社後、「Splunk」の運用、保守に2年携わり、直近1年はSplunkを活用したログ基盤構築関連のプロジェクトに携わりつつ、セキュリティアナリストになるために修行の日々を送っています。

　本稿では、私が携わったログ基盤構築プロジェクトの概要や失敗談、そこから得た学びなどを3回に分けて紹介します。

現行のログ基盤の用途

　私の所属する組織では、Splunkを使ったログ基盤を運用しており、下記4分類の業務で使用しています。業務によって、使用するデータの保管期間が長期にわたるものや、即時性が必要なものなど、求められる要件が異なります。各分類の詳しい説明については、連載「セキュリティログ分析基盤活用入門」をご参照ください。

ログ基盤の4つの業務（「セキュリティ業務における「ログ」の基礎知識――なぜ分析基盤が必要なのか：セキュリティログ分析基盤活用入門（1）」から引用）

　現行のシステムは、2016年ごろから使っており、喫緊で対応が必要となった際に構築されたSplunkの環境が複数存在している状態です。

ログ基盤クラウド化検討プロジェクト

　ログ基盤はオンプレミスのデータセンター内にあり、今後数年以内に順次End Of Service Life（EOSL）を迎えます。老朽化するインフラの更改に当たり、下記の5つの目標を掲げました。

プロジェクトの目標

　この目標を達成するプラットフォームとしてオンプレミスとクラウドのどちらが最適なのかを検討することになりました。弊社ではクラウド環境におけるSplunk構築の実績がなかったので、クラウドでの実現性やアーキテクチャを検討、検証することを目的として、「ログ基盤クラウド化検討プロジェクト」（以降、本プロジェクト）が発足しました。

　本プロジェクトでは、Amazon Web Services（AWS）のマネージドサービスをうまく活用して、AWS上でSplunkを使ったログ基盤を構築することの実現性を、機能や性能の観点から技術的に検証しました。

スケジュール

　2019年の夏、先述の連載を書いたとある先輩社員の「田村さん、むちゃ振りしていいっすか？」という一言から本プロジェクトはスタートしました。私にはAWSやGoogle Cloud Platform（GCP）での構築経験や知識がほとんどなかったので、「なるほど、むちゃ振りだな」と思いつつも、勉強がてら引き受けることにしました。

　本プロジェクトは下記のスケジュールで進めました。

プロジェクト推進スケジュール

　ところが検証を進めていくと、追加で課題が発生したり、想定通りの動きにならなかったりと、想定よりも長い時間を要しました。特に可用性や性能、拡張性といった非機能要件に関する検証に時間がかかってしまいました。具体的な検証内容やその結果、発生した課題は次回以降で紹介します。

なぜクラウド？

　なぜクラウドという選択肢が挙がり、クラウド上でSplunkを検証することになったのかを説明します。

スケーラビリティ

　次期システムのアーキテクチャを検討する際は、プロジェクトの目標と現行の課題の解決も併せて検討しました。特に、非機能要件に関わる課題は、アーキテクチャに関わる重要な要素です。

　現在、弊社ではスケーラビリティに関する課題を大きく2つ抱えています。

　1つ目はストレージの容量不足です。フォレンジック業務の要件である保管期間を満たす上で発生している課題です。導入時に設計したディスクの想定容量を既に超えており、運用でカバーしているケースがありました。取り込み対象のログ量が、導入時に想定していた量を大きく上回ったことが原因です。

　2つ目はCPUの性能不足です。サイバー攻撃の多様化に伴い、対応すべきセキュリティのリスクシナリオも年々増えています。監視業務では、定期的にサーチを実行する機能「スケジュールサーチ」を追加した際や、ハンティング業務でアドホックな検索を実施した際に、CPUコア数が足りずにスケジュールサーチがスキップされてしまうことがあります。Splunkは1サーチにつき1CPUコアを消費するので、同時に実行されるサーチ数がCPUのコア数より多くなった場合、サーチがスキップされることがあるのです。サーチの同時実行数を増やすには、CPUを増設したり、サーバを増設して「Search Head」をクラスタ化したりする必要があります。ディスクやCPUのリソースを追加すればいいのですが、機器のEOSLが近いこと、使用しているストレージが非常に高価であることもあり、ディスクの増設やサーバの増設は難しい状態となっています。

　以上のような課題を解決する上で、スケーラブルなクラウドサービスはまさに理想的でした。コンピューティングリソースの増設ができない理由に、機器のEOSLが近いことを挙げましたが、クラウドでは、ソフトウェアのEOSLは存在しても、ハードウェアのEOSLは存在しなくなります。そのため、コンピューティングリソースが足りなくなったタイミングでの増設が容易になります。また、物理的な搬送を行わないので、リソース調達のリードタイムが短縮できるというメリットがありました。

　機器のEOSLという制約から解放されて、目まぐるしく変化するサイバーリスクに対応する上で、新しい技術や機能を迅速にデプロイメントできるシステム環境は弊社SOCにとって不可欠になっています。

運用性の向上

　運用面における課題として、バックアップの取得やステージング／開発環境の確保があります。現行運用ではSplunkの設定ファイルのバックアップを取得しています。バックアップ取得用のスクリプトを作成して、スケジューラによって定期的に実行しているので、メンテナンス性の悪さや属人的な運用という課題を抱えています。また、バックアップが同システム内に保管されているので、システムの障害内容によってはバックアップが失われる可能性を含んでいます。

　また、ステージング／開発環境が不在なので、設定変更が発生した際は検証する環境も存在していません。そのため運用者は、自身の端末にインストールしたSplunkで動作を確認するか、一時的にクラウド上にステージング環境を構築して、動作検証後に本番環境に適用しています。しかし、ステージング環境には本番環境と同等のログデータやサーチが存在していないので、設定変更後に本番環境で不具合を起こすことがあります。

　さらに、サーチ文の開発は本番環境で実施しているので、テスト処理の負荷が本番環境にかかってしまい、内容によってはスケジュールサーチがスキップされてしまうことがあります。

　以上の課題から、メンテナンス性を損なうことなく、バックアップが容易に取得でき、システムの外にバックアップを取得できる環境、必要に応じて構築または起動でき、本番と同様のデータを持つことができる環境が必要でした。オンプレミスの場合、バックアップ用ソフトウェアや保管するためのストレージが必要になります。また、必要なタイミングで購入して不要になったら手放すことが難しく、ステージング／開発環境で本番同等のデータを持つには、データを本番環境とステージング／開発環境の2カ所に転送する必要があります。

　一方、クラウドでは必要に応じた環境の構築や削除が容易なので、現状抱えている課題を解決できる可能性があると判断しました。

なぜAWS？

　一口にクラウドといっても、さまざまなサービスが存在します。ここでは、AWSをプラットフォームとして検証することとし、「Splunk Cloud」やGCPを検証しなかった理由を紹介します。

Splunk Cloudを検証しなかった理由