ノイズの多いテナント：マルチテナントSIEMソリューションにおける公平性エンジニアリング

セキュリティ賞の審査パネルの一部として、5つの人気のあるSIEMソリューションをレビューする機会がありました。各プラットフォームは独自の特色がありましたが、その中核の約束は驚くほど一貫していました：

• 24/7/365 SOCモニタリング： アラートを検証し優先順位をつけるために世界中の専門家によってサポートされる継続的なカバレッジ。
• プロアクティブな脅威ハンティング： 自動トリガーを待つだけではなく、隠れた脅威を能動的に検索。
• AIと機械学習の統合： 基本的な異常検知から「エージェンティックAI」まで、ノイズを削減し調査を加速するためにすべてを活用。
• アクティブなインシデント対応と封じ込め： エンドポイントを隔離したり、侵害されたユーザーを無効化したりして横展開を停止する機能。
• サードパーティツール統合： 「ネイティブスタック」とCrowdStrikeやMicrosoft Defenderなどのサードパーティツールからテレメトリを取り込む。
• 継続的なインテリジェンスアップデート： グローバルリサーチに基づく新しい検出ルールとプレイブックの継続的なストリーム。
• サービスレベル保証： 破損したSLOに対する財務クレジットまたは価格調整。

これらの提供は印象的ですが、明らかな欠落がありました。マルチテナンシーをどのように処理するかについて、誰も議論していませんでした。クラウドネイティブの世界では、これらのプロバイダのほとんど、あるいはすべてが共有インフラストラクチャで動作している可能性が非常に高いです。これは、単一の不正な動作をするテナントがプラットフォーム上の他のすべてのユーザーのセキュリティ態勢を低下させる現象である「ノイズの多い隣人」効果の影響を受けやすいことを意味します。

ノイズの多い隣人効果

セキュリティ運用がクラウドネイティブフレームワークに移行してテレメトリデータの指数関数的成長に対応し、しばしばペタバイトのログに達するため、サービスとしてのソフトウェア（SaaS）の弾力性に依存しています。しかし、独立した顧客間での物理リソース（CPU、メモリ、I/Oを含む）の共有は、重大なエンジニアリングリスクをもたらします。

1つのテナントのワークロードがこれらのリソースの不相応な量を消費する場合、ボトルネックが生じます。他のテナントの場合、これは取り込みレイテンシーの増加、脅威検出の遅延、およびSLOの違反を意味します。セキュリティでは、「遅延した」アラートはアラートなしと同じくらい無用です。

マルチテナントのパラドックス

マルチテナントSIEMソリューションの中核的な魅力は効率性です。共有インフラストラクチャはコストの削減と統一管理につながります。しかし、意図的なエンジニアリングがなければ、これはゼロサムゲームになります。単純なシステムでは、大量のテナントが取り込みパイプラインを飽和させ、小さなテナントに「飢餓」を引き起こす可能性があります。これはこれらの企業が大いに宣伝している「リアルタイム検出と対応（RTDR）」の約束を破ります。

重要な区別は、マルチテナンシーがゼロサムである必要はないということです。この記事で探求される公平性戦略は、その結果を防ぐためにまさに存在していますが、ベンダーがそれに投資した場合のみです。マーケティング資料の沈黙は、多くがそうしていないことを示唆しています。

公平性がエンジニアリング問題である理由

「公平性」をエンジニアリングすることは、単に厳しい制限を設定することだけではありません。それは高度なリソースオーケストレーションについてです。マルチテナントシステムの公平性に関するAWSの論文を読むことを強くお勧めします。厳格な上限はシステムを保護するかもしれませんが、取り込み容量が最も必要な場合の真のセキュリティ緊急事態中にクライアントに罰を与える可能性があります。逆に、完全にオープンなシステムはカスケード障害の危険性があります。

これを解決するために、エンジニアは単純なレート制限を超えて、「フェアシェア」スケジューリング、インテリジェントキューイング、動的リソース割り当てを採用する必要があります。この記事は、隣の家が火事の時でさえ、すべてのテナントが約束されたパフォーマンスを受け取ることを確認するために必要なアーキテクチャ戦略を探求しています。

最新SIEMの解剖学

マルチテナント環境で公平性が失敗する場所を理解するには、まず最新SIEMの解剖学を分析する必要があります。もはやモノリシックなデータベースではなく、ペタバイトのテレメトリを取り込み、変換、分析するために設計された分散データパイプラインです。このパイプラインは、メッセージキューを使用してプロデューサーとコンシューマーを分離することに依存しており、1つのレイヤーのスパイクが必ずしも総システム障害につながらないことを確認しています。

取り込みレイヤー

取り込みレイヤーはシステムの正面玄関です。EDRエージェント、クラウドAPI、ファイアウォールなどの多様なソースから生のテレメトリを収集する責任があります。セキュリティインシデント中に予測不可能にスパイクする可能性がある「消防ホース」の着信データを処理するために、このレイヤーはデータを即座に処理しません。代わりに、生のイベントキュー（通常はApache Kafka）に生のイベントを直接書き込む高スループットバッファーとして機能します。この分離は、ダウンストリーム処理レイヤーが遅い場合でも、システムがデータ損失なく着信ログを受け入れることができることを確認するため重要です。

正規化レイヤー

正規化レイヤーは初期キューから生のイベントを消費します。その主な役割は、異種ログ形式（JSON、XMLまたはSyslog）を共通情報モデル（CIM）のような構造化スキーマに解析することにより、混乱に秩序をもたらすことです。これには、正規表現マッチング、フィールド抽出、エンリッチメントなどのCPU集約的なタスクが含まれます。処理されると、これらの構造化イベントは2番目の正規化イベントキューに発行されます。この中央バスはすべてのダウンストリームコンシューマーの単一の真実のソースになります。

ルールベース検出レイヤー（リアルタイム）

正規化キューの最初のコンシューマーはルールベース検出レイヤーであり、通常は過去2～3年間Apache Flinkのようなエンジンによって駆動されます。このレイヤーはスピード用に最適化され、イベントがパイプを流れるときに低レイテンシーのルールベースロジックを実行します。「1分間の5つの失敗したログイン」などの大量の単純な検出をミリ秒単位で処理します。これらのパターンにすぐにアラートすることで、データがインデックスされるのを待たずに重大な脅威の検出時間を短縮します。

アドホック検索レイヤー

ストリーミングエンジンと並行して、アドホック検索レイヤーも正規化キューから消費します。このシステム（通常はElasticsearchまたはSplunkインデクサーを使用）は人間との相互作用用に最適化されています。データをインデックスしてサブ秒検索と取得をサポートし、セキュリティアナリストが調査と脅威ハンティングを実行できるようにします。ストリーミングレイヤーが既知の脅威を検出する間、このレイヤーはアナリストがインタラクティブなクエリを通じて未知のものを見つけるのを支援します。

ストレージレイヤー（長期保持）

同時に、3番目のコンシューマーが正規化キューから読み取ってストレージレイヤーにデータを永続化します。このレイヤーは耐久性とコスト効率のためにアーキテクチャされており、通常はParquetなどの列形式でAmazon S3などのオブジェクトストレージにデータを書き込みます。この「コールドストレージ」はデータ保持ポリシーへのコンプライアンスを高性能検索層のコストの一部の価格で確保し、保持と計算を効果的に分離します。

分析と相関レイヤー（バッチ）

最後に、分析と相関レイヤーはストレージレイヤーからデータを消費することで動作します。単一のイベントを動きで見るストリーミングエンジンとは異なり、このレイヤーは広大な歴史的データセット全体で複雑なクエリを実行します。「30日間にわたってレアドメインへのビーコン」などの長い時間窓を分析する必要がある洗練されたパターンを検出するためにスケジュールされたジョブを実行します。ストレージではなくリアルタイムストリームから読み取ることにより、これらのリソース集約的なジョブを取り込みと検索パイプラインから隔離します。

SIEMレイヤーの概要

公平性をエンコードするための戦略

意図的な介入がなければ、共有インフラストラクチャは常に最も大きな声を支持するでしょう。弾力的なSIEMを構築するために、エンジニアは隔離を実行し、公正なリソース分配を確保する戦略を実装する必要があります。これらの戦略は一般的に3つのカテゴリに分類されます。アドミッション制御、テナント対応スケジューリング、リソースパーティショニング。

アドミッション制御とレート制限

最初の防衛線は、取り込みパイプラインの最前線にあります。アドミッション制御は、単一のテナントがある閾値を超えて生イベントキューをフラッディングすることができないことを確認します。しかし、最新SIEMは「ハード」レート制限（データは単に削除される）を超えて、「ソフト」制限または成形を代わりに使用します。

一般的なアプローチはトークンバケットアルゴリズムです。各テナントは、ライセンスされた取り込み速度を表す1秒あたりの特定の数のトークンが割り当てられています。スパイク中に、彼らは短期間の間に彼らの制限を超えて「バースト」するために蓄積されたトークンを消費することができます。バケットが空になると、システムは「成形」を開始し、そのテナントの特定のログへの取り込みに軽微な遅延を導入してシステムの全体的な安定性を保護し、重大なセキュリティデータを即座に破棄することなく。

実行中： 10,000イベント/秒で契約されたテナントは、最大60秒間彼らの蓄積されたトークン予備から引き出すことで、15,000 EPSまでバーストすることが許可されるかもしれません。20,000 EPSを生成する実際のインシデントはバケットを使い果たし、成形をトリガーします。彼らのログが遅くなりますが、何も削除されません。その間、プラットフォーム上の他のすべてのテナントは全速力で処理を続けています。

テナント対応フェアシェアスケジューリング

処理レイヤー（正規化や分析など）内で、システムはどのテナントのタスクを次に実行するかを決定する必要があります。単純な「先入先出」（FIFO）モデルでは、あるテナントからの大量のログが他のすべてをブロックします。

エンジニアはこれを加重フェアキューイング（WFQ）を実装することで解決します。すべてのイベントに対する1つの巨大なキューの代わりに、システムは各テナント用の仮想キューを保持しています。スケジューラはこれらのキューを循環させ、各キューから小さなバッチのイベントを拾い上げます。これは、1秒あたり10イベントのみの小さなテナントが1000万を処理する大きなテナントの背後で待つ必要がないことを保証します。この処理タスクの「インターリーブ」は、隣人のアクティビティに関係なく、すべての顧客が進歩することを保証します。

実行中： Kafkaで支援されるSIEMでは、これはトピック内の各テナントに独自のパーティション（またはパーティショングループ）を割り当てることにより実装されます。正規化コンシューマーは、ポーリング周期ごとに各テナントから境界付きの数のレコードを処理するように構成され、ラウンドロビン順序でパーティションを循環させます。ログボリューム50倍のスパイクを生成するテナントは、独自のパーティションが満杯になりますが、コンシューマーはその次のテナントに移動する前に、そのパーティションで公正なシェアを超える処理時間を費やしません。

仮想リソース隔離（クォータと予約）

アドホック検索レイヤーなどのリソース使用が非常に予測不可能なコンポーネントの場合、エンジニアはリソースパーティショニングを使用します。これは、共有計算プール内に論理的な境界を設定することを含みます。

リソースクォータを通じて、SIEMプロバイダーは単一のテナントのクエリが任意の時点で消費できる最大CPUとメモリをキャップすることができます。いくつかの高度なアーキテクチャは、これを保証された予約でさらに進めます。高階層のカスタマーはクラスタリソースの特定の割合が保証される可能性があり、世界的なシステムスパイク中でも、彼らのSOCアナリストは期待する同じサブ秒レイテンシーで検索クエリを実行できることを保証します。

実行中： Elasticsearchでは、これはノードごとの検索スレッドプールサイジングと検索レベルのサーキットブレーカーの組み合わせを通じて実装されます。テナントのクエリは専用ノードセット（シャード割り当てフィルタリングを使用）にルーティングでき、サーキットブレーカー制限は調整ノードレイヤーのテナントごとに構成できます。その結果、90日間のデータ全体で高価な集約を生成する暴走アナリストクエリは、クラスタ全体にカスケードするのではなく、そのメモリ上限に達して正常に失敗します。

テナントごとのバッファリングと分離されたプロセッシング

高度に弾力的なSIEMでは、背圧（ダウンストリーム障害がフロントエンドをデータ受け入れを停止するように強制する）を回避する必要があります。取り込みレイヤーに圧力をかける代わりに、システムは各レイヤーの間に位置するキューをショックアブソーバーとして使用します。

これらのキュー内でテナントごとの仮想パーティションを実装することにより、システムはストレージまたは検索レイヤーのボトルネックが責任のあるテナントの処理速度にのみ影響することを保証できます。1つのテナントのデータが遅く書き込まれている場合、彼らの特定の仮想キューは成長しますが、他のキューは全速力で処理を続けます。これは「ノイズの多い」テナントの検出遅延をもたらしますが、データの完全性を保証します。システムは最終的に、ログを削除したり、プラットフォームの他の部分の実時間パフォーマンスに影響を与えることなく追いつきます。

究極の隔離：物理対論理

上記の戦略は、共有インフラストラクチャ内の公平性に対処しています。しかし、特定の組織の場合、正しい答えはまったく共有がないことです。

最新のクラウド環境では、テナントごとに独立した完全なSIEMスタックをプロビジョニングして割り当てることは完全に実行可能です。この「テナント単位のクラスタ」モデルは、隣がないため、ノイズの多い隣人問題を完全に排除します。各カスタマーの取り込みパイプライン、正規化ワーカー、検索ノード、ストレージバケットは彼らの独自のワークロードに完全に専念しています。

コンプライアンスの含意だけで、これは真摯に検討する価値があります。FedRAMP、ITAR、CJIS等のフレームワークは、しばしば共有マルチテナントクラスタが重大なアーキテクチャの体操なしに満たすことができないコンピュート及びデータ隔離の周りの明示的または暗黙的な要件を有しています。専用クラスタはこれらの要件を清潔に満たし、監査表面領域を削減し、コンプライアンスレビュー中の証拠チェーンを簡素化します。

トレードオフはコストです。専用クラスタは実質的に高いテナントあたりのオーバーヘッドを伴います。アイドル計算はピーク負荷を処理するためにプロビジョニングされなければならず、管理の複雑さはクラスタ数でスケールし、共有SaaSを魅力的にする規模の経済は部分的に放棄されます。実際には、このモデルを提供するプロバイダーは通常、意味のあるプレミアム（マルチテナント相当の2～3倍）を請求し、特定の規制要件を持つエンタープライズまたは公共部門の顧客のためにそれを予約しています。

この決定を評価するセキュリティリーダーのための実用的なフレームワークは簡単です。あなたの組織がコンピュート又はデータ隔離を要件として命名するコンプライアンスフレームワークの下で動作している場合、専用クラスタの会話で開始します。あなたの主な懸念が検出パフォーマンスと費用である場合、ベンダーが共有環境にどのくらい深く公平性をエンジニアリングしたかを理解するために時間を投資してください。その公平性のエンジニアリングが、マルチテナント約束が最も重要な時に保持するかどうかを決定しているからです。

結論

主要なSIEMマーケティングのマルチテナンシーに関する沈黙は、セキュリティリーダーが無視してはいけないリスクです。テレメトリボリュームが爆発し続けるにつれて、「公平性」の背後のエンジニアリングは脅威を検出するAIと同じくらい重要になります。

理想的なSIEMソリューションは両方の世界を提供するべきです。公平性がすべてのレイヤーに深くエンジニアリングされたマルチテナントクラスタの柔軟性、および極端なパフォーマンスまたはコンプライアンス要件を持つ組織のための物理的に隔離された専用クラスタをデプロイするオプション。SIEMプロバイダーが隣の騒々しいテナントをどのように管理するかについて透明性がある場合まで、24/7/365保護の約束は、あなたが知らなかった隣人のアクティビティの危険にさらされたままです。

この記事は、Foundry Expert Contributor Networkの一部として発行されます。
参加したいですか？