分析ルールの種類としては最も一般的であるスケジュールされたルールは、Kusto クエリに基づいています。このクエリは一定の間隔で実行するように構成されていて、定義済みの "ルックバック" 期間の生データを調べます。 クエリは、複雑な統計操作をターゲット データに対して実行できるため、一群のイベント内のベースラインと外れ値が明らかになります。 クエリによって捕捉された結果の数がルール内で構成されたしきい値を超えている場合は、ルールがアラートを生成します。
この記事は、スケジュールされた分析ルールの構築方法の理解に役立ち、すべての構成オプションとその意味について説明します。 この記事の情報は、次の 2 つのシナリオで役立ちます。
テンプレートから分析ルールを作成する: クエリのロジックと、スケジューリングとルックバックの設定をテンプレートで定義されているとおりに使用するか、それらをカスタマイズして新しいルールを作成します。
分析ルールを最初から作成する: 独自のクエリとルールを最初から構築します。 これを効果的に行うには、データ サイエンスと Kusto クエリ言語について十分な基礎知識が必要です。
重要
Microsoft Sentinel は、Microsoft Defender XDR または E5 ライセンスを持たないお客様を含め、Microsoft Defender ポータルで一般提供されています。
2026 年 7 月以降、Azure portal で Microsoft Sentinel を使用しているすべてのお客様は Defender ポータルにリダイレクトされ、Defender ポータルでのみ Microsoft Sentinel が使用されます。 2025 年 7 月以降、多くの新規ユーザーが自動的にオンボードされ、Defender ポータルにリダイレクトされます。
Azure portal で Microsoft Sentinel を引き続き使用している場合は、スムーズな移行を確保し、Microsoft Defender によって提供される統合セキュリティ運用エクスペリエンスを最大限に活用するために、Defender ポータルへの移行の計画を開始することをお勧めします。 詳細については、「 移動する時間: セキュリティを強化するために Microsoft Sentinel の Azure portal を廃止する」を参照してください。
分析ルール テンプレート
スケジュールされたルール テンプレートの中のクエリは、Microsoft またはそのテンプレートを提供するソリューションのベンダーの、セキュリティとデータ サイエンスの専門家によって記述されています。
分析ルール テンプレートを使用するには、テンプレートのリストからテンプレート名を選び、それに基づいてルールを作成します。
各テンプレートには、必要なデータ ソースの一覧があります。 テンプレートを開くと、データ ソースの可用性が自動的にチェックされます。 可用性とは、データ ソースが接続されていて、そのデータ ソースを通じてデータが定期的に取り込まれていることを意味します。 必要なデータ ソースのいずれかが利用できない場合は、ルールを作成できず、その旨のエラー メッセージが表示されることもあります。
テンプレートからルールを作成すると、選択したテンプレートに基づいてルール作成ウィザードが開きます。 詳細はすべて自動的に入力されますが、特定のニーズに合わせてロジックやその他のルール設定をカスタマイズできます。 この手順を繰り返して、テンプレートに基づく追加のルールを作成できます。 ルール作成ウィザードが終了すると、カスタマイズが検証され、ルールが作成されます。 新しいルールが、[分析] ページの [アクティブなルール] タブに表示されます。 同様に、[ルール テンプレート] タブには、ルールの作成元となったテンプレートが In use タグ付きで表示されます。
分析ルール テンプレートは、バグを修正するため、またはクエリを改良するために、作成者によって継続的にメンテナンスされています。 テンプレートが更新プログラムを受け取ると、そのテンプレートに基づくすべてのルールが Update タグ付きで表示されるため、それらのルールを変更してテンプレートに加えられた変更を組み込むことができます。 ルールに加えた変更を元のテンプレート ベースのバージョンに戻すこともできます。 詳細については、「Microsoft Azure Sentinel でスケジュール化された分析ルールのテンプレート バージョンを管理する」を参照してください。
この記事の構成オプションについて理解したら、「スケジュール化された分析ルールをテンプレートから作成する」を参照してください。
この記事の残りの部分では、ルールの構成をカスタマイズするためのすべての可能性について説明します。
分析ルールの構成
このセクションでは、ルールの構成を開始する前に考慮する必要がある主な考慮事項について説明します。
分析ルールの名前と詳細
分析ルール ウィザードの最初のページには、ルールの基本情報が含まれています。
名前: ルールのリストとルールベースのフィルターに表示されるルールの名前。 名前はワークスペースに対して一意である必要があります。
説明: ルールの目的に関する自由形式の説明です。
ID: API の要求や応答などに使用される、Azure リソースとしてのルールの GUID。 この GUID はルールの作成時にのみ割り当てられるため、既存のルールを編集しているときにのみ表示されます。 これは読み取り専用フィールドであるため、淡色表示され、変更することはできません。 テンプレートからでも最初からでも、新しいルールを作成するときには、まだ存在しません。
重大度: このルールによって生成されるアラートに与える評価です。 アクティビティの重大度は、アクティビティの発生による潜在的な悪影響の計算です。
| 重大度 | 説明 |
|---|---|
| 情報 | システムに影響はありませんが、情報は、脅威アクターによって計画された将来の手順を示している可能性があります。 |
| 低 | 即時の影響は最小です。 脅威アクターは、環境への影響を達成する前に、複数の手順を実行する必要がある可能性があります。 |
| 中程度 | 脅威アクターは、このアクティビティを使用して環境に何らかの影響を与える可能性がありますが、スコープが制限されるか、追加のアクティビティが必要になります。 |
| 高 | 特定されたアクティビティが、脅威アクターに、環境に対するアクションを実行するための幅広いアクセス権を提供するか、環境への影響が大きいためにトリガーされます。 |
重大度レベルの既定値は、現在または環境への影響レベルを保証するものではありません。 アラートの詳細をカスタマイズして、クエリ出力の関連フィールドの値を使用して、アラートの特定のインスタンスの重大度、戦術、およびその他のプロパティをカスタマイズします。
Microsoft Sentinel 分析ルール テンプレートの重大度定義は、分析ルールによって作成されたアラートにのみ関連します。 他のサービスから取り込まれたアラートの場合、重大度はソース セキュリティ サービスによって定義されます。
MITRE ATT&CK: このルールによってキャプチャされたアクティビティによって表される攻撃戦術と手法の仕様です。 これらは、MITRE ATT&CK® フレームワークの戦術と手法に基づいています。
ここでルールに定義されている MITRE ATT&CK の戦術と手法は、ルールによって生成されるすべてのアラートに適用されます。 これらのアラートから作成されるすべてのインシデントにも適用されます。
MITRE ATT&CK 脅威ランドスケープの対象範囲を最大化する方法の詳細については、「MITRE ATT&CK® フレームワークによるセキュリティ カバレッジについて」を参照してください。
状態: ルールを作成すると、その状態は既定で有効になります。これは、作成が終わるとすぐに実行されることを意味します。 すぐに実行しない場合は、次の 2 つのオプションがあります。
- 無効を選択すると、そのルールは実行されずに作成されます。 ルールを実行したい場合は、それを [アクティブなルール] タブで見つけ、そこから有効にします。
- ルールが特定の日時に最初に実行されるようにスケジュールします。 この方法は、現在プレビュー段階です。 この記事で後述する「クエリ のスケジューリング」を参照してください。
ルールのクエリ
これがルールの本質です。このルールによって作成されるアラートに含まれる情報と、情報の編成方法を決定します。 この構成は、結果として生じるインシデントがどのようになるか、また、インシデントの調査、修復、解決の難易度に影響を及ぼします。 アラートにはできるだけ多くの情報を含め、その情報に簡単にアクセスできるようにすることが重要です。
生ログ データを分析する Kusto クエリを表示または入力します。 ルールを最初から作成する場合は、このウィザードを開く前にクエリを計画して設計することをお勧めします。 [ログ] ページでクエリを作成してテストできます。
ルール クエリ ウィンドウに入力した内容はすべて即座に検証されるため、間違いがあればすぐにわかります。
ネイティブ テーブルを使用する代わりに、Advanced Security Information Model (ASIM) パーサー をクエリ ソースとして使用することをお勧めします。 こうすることで、クエリが、1 つのデータ ソースに依存するのではなく、現在または将来の関連するデータ ソースをサポートするようになります。
クエリの長さは 1 ~ 10,000 文字にする必要があり、"
search *" または "union *" を含めることはできません。 ユーザー定義関数を使用すると、1 つの関数で数十行のコードを置き換えることができるため、クエリの長さの制限を回避できます。ADX 関数を使用して Log Analytics クエリウィンドウ 内で Azure Data Explorer クエリを作成することは、サポートされていません。
クエリで
bag_unpack関数を使用する場合、"" を使用して列をフィールドとしてproject field1し、列が存在しない場合、クエリは失敗します。 このような事態を防ぐために、次のように列を射影する必要があります。project field1 = column_ifexists("field1","")
詳細については、次を参照してください。
アラートの拡張機能
アラートの調査結果がインシデントで即座に表示され、適切に追跡および調査されるようにするには、アラートの拡張機能構成を使用してアラートにすべての重要な情報を表示させます。
このアラートの拡張機能には、調査結果を見やすく、アクセスしやすい方法で表示するという付加価値があります。
構成できるアラートの拡張機能には、次の 3 種類があります。
- エンティティ マッピング
- カスタム詳細
- アラートの詳細 (動的コンテンツとも呼ばれます)
エンティティ マッピング
エンティティは、攻撃ストーリーのどちら側にも存在するプレイヤーです。 脅威を検出して調査するためには、アラート内のすべてのエンティティを識別することが不可欠です。 Microsoft Sentinel で生データ内のエンティティを識別できるようにするには、Microsoft Sentinel で認識されるエンティティ型をクエリ結果のフィールドにマップする必要があります。 このマッピングにより、識別されたエンティティがアラート スキーマの [エンティティ] フィールドに統合されます。
エンティティ マッピングの詳細と完全な手順については、「データ フィールドを Microsoft Azure Sentinel のエンティティにマップする」を参照してください。
カスタム詳細
既定では、アラート エンティティとメタデータのみがインシデントに表示され、クエリ結果の生のイベントへのドリルダウンは行われません。 クエリ結果の他のフィールドをアラートとインシデントですぐに表示するには、それらをカスタム詳細として定義します。 Microsoft Sentinel では、これらのカスタム詳細がアラートの [ExtendedProperties] フィールドに統合され、アラートや、それらのアラートから作成されたすべてのインシデントに表示されます。
カスタム詳細の表示の詳細と完全な手順については、「Microsoft Sentinel でアラートに含まれるカスタム イベントの詳細を表示する」を参照してください。
アラートの詳細
この設定により、個々のアラートのさまざまなフィールドの内容に応じて、他の点では標準のアラート プロパティをカスタマイズできます。 これらのカスタマイズは、アラートの [ExtendedProperties] フィールドに統合されます。 たとえば、アラートの名前や説明をカスタマイズして、アラートに含まれるユーザー名や IP アドレスを含むようにすることができます。
アラートの詳細をカスタマイズする方法の詳細については、「Microsoft Sentinel でアラートの詳細をカスタマイズする」を参照してください。
注
Microsoft Defender ポータルでは、Defender XDR 関連付けエンジンはインシデントの名前付けのみを担当するため、カスタマイズしたアラート名は、これらのアラートからインシデントが作成されるときにオーバーライドされる可能性があります。
クエリのスケジューリング
次のパラメーターは、スケジュールされたルールを実行する頻度と、実行するたびに調べる期間を決定します。
| 設定 | 動作 |
|---|---|
| クエリの実行間隔 | クエリの実行頻度、つまりクエリの実行間隔を制御します。 |
| 参照する過去データの範囲 | クエリの対象期間、つまりルックバック期間を決定します。 |
これらの両方のパラメーターで使用できる範囲は、[5 分] から [14 日間] です。
クエリ間隔は、ルックバック期間以下である必要があります。 短い場合、クエリ期間が重複し、結果が重複する可能性があります。 ただし、ルールの検証では、ルックバック期間よりも長い間隔を設定することはできません。そのため、カバレッジにギャップが生じます。
現在プレビュー段階の [Start running] (実行の開始) 設定を使用すると、状態が [有効] のルールを作成し、その最初の実行を事前に決定した日時まで延期することができます。 この設定は、ソースからデータが取り込まれると予想される時間や、SOC アナリストが仕事を始める時間に応じてルールの実行時間を設定する場合に役立ちます。
| 設定 | 動作 |
|---|---|
| [自動] | ルールは、作成直後に初めて実行され、その後、[クエリの実行] 設定で設定 された間隔で実行されます 。 |
| [At specific time] (特定の時刻) (プレビュー) | ルールを最初に実行する日付と時刻を設定します。その後、[クエリの実行] 設定で設定された間隔で 実行されます 。 |
[Start running] (実行の開始) の時刻は、ルールの作成 (または有効化) の時点以降 10 分～ 30 日の間である必要があります。
[Start running] (実行の開始) 設定の下にあるテキスト行 (その左側に情報アイコンがある) に、クエリのスケジュールとルックバックの設定が要約されます。
注
インジェストの遅延
ソースでのイベントの生成と Microsoft Sentinel へのインジェストの間に発生する可能性のある 待機時間 を考慮し、データの重複を伴わずに完全なカバレッジを確保するために、Microsoft Sentinel はスケジュールされた時刻から 5 分の遅延 でスケジュールされた分析ルールを実行します。
詳細については、「スケジュールされた分析ルールでインジェストの遅延を処理する」を参照してください。
アラートのしきい値
セキュリティ イベントの多くは、少数の場合は正常または予想の範囲内ですが、大量に発生すると脅威の兆候となります。 規模が異なる大きな数値は、異なる種類の脅威を意味することがあります。 たとえば、1 分間に 2 回または 3 回失敗したサインイン試行は、ユーザーがパスワードを覚えていない兆候ですが、1 分に 50 回は人間による攻撃の兆候である可能性があり、1000 件はおそらく自動攻撃です。
ルールで検出しようとしているアクティビティの種類に応じて、アラートをトリガーするために必要なイベント (クエリ結果) の最小数を設定できます。 このしきい値は、ルールが実行されるたびに個別に適用され、全体に適用されるわけではありません。
このしきい値は、結果の最大数または正確な数に設定することもできます。
イベントのグループ化
イベントのアラートへのグループ化を処理するには、次の 2 つの方法があります。
[すべてのイベントを単一のアラートにグループ化する]: これが既定値です。 このルールでは、クエリで前のセクションで説明したアラートのしきい値よりも多くの結果が返される限り、実行されるたびに 1 つのアラートが生成されます。 この単一アラートで、クエリ結果で返されるすべてのイベントがまとめられます。
[各イベントに対するアラートをトリガーする]: このルールでは、クエリによって返されるイベント (結果) ごとに独自のアラートが生成されます。 このモードは、イベントを個々に表示する場合や、ユーザーやホスト名など、特定のパラメーター別にイベントをグループ化する場合に便利です。 これらのパラメーターはクエリ内で定義できます。
分析ルールでは、最大 150 個のアラートを生成できます。 [イベントのグループ化] が [各イベントについてアラートをトリガーする] に設定されていて、ルールのクエリから 150 を超えるイベントが返された場合、最初の 149 件のイベントについてはそれぞれに独自のアラート (149 件のアラート) が生成され、150 番目のアラートでは、返された一連のイベント全体がまとめられます。 言い換えると、150 番目のアラートは、[イベント グループ化] が[すべてのイベントを単一のアラートにグループ化する] に設定されていた場合に生成されたはずのアラートです。
アラートの [クエリ ] セクションは、これら 2 つの各モードで異なります。 [ すべてのイベントを 1 つのアラート モードにグループ化 ] では、アラートをトリガーしたすべてのイベントを表示できるクエリがアラートから返されます。 クエリ結果をドリルダウンして、個々のイベントを表示できます。 イベント モード ごとにアラートをトリガー すると、アラートは base64 でエンコードされた結果をクエリ領域に返します。 Log Analytics でこの出力をコピーして実行し、base64 をデコードし、元のイベントを表示します。
[各イベントに対するアラートをトリガーする] 設定を使用すると、クエリ結果が欠落したり、予想と異なる結果になったりする問題が発生する可能性があります。 このシナリオの詳細については、「Microsoft Sentinel での分析ルールに関するトラブルシューティングを実行する」の「問題点: クエリ結果にイベントが表示されない」を参照してください。
抑制
アラートを生成した後、このルールの動作を一定期間停止する場合は、[アラートの生成後にクエリの実行を停止する] 設定を [オン] にします。 次に、[クエリの実行を停止する] をクエリの実行を停止する時間 (最大 24 時間) に設定する必要があります。
結果のシミュレーション
分析ルール ウィザードを現在のデータ セットで実行すると、その有効性をテストできます。 テストを実行すると、[結果のシミュレーション] ウィンドウに、現在定義されているスケジュールに従って、そのクエリが直近の 50 回実行された場合に生成されたであろう結果のグラフが表示されます。 クエリを変更した場合は、もう一度テストを実行してグラフを更新できます。 グラフには、定義したクエリ スケジュールによって決まる、定義された期間での結果の数が表示されます。
前のスクリーンショットのクエリの結果シミュレーションは次のようになります。 左側は既定のビューであり、右側はグラフ上の特定の時点にマウス ポインターを合わせたときに表示される内容です。
クエリによってトリガーされるアラートが多すぎる場合や頻度が高すぎる場合は、スケジュールとしきい値の設定を試して、シミュレーションを再度実行できます。
インシデントの設定
Microsoft Sentinel がアラートを実用的なインシデントに変えるかどうかを選択します。
インシデントの作成は既定で有効になっています。 Microsoft Sentinel では、ルールによって生成されるアラートごとに個別のインシデントが 1 つ作成されます。
このルールによってインシデントが作成されないようにする場合は (たとえば、このルールが後続の分析のために情報を収集するだけの場合)、これを [無効] に設定します。
重要
Microsoft Sentinel を Defender ポータルにオンボードした場合、Microsoft Defender がインシデントの作成を担います。 ただし、Defender XDR でこのアラートのインシデントを作成する場合は、この設定を [有効] のままにしておく必要があります。 Defender XDR は、ここで定義されている命令を受け取ります。
これは、Microsoft Defender サービスで生成されたアラートのインシデントを作成する Microsoft Security の分析ルールの種類と混同しないでください。 これらのルールは、Microsoft Sentinel を Defender ポータルにオンボードすると自動的に無効になります。
単一のインシデントをアラートごとにではなく、アラートのグループから作成する場合は、次のセクションをご覧ください。
アラートのグループ化
インシデントでどのようにアラートをグループ化するかを選びます。 既定では、Microsoft Sentinel では生成されたすべてのアラートに対してインシデントが作成されます。 代わりに、複数のアラートを 1 つのインシデントにグループ化することもできます。
インシデントは、すべてのアラートが生成された後にのみ作成されます。 すべてのアラートは、作成後すぐにインシデントに追加されます。
最大 150 件のアラートを 1 つのインシデントにグループ化できます。 アラートを 1 つのインシデントにグループ化するルールによって生成されたアラートが 150 件を超える場合は、元のインシデントと同じインシデントの詳細を持つ新しいインシデントが生成され、超過したアラートは新しいインシデントにグループ化されます。
アラートをグループ化するには、アラートのグループ化設定を [有効] に設定します。
アラートをグループ化するときに考慮するオプションがいくつかあります。
概算時間: 既定では、インシデントの最初のアラートから 5 時間後までに作成されたアラートが同じインシデントに追加されます。 5 時間後に、新しいインシデントが作成されます。 この期間は、5 分から 7 日間の任意の場所に変更できます。
グループ化条件: グループに含めるアラートを決定する方法を選択します。 次の表に、可能な選択肢を示します。
オプション 説明 すべてのエンティティが一致した場合にアラートを 1 つのインシデントにグループ化する 以前に定義したマップされたエンティティごとに同じ値を共有する場合に、アラートがグループ化されます。 これが推奨される設定です。 このルールによってトリガーされるすべてのアラートを 1 つのインシデントにグループ化する 値が同じではない場合でも、このルールによって生成されるすべてのアラートをグループ化します。 選択したエンティティと詳細が一致する場合にアラートを 1 つのインシデントにグループ化する すべてのマップされたエンティティ、アラートの詳細、およびこの設定で選択したカスタムの詳細で同じ値を共有する場合に、アラートがグループ化されます。 このオプションを選択すると表示されるドロップダウン リストからエンティティと詳細を選択します。
たとえば、ソースまたはターゲットの IP アドレスに基づいて別々のインシデントを作成する場合や、特定のエンティティと重要度に一致するアラートをグループ化する場合、この設定を使用できます。
注: このオプションを選択する場合は、ルールに対して少なくとも 1 つのエンティティまたは詳細を選択する必要があります。 それ以外の場合、ルールの検証は失敗し、ルールは作成されません。インシデントの再び開く: インシデントが解決されて閉じられ、そのインシデントに属する必要がある別のアラートが後で生成された場合は、閉じたインシデントを再度開く場合はこの設定を [有効] に設定し、新しいアラートで新しいインシデントを作成する場合は [無効] のままにします。
Microsoft Sentinel を Defender ポータルにオンボードした場合、閉じたインシデントを再度開くオプションは使用できません。
自動応答
Microsoft Sentinel を使用すると、次の場合に自動応答を実行するように設定できます。
- この分析ルールによってアラートが生成される場合。
- この分析ルールによって生成されたアラートからインシデントが作成される場合。
- この分析ルールによって生成されたアラートを使用してインシデントが更新される場合。
作成および自動化できるさまざまな種類の応答について詳しくは、「自動化ルールを使って Microsoft Sentinel の脅威への対応を自動化する」をご覧ください。
ウィザードの [オートメーション ルール]の見出しの下には、ワークスペース全体で既に定義されているオートメーション ルールのリストが表示され、その条件がこの分析ルールに適用されます。 これらの既存のルールを編集することも、この分析ルールにのみ適用される新しいオートメーション ルールを作成することもできます。
自動化ルールを使用して、インシデントの基本的なトリアージ、割り当て、ワークフロー、終了を実行します。
これらの自動化ルールからプレイブックを呼び出すことで、より複雑なタスクを自動化し、リモート システムからの応答を呼び出して脅威に対する修復を行います。 インシデントと個々のアラートについて、プレイブックを呼び出すことができます。
プレイブックや自動化ルールの作成に関する詳細と手順については、「脅威への対応を自動化する」を参照してください。
インシデント作成トリガー、インシデント更新トリガー、アラート作成トリガーを使用するタイミングの詳細については、「Microsoft Sentinel のプレイブックでトリガーとアクションを使用する」を参照してください。
[アラートのオートメーション (クラシック)] の見出しの下に、2026 年 3 月に非推奨になる予定の以前の方法を使用して自動的に実行するように構成されたプレイブックのリストが表示される場合があります。 このリストには何も追加できません。 ここに一覧表示されているすべてのプレイブックには、アラート作成トリガーに基づいてプレイブックを呼び出すオートメーション ルールを作成する必要があります。 完了したら、ここに記載されているプレイブックの行の末尾にある省略記号を選択し、[削除] を選択します。 詳細な手順については、「Microsoft Sentinel のアラートトリガー プレイブックをオートメーション ルールに移行する」を参照してください。
次のステップ
Microsoft Sentinel 分析ルールを使用して環境全体の脅威を検出する場合は、接続されたデータ ソースに関連付けられているすべてのルールを有効にして、環境の完全なセキュリティ カバレッジを確保してください。
ルールの有効化を自動化するには、 API と PowerShell を使用して Microsoft Sentinel にルールをプッシュします。ただし、これを行うにはさらに多くの労力が必要です。 API または PowerShell を使用している場合は、ルールを有効にする前に、まずルールを JSON にエクスポートする必要があります。 API または PowerShell は、各インスタンスで同じ設定で Microsoft Sentinel の複数のインスタンスでルールを有効にする場合に役立ちます。
詳細については、次を参照してください。
- ARM テンプレート間で分析ルールをエクスポートおよびインポート
- Microsoft Sentinel での分析ルールに関するトラブルシューティングを実行
- Microsoft Sentinel でのインシデントの確認と調査
- Microsoft Sentinel のエンティティ
- チュートリアル: Microsoft Sentinel でオートメーション ルールとプレイブックを使用する
また、カスタム コネクタで Zoom を監視するするときにカスタム分析ルールを使用する例も参照してください。