Microsoft Sentinelの自動化ルールは、Microsoft Defender環境で発生するインシデントやアラートに対して、担当者の割り当て、ステータス変更、タグ付け、タスク追加、プレイブック実行を自動化するための仕組みです。結論から言うと、管理者が今すぐ確認すべきポイントは「Defenderポータル移行を前提に、既存の自動化ルールのトリガー、条件、実行順序、プレイブック権限、外部連携を棚卸しすること」です。
特に、Azure portalでMicrosoft Sentinelを運用している組織は注意が必要です。Microsoft Sentinelは2027年3月31日以降、Azure portalではサポートされず、Microsoft Defenderポータルでの利用に移行します。既存の自動化ルールがそのまま意図どおり動くとは限らないため、SOC運用、チケット連携、通知フロー、インシデント抑制ルールを早めに見直しておくべきです。(Microsoft Learn)
Microsoft Sentinel自動化ルールとは
Microsoft Sentinel自動化ルールは、脅威対応の自動化を一元管理するための機能です。Security Orchestration, Automation and Response、いわゆるSOAR運用の中で、繰り返し発生するインシデント処理を標準化し、SOC担当者の手作業を減らす役割を持ちます。(Microsoft Learn)
自動化ルールで実行できる代表的な処理は次のとおりです。
| 自動化できる処理 | 実務での使い方 |
|---|---|
| インシデントタスクの追加 | 初動調査、影響範囲確認、封じ込め確認などのチェックリストを自動で付与する |
| ステータス変更 | 新規インシデントを自動でアクティブ化し、対応漏れを減らす |
| 重大度変更 | 条件に応じてHighからMediumへ下げる、または重要システムなら引き上げる |
| 担当者割り当て | Endpoint系は端末担当、Identity系はID管理担当に自動割り当てする |
| タグ追加 | endpoint、identity、pentest、false-positive-candidateなどで分類する |
| プレイブック実行 | Logic Appsを使い、通知、チケット作成、外部システム連携を実行する |
ポイントは、自動化ルールが「すべてを自動修復する魔法の機能」ではないことです。実務では、誤検知の自動クローズ、一次振り分け、担当者割り当て、チケット連携、アナリスト向けタスク追加のように、判断が定型化できる処理から適用すると失敗しにくくなります。
何が変わるのか：Defenderポータル前提の運用に寄せる必要がある
今回の公式情報で重要なのは、単に「自動化ルールの使い方を理解する」ことではありません。Microsoft DefenderポータルでMicrosoft Sentinelを使う前提が強まり、Azure portal時代の設計をそのまま維持すると、条件評価や外部連携で差異が出る可能性がある点です。
Microsoft Sentinelの自動化ルールは、Microsoft DefenderポータルとAzure portalの両方に適用されます。ただし、Defenderポータルにワークスペースをオンボードした後は、インシデント生成、相関、表示、API、プレイブック起動の挙動に差が出ます。公式ドキュメントでも、Defenderポータルへの移行時に自動化ルールとプレイブックの設定変更が必要になる可能性があると説明されています。(Microsoft Learn)
管理者が特に確認すべき変更点は次のとおりです。
| 確認項目 | 影響 | 管理者が取るべき対応 |
|---|---|---|
| Azure portal依存 | 2027年3月31日以降はAzure portalでMicrosoft Sentinelがサポートされない | Defenderポータルへの移行計画を作成する |
| アラートトリガー | Defenderポータルでは、アラートトリガーの自動化ルールはMicrosoft Sentinelアラートに対して動作する | Defender XDR由来アラートを対象にしていないか確認する |
| インシデントプロバイダー条件 | Defenderポータルではインシデントプロバイダー条件の扱いが変わり、既存ルールの対象範囲が広がる可能性がある | 条件を分析ルール名やタグに寄せる |
Description条件 | Defenderポータルにオンボード後、SecurityIncidentテーブルにDescriptionフィールドが含まれない | 説明文を条件にしているルールを修正する |
| インシデント名条件 | Defenderポータルの相関エンジンにより、既存インシデント名が変わる可能性がある | インシデントタイトルではなく、分析ルール名やタグを使う |
Updated by条件 | オンボード後にサポート値が変わり、Microsoft 365 DefenderがOtherに置き換わる場合がある | 更新者条件を使うルールを再確認する |
| 実行遅延 | Defender側で作成されたインシデントがSentinelに反映されるまで遅延する場合がある | 即時実行を前提にした通知・封じ込め処理を検証する |
| インシデントからの直接作成 | Defenderポータルでは、インシデントから直接自動化ルールを作成する手順はサポートされない | Automationページから新規作成する |
| 複数ワークスペース | Defender XDRデータがプライマリワークスペースに取り込まれる構成では、ルール配置の見直しが必要 | 実際にデータが入るワークスペースへルールを移す |
この中でも、Description条件、インシデント名条件、Updated by条件は見落としやすいポイントです。既存ルールが「エラーで止まる」だけでなく、「動いているように見えるが対象が変わる」ケースもあるため、移行前後でテストインシデントを使った動作確認が必要です。(Microsoft Learn)
対象者と影響範囲
この変更の影響を受けやすいのは、Microsoft DefenderとMicrosoft Sentinelを組み合わせてSOC運用している組織です。特に、次の担当者は早めに確認しておくべきです。
| 対象者 | 確認すべきこと |
|---|---|
| セキュリティ管理者 | Defenderポータル移行計画、ワークスペース、データコネクタ、権限設計 |
| SOCマネージャー | インシデント振り分け、担当者割り当て、抑制ルール、エスカレーション基準 |
| 検知エンジニア | 分析ルール名、インシデント作成設定、アラートグルーピング、相関後の挙動 |
| プレイブック開発者 | Logic Apps、外部チケットシステム、通知、API応答形式の変更 |
| MSSP運用担当 | マルチテナント、Azure Lighthouse、顧客テナントとサービスプロバイダーテナントの権限 |
| 監査・運用改善担当 | 自動クローズ理由、コメント、タグ、監査ログ、CI/CD管理 |
Microsoft Defender for Endpoint、Microsoft Defender for Office 365、Microsoft Defender for Identity、Microsoft Defender for Cloud AppsなどのアラートをSentinel側で扱っている場合、自動化ルールの条件がどのインシデントに適用されるのかを必ず確認してください。Microsoftセキュリティアラートをインシデントとして扱い、そこからプレイブックを呼び出す構成は一般的ですが、Defenderポータル移行後は相関や統合インシデントキューの考え方も含めて見直しが必要です。(Microsoft Learn)
自動化ルールの基本構造
Microsoft Sentinel自動化ルールは、主に「トリガー」「条件」「アクション」の3要素で構成されます。設計時は、いきなりアクションから考えるのではなく、「どのタイミングで」「どの対象に」「何をするか」の順に整理すると失敗しにくくなります。(Microsoft Learn)
トリガー：いつ自動化を開始するか
自動化ルールのトリガーは、大きく次の3種類です。
| トリガー | 向いている用途 | 注意点 |
|---|---|---|
| インシデント作成時 | 初期トリアージ、担当者割り当て、タグ付け、チケット作成 | 多くのケースで第一候補になる |
| インシデント更新時 | 重大度変更時の通知、所有者変更時の連携、チケット更新 | 更新者条件や実行順序を慎重に設計する |
| アラート作成時 | インシデントを作らない分析ルールへの対応 | Defenderポータルでは対象範囲に制約がある |
公式ドキュメントでは、多くのユースケースではインシデントを起点にした自動化が推奨されています。インシデントはアラート、エンティティ、コメント、タグ、ブックマークなどを含む「調査のケースファイル」として扱えるため、単一のアラートよりもSOC運用に適しているからです。(Microsoft Learn)
一方、アラートトリガーが有効なのは、インシデントを作成しない分析ルールに対応したい場合です。たとえば、外部ロジックでインシデント作成の可否を判断したい、またはアラートを外部チケットシステムへ先に送信したい場合に使います。ただし、アラートトリガーの自動化は、スケジュール済み、NRT、Microsoftセキュリティ分析ルールで作成されたアラートに限定され、Microsoft Defender XDRによって作成されたアラートに対するアラートトリガー自動化はDefenderポータルでは利用できません。(Microsoft Learn)
条件：どのインシデント・アラートに適用するか
条件では、インシデントの状態、重大度、所有者、タグ、分析ルール名、エンティティ情報などを使って、ルールを実行する対象を絞り込みます。
実務でよく使う条件の例は次のとおりです。
| 条件の例 | 使い方 |
|---|---|
| 分析ルール名に特定文字列を含む | Endpoint系、Identity系、Cloud Apps系などに分類する |
| 重大度がHigh以上 | 緊急通知や上位担当者への割り当てを行う |
タグにpentestを含む | ペネトレーションテスト期間中のノイズを抑制する |
| 所有者が未割り当て | 一次担当者に自動割り当てする |
| 更新者が自動化ルールではない | 自動化ループを防ぐ |
注意したいのは、複数の自動化ルールが同じインシデントに対して実行される場合です。後続ルールは、先に実行されたルールによって変更された後の状態をもとに条件を評価します。たとえば、最初のルールが重大度をMediumからLowへ変更した場合、「重大度がMedium以上」の後続ルールは実行されない可能性があります。(Microsoft Learn)
アクション：実際に何を自動実行するか
アクションでは、条件を満たしたインシデントやアラートに対して実行する処理を指定します。プレイブックを使わなくても、タスク追加、ステータス変更、重大度変更、担当者割り当て、タグ追加を実行できます。より複雑な処理が必要な場合は、Azure Logic Appsベースのプレイブックを呼び出します。(Microsoft Learn)
ただし、プレイブック実行には2つの重要な条件があります。
1つ目は、トリガー種別の一致です。インシデントトリガーの自動化ルールからは、インシデントトリガーで始まるプレイブックだけを実行できます。アラートトリガーの自動化ルールからは、アラートトリガーのプレイブックだけが対象です。
2つ目は、権限です。Microsoft Sentinelがプレイブックのあるリソースグループに対して明示的な権限を持っていない場合、プレイブックは選択肢でグレーアウトします。権限付与には対象リソースグループのOwner権限が必要で、プレイブックを含むリソースグループにはMicrosoft Sentinel Automation Contributorロールも関係します。(Microsoft Learn)
インシデント起点とアラート起点の使い分け
自動化ルールの設計で迷いやすいのが、インシデント起点にするか、アラート起点にするかです。基本方針はシンプルです。
調査、担当者割り当て、エスカレーション、チケット連携、対応履歴の管理を目的にするなら、インシデント起点を選びます。インシデントは複数のアラートやエンティティをまとめた調査単位であり、SOCの運用単位として扱いやすいからです。
一方、インシデントを作成しない分析ルールに対して通知だけ行いたい、外部システムでインシデント化するか判断したい、または特定のアラートを別のシステムに送信したい場合は、アラート起点を検討します。
| 判断基準 | 推奨 |
|---|---|
| SOCがインシデント単位で調査する | インシデント起点 |
| 担当者割り当てやステータス管理をしたい | インシデント起点 |
| インシデントにタスクを追加したい | インシデント起点 |
| インシデントを作らない分析ルールに反応したい | アラート起点 |
| 外部システム側でチケット化を判断したい | アラート起点も検討 |
| Defender XDR由来アラートをDefenderポータルで直接アラートトリガー処理したい | 制約があるため再設計が必要 |
迷った場合は、インシデント起点で設計してください。アラート起点は便利ですが、Defenderポータルでの制約やインシデント相関の影響を受けやすく、運用が複雑になりがちです。
管理者が確認すべき設定チェックリスト
既存環境を見直す場合は、次の順番で確認すると抜け漏れを減らせます。
既存の自動化ルールを棚卸しする
まず、すべての自動化ルールを一覧化します。ルール名、トリガー、条件、アクション、実行順序、対象分析ルール、プレイブック、作成元ポータル、最終更新者を記録してください。
Microsoft Sentinelでは、自動化ルールをARMテンプレートとしてエクスポートし、別ワークスペースや別テナントにインポートできます。JSONファイルとして管理できるため、バージョン管理やCI/CDに組み込むことも可能です。運用変更の履歴を残したい組織は、エクスポートしたルールをリポジトリで管理するのが現実的です。(Microsoft Learn)
ルールの目的を分類する
次に、各ルールを目的別に分類します。分類すると、不要な重複や危険な自動クローズを見つけやすくなります。
| 分類 | 例 | 見直しポイント |
|---|---|---|
| 初期トリアージ | 新規インシデントをActiveにし、所有者を割り当てる | 担当者が退職・異動していないか |
| 抑制 | 既知の誤検知やメンテナンス起因のインシデントを閉じる | 有効期限とクローズ理由があるか |
| エスカレーション | High以上を上位担当者へ割り当てる | 実行順序が抑制ルールより後になっていないか |
| タグ付け | 製品、攻撃種別、運用区分で分類する | タグ名が一貫しているか |
| タスク追加 | 初動対応チェックリストを付与する | 現在の運用手順と合っているか |
| 外部連携 | チケット作成、通知、台帳更新 | API、URL、説明フィールドの変更に対応しているか |
特に、抑制ルールは慎重に扱う必要があります。ペネトレーションテストや計画メンテナンス時のノイズを自動クローズする用途には有効ですが、有効期限なしで残すと、本来調査すべきインシデントまで閉じてしまう危険があります。Microsoft Sentinelでは自動化ルールに有効期限を設定できるため、期間限定の抑制では必ず期限を入れるべきです。(Microsoft Learn)
Defenderポータル移行で壊れやすい条件を探す
Defenderポータルへの移行で特に確認したいのは条件です。次の条件を使っているルールは、優先的に見直してください。
| 条件 | なぜ危険か | 代替案 |
|---|---|---|
| インシデントタイトル | 相関により名前が変わる可能性がある | 分析ルール名、タグ、重大度を使う |
Description | Defenderポータル移行後にSecurityIncidentテーブルからなくなる | タグ、カスタムエンティティ、外部チケット側の項目を使う |
| インシデントプロバイダー | DefenderポータルではProviderNameがMicrosoft XDRになる | 分析ルール名でSentinel由来を絞る |
Updated by = Microsoft 365 Defender | オンボード後にOtherへ置き換わる可能性がある | 新しいサポート値に合わせて再設定する |
| 否定条件のタグ判定 | 個別タグとタグ集合で評価結果が変わる | 「個々のタグ」か「タグ全体」かを明確に選ぶ |
タグ条件も油断できません。たとえば「タグに2024を含まない」という条件は、個々のタグを評価するのか、タグ集合全体を評価するのかで結果が変わります。複数タグを付ける運用では、否定条件を使った自動クローズや抑制を避け、できるだけ肯定条件で対象を明示した方が安全です。(Microsoft Learn)
実行順序を整理する
自動化ルールは順番に実行されます。並列ではありません。さらに、同じトリガー種別で同じ順序番号を持つルールが複数ある場合、実行順序はランダムに選ばれます。コマンドラインやAPIで作成したルールでは順序番号を手動で割り当てる必要があるため、IaC運用では特に注意してください。(Microsoft Learn)
実務では、次の順序を目安にすると安定しやすくなります。
| 順序 | ルールの種類 | 理由 |
|---|---|---|
| 先頭 | 明確な誤検知・メンテナンス抑制 | 後続の通知やチケット作成を不要にする |
| 次 | 重大度補正・タグ付け | 後続ルールの条件に使える |
| 次 | 担当者割り当て・タスク追加 | アナリスト作業を標準化する |
| 次 | プレイブックによる通知・チケット連携 | 補正後の状態で外部システムへ送る |
| 最後 | 監査・記録・補助的な更新 | 主処理の後に実行する |
ただし、緊急通知が必要なHighインシデントでは、抑制ルールより通知を先にする方が適切なケースもあります。順序は「ノイズ削減」と「見逃し防止」のどちらを優先するかで決めてください。
プレイブックの権限とトリガーを確認する
プレイブックを実行する自動化ルールでは、次の3点を必ず確認してください。
| 確認項目 | 確認内容 |
|---|---|
| トリガー種別 | インシデントルールにはインシデントトリガーのプレイブック、アラートルールにはアラートトリガーのプレイブックを使う |
| リソースグループ権限 | Microsoft Sentinelがプレイブックのリソースグループにアクセスできるか |
| 実行時間 | 後続アクションがプレイブック完了をどこまで待つかを理解する |
プレイブックの実行時間にも注意が必要です。1秒未満で完了するプレイブックなら完了後すぐに次のアクションへ進みますが、2分を超える場合は、完了していなくても2分後に次のアクションへ進む扱いになります。長時間処理を前提にしている場合、後続アクションが「プレイブック完了後の状態」を前提にしないよう設計してください。(Microsoft Learn)
開発者・外部連携担当が注意すべきポイント
外部チケットシステム、通知基盤、CMDB、SOAR基盤と連携している場合、Defenderポータル移行はAPI設計にも影響します。
公式情報では、Microsoft Defenderポータルの統合エクスペリエンスでは、インシデントやアラート関連の自動化にMicrosoft Graph REST API v1.0を利用できるとされています。一方、Microsoft Sentinel APIは、分析ルールや自動化ルールなどSentinelリソースへの操作を引き続きサポートします。統合されたインシデントやアラートを扱う場合はMicrosoft Graph REST APIが推奨されており、従来のSecurityInsights APIでSentinelインシデントを扱っている場合は、レスポンス本文の変更により条件やトリガー基準の更新が必要になる可能性があります。(Microsoft Learn)
外部連携で特に確認すべき項目は次のとおりです。
| 項目 | 確認内容 |
|---|---|
| インシデントURL | incidentUrlだけでなく、Defenderポータル側のURL項目を利用すべきか |
| プロバイダー名 | Azure Sentinel前提の文字列判定をしていないか |
| 製品名・検知元 | serviceSource、detectionSource、productNameなどの新しい情報を使えるか |
| 説明文 | Descriptionがなくなる前提でチケット本文を構成できるか |
| 相関・マージ | 複数アラートが1つのインシデントに統合された場合、既存チケットの更新として扱えるか |
| 遅延 | DefenderからSentinelへの同期遅延を考慮してリトライできるか |
チケット連携では、「インシデント作成時にチケットを作る」だけでは不十分です。Defenderポータルでは相関エンジンによりアラートが統合されるため、後から追加されたアラート、重大度変更、所有者変更をチケットへ反映する更新系プレイブックも必要になります。
失敗しやすい設定と回避策
インシデントタイトルで条件分岐している
インシデントタイトルは人間には分かりやすい条件ですが、自動化の条件としては不安定です。Defenderポータルでは相関処理により既存インシデント名が変わる可能性があるため、タイトル依存のルールは避けるべきです。分析ルール名、タグ、重大度、エンティティ条件を組み合わせて対象を絞る方が安全です。(Microsoft Learn)
同じ順序番号のルールが複数ある
同じトリガー種別で同じ順序番号のルールが複数あると、実行順序はランダムになります。たとえば、先にタグ付けされることを前提に後続ルールを作っている場合、順序がランダムだと条件を満たさず処理が抜けることがあります。順序番号は用途ごとに間隔を空けて設計すると運用しやすくなります。
例として、抑制系を100番台、重大度補正を200番台、割り当てを300番台、外部連携を400番台にすると、後からルールを追加しても整理しやすくなります。
自動クローズに有効期限を設定していない
ペネトレーションテスト、検証作業、メンテナンス期間中のノイズを閉じるルールは有効ですが、終了後も残ると本番インシデントを閉じてしまうリスクがあります。抑制ルールには有効期限、クローズ理由、コメント、タグを必ず設定してください。
良い例は、pentest-2026-05のようなタグを追加し、終了理由とコメントに「承認済みテスト期間中の検知」と残すことです。悪い例は、分析ルール名だけで恒久的に自動クローズすることです。
アラートトリガーでDefender XDRアラートを処理しようとしている
Defenderポータルでは、Microsoft Defender XDRによって作成されたアラートに対するアラートトリガー自動化は利用できません。Defender XDR由来のイベントを自動化したい場合は、インシデント起点に設計し直すか、Defenderポータルでの対応可能な自動化機能と組み合わせて検討してください。(Microsoft Learn)
プレイブックがグレーアウトしている
プレイブックが選べない場合、よくある原因は権限不足かトリガー不一致です。Microsoft Sentinelにプレイブックのリソースグループに対する権限がない、またはインシデントトリガーの自動化ルールからアラートトリガーのプレイブックを呼ぼうとしている可能性があります。まずはリソースグループ権限とプレイブックの開始トリガーを確認してください。
実務で使いやすい自動化ルール設計例
高重大度インシデントの初動対応を標準化する
重大度Highのインシデントが作成されたら、担当者を割り当て、タグを追加し、初動タスクを付与し、チケットを作成する構成です。
| 設定項目 | 例 |
|---|---|
| トリガー | インシデント作成時 |
| 条件 | 重大度がHigh、または特定の分析ルール名を含む |
| アクション | タグ追加、所有者割り当て、タスク追加、プレイブック実行 |
| 注意点 | 通知前に重大度補正ルールが動くなら、実行順序を調整する |
この設計では、アナリストが最初に見るべき作業がインシデント画面に表示されます。人によって対応手順が変わる問題を減らせるため、SOCの品質を安定させやすくなります。
メンテナンス期間中のノイズを抑制する
計画メンテナンスやペネトレーションテストで大量の既知アラートが発生する場合、条件に一致したインシデントを自動で閉じ、タグとコメントを残す設計です。
| 設定項目 | 例 |
|---|---|
| トリガー | インシデント作成時 |
| 条件 | 分析ルール名、対象エンティティ、メンテナンス用タグ |
| アクション | ステータスをClosedへ変更、クローズ理由とコメント追加、タグ追加 |
| 注意点 | 必ず有効期限を設定する |
このルールは便利ですが、条件を広くしすぎると危険です。「特定期間」「特定分析ルール」「特定対象」の3つを組み合わせ、意図しない本番インシデントを閉じないようにしてください。
外部チケットシステムと同期する
インシデント作成時にチケットを作り、インシデント更新時にチケットを更新する設計です。
| 設定項目 | 作成時ルール | 更新時ルール |
|---|---|---|
| トリガー | インシデント作成時 | インシデント更新時 |
| 条件 | 対象分析ルール、重大度、タグ | 重大度変更、所有者変更、ステータス変更 |
| アクション | プレイブックでチケット作成 | プレイブックでチケット更新 |
| 注意点 | 相関でアラートが追加された場合の更新処理を考慮する | 自動化ループを避ける |
Defenderポータル移行後は、インシデント名や説明文だけに依存せず、インシデントID、関連アラート、プロバイダーURL、製品名、検知元を使ってチケットを構成すると安定します。
MSSPで顧客テナントとサービスプロバイダーテナントを分ける
マルチテナント環境では、自動化ルールがあるテナントとプレイブックがあるテナントが異なる場合があります。Microsoft Sentinelの自動化ルールはクロスワークスペース、マルチテナント展開をサポートしますが、プレイブック実行権限はプレイブックが存在するテナント側で定義する必要があります。MSSP構成では、Azure Lighthouse委任やMicrosoft Sentinel Automation Contributorロールの扱いを事前に確認してください。(Microsoft Learn)
展開前のテスト手順
本番反映前には、最低限次の流れでテストしてください。
| 手順 | 確認内容 |
|---|---|
| ルールをエクスポート | 変更前の状態をバックアップする |
| テスト用ルールを低優先度で作成 | 既存ルールへの影響を避ける |
| テスト用インシデントを発生させる | 条件に一致するか確認する |
| アクション結果を確認 | ステータス、タグ、所有者、タスクが期待どおりか |
| プレイブック実行履歴を確認 | 失敗、遅延、権限エラーがないか |
| 外部チケットを確認 | URL、説明、重大度、更新内容が正しいか |
| 監査ログを確認 | 自動化ルールによる変更が追跡できるか |
| 順序番号を確定 | 同一順序番号がないか確認する |
自動化ルールの活動確認には、SecurityIncidentテーブルでModifiedByにAutomationを含むデータを確認する方法があります。Azure portalのLogsページ、またはDefenderポータルのAdvanced huntingで確認できます。(Microsoft Learn)
SecurityIncident
| where ModifiedBy contains "Automation"このクエリは、どのインシデントが自動化ルールによって変更されたかを確認する起点になります。運用開始直後は、意図しない自動クローズや担当者変更が発生していないか、毎日確認することをおすすめします。
これから取るべき行動
Microsoft Sentinel自動化ルールは、Microsoft Defender環境のSOC運用を効率化する強力な機能です。ただし、Defenderポータルへの移行、インシデント相関、APIの違い、プレイブック権限、条件評価の変化を理解せずに使うと、通知漏れや誤った自動クローズにつながります。
まず取り組むべきことは、既存の自動化ルールをエクスポートし、トリガー、条件、アクション、実行順序、プレイブック権限を一覧化することです。次に、インシデントタイトル、Description、インシデントプロバイダー、Updated byに依存しているルールを優先的に修正してください。
新規に設計する場合は、原則としてインシデント起点で作り、抑制ルールには有効期限を設定し、外部連携は作成時だけでなく更新時も考慮します。最後に、テストインシデントで動作を確認し、監査ログで自動化の結果を継続的に確認すれば、Microsoft Sentinel自動化ルールを安全に展開できます。
コメント