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を検証しなかった理由

　Splunkのクラウド化ということを検討する場合、Splunk Cloudをイメージする人がいるのではないでしょうか。Splunk CloudはSplunk社が提供するSaaSです。このサービスを利用すると、自前でSplunkを構築する必要がなく、最短2日でSplunk環境を利用できるようになります。また、インフラを管理する必要がないため、運用工数の削減が見込めるという利点があります。Splunkの構築や運用の経験がない場合やSplunk Cloudの制約に引っ掛かる要件がない場合は、非常にメリットの多いサービスだと思います。

　では、なぜSplunk Cloudを検証しなかったのでしょうか。主な理由は次の3点です。

・【1】柔軟性

　Splunk Cloudの場合、自前で開発したスクリプト（以降、カスタムスクリプト）や作成したアラート（以降、カスタムアラート）の設定、データの取り込みには「Splunk Support」への申請および審査が必要です。設定の反映までには数日〜数週間程度のリードタイムが発生します。また、リソース制限を引き上げたい場合など、システム環境全体に影響を与えるような設定変更については、申請しても承認されない可能性もあります。

　弊社では、カスタムスクリプトでデータを取得してルックアップとして使用しているので、これらの制限やリードタイムがネックとなってしまいました。

・【2】運用人件費

　「Splunk Cloudを使用することでインフラ管理が不要になる」と述べましたが、完全に不要になるわけではありません。SplunkのSearch Headや「Indexer」などの主要なコンポーネントの管理は不要になりますが、Splunk Cloudにデータを転送する「Forwarder（Gateway Forwarder）」や、その管理を担う「Deployment Server」は自組織で管理する必要があります。

　そのため、Splunkのことを理解しているエンジニアが必要なことに変わりはなく、Splunk Cloudにかかるコストと運用体制を維持するのに必要なコストを考慮した際に、Splunk Cloudには大きなメリットがなかったのです。

Splunk Cloudにデータを転送する

・【3】ステージング／開発環境のランニングコスト

　本番環境とは別にステージング／開発環境を持とうとすると、単純に2倍のコストがかかってしまいます。常に利用できる必要はなく、必要な時に必要な本番相当のデータが利用できればよく、ステージング／開発環境のランニングコストを考えると、こちらも弊社にとってのメリットがありませんでした。

AWSか、GCPか

　次に、IaaSを使ってクラウド上にSplunkを構築することを検討しました。IaaSにおいて、弊社の中の他システムでも比較的よく利用されているAWSとGCPの2つが候補に挙がりましたが、結論からいうと、当時はAWSで検証することになりました。

　まず、2つのサービスを検討した2019年7月時点においては、Splunkの拡張モジュール「Add-on」がAWSにしか対応していませんでした。このAdd-onが、「Amazon S3」や「Amazon Simple Notification Service」（SNS）、「Amazon Simple Queue Service」（SQS）といったAWSのマネージドサービスとの連携を容易にしてくれます。Add-onが提供されていないGCPでの構築はAWSで構築するよりも難易度が高く、運用が複雑になる可能性がありました。

　また、当時検討していた「Splunk Enterprise」の7.3系は、Splunkに取り込むデータの保管先としてS3のオブジェクトストレージを使用できる機能「Splunk SmartStore」（以降、S2）が使えたので、コスト削減効果を期待できました。しかし、GCPの「Google Cloud Storage」（GCS）はS2に対応していなかったことがAWSで検証した最大の要因となっています。

　なおSplunk社は、2020年12月にGCP対応のAdd-onをリリースし、Splunk Enterprise 8.1からGCSにおけるS2を正式にサポートしています。今後、クラウド上でのSplunk構築を検討している方は、GCPでの構築も十分に視野に入れられるのではないかと思っています。

次回は、AWSでSplunkを構築するにはどういった構成が推奨されるのか

　本稿ではプロジェクトの背景や概要、クラウドを検討した理由、その中でもAWSで検証した理由を紹介しました。

　次回は、検証で構築した環境や検証内容、トラブルシューティングなどでハマったポイントもふまえて、「AWSでSplunkを構築するにはどういった構成が推奨されるのか」を紹介します。また、最後に少しだけ触れたS2についても、より深く掘り下げて紹介するので、楽しみにしていてください。

筆者紹介

田村 由佳（たむら ゆか）

株式会社リクルート リスクマネジメント担当 セキュリティ推進室 セキュリティオペレーションセンター ソリューションアーキテクトグループ 兼 インシデントレスポンスグループ所属。

5年間、SIerに在籍。インフラエンジニアとして、主にサーバやセキュリティアプライアンスの設計や構築を担当。2018年から現職において、Splunk基盤の運用や次期ログ分析基盤の検証を担当。現在はインシデントレスポンスグループで攻撃者の思考回路をトレースしながら、どんな悪いことができるのか日々勉強中。BigQueryやSplunkなどを用いたログ分析に情熱を注いでいる。