Microsoft Sentinel Data Lakeでコスパ良くセキュリティログを長期保管する
最近、マイクロソフトから Microsoft Sentinel Data Lake がパブリックプレビューとして発表されました[1] 。このデータレイクを使うことで、より簡単に、コスパよくデータの長期保存ができるようになります。そこで今回は、データレイク機能について掘り下げていきます。
セキュリティログ管理のジレンマ
世界全体のデータ量が年々爆増しているとはよく言われていることですが、それに伴いセキュリティログも急激に増加し、多くのセキュリティチームは厳しい選択を迫られています。全部のログを永久的に分析可能な状態（Sentinelでいう分析層＝Analytics Tier）で保管すると膨大な費用が掛かるので、ログ収集範囲を縮小して死角を作るか、追従性・監査性を犠牲にして保持期間を短縮するなどの対応策で工面している会社は多いのではないかと思います。
あるいは、SIEMに取り込まずSyslogサーバーやBlobストレージなどに別保管するなどの対応をしている企業もありますが、これは「安かろう・悪かろう」という感覚で、ひとたび調査が必要となった場合には分析基盤への取り込みが必要となり効率的とは言えませんし、定常的な監視・アラート検出には不向きです。お金のあるエンプラだったら、金に物を言わせて全てのログを分析層で保管して解決することもありますが持続可能ではありませんし、コスパがいいとは言えません。
Microsoft Sentinel Data Lake
そんな中、登場したMicrosoft Sentinel Data Lakeでは、より安く・簡単にデータを長期保管することができます。加えて、通常のSentinelの保管先である「分析層」と比較して制限はあるものの、KQLを利用したクエリにも対応しており、インシデント発生時等に長期保管していたログから「何か」を取り出したいときに最適な基盤となっています。
分析層とデータレイク層の比較
分析層とデータレイク層、およびそれぞれの主要な特徴については、MS社がまとめていた表が非常に分かりやすかったので引用してきました。[2]手抜きではないです。
| 項目 | 分析層（Analytics Tier） | データレイク層（Data Lake Tier） |
|---|---|---|
| 主な特徴 | ログの高性能クエリとインデックス作成（ホットまたはインタラクティブ保持とも呼ばれる） | 大量データのコスト効率的な長期保持（コールドストレージとも呼ばれる） |
| 最適な用途 | リアルタイム分析ルール、アラート、ハンティング、ワークブック、およびすべてのMicrosoft Sentinel機能 | コンプライアンスおよび規制ロギング、履歴トレンド分析とフォレンジック、リアルタイムアラートが不要なあまり触れられないデータ |
| 取り込みコスト | 標準 | 最小限 |
| クエリ価格 | 込み ✅ | 別途課金 ❌ |
| 最適化されたクエリパフォーマンス | ✅ | クエリが遅い ❌ 監査に適しているが、リアルタイム分析には最適化されていない |
| クエリ機能 | Microsoft DefenderおよびAzureポータルでの完全なクエリ機能、およびAPIの使用 | 単一テーブルでの完全なKQL（ルックアップを使用して分析テーブルのデータで拡張可能）、スケジュールされたKQLまたはSparkジョブの実行、ノートブックの使用 |
| リアルタイム分析機能 | フルセット ✅ | 制限あり ❌ 分析ルール、ハンティングクエリ、パーサー、ウォッチリスト、ワークブック、プレイブックなどの一部機能に制限 |
| 検索ジョブ | ✅ | ✅ |
| サマリー ルール | ✅ | ✅ |
| KQL | フル機能 | 単一テーブルに限定 |
| 復元 | ✅ | ❌ |
| データエクスポート | ✅ | ❌ |
| 保持期間 | Microsoft Sentinelは90日間、Microsoft Defender XDRは30日間。比例配分された月額長期保持料金で最大2年まで延長可能 | デフォルトでは分析保持と同じ。最大12年まで延長可能 |
ちなみに、コストについては単純比較できませんが、Sentinelの従量課金（Pay-as-you-go）で分析層に取り込んだ場合1GBあたり$4.3 USDかかりますが、データレイクでは取り込みに1GBあたり$0.05、格納データに対して1GBあたり0.026ドル/月となっています。[3]
Microsoft Sentinelデータレイクを使ってみる
前提条件
Microsoft Sentinelデータレイクのパブリックプレビューにオンボードするには、以下の前提条件を満たす必要があります。
- Microsoft DefenderとMicrosoft SentinelがDefender XDRに統合されて利用可能であること
- データレイクの請求用の既存のAzureサブスクリプションとリソースグループがあること、サブスクリプションの所有者権限を持っていること
- Microsoft DefenderポータルにMicrosoft Sentinelプライマリワークスペースが接続されていること
- プライマリおよびその他のワークスペースへの読み取り権限があり、データレイクにアタッチできることが必要です。
- Microsoft Sentinelプライマリワークスペースとその他のワークスペースがテナントのホームリージョンと同じリージョンにあること（パブリックプレビューの制約）
オンボーディング（初期設定）[4]
テナントをMicrosoft Sentinelデータレイクにオンボードする手順は簡単です。前提条件として、SIEMワークスペース機能を通じてSentinelをDefenderポータルに接続します。こちらについては、前職時代にブログを書いているのでそちらを参照ください。
続いて、Defender XDRポータル（ https://security.microsoft.com ）で、[システム] > [設定] > [Microsoft Sentinel] > [データレイク] のデータレイク設定ページに遷移します。すべての前提条件が満たされると、接続ボタンが表示されます。「セットアップの開始」ボタンをクリックすると、設定の画面が起動します。すべての情報を入力したら、「データレイクのセットアップ」をクリックします。データレイクが完全に作成され、Defenderテナントにリンクされるまでに最大60分かかります。
プロセスが進行中の場合、「レイクのセットアップが進行中」というメッセージが表示されます。しばらく待つと、データレイクのセットアップが完了します。
ちなみに、セットアップが完了すると、Defender XDRに新しいデータレイク探索ビューが表示されます。また、その際「default」という名前のワークスペースが作成されます。KQLクエリのワークスペースセレクターに表示される「Default」ワークスペースは、オンボード時にMicrosoft Sentinelデータレイクによって作成されます。
データレイク層でログを長期保管する
Microsoft Sentinelにログを取り込むデータコネクタは、規定では分析層と長期保存用のデータレイク層の両方にデータを送信するように構成されています。Sentinelデータコネクタが有効になると、データは分析層にプッシュされ、データレイク層に自動的にミラーリングされます。分析層と同じ保持期間でデータレイクにデータをミラーリングしても、追加の請求料金は発生しません。[5]
そして、データレイク設定後、以下の画像のように保持期間が延長された場合にのみ、データレイクとしてストレージに追加コストが発生します。設定は [Defender XDRポータル] > [Microsoft Sentinel] > [Configuration] > [Tables] でテーブル単位で実施できます。
データレイク層に直接データを取り込む
別の方法として、データレイク層にのみデータを取り込むことも可能です。FWの生ログやEntraIDの [AADNonInteractiveUserSignInLogs] などは、分析層に直接取り込むと非常に高コストになります。新しいデータレイクを使用すると、データを直接データレイクにストリーミングし、Sentinelの分析層をスキップできます。これにより、データはデータレイク層にのみ取り込まれ、分析層への取り込みは停止され、データはデータレイクにのみ保存されます。
KQL queris
データレイク層の特徴として、データを貯めておくだけではなく、KQLクエリを実行するとログの調査を行うことができる点にあります。これは言葉にすると安っぽいですが、実は重要なことで、これまで安いストレージ（Blob等）にログを保管する場合、分析を行うためには分析用の基板に取り込んでから分析する必要があり手間でありました。一方、データレイクでは、価格を安く抑えながら、調査したい場合はクイックにクエリを実行できる点が非常に良きです。
Serch & Restore
上述の通り、データレイク層においてのKQLを使った調査には制約がありますが、制約を取っ払ってガッツリと調査したい場合にはデータを分析層にリストアすることもできます。[Serch & Restore] のタブでテーブルと期間を選択し、データをリストアするとAdvanced Huntingでデータを調査できます。
しかしながら、下記のようにデータの形式はAdvanced Huntingに直接取り込んだ形式とは異なるので、その点には注意が必要です。
Jobs
加えて、Jobs を使用して、データレイクから少量のデータを分析層に直接移動させることができます。ジョブは、データレイク層のデータに対してKQLクエリを実行し、結果を分析層に昇格させる機能です。単発または定期実行のスケジュールされたタスクを実行できます。
分析層のストレージは、データレイク層よりも高い請求レートが発生しますが、KQLを使用することで、データを削減・フィルタリングしてコストを節約しながら分析層に昇格できます。これにより、データ全体はデータレイク層に送りつつ、特定の条件でログが分析層に送信され、さらなるハンティングに利用できるようになります。
Jobs でデータを移動する際のテーブルはJobsで利用する専用のテーブルを利用(作成)する形となります。そのため、テーブル名が変わることに伴うクエリの変更等が後々発生する場合があるので注意が必要です。
Sentinelのワークスペースを選択して、クエリを書きます。
スケジュール設定では、ワンショット・日時・週次・月次で実行スパンを選べます。
ジョブが実行されると、完了したジョブは一覧で確認できます。
前述の通り、データを移行する際には別テーブルを作成（選択）するので、Advanced HuntingではCustamm Logsという形式で見ることになります。
まとめ
これまでも、Blob等を使えば安くデータを長期保管できましたが、構築や運用を含めてコスパがいいとは言えませんでしたが、Data Lake の登場によりコスパが非常に良くなったように思います。また、興味深いのは、マイクロソフト社がこのデータレイクを単なる安い保管オプションではなく、「エージェント化された AI の導入を加速させるもの」と言っている点です。今だと、Data Lakeによるデータのサイロ化の抑制という価値が見えて来ていますが、そこから先のAIの活用についてもMSはビジョンを持って取り組んでいることが見えているので今後も注視していきたいです。
Discussion