脅威を検出するためのカスタム分析規則を作成する
Microsoft Sentinel にデータ ソースを接続した後、環境内の脅威や異常な動作を検出するために役立つカスタム分析ルールを作成します。
分析ルールでは、環境全体にわたる特定のイベントまたは一連のイベントを検索したり、特定のイベントしきい値または条件に達したときはユーザーに警告したり、SOC でトリアージと調査を行うためのインシデントを生成したり、自動化された追跡および修復プロセスを使用して脅威に対応したりします。
ヒント
カスタム ルールを作成する場合は、既存のルールをテンプレートまたは参照として使用します。 既存のルールをベースラインとして使用すると、必要な変更を行う前にほとんどのロジックを構築するのに役立ちます。
- 分析ルールを作成する
- イベントとアラートの処理方法を定義する
- アラートとインシデントの生成方法を定義する
- ルールに対して脅威への自動対応を選択する
スケジュールされたクエリを使用してカスタム分析ルールを作成する
Microsoft Sentinel のナビゲーション メニューから [分析] を選択します。
上部のアクション バーで、 [+ 作成] を選択し、 [スケジュール済みクエリ ルール] を選択します。 分析ルール ウィザードが開きます。
分析ルール ウィザード—[全般] タブ
一意の [名前] と [説明] を指定します。
[戦術と手法] フィールドでは、ルールを分類する攻撃のカテゴリを選択できます。 これらは、MITRE ATT&CK フレームワークの戦術と手法に基づいています。
MITRE ATT&CK の戦術と手法にマップされたルールによって検出されたアラートから作成されたインシデントでは、ルールのマッピングが自動的に継承されます。
必要に応じて、アラートの [重大度] を設定します。
ルールを作成すると、その [状態] は既定で [有効] になります。これは、作成が終わるとすぐに実行されることを意味します。 すぐに実行したくない場合は、 [無効] を選択します。ルールは [アクティブな規則] タブに追加され、必要に応じてそこから有効にすることができます。
ルールのクエリ ロジックを定義して設定を構成する
[ルールのロジックを設定] タブでは、 [ルールのクエリ] フィールドにクエリを直接入力するか、または Log Analytics でクエリを作成し、コピーしてフィールドに貼り付けることができます。
クエリは Kusto クエリ言語 (KQL) で作成します。 KQL の概念とクエリの詳細については、この便利なクイック リファレンス ガイドに関するページを参照してください。
このスクリーンショットに示されている例では、SecurityEvent テーブルにクエリを実行して、失敗した Windows ログオン イベントの種類を表示します。
もう 1 つ、異常な数のリソースが Azure アクティビティで作成されたときにアラートを発するサンプル クエリを次に示します。
AzureActivity | where OperationName == "Create or Update Virtual Machine" or OperationName =="Create Deployment" | where ActivityStatus == "Succeeded" | make-series dcount(ResourceId) default=0 on EventSubmissionTimestamp in range(ago(7d), now(), 1d) by Caller重要
クエリでは、ネイティブ テーブルではなく、高度なセキュリティ情報モデル (ASIM) パーサーを使用することをお勧めします。 これにより、クエリは、1 つのデータ ソースではなく、現在または将来の関連するデータ ソースをサポートします。
注意
ルール クエリのベスト プラクティス:
クエリの長さは 1 から 10,000 文字にする必要があります。また、"
search *" または "union *" を含めることはできません。 ユーザー定義関数を使用すると、クエリの長さの制限を克服できます。ADX 関数を使用して Log Analytics クエリウィンドウ 内で Azure Data Explorer クエリを作成することは、サポートされていません。
クエリで
bag_unpack関数を使用する場合、"project field1" を使用して列をフィールドとして射影しても、その列が存在しないと、クエリは失敗します。 このような事態を防ぐために、次のように列を射影する必要があります。project field1 = column_ifexists("field1","")
アラート エンリッチメント
エンティティ マッピング構成に関するセクションを参考にして、クエリ結果からのパラメーターを Microsoft Sentinel で認識しているエンティティにマッピングします。 エンティティにより、ルールの出力 (アラートとインシデント) が、その後の調査プロセスと修正アクションの構成要素として機能する重要な情報で強化されます。 また、 [インシデントの設定] タブでアラートをインシデントにグループ化するための条件でもあります。
Microsoft Sentinel のエンティティの詳細を確認します。
エンティティのマッピングの詳細な手順と、制限と下位互換性に関する重要な情報については、「データ フィールドを Microsoft Sentinel のエンティティにマップする」を参照してください。
[カスタムの詳細] 構成セクションを使用すると、クエリからイベント データ項目を抽出し、このルールによって生成されるアラートにそれらを表示できます。これにより、アラートとインシデントでイベント コンテンツをすぐに確認できます。
アラートにカスタムの詳細を表示する詳細については、詳細な手順を参照してください。
[アラートの詳細] 構成セクションを使用して、アラートのプロパティの既定値を基になるクエリ結果の詳細でオーバーライドします。 アラートの詳細を使用すると、たとえば攻撃者の IP アドレスやアカウント名をアラート自体のタイトルに表示できます。したがって、インシデント キューに表示され、脅威状況をより明確にはっきりと把握できます。
詳細な手順については、アラート詳細のカスタマイズに関するページを参照してください。
注意
アラート全体のサイズ制限は 64 KBです。
64 KB を超えるアラートは切り捨てられます。 エンティティは、識別されると、アラートのサイズが 64 KB に達するまで 1 つずつアラートに追加され、残りのエンティティはアラートから削除されます。
他のアラート エンリッチメントもアラートのサイズに影響します。
アラートのサイズを小さくするには、クエリで
project-away演算子を使用して、不要なフィールドを削除します。 (保持する必要のあるフィールドが少ない場合は、project演算子も検討してください。)
クエリのスケジュール設定とアラートのしきい値
[クエリのスケジュール設定] セクションで、次のパラメーターを設定します。
[クエリの実行間隔] の設定では、クエリが実行される頻度 (5 分間隔の高頻度や、14 日に 1 回の低頻度) を制御します。
[次の時間分の過去のデータを参照します] の設定では、クエリの対象となるデータの期間を決定します。たとえば、過去 10 分間のデータや、過去 6 時間のデータのクエリを実行できます。 最大値は 14 日です。
新しい [Start running](実行の開始) 設定 (プレビュー) について:
設定を [自動] のままにすると、元の動作が維持されます。ルールは、まず作成直後に、それから [クエリの実行間隔] 設定に設定されている間隔で実行されます。
ルールをすぐに実行するのではなく、最初に実行するタイミングを指定する必要がある場合は、スイッチを [At specific time](特定の時点) に切り替えます。 次に、カレンダー選択機能を使用して日付を選択し、例に示されている形式で時刻を入力します。
ルールが最初に実行されたら、その後の実行は指定された間隔で行われます。
[Start running](実行の開始) 設定の下にあるテキスト行 (その左側に情報アイコンがある) に、クエリのスケジュールとルックバックの設定が要約されます。
注意
クエリ間隔とルックバック期間
これら 2 つの設定は、ある程度まで互いに独立しています。 間隔より長い期間をカバーする短い間隔でクエリを実行できますが (重複するクエリがある場合)、カバレッジ期間を超える間隔でクエリを実行することはできません。そうしないと、クエリ カバレッジ全体にギャップが生じることになります。
インジェストの遅延
ソースでのイベントの生成と Microsoft Sentinel へのインジェストの間で発生する可能性がある待ち時間を考慮し、データが重複せずに完全にカバーされるようにするために、Microsoft Sentinel では、スケジュールされた時間から 5 分間遅延して、スケジュールされた分析ルールが実行されます。
詳細については、「スケジュールされた分析ルールでインジェストの遅延を処理する」を参照してください。
ルールの感度を定義するには、 [アラートのしきい値] セクションを使用します。 たとえば、クエリが実行されるたびに 1,000 件を超える結果が返される場合にのみアラートを生成するルールが必要な場合は、 [クエリ結果件数でアラートを生成する] を [次の値より大きい] に設定し、数値の 1,000 を入力します。 これは必須フィールドなので、しきい値を設定しない場合、つまりアラートですべてのイベントを登録する場合は、数値のフィールドに「0」を入力します。
結果のシミュレーション
ウィザードの右側にある [Results simulation](結果のシミュレーション) 領域で、 [Test with current data](現在のデータでテストする) を選択すると、Microsoft Sentinel によって、現在定義されているスケジュールに従って、クエリから実行された最後の 50 回で生成された結果 (ログ イベント) のグラフが表示されます。 クエリを変更する場合は、 [Test with current data](現在のデータでテストする) をもう一度クリックして、グラフを更新します。 グラフには、定義された期間における結果の数が表示されます。これは、 [クエリのスケジュール設定] セクションの設定によって決まります。
上のスクリーンショットのクエリに対する結果のシミュレーションは次のようになります。 左側は既定のビューであり、右側はグラフ上の特定の時点にマウス ポインターを合わせたときに表示される内容です。
クエリによってトリガーされるアラートが多すぎる場合や頻繁すぎる場合は、[クエリのスケジュール設定] と [アラートのしきい値]セクション の設定を試してから、[現在のデータでテストする] をもう一度選択します。
イベントのグループ化とルールの抑制
[イベントのグループ化] で、イベントのアラートへのグループ化を処理する 2 つの方法のうち、いずれかを選択します。
[すべてのイベントを単一のアラートにグループ化する] (既定の設定)。 このルールでは、クエリで前記のアラートのしきい値よりも多くの結果が返される限り、実行されるたびに 1 つのアラートが生成されます。 このアラートには、結果で返されたすべてのイベントの概要が含まれています。
[各イベントに対するアラートをトリガーする] 。 このルールでは、クエリによって返されるイベントごとに独自のアラートが生成されます。 これは、イベントを個々に表示する場合や、ユーザーやホスト名など、特定のパラメーター別にイベントをグループ化する場合に便利です。 これらのパラメーターはクエリ内で定義できます。
現在のところ、1 つのルールで生成できるアラートの数は 150 に制限されています。 特定のルールで、[イベントのグループ化] が [各イベントに対するアラートをトリガーする] に設定されていて、ルールのクエリから 150 を超えるイベントが返された場合、最初の 149 件のイベントについてはそれぞれに独自のアラートが生成され、150 番目のアラートでは、返された一連のイベント全体がまとめられます。 言い換えると、150 番目のアラートは、[すべてのイベントを単一のアラートにグループ化する] オプションによって生成されたであろうアラートです。
このオプションを選択すると、Microsoft Sentinel によって、新しいフィールド [OriginalQuery] がクエリの結果に追加されます。 既存の [Query] フィールドと新しいフィールドの比較を次に示します。
フィールド名 内容 このフィールドでクエリを実行した場合の
結果クエリ このアラート インスタンスを生成したイベントの圧縮レコード このアラート インスタンスを生成したイベント。
10240 バイトに制限OriginalQuery 分析ルールに記述されている元のクエリ クエリによって定義されたパラメーターに適合する、クエリが実行される時間枠内で最新のイベント つまり、OriginalQuery フィールドは、Query フィールドの通常の動作と同様に動作します。 この追加フィールドの結果として、下のトラブルシューティング セクションの最初の項目で説明されている問題が解決されました。
注意
イベントとアラートの違いは何でしょうか。
イベントは、アクションの 1 回の出現を表します。 たとえば、ログ ファイル内の 1 つのエントリは、1 つのイベントとしてカウントされる可能性があります。 このコンテキストでは、1 つのイベントは、分析ルールのクエリによって返された単一の結果を指します。
アラートは、一緒にまとめられるイベントのコレクションで、セキュリティの観点からは重要なものです。 イベントにセキュリティ上の重要な意味がある場合は、1 つのアラートに 1 つのイベントが含まれる場合があります。たとえば、勤務時間外に外国または他の地域からの管理ログインがあったなどです。
では、インシデントとは何でしょうか。 Microsoft Sentinel の内部ロジックでは、アラートまたはアラートのグループからインシデントが作成されます。 インシデント キューは、トリアージ、調査、修復といった SOC アナリストの作業の中心です。
Microsoft Sentinel は、いくつかのデータ ソースから未加工のイベントを取り込み、他のデータ ソースから処理済みのアラートを取り込みます。 ある時点で、どちらを扱っているかに注目することが重要です。
アラートが生成された後、クエリ間隔を超える期間だけこのルールの操作を中断する場合は、 [抑制] セクションで、 [アラートの生成後にクエリの実行を停止する] の設定を [オン] にすることができます。 これをオンにする場合は、 [クエリの実行を停止する] をクエリの実行を停止する時間 (最大 24 時間) に設定する必要があります。
インシデントの作成の設定を構成する
[インシデントの設定] タブでは、アラートをアクションにつながるインシデントに変換するかどうか、およびその方法を選択できます。 このタブを設定しないと、すべてのアラートに対して個別に 1 つのインシデントが作成されます。 このタブの設定を変更することで、インシデントを作成しないようにしたり、複数のアラートを 1 つのインシデントにグループ化したりすることができます。
次に例を示します。
インシデントの設定
[インシデントの設定] セクションでは、 [この分析ルールによってトリガーされるアラートからインシデントを作成する] が既定で [有効] に設定されています。つまり、ルールによってトリガーされるすべての個々のアラートから、1 つの個別のインシデントが作成されます。
このルールによってインシデントが作成されないようにする場合は (たとえば、このルールが後続の分析のために情報を収集するだけの場合)、これを [無効] に設定します。
単一のインシデントをアラートごとにではなく、アラートのグループから作成する場合は、次のセクションをご覧ください。
アラートのグループ化
最大 150 件の類似したアラートまたは繰り返し発生するアラートのグループから単一のインシデントを生成する場合 (注を参照) は、 [アラートのグループ化] セクションで、 [この分析ルールによってトリガーされる関連アラートをインシデントにグループ化する] を [有効] に設定し、以下のパラメーターを設定します。
[選択した期間内に作成されたアラートのみにグループを制限する] :似たアラートまたは繰り返し発生するアラートをグループ化する期間を決定します。 この期間内の対応するすべてのアラートでは、1 つのインシデントまたはインシデントのセットがまとめて生成されます (以下のグループ化の設定に依存します)。 この期間外のアラートでは、個別のインシデントまたはインシデントのセットが生成されます。
[この分析ルールによってトリガーされるアラートを次の方法で単一のインシデントにグループ化する] :アラートをグループ化する基準を選択します。
オプション 説明 すべてのエンティティが一致した場合にアラートを 1 つのインシデントにグループ化する (上の [ルールのロジックを設定] タブに定義された) マップされている各エンティティに関して同じ値を共有している場合、アラートはグループ化されます。 これは推奨される設定です。 このルールによってトリガーされるすべてのアラートを 1 つのインシデントにグループ化する 値が同じではない場合でも、このルールによって生成されるすべてのアラートをグループ化します。 選択したエンティティと詳細が一致する場合にアラートを 1 つのインシデントにグループ化する マップされたエンティティ、アラートの詳細、および各ドロップダウン リストから選択されたカスタムの詳細のすべてに関して同じ値を共有している場合、アラートはグループ化されます。
たとえば、ソースまたはターゲットの IP アドレスに基づいて別々のインシデントを作成したい場合や、特定のエンティティと重要度に一致するアラートをグループ化したい場合、この設定を使用できます。
注: このオプションを選択する場合は、ルールに対して少なくとも 1 つのエンティティ型またはフィールドが選択されている必要があります。 そうしないと、ルールの検証が失敗し、ルールは作成されません。[Re-open closed matching incidents](クローズされた一致するインシデントを再度開く) :あるインシデントが解決されて閉じられたとします。後でそのインシデントに属するはずの別のアラートが生成されたときに、閉じられたインシデントを再び開きたい場合は、この設定を [有効] に設定します。別のアラートで新しいインシデントを作成する場合は [無効] のままにします。
注意
最大 150 件のアラートを 1 つのインシデントにグループ化できます。
インシデントが作成されるのは、すべてのアラートが生成された後です。 すべてのアラートは、インシデントの作成時にすぐにそこに追加されます。
アラートを 1 つのインシデントにグループ化するルールによって生成されたアラートが 150 件を超える場合は、最初と同じインシデントの詳細を含む新しいインシデントが生成され、超過したアラートは新しいインシデントにグループ化されます。
自動応答を設定してルールを作成する
[Automated responses] (自動応答) タブでは、自動化ルールを使用して、次の 3 種類の場合に自動応答を実行するように設定できます。
- この分析ルールによってアラートが生成されたとき。
- この分析ルールによって生成されたアラートを使用してインシデントが作成されたとき。
- この分析ルールによって生成されたアラートを使用してインシデントが更新されたとき。
[自動化ルール] の下に表示されるグリッドには、この分析ルールに既に適用されている自動化ルールが表示されます (これらのルールで定義されている条件を満たしているため)。 各行の末尾にある省略記号を選択することで、これらの任意のものを編集できます。 または、新しい自動化ルールを作成することもできます。
自動化ルールを使用して、インシデントの基本的なトリアージ、割り当て、ワークフロー、終了を実行します。
これらの自動化ルールからプレイブックを呼び出すことで、より複雑なタスクを自動化し、リモート システムからの応答を呼び出して脅威を修復します。 これは、インシデントと個々のアラートに対して行うことができます。
プレイブックや自動化ルールの作成に関する詳細と手順については、「脅威への対応を自動化する」を参照してください。
インシデント作成トリガー、インシデント更新トリガー、アラート作成トリガーを使用するタイミングの詳細については、「Microsoft Sentinel のプレイブックでトリガーとアクションを使用する」を参照してください。
画面下部の [アラートのオートメーション (クラシック)] の下に、古い方式を使用してアラートが生成されたときに自動的に実行するように構成したプレイブックが表示されます。
2023 年 6 月の時点で、このリストにプレイブックを追加することはできなくなりました。 既にここに記載されているプレイブックは、2026 年 3 月にこの方法が非推奨となるまで実行され続けます。
ここに記載されているプレイブックをまだお持ちの場合は、代わりにアラート作成トリガーに基づいて自動化ルールを作成し、そこからプレイブックを呼び出す必要があります。 完了したら、ここに記載されているプレイブックの行の末尾にある省略記号を選択し、[削除] を選択します。 詳細な手順については、「Microsoft Sentinel のアラートトリガー プレイブックをオートメーション ルールに移行する」を参照してください。
[確認と作成] を選択して新しい分析ルールのすべての設定を確認します。 "検証に成功しました" のメッセージが表示されたら、[作成] を選びます。
ルールとその出力を表示する
新しく作成されたカスタムルール (種類は "スケジュールされた") は、メインの [分析] 画面の [アクティブなルール] タブの下のテーブルにあります。 この一覧から、各ルールを有効にしたり、無効にしたり、削除したりできます。
作成した分析ルールの結果を表示するには、[インシデント] ページに移動します。ここで、インシデントをトリアージし、調査し、脅威を修復できます。
ルール クエリを更新して、偽陽性を除外できます。 詳細については、「Microsoft Sentinel での擬陽性の処理」を参照してください。
注意
Microsoft Sentinel で生成されたアラートは、Microsoft Graph Security を通じて使用できます。 詳細については、Microsoft Graph のセキュリティ アラートのドキュメントを参照してください。
ルールを ARM テンプレートにエクスポートする
ルールをコードとして管理およびデプロイするようにパッケージ化する場合は、簡単にルールを Azure Resource Manager (ARM) テンプレートにエクスポートできます。 また、ルールをユーザー インターフェイスに表示して編集するために、テンプレート ファイルからインポートすることもできます。
トラブルシューティング
問題点:クエリ結果にイベントが表示されない
イベントのグループ化が各イベントのアラートをトリガーするように設定されている場合、後で表示されるクエリ結果が欠落しているか、予想とは異なるように見える場合があります。 たとえば、後で関連するインシデントの結果にピボットして戻ったときに、クエリの結果を表示する場合があります。
- 結果は、アラートと共に自動的に保存されます。 ただし、結果が大きすぎる場合、結果は保存されず、クエリ結果を再度表示したときにデータが表示されません。
- インジェストの遅延が発生した場合、または集計が原因でクエリが決定的ではない場合、アラートの結果は、手動でクエリを実行したときに表示される結果とは異なる場合があります。
注意
この問題は、このイベントのグループ化オプションが選択されるときに新しいフィールド OriginalQuery を結果に追加することによって解決されました。 上記の説明を参照してください。
問題点:スケジュールされたルールの実行に失敗するか、名前に「自動無効化」が追加される
スケジュールされたクエリ ルールの実行が失敗することはめったにありませんが、発生する可能性があります。 Microsoft Sentinel は、具体的な障害の種類とそれを引き起こした状況に基づいて、障害を一時的または永続的として事前に分類します。
一時的な障害
一時的な障害は、一時的な状況が原因で発生し、すぐに正常な状況に戻ります。その時点で、ルールの実行は成功します。 Microsoft Sentinel によって一時的として分類される障害の例を次に示します。
- ルール クエリの実行に時間がかかりすぎて、タイムアウトになった。
- データ ソースと Log Analytics 間、または Log Analytics と Microsoft Sentinel 間の接続に問題がある。
- その他の新規および不明な障害は一時的なものと見なされます。
一時的な障害が発生した場合、Microsoft Sentinel では、(ある時点まで) 毎回増分するように事前定義された間隔で、ルールの実行が再試行し続けられます。 その後、ルールは次回のスケジュールされた時刻にのみ再び実行されます。 一時的な障害が原因で、ルールが自動的に無効になることはありません。
永続的な障害 - ルールの自動無効化
永続的な障害は、ルールの実行を許可する条件が変更されたことが原因で発生します。これは、ユーザーの介入なしでは元の状態に戻りません。 永続的として分類される障害の例をいくつか次に示します。
- (ルール クエリが運用されている) ターゲット ワークスペースが削除された。
- (ルール クエリが運用されている) ターゲット テーブルが削除された。
- Microsoft Sentinel がターゲット ワークスペースから削除された。
- ルール クエリで使用される関数が有効ではなくなった (変更または削除された)。
- ルール クエリのいずれかのデータ ソースに対するアクセス許可が変更された (以下の例をご覧ください)。
- ルール クエリのいずれかのデータ ソースが削除された。
同じルールに対して同じ種類の永続的な障害が事前に指定されている回数連続して発生した場合、Microsoft Sentinel ではルールの実行が停止され、次の手順も実行されます。
- ルールを無効にします。
- ルールの名前の先頭に「自動無効化」という単語を追加します。
- 障害 (および無効化) の理由をルールの説明に追加します。
ルールの一覧を名前で並べ替えると、自動無効化されたルールがあるかどうかを簡単に確認することができます。 自動無効化されたルールは、一覧の先頭付近にあります。
SOC マネージャーは、自動無効化されたルールがあるかどうかについて、ルールの一覧を定期的に確認する必要があります。
リソースのドレインによる永続的な障害
別の種類の永続的な障害の原因として、不適切に構築されたクエリがあります。これにより、ルールが過剰なコンピューティング リソースを消費し、システムのパフォーマンス低下のリスクを引き起こします。 Microsoft Sentinel でこのようなルールが識別されると、他の永続的な障害について説明した上記と同じ 3 つの手順が実行されます。ルールは無効になり、ルール名の前に "AUTO DISABLED" が付加され、エラーの理由が説明に追加されます。
このルールを再度有効にするには、クエリでリソースの使用が多すぎる原因となっている問題に対処する必要があります。 Kusto クエリを最適化するためのベスト プラクティスについては、次の記事を参照してください。
また、追加の支援のために、「Microsoft Sentinel で Kusto 照会言語を操作する際に役立つリソース」も参照してください。
サブスクリプション/テナント間でアクセスが失われたための永続的なエラー
データソースに対するアクセス許可の変更 (上記の一覧を参照) が原因で永続的なエラーが発生する可能性のある場合の具体例として、MSSP の場合など、分析ルールがサブスクリプションまたはテナント間でクエリを実行するシナリオに関するものがあります。
分析ルールを作成すると、アクセス許可トークンがそのルールに適用され、一緒に保存されます。 このトークンにより、ルールによってクエリが実行されたデータを含むワークスペースにルールがアクセスできるようになります。また、ルールの作成者がこのワークスペースへのアクセスを失った場合でも、このアクセスは維持されます。
ただし、これには例外が 1 つあります。MSSP の場合のように、他のサブスクリプションまたはテナントのワークスペースにアクセスするためのルールが作成される場合、Microsoft Sentinel は顧客データへの無認可のアクセスを防ぐために追加のセキュリティ対策を講じます。 これに該当するルールの場合、個別のアクセス トークンではなくルールを作成したユーザーの資格情報がそのルールに適用されるため、ユーザーが他のテナントにアクセスできなくなった場合、そのルールは機能しなくなります。
Microsoft Sentinel をクロス サブスクリプションまたはクロス テナントのシナリオで運用する場合、アナリストまたはエンジニアの誰かが特定のワークスペースへのアクセスを失うと、そのユーザーにより作成されたすべてのルールが機能しなくなるので注意してください。 "リソースへのアクセスが不十分" という稼働状況の監視に関するメッセージが表示され、ルールは上記の手順に従い自動的に無効になります。
次のステップ
分析ルールを使用して Microsoft Sentinel から脅威を検出する場合は、セキュリティが環境全体に確実に適用されるように、接続されたデータ ソースに関連付けられているすべてのルールを必ず有効にしてください。
ルールの有効化を自動化するには、API および PowerShell 経由で Microsoft Sentinel にルールをプッシュすることもできますが、それを行うには追加の作業が必要です。 API または PowerShell を使用する場合は、ルールを有効にする前に、最初にルールを JSON にエクスポートする必要があります。 API または PowerShell は、Microsoft Sentinel の複数のインスタンスでルールを有効にし、各インスタンスの設定を同じにする場合に役立つことがあります。
詳細については、次を参照してください。
- チュートリアル: Microsoft Sentinel でインシデントを調査する
- Microsoft Sentinel でのインシデントの確認と調査 - プレビュー
- Microsoft Sentinel でエンティティを使用してデータを分類および分析する
- チュートリアル: Microsoft Sentinel でオートメーション ルールとプレイブックを使用する
また、カスタム コネクタで Zoom を監視するするときにカスタム分析ルールを使用する例も参照してください。