実践セキュリティ監視基盤構築(7): セキュリティ監視基盤のアーキテクチャ

この記事はアドベントカレンダー実践セキュリティ監視基盤構築の7日目です。

本日からセキュリティ監視基盤の設計についてお話しします。今回は、このアドベントカレンダーで取り扱う全体のアーキテクチャについて解説します。具体的なコンポーネントやサービスの選定・構成の前に、どの要素がどのような役割を担い、どのように組み合わさるのが望ましいかを整理します。

セキュリティ監視基盤のアーキテクチャ

上の図はアーキテクチャの全体像を示しています。このアーキテクチャで注目すべきポイントは、ログとアラートのパイプラインです。ログを収集し、変換・取り込みを行い、分析可能な状態にしてからアラートを検知し対応するという一連の流れが基本形となります。

各機能について説明します。

ログの収集

各システムからログを収集する機能です。システムログ、アプリケーションログ、ネットワーク機器のログ、クラウドサービスのログなど、多様なログを収集します。ログの収集方法はプッシュ型とプル型に分かれます。プッシュ型はログを送信する側がアクティブにログを送信する方法で、プル型はログを収集する側がアクティブにログを取得する方法です。必要に応じて収集機能を設置します。

収集したログはデータレイクに保存します。データレイクはログをそのまま保存する領域で、データウェアハウスはデータを分析しやすい形に変換して保存する領域です。基本的には安価でスケーラブルなオブジェクトストレージを利用します。

ログの変換・取込

データレイクに保存されたログを適切な形式・スキーマに変換し、データウェアハウスに取り込む機能です。ログの形式やスキーマは多様で、それぞれのログをデータウェアハウスに取り込める適切な形式・スキーマに変換したり、必要な情報を補完する役割があります。通常のデータ基盤におけるETL（Extract, Transform, Load）のTransformとLoadに相当します。

セキュリティ監視に使われるログは、システムを監視したデータであり、各システムが定めたスキーマを利用します。そのため、通常のデータ基盤と比べてログの値の補正はそれほど重要ではありません。逆にスキーマの変更や正規化などの処理の重要性は高くなります。また、データウェアハウスとして使うプロダクトやサービスに応じて、最適化した形式でログを投入することも重要です。これにより、ログの扱いやすさやコストを最適化できます。

ログの調査

ログの調査は、ログから異常を探し出す、アラートに関連するログを見て深刻度を決める（トリアージ）、インシデント発生時の影響範囲の調査のために行われます。基本的に人間が実施し、担当者をアナリストと呼びます。

調査はデータウェアハウスを通して行います。この段階では具体的なインターフェースは規定していませんが、データウェアハウスに直接クエリを発行する場合もあれば、ユーザーインターフェースを設ける場合もあります。マネージドSQLサービスを利用する場合、BIツールを使ってデータウェアハウスに接続することも可能です。構成はアナリストのスキルや調査の頻度によって変わります。

アラート検知

データウェアハウスに保存されたログからアラートを検知する機能です。定期的にデータウェアハウスに問い合わせをするプル型、データウェアハウスに投入された（あるいはこれから投入される）ログを順次受け取ってアラートを検知するプッシュ型があります。プル型は安定して検知処理を実施でき、リトライがしやすいという利点がありますが、遅延が発生しやすいという欠点があります。プッシュ型は遅延が少ない反面、リトライが難しく、検知ロジックの表現や制御が複雑になるという欠点があります。遅延を小さくしたい場合を除いては、プル型を採用することをお勧めします。

アラート対応

検知されたアラートに対して自動的に対応する機能です。一般的にSOAR（Security Orchestration, Automation and Response）と呼ばれる機能に相当します。アラートに対して自動的に処理を行うことで、アナリストの負担を軽減し、迅速な対応を可能にします。ここではデータウェアハウスから検知されたアラートだけでなく、他のシステムが独自に検知したアラートも同じパイプラインで処理します。

対応とは、アラートが発生した対象（端末、インスタンス、ネットワークなど）に対して能動的な操作をするだけでなく、通知やチケット作成、データの収集なども含みます。能動的な対応は誤検知や誤動作のリスクが高いため、管理系の対応に利用されることが多いです。どのアラートを誰にどの手段で通知するか、チケット作成時に誰にアサインしてどの情報を付与するか、どんな関連データを収集するかといった制御が必要であり、それらを管理・自動化することがアラート対応部分の目的です。

構成管理

セキュリティ監視のログおよびアラートのパイプラインとは別に、構成管理についても触れておきます。これはパイプライン側のアーキテクチャに直接影響を及ぼすものではありませんが、継続的なセキュリティ監視を実現するうえで必要な要素です。

ログの収集、変換・取込、調査、アラート検知、アラート対応の各機能を実現するためには、それぞれに設定やルールが必要です。例えば、ログの収集においてはどのログを収集するか、どの形式で収集するか、どのスキーマで保存するかなどの設定が必要です。また、アラート検知においては検知のためのルールやロジックを管理する必要があります。特にアラート検知については継続的に改善をしていく必要があり、頻繁なアップデートに対応できるようにする必要があります。

構成管理は、これらの設定やルールを管理するための仕組みです。具体的には、設定やルールのバージョン管理、適用状況の管理、変更履歴の管理、テスト、自動適用などが含まれます。これらの機能は、バージョン管理システム・サービスを用いて管理し、CI/CDパイプラインを構築することで実現できます。ルールや設定の更新をした際、自動的にテストされて適用されることで、アナリストの負荷を軽減しつつ迅速な対応を可能にします。

本アーキテクチャの特徴

図中の左から右へとログとアラートが流れるパイプラインです。基本的には、ログを集める、変換・取り込む、調査する、アラートを検知する、アラートに対応する、アラートを通知・管理するという流れになります。

特徴(1): データレイクとデータウェアハウス

このアーキテクチャの特徴の一つは、ログの検索を実現するためのデータウェアハウス（DWH）の前にデータレイクの層を挟む点です。データレイクはログをそのまま保存する領域で、データウェアハウスはデータを分析しやすい形に変換して保存する領域です。すべてのログを一度データレイクに保存するのは一見効率が悪いように見えますが、いくつかの利点があります。

• 収集と変換・取込の処理を分離できる: データレイクにはオブジェクトストレージなど、データの形式やスキーマを気にせずに保存できるストレージを利用します。この一時的な保存領域を使うことで、ログの収集と変換・取り込みの処理を分離でき、それぞれ異なるスケールで処理をする、異なるエラー対応戦略をとることが可能になります。
• 収集時にスキーマが不要: データレイクに保存する際には、ログのスキーマを気にする必要がありません。ログの変換・取り込みをしてデータウェアハウスに保存する際には、データのスキーマをあらかじめ定義しておく必要がありますが、データレイクの場合はそれがなくてもまず自分たちの基盤へログを持ってくることができます。これにより、まずはログを集めることに集中し、その後に後段の処理を構築することが可能になります。
• リトライの容易性: データレイクに保存されたログは、何度でも取り込み処理をやり直すことができます。ログの収集は基盤と別システムの連携部分であり、自分たちのコントロール外であることが多いです。そのためデータ転送やリトライ処理に対するコストが比較的高く、気軽に何度もログの収集ができない場合が多いです。

これらの特性により、ログ収集、変換、取り込みの処理の可用性や運用の容易さを向上させることができます。セキュリティ監視に使うログの特徴として、ほぼすべてのログのスキーマが自分たちのコントロール外にあることがあります。そのため、スキーマの仕様が不明であったり、変更されたりすることが多いです。データレイクを使うことで、こういったトラブルに対応しやすくなるのが大きな利点です。

データレイクの保存域としてオブジェクトストレージを用いた場合、ストレージコストも低額で、オブジェクトのライフサイクル管理を導入することで一定期間経過後に自動的に削除できるため、全体的にコストも抑えられます。

特徴(2): 多様なログやアラートの取り込み

もう一つの特徴は、データレイクやDWH、アラート対応の処理に直接ログ・アラートを取り込める構造にしている点です。システムやサービスによっては、ログやアラートを直接出力してくれる機能を持っている場合があります。例えば、定期的にCloud Storageへ出力したり、BigQueryへ直接書き込んでくれる機能です。

そのような場合、パイプラインの先頭から処理するのではなく、その機能を活かすことで、全体的な複雑性を低減しつつ、コストも抑えることができます。特にGoogle Cloudを利用している場合、Cloud LoggingやAudit LogsなどのサービスはログをそのままBigQueryに取り込むことができるため、途中の処理を大幅に省くことができます。

また、アラートについても、システム内での不審な行動を検知してくれるサービスがあります。このようなアラートは直接アラート対応のプロセスに取り込むことができるため、アラートの検知から対応までの時間を短縮できます。

（番外編）より高機能なアーキテクチャ

今回は取り扱いませんが、より機能性を高めたアーキテクチャも紹介しておきたいと思います。データレイク以前とアラート対応以降は省略していますが、基本的には先程の図に検索エンジンと検知エンジンの2つを追加したアーキテクチャになります。

追加したコンポーネントの役割は以下のとおりです。

• 検索エンジン: Elasticsearchのような高速にログを検索・分析するために利用します。データウェアハウスに比べてコストが高くなりがちで長期間のログを保有するには不向きですが、頻繁にログの検索や分析をするのであれば非常に有用です。
• 検知エンジン: 変換までしたログを直接取込み、不審なイベントがあれば即座にアラートとするコンポーネントです。データウェアハウスからの検知に比べて遅延が小さいのが特徴です。筆者の知る限りこの目的に特化したツールはあまり一般にはないという認識で、個別に実現するのであれば自分で実装する必要があります。また、検索エンジンがこの機能を有する場合もあります。

この構成は遅延の最小化と検索のユーザビリティ向上という観点で、今回のアドベントカレンダーで取り扱うアーキテクチャに比べて高機能であると言えます。ただし全体のシステム利用料だけでなく、運用コストも大きく増加するため、どのくらいセキュリティ監視基盤を使い倒すかを踏まえて検討するのが良いでしょう。基本的には専任で監視に携わるメンバーが数人以上いる場合に、効果を発揮すると考えています。

まとめ

本記事では、セキュリティ監視基盤のアーキテクチャについて解説しました。セキュリティ監視基盤は、ログの収集からアラートの対応までの一連の流れをパイプラインとして捉え、それぞれの機能がどのような役割を担い、どのように組み合わさるのが望ましいかを整理しました。

具体的なサービス、コンポーネント、実装についてはこのあと詳しく解説していきますが、このアーキテクチャ自体はある程度一般化されたものであり、これから説明する内容以外で設計・実装することも可能です。独自のセキュリティ監視基盤を実装する際にも、この考え方が参考になれば幸いです。

次回からは、セキュリティ監視基盤に取り入れるデータについて解説していきます。