Microsoft Sentinel データレイクで KQL ジョブを作成する

KQL ジョブは、Microsoft Sentinel データレイクとフェデレーションテーブル内のデータに対する 1 回限りの KQL クエリまたはスケジュールされた KQL クエリです。次のような調査および分析シナリオにジョブを使用します。

インシデント調査とインシデント対応 (IR) に対する実行時間の長い 1 回限りのクエリ
忠実度の低いログを使用したエンリッチメントワークフローをサポートするデータ集計タスク
過去の脅威インテリジェンス (TI) 照合スキャンによる振り返り分析
複数のテーブル間で異常なパターンを識別する異常検出スキャン

KQL ジョブは、クエリが異なるデータセット間で結合または和集合を使用する場合に特に効果的です。

ジョブを使用して、データレイク層から分析層にデータを昇格します。分析レベルに入ったら、高度なハンティング KQL エディターを使用してデータのクエリを実行します。分析レベルへのデータの昇格には、次の利点があります。

分析レベルまたはフェデレーションテーブルの現在のデータと履歴データを組み合わせて、データに対して高度な分析と機械学習モデルを実行します。
分析レベルでクエリを実行することで、クエリコストを削減します。
複数のワークスペースのデータを分析レベルの 1 つのワークスペースに結合します。
分析レベルでMicrosoft Entra ID、Microsoft 365、および Microsoft Resource Graph データを組み合わせて、データソース間で高度な分析を実行します。

注:

分析レベルのストレージでは、データレイク層よりも高い課金率が発生します。コストを削減するには、さらに分析する必要があるデータのみを昇格させます。クエリの KQL を使用して、必要な列のみを投影し、データをフィルター処理して分析層に昇格するデータの量を減らします。

データを新しいテーブルに昇格させたり、分析レベルの既存のテーブルに結果を追加したりできます。新しいテーブルを作成するときに、テーブル名に _KQL_CL を付けて、テーブルが KQL ジョブによって作成されたことを示します。

必要に応じて、KQL ジョブの出力を Data Lake レベルの別のテーブルに書き込んで、調査を高速化したり、強化されたデータを脅威ハンティングに使用したりできます。新しいテーブルを作成するときに、システムテーブルワークスペースに書き込む場合、テーブル名のサフィックスは _KQL になります。

前提条件

Microsoft Sentinel データレイクで KQL ジョブを作成および管理するには、次の前提条件が必要です。

データレイクへのオンボード

Microsoft Sentinel データレイクで KQL ジョブを作成して管理するには、まずデータレイクにオンボードする必要があります。データレイクへのオンボードの詳細については、「Microsoft Sentinel データレイクへのオンボード」を参照してください。

アクセス許可

Microsoft Entra IDロールは、データレイク内のすべてのワークスペースに広範なアクセスを提供します。すべてのワークスペースでテーブルを読み取り、分析レベルに書き込み、KQL クエリを使用してジョブをスケジュールするには、サポートされている Microsoft Entra ID ロールのいずれかが必要です。ロールとアクセス許可の詳細については、「data lake ロールとアクセス許可のMicrosoft Sentinel」を参照してください。

分析レベルで新しいカスタムテーブルを作成するには、 Log Analytics ワークスペースの Log Analytics 共同作成者 ロールを Data Lake マネージド ID に割り当てます。

ロールを割り当てるには、次の手順に従います。

Azure portalで、ロールを割り当てる Log Analytics ワークスペースに移動します。
左側のナビゲーションウィンドウで [ アクセス制御 (IAM)] を選択します。
[ ロールの割り当ての追加] を選択します。
[ロール] テーブルで、[*Log Analytics 共同作成者] を選択し、[次へ] を選択します。
[ マネージド ID] を選択し、[ メンバーの選択] を選択します。
Data Lake マネージド ID は、 msg-resources-<guid> という名前のシステム割り当てマネージド ID です。マネージド ID を選択し、[選択] を選択します。
[ 確認と割り当て] を選択します。

マネージド ID へのロールの割り当ての詳細については、「Azure portalを使用してAzureロールを割り当てる」を参照してください。

ジョブを作成する

スケジュールまたは 1 回限り実行するジョブを作成できます。ジョブを作成するときに、結果の対象のワークスペースとテーブルを指定します。結果を新しいテーブルに書き込むか、分析またはデータレイク層の既存のテーブルに追加できます。結果をフェデレーションテーブルに書き込むできません。新しい KQL ジョブを作成することも、クエリとジョブの設定を含むテンプレートからジョブを作成することもできます。詳細については、「テンプレートから KQL ジョブを作成する」を参照してください。

KQL クエリエディターまたはジョブ管理ページからジョブ作成プロセスを開始します。
1. KQL クエリエディターからジョブを作成するには、クエリエディターの右上隅にある [ ジョブの作成 ] ボタンを選択します。
2. ジョブ管理ページからジョブを作成するには、[Microsoft Sentinel>Data lake exploration>Jobs] を選択し、[ジョブの作成] ボタンを選択します。
ジョブ名を入力します。ジョブ名は、テナントに対して一意である必要があります。ジョブ名には、最大 256 文字を含めることができます。ジョブ名に # または - を使用することはできません。
ジョブのコンテキストと目的を指定するジョブの説明を入力します。
[ ワークスペースの選択 ] ドロップダウンから、対象のワークスペースを選択します。このワークスペースには、クエリ結果を書き込むシステムテーブルまたはSentinel ワークスペースのいずれかを指定できます。
変換先のテーブルを選択します。
1. 既存のテーブルに追加するには、[ 既存のテーブルに追加] を選択し、ドロップダウンリストからテーブル名を選択します。既存のテーブルに追加する場合、クエリ結果は既存のテーブルのスキーマと一致する必要があります。
[次へ] を選択します。
[クエリの準備] パネルで クエリを 確認または記述します。日付範囲がクエリで指定されていない場合は、時間ピッカーがジョブに必要な時間範囲に設定されていることを確認します。
[選択したワークスペース] ドロップダウンから、クエリを実行する ワークスペースを選択 します。これらのワークスペースは、クエリを実行するテーブルを持つソースワークスペースです。選択したワークスペースによって、クエリに使用できるテーブルが決まります。選択したワークスペースは、クエリエディターのすべてのクエリタブに適用されます。複数のワークスペースを使用する場合、 union() 演算子は、異なるワークスペースの名前とスキーマが同じテーブルに既定で適用されます。 workspace("MyWorkspace").AuditLogsなど、特定のワークスペースからテーブルを照会するには、workspace() 演算子を使用します。

注:

既存のテーブルに書き込む場合、クエリは、変換先テーブルスキーマと一致するスキーマで結果を返す必要があります。クエリが正しいスキーマで結果を返さない場合、ジョブの実行時に失敗します。

システムテーブルへの KQL ジョブの書き込みは現在プレビュー段階です。
[次へ] を選択します。

[ クエリジョブのスケジュール] ページで、ジョブを 1 回実行するか、スケジュールに従って実行するかを選択します。 [1 回限り] を選択すると、ジョブ定義が完了するとすぐにジョブが実行されます。 [スケジュール] を選択した場合は、ジョブの実行日時を指定するか、定期的なスケジュールでジョブを実行できます。
[ 1 回限り ] または [ スケジュールされたジョブ] を選択します。

注:

1 回限りのジョブを編集すると、すぐに実行がトリガーされます。
[スケジュール] を選択した場合は、次の詳細を入力します。
1. ドロップダウンから [ 繰り返し頻度] を選択します。分単位、時間単位、 日単位、 週単位、または 月単位を選択できます。
2. 選択した頻度に対してジョブを実行する頻度の [ Repeat every]\(すべての繰り返し \) の値を設定します。
3. [ スケジュールの設定] で、[ 開始日 ] を選択し、時刻を入力します。 [開始] フィールドのジョブ開始時刻は、ジョブの作成後少なくとも 30 分後である必要があります。ジョブは、この日付と時刻から [ Run every ]\(すべての実行\) ドロップダウンで選択した頻度に従って実行されます。
4. [ 終了日] を 選択し、ジョブスケジュールがいつ終了するかを指定する時刻を入力します。スケジュールを無期限に継続する場合は、[ジョブを無期限 に実行するように設定する] を選択します。
ジョブの開始時刻と時刻は、ユーザーのロケールに対して設定されます。

注:

たとえば、30 分ごとに高頻度で実行するようにジョブをスケジュールする場合は、データレイクでデータが使用可能になるまでにかかる時間を考慮する必要があります。通常、新しく取り込まれたデータをクエリに使用できるようになるまで、最大 15 分の待機時間があります。
[ 次へ ] を選択して、ジョブの詳細を確認します。
ジョブの詳細を確認し、[ 送信] を選択してジョブを作成します。ジョブが 1 回限りのジョブの場合は、[送信] を選択した後に実行 されます。ジョブがスケジュールされている場合は、[ジョブ ] ページの ジョブの一覧に追加され、開始データと時刻に従って実行されます。
ジョブがスケジュールされ、次のページが表示されます。ジョブを表示するには、リンクを選択します。

テンプレートからジョブを作成する

定義済みのジョブテンプレートから KQL ジョブを作成できます。ジョブテンプレートには、KQL クエリとジョブ設定 (変換先のワークスペース、テーブル、スケジュール、説明など) が含まれています。独自のジョブテンプレートを作成することも、Microsoft が提供する組み込みのテンプレートを使用することもできます。

テンプレートからジョブを作成するには、次の手順に従います。

[ジョブ] ページまたは KQL クエリエディターで、[ジョブの作成] を選択し、[テンプレートから作成] を選択します。
[ ジョブテンプレート ] ページで、使用可能なテンプレートの一覧から使用するテンプレートを選択します。
テンプレートから Descriptionクエリと KQL クエリ を確認します。
[ テンプレートからジョブを作成する] を選択します。
ジョブ作成ウィザードが開き、[ 新しい KQL ジョブの作成 ] ページが表示されます。ターゲットワークスペースを除き、テンプレートから事前入力されたジョブの詳細。
[ワークスペースの選択] ドロップダウンから移動先 ワークスペースを選択 します。
必要に応じてジョブの詳細を確認して変更し、[ 次へ ] を選択してジョブ作成ウィザードを続行します。
残りの手順は、新しいジョブの作成と同じです。フィールドはテンプレートから事前設定され、必要に応じて変更できます。詳細については、「ジョブの作成」を参照してください。

次のテンプレートを使用できます。

テンプレート名	カテゴリ
異常なサインイン場所の増加 Entra ID サインインログの傾向分析を分析し、場所の多様性の傾向線を計算することで、アプリケーション全体のユーザーに対する異常な場所の変更を検出します。場所のばらつきが最も急激に増加した上位 3 つのアカウントが強調表示され、21 日間のウィンドウ内で関連する場所が一覧表示されます。変換先テーブル: UserAppSigninLocationTrend クエリのルックバック: 1 日スケジュール: 毎日開始日: 現在の日付 + 1 時間	検索
場所の変更に基づく異常なサインイン動作 Entra ID ユーザーとアプリの場所の変更に基づいて異常なサインイン動作を特定し、動作の突然の変更を検出します。変換先テーブル: UserAppSigninLocationAnomalies クエリのルックバック: 1 日スケジュール: 毎日開始日: 現在の日付 + 1 時間	異常検出
アプリ別のまれなアクティビティを監査する特権を静かに作成できるまれなアクション (同意、許可など) を実行するアプリを検索します。現在の日と過去 14 日間の監査を比較して、新しい監査アクティビティを特定します。 Azureアプリと自動承認によるユーザー/グループの追加または削除に関連する悪意のあるアクティビティを追跡するのに役立ちます。変換先テーブル: AppAuditRareActivity クエリのルックバック: 14 日間スケジュール: 毎日開始日: 現在の日付 + 1 時間	検索
Azureまれなサブスクリプションレベルの操作 Azure アクティビティログに基づいて、機密性の高いAzureサブスクリプションレベルのイベントを特定します。たとえば、"スナップショットの作成または更新" という操作名に基づいて監視します。これはバックアップの作成に使用されますが、攻撃者がハッシュをダンプしたり、ディスクから機密情報を抽出したりするために悪用される可能性があります。変換先テーブル: AzureSubscriptionSensitiveOps クエリのルックバック: 14 日間スケジュール: 毎日開始日: 現在の日付 + 1 時間	検索
AuditLogs でのアプリごとの毎日のアクティビティの傾向過去 14 日間から、ユーザーまたはアプリによって発生する "アプリケーションへの同意" 操作を特定します。これは、一覧表示されている AzureApp にアクセスするためのアクセス許可が悪意のあるアクターに提供されたことを示している可能性があります。アプリケーションへの同意、サービスプリンシパルの追加、Auth2PermissionGrant イベントの追加はまれです。使用可能な場合は、"アプリケーションへの同意" を実行したのと同じアカウントの CorrleationId に基づいて、AuditLogs から追加のコンテキストが追加されます。変換先テーブル: AppAuditActivityBaseline クエリのルックバック: 14 日間スケジュール: 毎日開始日: 現在の日付 + 1 時間	基準
SignInLogs でのユーザーまたはアプリごとの毎日の位置情報の傾向すべてのユーザーサインイン、場所数、アプリの使用状況に関する毎日の傾向を構築します。変換先テーブル: UserAppSigninLocationBaseline クエリのルックバック: 1 日スケジュール: 毎日開始日: 現在の日付 + 1 時間	基準
宛先 IP ごとの毎日のネットワークトラフィックの傾向ビーコンと流出を検出するために、バイトと個別のピアを含むベースラインを作成します。変換先テーブル: NetworkTrafficDestinationIPDailyBaseline クエリのルックバック: 1 日スケジュール: 毎日開始日: 現在の日付 + 1 時間	基準
データ転送統計を使用した宛先 IP ごとの毎日のネットワークトラフィックの傾向ボリュームの傾向、爆発半径の推定など、送信先に到達した内部ホストを特定します。変換先テーブル: NetworkTrafficDestinationIPTrend クエリのルックバック: 1 日スケジュール: 毎日開始日: 現在の日付 + 1 時間	検索
ソース IP ごとの毎日のネットワークトラフィックの傾向ビーコンと流出を検出するために、バイトと個別のピアを含むベースラインを作成します。変換先テーブル: NetworkTrafficSourceIPDailyBaseline クエリのルックバック: 1 日スケジュール: 毎日開始日: 現在の日付 + 1 時間	基準
データ転送統計を使用したソース IP ごとの毎日のネットワークトラフィックの傾向今日の接続とバイトは、ホストの 1 日のベースラインに対して評価され、観察された動作が確立されたパターンから大幅に逸脱しているかどうかを判断します。変換先テーブル: NetworkTrafficSourceIPTrend クエリのルックバック: 1 日スケジュール: 毎日開始日: 現在の日付 + 1 時間	検索
ユーザーとアプリごとの毎日のサインイン場所の傾向一般的な地理的および IP を使用して、ユーザーまたはアプリケーションごとにサインインベースラインを作成し、大規模で効率的でコスト効率の高い異常検出を実現します。変換先テーブル: UserAppSigninLocationDailyBaseline クエリのルックバック: 1 日スケジュール: 毎日開始日: 現在の日付 + 1 時間	基準
毎日のプロセス実行の傾向新しいプロセスと普及率を特定し、"新しいまれなプロセス" の検出を容易にします。変換先テーブル: EndpointProcessExecutionBaseline クエリのルックバック: 1 日スケジュール: 毎日開始日: 現在の日付 + 1 時間	基準
アプリごとのEntra ID レアユーザーエージェント特定のアプリケーションで一般的に使用される UserAgent の種類 (つまり、ブラウザー、Office アプリケーションなど) のベースラインを確立するには、日数を振り返ります。次に、このパターンからの逸脱、つまり、このアプリケーションと組み合わせて前に見たことがない UserAgents の種類について、現在の日を検索します。変換先テーブル: UserAppRareUserAgentAnomalies クエリのルックバック: 7 日間スケジュール: 毎日開始日: 現在の日付 + 1 時間	異常検出
ネットワークログ IOC の照合 CommonSecurityLog で一致を検索して、脅威インテリジェンス (TI) から侵害の IP インジケーター (IOC) を特定します。変換先テーブル: NetworkLogIOCMatches クエリのルックバック: 1 時間スケジュール: 時間単位開始日: 現在の日付 + 1 時間	検索
過去 24 時間に観察された新しいプロセス安定した環境の新しいプロセスは、悪意のあるアクティビティを示している可能性があります。これらのバイナリが実行されたサインインセッションを分析すると、攻撃を識別するのに役立ちます。変換先テーブル: EndpointNewProcessExecutions クエリのルックバック: 14 日間スケジュール: 毎日開始日: 現在の日付 + 1 時間	検索
以前に表示されていない IP を使用した SharePoint ファイル操作新しい IP アドレスからのファイルのアップロード/ダウンロードアクティビティの大幅な変更のしきい値を設定して、ユーザーの動作を使用して異常を特定します。これは、一般的な動作のベースラインを確立し、最近のアクティビティと比較し、既定のしきい値 25 を超える偏差にフラグを設定します。変換先テーブル: SharePointFileOpsNewIP クエリのルックバック: 14 日間スケジュール: 毎日開始日: 現在の日付 + 1 時間	検索
Palo Alto の潜在的なネットワークビーコン繰り返しの時間デルタパターンに基づいて Palo Alto Network トラフィックログからビーコンパターンを識別します。クエリでは、さまざまな KQL 関数を使用して時間差を計算し、1 日に観測されたイベントの合計と比較してビーコンの割合を見つけます。変換先テーブル: PaloAltoNetworkBeaconingTrend クエリのルックバック: 1 日スケジュール: 毎日開始日: 現在の日付 + 1 時間	検索
通常の時間外の Windows 不審なログイン過去 14 日間のサインインアクティビティと比較し、履歴パターンに基づいて異常にフラグを付けることで、ユーザーの通常の時間外の異常な Windows サインインイベントを特定します。変換先テーブル: WindowsLoginOffHoursAnomalies クエリのルックバック: 14 日間スケジュール: 毎日開始日: 現在の日付 + 1 時間	異常検出

考慮事項と制限事項

Microsoft Sentinel データレイクでジョブを作成する場合は、次の制限事項とベストプラクティスを考慮してください。

データ層

KQL ジョブは、ターゲットテーブルの層に応じて、Analytics レベルまたは Data Lake 層のいずれかにデータを書き込むことができます。ジョブ作成ウィザードを使用して新しいテーブルを作成する場合は、変換先ワークスペースとしてシステムテーブルを選択して、データレイクに直接データを書き込むことができます。この方法で作成されたテーブルは、データレイク層に直接作成および格納され、_KQLで自動的にサフィックスが付けられます。

KQL

以下を除き、すべての KQL 演算子と関数がサポートされます。
- adx()
- arg()
- externaldata()
- ingestion_time()
stored_query_results コマンドを使用する場合は、KQL クエリで時間範囲を指定します。クエリエディターの上のタイムセレクターは、このコマンドでは機能しません。
ユーザー定義関数はサポートされていません。

ジョブ

ジョブ名は、テナントに対して一意である必要があります。
ジョブ名は最大 256 文字です。
ジョブ名に # または -を含めることはできません。
ジョブの開始時刻は、ジョブの作成または編集から少なくとも 30 分後である必要があります。

Data Lake のインジェスト待機時間

データレイク層は、コールドストレージにデータを格納します。ホットまたはほぼリアルタイムの分析レベルとは異なり、コールドストレージは長期保有とコスト効率のために最適化されており、新しく取り込まれたデータにすぐにアクセスすることはできません。データレイクまたはフェデレーションテーブル内の既存のテーブルに新しい行が追加されると、データがクエリに使用できるようになるまで、最大 15 分の一般的な待機時間が発生します。クエリを実行し、KQL ジョブをスケジュールする際のインジェスト待機時間を考慮します。ルックバックウィンドウとジョブスケジュールが、まだ使用できないデータを回避するように構成されています。

まだ使用できない可能性があるデータのクエリを回避するには、KQL クエリまたはジョブに delay パラメーターを含めます。たとえば、自動ジョブをスケジュールする場合は、クエリの終了時刻を now() - delay に設定します。ここで、 delay は一般的なデータ準備待ち時間 (15 分) と一致します。この方法により、クエリは、完全に取り込まれた分析の準備ができているターゲットデータのみを対象とします。

let lookback = 15m;
let delay = 15m;
let endTime = now() - delay;
let startTime = endTime - lookback;
CommonSecurityLog
| where TimeGenerated between (startTime .. endTime)

この方法は、ルックバックウィンドウが短いジョブや頻繁な実行間隔を持つジョブに有効です。

ルックバック期間とジョブの頻度を重複して、到着遅延データが欠落するリスクを減らすことを検討してください。

詳細については、「スケジュールされた分析ルールでのインジェスト遅延の処理」を参照してください。

列名

列名は文字で始まる必要があります。

次の標準列はエクスポートではサポートされていません。インジェストプロセスでは、移行先層の次の列が上書きされます。

TenantId
_TimeReceived
型
SourceSystem
_ResourceId
_SubscriptionId
_Itemid
_BilledSize
_IsBillable
_WorkspaceId
TimeGenerated は、2 日より前の場合は上書きされます。元のイベント時刻を保持するには、ソースタイムスタンプを別の列に書き込みます。

サービスの制限については、「data lake サービスの制限Microsoft Sentinel」を参照してください。

注:

ジョブのクエリが 1 時間の制限を超えると、部分的な結果が昇格される可能性があります。

KQL ジョブのサービスパラメーターと制限

次の表に、Microsoft Sentinel データレイク内の KQL ジョブのサービスパラメーターと制限を示します。

カテゴリ	パラメーター/制限
テナントごとの同時ジョブ実行	3
ジョブクエリの実行タイムアウト	1 時間
テナントごとのジョブ (有効なジョブ)	100
ジョブあたりの出力テーブル数	1
クエリスコープ	複数のワークスペース
クエリ時間範囲	最大 12 年

トラブルシューティングのヒントとエラーメッセージについては、「Microsoft Sentinel データレイクの KQL クエリのトラブルシューティング」を参照してください。

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-04-23

次の方法で共有

Microsoft Sentinel データ レイクで KQL ジョブを作成する