Microsoft DefenderポータルからMicrosoft Sentinel data lakeに対してKQLクエリを実行できるようになると、長期保管されたセキュリティログを調査・集計・分析に使いやすくなります。結論として、管理者が最初に確認すべきなのは、オンボーディング状況、ワークスペースの範囲、権限、保持期間、課金、クエリ制限です。Microsoft Learnの該当ドキュメントは2026年5月14日に更新されており、Data lake explorationのKQL queriesで、データレイクリソースやフェデレーションテーブルに対するクエリ作成・編集・実行、ジョブ作成、非同期クエリ、Azure Data Explorerからの接続などが整理されています。(Microsoft Learn)
Microsoft Defenderのセキュリティ更新で何ができるようになるのか
今回確認すべきポイントは、Microsoft DefenderポータルのData lake explorationで、Microsoft Sentinel data lakeに対してKQLを実行できる点です。これにより、SOC担当者やセキュリティ管理者は、分析層だけでなくデータレイク層に保存されたログも、KQLで探索できるようになります。
公式情報では、KQL queriesページで次の操作が可能とされています。
| 機能 | できること | 実務での使いどころ |
|---|---|---|
| KQLクエリエディター | KQLの作成、編集、実行 | インシデント調査、脅威ハンティング、ログ確認 |
| 複数ワークスペース選択 | 単一または複数のワークスペースを対象にクエリ実行 | 部門別・環境別ワークスペースを横断調査 |
| フェデレーションテーブル | System tablesを選択してクエリ | Microsoft Entra ID、Microsoft 365、Azure Resource Graphなどの資産情報確認 |
| 非同期クエリ | 長時間かかるクエリをサーバー側で実行 | 広い期間の調査、重い集計、履歴分析 |
| KQLジョブ | 1回限りまたはスケジュール実行 | 調査結果の分析層への昇格、集計テーブル作成 |
| Azure Data Explorer連携 | ADXからデータレイクに接続 | 既存のADX運用や高度な分析基盤との連携 |
重要なのは、これは単なる検索画面の追加ではないという点です。長期保管されたセキュリティデータを、調査・集計・再分析・分析層への昇格に使うための運用機能として捉えるべきです。
影響を受ける管理者・開発者・運用チーム
影響範囲は、Microsoft Defenderを操作するSOC担当者だけに限られません。Microsoft Sentinelのワークスペース、保持期間、課金、アクセス権限に関わる担当者も確認が必要です。
| 対象者 | 主な影響 | 確認すべきこと |
|---|---|---|
| セキュリティ管理者 | 長期ログをDefenderポータル上で調査しやすくなる | データレイクのオンボーディング、対象ワークスペース、権限 |
| SOCアナリスト | 過去ログや複数ワークスペースを横断した調査が可能になる | クエリ範囲、時間条件、結果件数、非同期クエリの使い分け |
| Microsoft Sentinel管理者 | ワークスペース接続、保持期間、データ階層の設計が重要になる | Analytics tierとData lake tierの使い分け |
| ID・権限管理担当 | Microsoft Entra IDロールとAzure RBACの設計が必要になる | 最小権限、行レベルRBAC、Unified RBAC |
| 開発者・データエンジニア | ADXやKQLジョブを使った自動化・集計が可能になる | external_table()、スキーマ整合性、未対応関数 |
| コスト管理担当 | クエリ実行、保持期間、分析層への昇格で費用が変わる | 課金メーター、保存期間、昇格対象データ |
特に注意したいのは、Microsoft Sentinel data lakeへのオンボーディング後、同じリージョンでDefenderに接続されているワークスペースが自動的にデータレイクへ関連付けられる点です。ワークスペース単位で自由にオンボード対象を選べる運用ではないため、事前に接続済みワークスペースとリージョンを棚卸ししておく必要があります。(Microsoft Learn)
まず確認すべき前提条件
KQLクエリを実行するには、Microsoft Sentinel data lakeへのオンボーディングが完了している必要があります。公式ドキュメントでは、Microsoft DefenderポータルでKQLを実行する前提として、データレイクへのオンボーディングと適切な権限が挙げられています。(Microsoft Learn)
オンボーディング前に確認する項目
| 確認項目 | 判断基準 | 注意点 |
|---|---|---|
| Microsoft DefenderとMicrosoft Sentinelの構成 | DefenderポータルとSentinelが利用可能か | Microsoft SentinelをDefenderポータルに接続しておく |
| プライマリワークスペース | SentinelのプライマリワークスペースがDefenderに接続されているか | データレイクはプライマリワークスペースと同じリージョンに作成される |
| Azureサブスクリプション | 課金用のサブスクリプションとリソースグループがあるか | 管理グループ単位の所有者では不十分な場合がある |
| リージョン | 対象ワークスペースが同じリージョンにあるか | 同一リージョンのDefender接続済みワークスペースが対象になる |
| 暗号化ポリシー | Customer-Managed Keysを使っていないか | data lakeに保存されるデータではCMKがサポートされない |
| データ所在地 | Microsoft 365データとdata lakeのリージョンが一致するか | 異なる場合、data lakeのリージョンへ取り込むことへの同意が必要 |
| Azure Policy | 必要なリソース展開がブロックされないか | 必要に応じて対象リソースタイプのポリシー例外を検討 |
CMKを前提にした厳格な暗号化ポリシーを採用している組織では、特に慎重に判断する必要があります。公式情報では、CMKはMicrosoft Sentinel data lakeに保存されるデータではサポートされず、CMKを適用しているSentinelワークスペースはdata lakeのエクスペリエンスからアクセスできないと説明されています。(Microsoft Learn)
権限設計で注意すべきポイント
Microsoft Sentinel data lakeでは、全体アクセスにはMicrosoft Entra IDロール、個別ワークスペースへのアクセスにはAzure RBACを使う構成になります。ここを曖昧にすると、想定以上のワークスペースやテーブルにアクセスできる状態になりやすいため、最小権限で設計することが重要です。
公式情報では、data lake全体の読み取りにはGlobal reader、Security reader、Security operator、Security administrator、Global administratorなどのMicrosoft Entra IDロールが示されています。一方、特定ワークスペースに対する読み取りでは、Log Analytics Reader、Microsoft Sentinel Reader、ReaderなどのAzure RBACロールが使われます。(Microsoft Learn)
権限設計の実務判断
| やりたいこと | 推奨される考え方 | 避けたい設定 |
|---|---|---|
| SOCアナリストに調査を任せる | 必要なワークスペースだけに読み取り権限を付与 | Global Administratorを日常運用に使う |
| 全社横断で脅威ハンティングする | Security readerなどの広域ロールを検討 | 部門データの閲覧範囲を未定義にする |
| KQLジョブを作成・管理する | Security operator以上など、必要な書き込み権限を確認 | 読み取り権限だけでジョブ運用を始める |
| テーブル単位で制限したい | resource-context RBAC、Table-level RBAC、Defender XDR Unified RBACを検討 | ワークスペース全体を安易に開放する |
| 機密データを含むログを扱う | 行レベルRBACやMicrosoft Sentinel scopingを確認 | クエリ結果の閲覧範囲をユーザー任せにする |
Microsoftは、権限は累積されるため、複数ロールを持つユーザーが意図以上の権限を持つ可能性があると説明しています。既存のAzure RBAC、Log Analytics権限、Microsoft Sentinelロール、Entra IDロールをまとめて棚卸ししてください。(Microsoft Learn)
KQLクエリ実行時の基本操作と実務上のコツ
Data lake explorationのKQL queriesでは、新しいクエリタブを作成し、対象ワークスペースを選択してKQLを実行します。クエリ履歴は30日間保存され、過去に実行したクエリを開いて再実行できます。(Microsoft Learn)
実務では、いきなり広範囲のログに対して重いクエリを実行するのではなく、次の順序で確認すると失敗しにくくなります。
| 手順 | 操作 | 確認ポイント |
|---|---|---|
| 1 | 対象ワークスペースを選択 | 本番・検証・部門別ワークスペースを取り違えない |
| 2 | スキーマブラウザーでテーブルを確認 | 空テーブルは表示されない場合がある |
| 3 | 時間範囲を狭く設定 | まずは直近1日や数時間で試す |
| 4 | takeやprojectで結果を絞る | 取得行数と列数を抑える |
| 5 | 条件を追加してから範囲を広げる | 広範囲クエリは非同期クエリを検討 |
| 6 | 必要に応じてCSV出力 | 監査証跡や分析資料に利用 |
複数ワークスペースを選択した場合、同じ名前とスキーマを持つテーブルには既定でunion()演算子が適用されます。特定ワークスペースだけを対象にしたい場合は、workspace()演算子を使って明示するのが安全です。(Microsoft Learn)
workspace("MyWorkspace").AuditLogs
| where TimeGenerated between (datetime(2026-04-01) .. datetime(2026-04-30))
| take 100フェデレーションテーブルを扱う場合は、時間範囲の指定にも注意が必要です。TimeGenerated列がない、または形式が適切でないフェデレーションテーブルでは、画面上部のタイムピッカーが期待どおりに機能しません。その場合は、KQL内で対象列を使って時間条件を明示してください。(Microsoft Learn)
非同期クエリとKQLジョブの使い分け
通常の対話クエリは、調査中に素早く結果を確認する用途に向いています。一方、長期間のログを対象にした集計や、複数テーブルのjoin、履歴データのスキャンは、非同期クエリやKQLジョブを使った方が安定します。
| 使い分け | 向いている用途 | 注意点 |
|---|---|---|
| 通常のKQLクエリ | 短時間の調査、少量データの確認、条件作成 | 結果サイズやタイムアウト制限に注意 |
| 非同期クエリ | 広範囲の履歴調査、時間がかかる集計 | 結果は24時間保存される |
| KQLジョブ | 定期集計、分析層への昇格、調査結果テーブル作成 | 出力先テーブルのスキーマ整合性が必要 |
| ADX接続 | 既存ADX運用からの分析、外部分析基盤との連携 | data lakeテーブル参照にはexternal_table()を使う |
非同期クエリは、長時間かかるクエリをサーバー側で実行し、完了後に結果を取得する仕組みです。公式情報では、非同期クエリの同時実行はテナントあたり3、実行タイムアウトは1時間、結果キャッシュは24時間とされています。(Microsoft Learn)
KQLジョブは、1回限りまたはスケジュール実行できるKQL処理です。インシデント対応での長時間クエリ、低頻度ログを使ったエンリッチメント、過去の脅威インテリジェンス照合、異常検知などに適しています。また、data lake tierの結果をanalytics tierへ昇格させることで、Advanced hunting側でさらに分析する運用も可能です。(Microsoft Learn)
ただし、analytics tierはdata lake tierより高い課金になる場合があります。昇格するデータは、whereで対象を絞り、projectで必要な列だけに限定するのが基本です。
DeviceEvents
| where TimeGenerated between (ago(180d) .. ago(90d))
| where ActionType has "Process"
| summarize EventCount = count() by bin(TimeGenerated, 1d), DeviceName上記のような履歴集計は、まず短い期間で検証し、結果件数・列・実行時間を確認してから、非同期クエリやジョブ化を検討してください。
Analytics tierとData lake tierの違いを理解する
Microsoft Sentinel data lakeを使ううえで、最も重要なのはAnalytics tierとData lake tierを混同しないことです。
Analytics tierは、アラート、リアルタイム分析、ハンティング、ワークブックなどの高性能な運用に向いています。一方、Data lake tierは、長期保管、履歴分析、フォレンジック、監査向けの低コスト保管に向いています。公式情報では、data lake tierはリアルタイム分析や脅威ハンティング向けではなく、KQLジョブ、Sparkジョブ、ノートブックなどで必要時にアクセスする層として説明されています。(aka.ms)
| 比較項目 | Analytics tier | Data lake tier |
|---|---|---|
| 主な用途 | リアルタイム検知、アラート、ハンティング、ワークブック | 長期保管、履歴分析、監査、フォレンジック |
| クエリ性能 | 高性能 | Analytics tierより遅い |
| コスト設計 | 高性能な分析向け | 大容量・長期保存向け |
| リアルタイム機能 | 利用可能 | 一部機能に制限あり |
| 保持期間 | Microsoft Sentinelは既定90日、Microsoft Defender XDRは既定30日など | analytics retentionと同じ期間が既定。最大12年まで拡張可能 |
| 昇格 | 不要 | KQLジョブやNotebookジョブでanalytics tierへ昇格可能 |
運用上の失敗で多いのは、コスト削減だけを目的に重要なテーブルをdata lake tierへ移してしまい、リアルタイム検知やハンティングが動かなくなるケースです。公式情報でも、テーブルの階層をanalyticsからdata lakeへ変更すると、リアルタイム分析やハンティングクエリが停止すると説明されています。(aka.ms)
クエリ制限・未対応機能・遅延に注意する
Microsoft Sentinel data lakeへのKQL実行には、通常のLog AnalyticsやAdvanced huntingと同じ感覚では扱えない制限があります。特に、長期データを扱う場合は、クエリ範囲を広げすぎないことが重要です。
| 項目 | 公式情報で示されている制限・注意点 | 実務上の対策 |
|---|---|---|
| 結果サイズ | 最大64MB | 必要な列だけprojectする |
| 結果行数 | 最大500,000行 | summarizeやtakeで絞る |
| 対話クエリ数 | 1分あたり45件 | 自動連打や検証スクリプトを避ける |
| クエリ可能期間 | 保持期間に応じて最大12年 | 保持ポリシーを事前確認 |
| データ反映 | 取り込み後、クエリ可能になるまで約15分の遅延 | 直近ログ調査ではanalytics tierやAdvanced huntingも併用 |
| レガシーテーブル | AzureDiagnosticsなど一部レガシーテーブルは非対応 | 対象テーブルを事前に確認 |
| 空テーブル | スキーマビューに表示されず、データが入るまでクエリ不可 | 初回取り込み後に再確認 |
| カスタム関数 | out-of-the-box関数やカスタム関数は非対応 | クエリ内にロジックを展開 |
| 外部データ呼び出し | KQLから外部データ呼び出しは非対応 | 事前に取り込み・別ジョブで加工 |
| 未対応演算子・関数 | adx()、arg()、externaldata()、ingestion_time()は非対応 | 代替ロジックを設計 |
公式ドキュメントでは、data lakeへのKQLクエリはanalytics tierよりパフォーマンスが低いため、履歴データの探索やdata lake-only modeのテーブルを扱う場合に使うべきとされています。(Microsoft Learn)
コスト管理で確認すべきポイント
KQL queries against the Microsoft Sentinel data lakeは便利ですが、実行そのものや保持期間、analytics tierへの昇格にはコストが関係します。公式情報では、data lakeに対するKQLクエリ実行はクエリ課金メーターに基づいて課金されると説明されています。(Microsoft Learn)
コストを抑えるには、次の考え方が有効です。
| コストが増えやすい操作 | 原因 | 対策 |
|---|---|---|
| 長期間を対象にした広範囲クエリ | 読み取るデータ量が増える | まず短期間で検証し、条件を絞る |
| 多数列の取得 | 結果サイズが増える | projectで必要列だけ取得 |
| analytics tierへの大量昇格 | 高性能分析層の保存・処理対象が増える | 必要な結果だけ昇格する |
| スケジュールジョブの乱立 | 定期的に処理コストが発生 | 実行頻度と対象期間を明確化 |
| data lake長期保持の拡大 | 保存期間が長くなる | 法務・監査要件に合わせて保持期間を決める |
Microsoft Defender XDRデータは、既定でAdvanced huntingに30日間利用できる前提があります。保持期間を延ばす場合やdata lake tierへ直接取り込む場合は、取り込み・保存・処理のコストを事前に見積もる必要があります。(aka.ms)
管理者が展開前に確認すべきチェックリスト
本番展開前には、次の項目を順番に確認してください。
ワークスペースとデータ範囲
- Defenderポータルに接続済みのMicrosoft Sentinelワークスペースを一覧化する
- プライマリワークスペースのリージョンを確認する
- 同一リージョンで自動的にdata lakeへ関連付けられるワークスペースを確認する
- Microsoft 365データのリージョンとdata lakeのリージョン差異を確認する
- data lakeへ取り込むテーブルとanalytics tierに残すテーブルを分ける
権限と監査
- Global Administratorを日常運用に使わない
- SOCアナリストには必要なワークスペースの読み取り権限を付与する
- KQLジョブ作成者には必要な書き込み・ジョブ管理権限を付与する
- 行レベルRBACやMicrosoft Sentinel scopingの必要性を確認する
- data lakeのクエリ実行、ジョブ作成・削除などの監査ログを確認できる体制を作る
Microsoft Sentinel data lakeでは、KQLクエリによるデータアクセス、ノートブック実行、ジョブの作成・編集・実行・削除などが監査対象として示されています。監査は既定で有効とされています。(Microsoft Learn)
クエリとジョブ設計
- 初回は短い時間範囲でKQLを検証する
where TimeGeneratedを明示して、不要なスキャンを避ける- 複数ワークスペース選択時の
union()挙動を理解する - 特定ワークスペースは
workspace()で明示する - 長時間クエリは非同期クエリまたはKQLジョブへ切り替える
- ジョブ出力先のテーブルスキーマを確認する
- analytics tierへ昇格するデータは必要最小限にする
移行・運用変更
- Azure portal中心のMicrosoft Sentinel運用からDefenderポータル中心の運用へ移行計画を作る
- Advanced huntingで見ていたテーブルがdata lake側へ移る可能性を確認する
- 補助ログテーブルの扱いを確認する
- 既存KQLで未対応関数・外部データ参照・カスタム関数を使っていないか確認する
- ADXから接続する場合は
external_table()前提でクエリを見直す
Microsoft Sentinelは、2027年3月31日以降Azure portalでサポートされなくなり、Defenderポータルのみで利用される予定と公式に案内されています。現在Azure portal中心で運用している組織は、data lake対応とあわせてDefenderポータルへの移行計画を進めるべきです。(Microsoft Learn)
よくある失敗と回避策
対象ワークスペースを間違えてクエリしてしまう
Data lake explorationでは、選択したワークスペースがクエリタブ全体に適用されます。複数タブで作業している場合でも、ワークスペース選択が想定どおりか確認してください。
回避策は、重要な調査クエリではworkspace("ワークスペース名")を使って対象を明示することです。
時間範囲を広げすぎて失敗する
最大12年のデータを扱えるからといって、最初から広範囲を検索するのは危険です。結果サイズ、行数、タイムアウト、コストの問題が発生しやすくなります。
まず1日、次に7日、最後に必要な期間という順番で広げると、無駄なスキャンを避けられます。
data lake tierをリアルタイム検知に使おうとする
Data lake tierは長期保管や履歴分析に向いた層であり、リアルタイム検知や高頻度ハンティングには向きません。アラートや即時調査が必要なテーブルは、analytics tierに置くか、必要な結果だけをKQLジョブで昇格する設計にしてください。
権限を広く付けすぎる
Microsoft Entra IDロールでdata lake全体への読み取り権限を付与すると、複数ワークスペースのデータに広くアクセスできる可能性があります。部門別データ、個人情報、内部不正調査ログなどを扱う場合は、ワークスペース単位・テーブル単位・行レベルの制御を検討してください。
既存KQLをそのまま流用して動かない
data lakeのKQLでは、すべての既存クエリがそのまま動くとは限りません。特に、外部データ呼び出し、カスタム関数、未対応演算子を使っているクエリは修正が必要です。移行時は、よく使うKQLを一覧化し、data lakeで実行できるか検証してください。
開発者が確認すべきADX連携のポイント
Azure Data ExplorerからMicrosoft Sentinel data lakeに対してKQLを実行する場合、接続先URIとしてhttps://api.securityplatform.microsoft.com/lake/kqlが示されています。また、ADXからdata lake内のテーブルをクエリする場合は、external_table()関数を使う必要があります。(Microsoft Learn)
external_table("AADRiskyUsers")
| take 100既存のADXクエリ資産を流用する場合は、次の点を確認してください。
- 参照するテーブルがdata lake上で利用可能か
external_table()形式に書き換えられるか- 未対応関数を使っていないか
- 時間範囲をKQL側で明示しているか
- 結果サイズが64MBや500,000行の上限に近づいていないか
- 自動実行する場合、課金と実行頻度が妥当か
開発者視点では、data lakeを「大きなログ保管庫」と見るだけでなく、KQLジョブやADX連携によって、調査結果を再利用可能な分析データに変換する基盤として設計するのが効果的です。
次に取るべき対応
Microsoft DefenderポータルからMicrosoft Sentinel data lakeへKQLを実行できる機能は、長期ログの調査や履歴分析を強化します。一方で、ワークスペース範囲、権限、保持期間、課金、クエリ制限を確認しないまま展開すると、意図しないデータ閲覧やコスト増、リアルタイム検知の停止につながる可能性があります。
まずは、次の3点から着手してください。
- 対象ワークスペースと保持期間を棚卸しする
- SOC担当者・管理者・開発者ごとの権限を見直す
- 代表的なKQLを短い期間で検証し、非同期クエリやKQLジョブに分ける
本番運用では、data lake tierを長期保管と履歴分析、analytics tierをリアルタイム検知と高性能調査に使い分けることが重要です。Microsoft DefenderとMicrosoft Sentinelを統合運用している組織では、2027年のDefenderポータル中心運用への移行も見据え、KQL、権限、保持期間、コスト管理をセットで整備しておきましょう。
コメント