Microsoft Sentinel data lakeは、Microsoft Sentinelで扱うセキュリティデータを長期保管し、KQLやJupyter notebooksで分析できるクラウドネイティブなセキュリティデータレイクです。2026年4月22日に更新されたMicrosoft公式ドキュメントでは、単なる「ログの保管場所」ではなく、SIEM運用、脅威ハンティング、フォレンジック、コンプライアンス監査をつなぐ中核基盤としての位置付けが明確になっています。(Microsoft Learn)
特に押さえるべきポイントは、データをAnalytics tierとData lake tierに分けてコストと性能を最適化できること、最大12年の長期保持に対応すること、KQLジョブやJupyter notebooksで過去データを分析できること、そしてMicrosoft Purviewの監査ログでデータアクセスやジョブ実行を追跡できることです。security admins、identity teams、compliance teamsは、まず「どのログをリアルタイム検知に使い、どのログを長期分析・監査用に保持するか」を整理するところから始めるべきです。(aka.ms)
Microsoft Sentinel data lakeとは
Microsoft Sentinel data lakeは、Microsoft Sentinelに取り込むセキュリティ関連データを一元的に保存し、長期保持と高度な分析に使うためのデータレイクです。Microsoftの説明では、Microsoft Defender XDR、サードパーティ製品、資産情報、アクティビティログ、脅威インテリジェンスなどのデータを、オープン形式で拡張可能なプラットフォームに集約する仕組みとされています。(Microsoft Learn)
従来のSIEM運用では、ログを長く保持したい一方で、ストレージ費用やクエリ性能、運用負荷が課題になりやすいです。Microsoft Sentinel data lakeは、この課題に対して「すべてを高コストなリアルタイム分析用ストレージに置く」のではなく、用途に応じてデータ階層を分ける設計を取っています。
実務では、次のような使い分けが重要です。
| 用途 | 向いているデータ | Microsoft Sentinel data lakeでの扱い |
|---|---|---|
| リアルタイム検知 | 重大アラート、EDR、認証失敗、特権操作 | Analytics tierで保持し、分析ルールやハンティングに利用 |
| 長期調査 | 数か月前のサインイン、DNS、Firewall、Proxyログ | Data lake tierで保持し、必要時にKQLやNotebookで分析 |
| コンプライアンス | 監査証跡、保持義務のあるログ | 長期保持ポリシーを設計し、監査ログと組み合わせて管理 |
| フォレンジック | 侵害範囲調査、過去の横展開痕跡 | Data lakeの履歴データを検索し、必要なデータをAnalytics tierへ昇格 |
重要なのは、data lakeを「安価な倉庫」とだけ捉えないことです。インシデント発生後に過去ログを深掘りする、低頻度だが重要なログを保持する、IDや資産情報とイベントを突き合わせるといった用途で価値を発揮します。
2026年4月更新で押さえるべき主なポイント
2026年4月22日更新の概要ページでは、Microsoft Sentinel data lakeの価値が、長期保持、単一コピー、複数分析エンジン、AI・自動化、監査対応という観点で整理されています。セキュリティ運用の現場では、特に次の5点を確認しておくとよいでしょう。(Microsoft Learn)
単一コピーのデータを複数の分析手段で使える
Microsoft Sentinel data lakeは、セキュリティデータを単一コピーとして保持し、KQLやJupyter notebooksなど複数の分析手段から利用できる設計です。これにより、同じログを別システムに複製して分析する必要を減らし、データ管理をシンプルにできます。(Microsoft Learn)
たとえば、SOCアナリストはKQLで過去のサインインログを調査し、データサイエンス寄りの担当者はJupyter notebooksで異常検知モデルや可視化を試す、といった分担が可能です。特定の調査だけに必要なログを別の分析基盤へ移すより、Sentinelの文脈の中で調査を完結しやすくなります。
Analytics tierとData lake tierの役割が明確になった
Microsoft Sentinelでは、データ保持を大きくAnalytics tierとData lake tierに分けて考えます。Analytics tierはリアルタイム分析、アラート、ハンティング、ワークブックなどに使う高性能な領域です。一方、Data lake tierは長期保持や履歴分析、監査、フォレンジックに向いた低コストの領域です。(aka.ms)
| 比較項目 | Analytics tier | Data lake tier |
|---|---|---|
| 主な目的 | リアルタイム検知、アラート、ハンティング | 長期保持、履歴調査、監査、傾向分析 |
| 向いているログ | 直近の重要ログ、検知ルール対象ログ | 大容量・低頻度参照のログ、過去調査用ログ |
| クエリ性能 | 高速な対話型分析向け | 長期データ分析向け。リアルタイム用途には不向き |
| 利用シーン | インシデント対応、分析ルール、ワークブック | 過去ログ検索、KQLジョブ、Notebook分析 |
| 保持期間の考え方 | 既定保持に加え、必要に応じて延長 | Analytics tierを超える長期保持に利用 |
失敗しやすいのは、コスト削減だけを目的に重要ログをData lake tierへ寄せすぎることです。Data lake tierのデータはリアルタイム分析機能や脅威ハンティングの一部用途には向きません。検知に必要なログはAnalytics tierに置き、調査・監査に必要なログはData lake tierに置く、という切り分けが基本です。(aka.ms)
最大12年の長期保持が設計上の重要ポイントになる
Microsoft公式ドキュメントでは、Data lake tierで最大12年のセキュリティデータ保持に対応することが示されています。これは、規制対応、内部監査、長期的な脅威分析を行う組織にとって大きな意味があります。(Microsoft Learn)
ただし、「すべてのログを12年保持すればよい」という話ではありません。保持期間を決めるときは、次のようにログの価値とコストを分けて考えるべきです。
| ログ種別 | 推奨される考え方 |
|---|---|
| サインインログ、特権操作ログ | ID侵害調査で重要。長期保持の優先度が高い |
| EDRイベント | 容量が大きくなりやすい。重大端末や高リスク環境を優先 |
| Firewall、DNS、Proxyログ | ノイズは多いが、侵害範囲調査では有用。Data lake tier向き |
| クラウドリソース操作ログ | 設定変更や権限昇格の追跡に重要 |
| メール、コラボレーション関連ログ | フィッシング、内部不正、情報漏えい調査で有用 |
コンプライアンス担当者は、法令名や社内規程だけで保持期間を決めるのではなく、「調査時にどの粒度のログが必要か」までsecurity adminsとすり合わせる必要があります。保持期間が長くても、必要なテーブルが対象外であれば、インシデント調査では役に立ちません。
KQLジョブで過去データをAnalytics tierへ昇格できる
Microsoft Sentinel data lakeでは、KQLを使ってData lake上のデータを探索できます。さらにKQL jobsを使うと、1回限りまたはスケジュール実行の非同期クエリを実行し、調査に必要な履歴データをAnalytics tierへ昇格できます。(Microsoft Learn)
これは、ゼロデイ脆弱性や新しい攻撃キャンペーンが公表された後の調査で特に役立ちます。たとえば、6か月前から存在していた不審な通信先が判明した場合、Data lakeに保持しているDNSやProxyログをKQLで検索し、該当期間のデータをAnalytics tierへ昇格して詳細な相関分析を行えます。
実務では、次のような流れが現実的です。
| 手順 | 作業内容 | 担当の例 |
|---|---|---|
| 事前設計 | 長期保持すべきテーブルを決める | security admins、compliance teams |
| 調査開始 | IoC、ユーザー、端末、期間を定義する | SOC、脅威ハンティング担当 |
| Data lake検索 | KQLで履歴データを絞り込む | SOC、IR担当 |
| 昇格 | 必要なデータをAnalytics tierへ移して相関分析する | SOC、Sentinel管理者 |
| 再発防止 | 検知ルール、保持設定、ダッシュボードを見直す | security admins、identity teams |
ポイントは、KQLジョブを「調査時だけの便利機能」にしないことです。頻出する調査パターンはスケジュールジョブや標準クエリとして整備しておくと、緊急時の初動が速くなります。
Jupyter notebooksで高度な分析や可視化に対応する
Microsoft Sentinel data lakeでは、Jupyter notebooksを使った分析も重要な要素です。公式ドキュメントでは、Microsoft Sentinel Visual Studio Code拡張機能を通じて、PySpark、Pythonライブラリ、機械学習、可視化を活用できると説明されています。(Microsoft Learn)
KQLはセキュリティ調査に強く、Notebookは大量データの変換、統計分析、可視化、機械学習に向いています。たとえば、次のような場面でNotebookが有効です。
| シーン | Notebookが役立つ理由 |
|---|---|
| 失敗サインインの傾向分析 | ユーザーごとの通常パターンを可視化し、異常を見つけやすい |
| 内部不正リスクの分析 | ユーザー、端末、データアクセス、組織情報を組み合わせやすい |
| 低速な横展開の検出 | 長期間にわたる小さな兆候を時系列で分析できる |
| 経営層向けレポート | グラフや説明付きの分析結果を共有しやすい |
| カスタムリスクスコア | 重要資産、ユーザー属性、イベントを組み合わせて評価できる |
一方で、Notebookは自由度が高い分、属人化しやすいです。共有前提で使う場合は、入力データ、実行条件、前提、出力結果をNotebook内に明記し、再現できる形にしておくことが重要です。
対象読者別に見る実務上の影響
Microsoft Sentinel data lakeの更新ポイントは、担当ロールによって見え方が変わります。ここでは、security admins、identity teams、compliance teamsの観点で、確認すべき事項を整理します。
security adminsが確認すべきこと
security adminsにとって重要なのは、データ保持の設計と運用コストの制御です。Microsoft Sentinel data lakeにより、長期保持の選択肢は広がりますが、テーブルごとの保持設定、Analytics tierとData lake tierの使い分け、コスト監視を設計しないと、期待した効果が出ません。
まず確認すべき項目は次の通りです。
| 確認項目 | 判断基準 |
|---|---|
| どのログをAnalytics tierに置くか | リアルタイム検知、アラート、ハンティングに必要か |
| どのログをData lake tier中心にするか | 大容量だが、普段は参照頻度が低いか |
| 保持期間をどう決めるか | 調査要件、監査要件、データ量、コストを比較する |
| KQLジョブをどう使うか | 過去調査、定期集計、データ昇格のパターンを標準化する |
| コストをどう監視するか | Azure Cost ManagementやDefenderポータルで使用量を確認する |
Microsoftのコスト管理ドキュメントでは、Microsoft Sentinel利用後はAzure Cost Managementの機能を使って予算、予測コスト、支出傾向を確認でき、Sentinel data lake有効化後はMicrosoft Defenderポータルでも使用量を確認できると説明されています。(Microsoft Learn)
identity teamsが確認すべきこと
identity teamsにとってMicrosoft Sentinel data lakeが重要なのは、Microsoft Entra IDのサインイン、ユーザーリスク、権限、アプリ、グループなどの情報を、セキュリティイベントと組み合わせて分析しやすくなるためです。
たとえば、次のような調査に向いています。
| 調査テーマ | 見るべきデータの例 |
|---|---|
| アカウント侵害 | サインインログ、失敗ログ、MFAイベント、場所、端末 |
| 特権IDの悪用 | ロール変更、管理操作、アプリ同意、条件付きアクセスの変化 |
| 横展開 | ユーザー、端末、クラウドリソース、アプリ利用履歴 |
| 退職者・休職者のリスク | アクセス履歴、データ操作、権限残存 |
| アプリ経由の不審アクセス | サービスプリンシパル、OAuth同意、APIアクセス |
KQLのdata lake探索シナリオでは、IDログや資産情報を組み合わせ、ユーザー活動とリソースを関連付けることで、より広い攻撃範囲を把握できるとされています。(Microsoft Learn)
identity teamsは、単にログをSentinelへ送るだけでなく、「どのIDイベントが長期的に意味を持つか」を定義する必要があります。特に、特権ID、外部ユーザー、サービスアカウント、重要アプリケーションのログは、Data lake tierでの長期保持候補になります。
compliance teamsが確認すべきこと
compliance teamsにとっては、データの保持期間、保存地域、アクセス監査が重要です。Microsoft Sentinelの地理的可用性とデータ所在地に関する公式ドキュメントでは、収集されたRaw dataはMicrosoft Sentinelに関連付けられたAzure Log Analyticsワークスペースと同じリージョンに保存されると説明されています。(Microsoft Learn)
日本の環境では、Microsoft Sentinel SIEMの対応リージョンとしてJapan EastとJapan Westが示され、Data lake supported regionとしてJapan Eastが示されています。グローバル企業では、テナント、Microsoft 365データ、Sentinelワークスペース、data lakeリージョンの関係を事前に確認することが重要です。(Microsoft Learn)
また、Microsoft Sentinel data lakeとgraphのアクティビティはMicrosoft Purviewの監査ログで検索でき、KQLによるlakeデータアクセス、Notebook実行、ジョブの作成・編集・実行・削除などが監査対象として示されています。(Microsoft Learn)
コンプライアンス観点では、次の3点を事前に文書化しておくと運用しやすくなります。
| 文書化すべき項目 | 具体例 |
|---|---|
| データ保持ポリシー | テーブル別の保持期間、保持理由、削除方針 |
| データ所在地 | ワークスペースリージョン、data lakeリージョン、越境データの有無 |
| アクセス監査 | 誰がKQLを実行したか、誰がNotebookを実行したか、誰がジョブを変更したか |
特にグローバル展開では、「セキュリティ上は長期保持したいが、地域のデータ保護要件では慎重な扱いが必要」という衝突が起きやすいです。技術設定だけで解決しようとせず、法務、プライバシー、セキュリティ、IT運用が同じ保持ポリシーを確認する必要があります。
導入前に確認したい前提条件
Microsoft Sentinel data lakeを使う前に、オンボーディング条件を確認しておく必要があります。公式ドキュメントでは、Microsoft DefenderとMicrosoft Sentinelが構成済みであること、Azureサブスクリプションとリソースグループが必要であること、Microsoft SentinelのPrimary workspaceがDefenderポータルに接続されていることなどが前提として示されています。(Microsoft Learn)
特に見落としやすいのは、Customer-Managed Keys、つまりCMKに関する制約です。公式ドキュメントでは、Microsoft Sentinel data lakeに保存されるデータではCMKがサポートされず、CMKを適用しているSentinelワークスペースはdata lakeエクスペリエンスからアクセスできないと説明されています。(Microsoft Learn)
導入前チェックリストは次の通りです。
| チェック項目 | 確認内容 |
|---|---|
| Defenderポータル連携 | Microsoft SentinelのPrimary workspaceがDefenderポータルに接続されているか |
| リージョン | Primary workspaceとdata lakeのリージョン要件を満たしているか |
| 権限 | サブスクリプション、ワークスペース、Entra IDに必要な権限があるか |
| CMK要件 | CMK利用ポリシーとdata lakeの仕様が矛盾しないか |
| Microsoft 365データ | データ所在地とdata lakeリージョンの関係を確認したか |
| コスト | 保持期間、データ量、クエリ、処理コストの見込みを確認したか |
| 監査 | Purview監査ログを確認できる権限と運用手順があるか |
この段階でCMK、リージョン、権限のいずれかに問題があると、導入後に運用設計をやり直すことになりやすいです。特に大企業や規制業種では、技術検証より先にデータ所在地と暗号化ポリシーを確認することをおすすめします。
権限設計で注意すべきポイント
Microsoft Sentinelでは、SIEM側の権限にAzure RBAC、data lake側の権限にMicrosoft Entra ID RBACが使われます。公式ドキュメントでは、Microsoft Sentinel SIEMにはAzure RBAC、Microsoft Sentinel data lakeにはMicrosoft Entra ID RBACを使うと説明されています。(Microsoft Learn)
ここで注意したいのは、「Sentinelの閲覧権限があるからdata lakeのすべての操作ができる」とは限らないことです。Microsoft Sentinel ReaderやContributorなどのAzure組み込みロールにはdata lakeサポートが示されていますが、操作範囲はロールごとに異なります。(Microsoft Learn)
権限設計では、次のように分けて考えると安全です。
| ロール設計の観点 | 推奨される考え方 |
|---|---|
| SOCアナリスト | 調査に必要な閲覧・KQL実行権限を付与 |
| IR担当 | 必要に応じてジョブ実行やデータ昇格を許可 |
| Detection engineer | KQLジョブ、分析ルール、保持設計に関わる権限を整理 |
| Compliance担当 | 監査ログ閲覧、保持ポリシー確認に必要な権限を付与 |
| 管理者 | 最小権限を基本にし、Global Administrator常用を避ける |
Microsoftは、組織のセキュリティ向上のために最小権限のロールを使うことを推奨しており、Global Administratorは既存ロールで対応できない緊急時に限定すべき高権限ロールとしています。(Microsoft Learn)
コスト最適化の考え方
Microsoft Sentinel data lakeの大きな価値は、セキュリティログの長期保持を現実的にしやすい点です。ただし、保持期間を伸ばすほど無条件にコストが下がるわけではありません。データ取り込み、保存、処理、クエリ、Analytics tierへの昇格など、複数の要素でコストが発生します。(aka.ms)
コスト設計では、次の順番で考えると失敗しにくいです。
| 順番 | 検討内容 | 例 |
|---|---|---|
| 1 | 検知に必要なログを決める | EDR、認証、特権操作はAnalytics tier中心 |
| 2 | 長期保持が必要なログを決める | DNS、Proxy、Firewall、資産情報はData lake tier候補 |
| 3 | 保持期間をテーブル別に決める | 90日、1年、3年、7年などを用途別に設定 |
| 4 | クエリ頻度を見積もる | 毎日見るログと、調査時だけ見るログを分ける |
| 5 | 月次で使用量をレビューする | 予算超過、急増テーブル、不要ログを確認 |
よくある失敗は、ログ取り込み時点ではコストを抑えたつもりでも、後から頻繁にData lakeへ重いクエリを実行し、結果的に運用コストや調査時間が増えることです。頻繁に見るログはAnalytics tier、めったに見ないが必要なログはData lake tier、という基本を崩さないことが重要です。
具体的な活用シーン
Microsoft Sentinel data lakeは、導入しただけでは効果が出ません。どのような調査や業務で使うかを事前に決めることで、セキュリティ運用に組み込みやすくなります。
数か月前から続いていた認証攻撃を調査する
認証攻撃は、短期間の大量試行だけとは限りません。低頻度で長期間続くパスワードスプレーや、地理的に分散した不審サインインでは、直近30日や90日だけでは全体像をつかめないことがあります。
Data lake tierにサインインログやユーザー関連ログを保持していれば、数か月単位で失敗サインイン、成功サインイン、MFA結果、端末、IPアドレスを分析できます。identity teamsは、通常のサインイン傾向と異なるユーザーやアプリを抽出し、SOCと連携して侵害範囲を絞り込めます。
新しいIoCが出た後に過去ログを遡る
脅威インテリジェンスで新しい悪性ドメイン、IPアドレス、ファイルハッシュが公開された場合、重要なのは「今ブロックすること」だけではありません。過去に自社環境で接触があったかを調べる必要があります。
Data lakeにDNS、Proxy、Firewall、EDRログを保持していれば、過去数か月から数年のデータに対してKQLジョブを実行できます。該当する通信や端末が見つかった場合は、関連データをAnalytics tierへ昇格し、インシデントとして詳細調査できます。(Microsoft Learn)
監査証跡を長期保持し、アクセスも監査する
コンプライアンス対応では、ログを保持するだけでなく、「誰がそのログにアクセスしたか」も重要です。Microsoft Sentinel data lakeとgraphのアクティビティはMicrosoft Purviewの監査ログで扱われ、KQLアクセス、Notebook実行、ジョブ操作などを確認できます。(Microsoft Learn)
たとえば、内部調査や規制対応で特定ユーザーの履歴を検索した場合、その検索操作自体も監査対象として追跡できます。これは、セキュリティチームの強力な権限を統制するうえで重要です。
導入時に避けたい失敗
Microsoft Sentinel data lakeの導入でよくある失敗は、機能単位で設定を進めてしまい、運用ルールが後回しになることです。特に次の点には注意してください。
| 失敗しやすいポイント | 起きる問題 | 対策 |
|---|---|---|
| 重要ログをData lake tierに寄せすぎる | リアルタイム検知やハンティングで使いにくくなる | 検知対象ログはAnalytics tierに残す |
| 保持期間を一律にする | コスト増または調査不足が起きる | テーブル別に保持理由を決める |
| CMK要件を後から確認する | 導入後にポリシー不一致が判明する | 事前に暗号化要件を確認する |
| 権限設計を広くしすぎる | 不要なデータアクセスや監査リスクが増える | 最小権限でロールを分ける |
| 監査ログを見ていない | 不正・過剰な検索に気付けない | Purview監査ログの確認手順を作る |
| リージョンを軽視する | データ所在地や越境データの問題が起きる | Primary workspaceとdata lakeのリージョンを確認する |
| Notebookが属人化する | 調査結果を再現できない | Notebookに前提、入力、出力、判断理由を残す |
まず実施すべきアクション
Microsoft Sentinel data lakeを検討している組織は、いきなり全ログの長期保持を始めるのではなく、小さく設計して段階的に広げるのが現実的です。
最初に実施すべきことは、次の5つです。
| 優先度 | アクション | 目的 |
|---|---|---|
| 高 | 現在のSentinelテーブルと保持期間を棚卸しする | 何をどれだけ保持しているか把握する |
| 高 | リアルタイム検知に必要なログを分類する | Analytics tierに残すべきデータを決める |
| 高 | 長期調査・監査に必要なログを分類する | Data lake tierの対象を決める |
| 中 | リージョン、CMK、権限、Purview監査を確認する | 導入後の手戻りを防ぐ |
| 中 | 代表的な調査クエリとKQLジョブを作る | インシデント時にすぐ使える形にする |
Microsoft Sentinel data lakeは、ログ保管コストを下げるためだけの機能ではありません。リアルタイム検知、長期フォレンジック、ID調査、コンプライアンス監査をつなぐ基盤として設計すると価値が出ます。
security adminsはテーブル階層とコストを設計し、identity teamsは長期的に意味のあるIDログを定義し、compliance teamsは保持期間・データ所在地・監査証跡を確認する。この3者が同じ設計図を持てれば、Microsoft Sentinel data lakeは単なるログ置き場ではなく、グローバルなセキュリティ運用を支える分析基盤として機能します。
コメント