自動化ルールを使って Microsoft Sentinel の脅威への対応を自動化する

この記事では、Microsoft Sentinel 自動化ルールの概要と、それらを使用してセキュリティ オーケストレーション、自動化、および対応 (SOAR) の操作を実装する方法について説明します。 自動化ルールは SOC の効果を高め、時間とリソースを節約します。

自動化ルールとは

自動化ルールは、さまざまなシナリオに渡って適用できる小さなルール セットを定義して調整できるようにすることで、Microsoft Sentinel の自動化を一元的に管理する方法です。

自動化ルールは、次のカテゴリのユース ケースに適用されます。

• インシデント処理の基本的な自動化タスクをプレイブックを使わずに実行します。 次に例を示します。

  • アナリストがフォローするインシデント タスクを追加します。
  • ノイズの多いインシデントを抑制します。
  • 状態を [新規] から [アクティブ] に変更し、所有者を割り当てることで、新しいインシデントをトリアージします。
  • インシデントにタグ付けして分類します。
  • 新しい所有者を割り当ててインシデントをエスカレートします。
  • 理由を指定し、コメントを追加して、解決されたインシデントをクローズします。

• 一度に複数の分析ルールの応答を自動化します。

• 実行されるアクションの順序を制御します。

• インシデントの内容 (アラート、エンティティ、その他のプロパティ) を検査し、プレイブックを呼び出してさらなるアクションを実行します。

• 自動化ルールは、インシデントに関連付けられていないアラートに応答してプレイブックを実行するメカニズムにもなることができます。

つまり、自動化ルールを使用すると、Microsoft Sentinel での自動化の使用が効率化され、脅威対応オーケストレーション プロセスの複雑なワークフローを簡略化することができます。

コンポーネント

自動化ルールは、次のいくつかのコンポーネントで構成されています。

• 条件に応じてルールを実行するインシデント イベントの種類を定義するトリガー。
• ルールを実行してアクションを実行する正確な状況を決定する条件。
• 何らかの方法でインシデントを変更したり、プレイブックを呼び出したりするためのアクション。これは、より複雑なアクションを実行し、他のサービスと対話します。

トリガー

自動化ルールは、インシデントが作成または更新されたとき、またはアラートが作成されたときにトリガーされます。 インシデントにはアラートが含まれており、 Microsoft Sentinel の脅威検出で説明されているように、アラートとインシデントの両方を分析ルールで作成できることを思い出してください。

次の表は、オートメーション ルールが実行される、さまざまなシナリオを示しています。

インシデントベースまたはアラートベースの自動化

インシデントとアラートのどちらにも対応する自動化ルールを一元管理する場合、どのような状況で、どちらを自動化する必要があるか、どのように選択すべきでしょうか。

ほとんどのユース ケースでは、 インシデントによってトリガーされる自動化 が推奨されるアプローチです。 Microsoft Sentinel では、 インシデント は "ケース ファイル" であり、特定の調査に関連するすべての証拠の集計です。 これは、アラート、エンティティ、コメント、コラボレーション、その他の成果物のコンテナーです。 1 つの証拠である アラート とは異なり、インシデントは変更可能であり、最新の状態を持ち、コメント、タグ、ブックマークで強化できます。 インシデントを使用すると、新しいアラートを追加することで進化し続ける攻撃ストーリーを追跡できます。

これらの理由から、インシデントを中心に自動化を構築する方がより理にかなっています。 そのため、プレイブックを作成する最も適切な方法は、Azure Logic Apps の Microsoft Sentinel インシデント トリガーをベースにすることです。

アラートによってトリガーされる自動化を使用する主な理由は、インシデントを作成しない分析ルールによって生成されたアラート (つまり、分析ルール ウィザードの [インシデント設定] タブでインシデントの作成が無効になっている) に対応するためです。

この理由は、Microsoft Sentinel ワークスペースが Defender ポータルにオンボードされている場合に特に関連します。 このシナリオでは、すべてのインシデント作成が Defender ポータルで行われるため、Microsoft Sentinel のインシデント作成ルール を無効にする必要があります。

統合ポータルにオンボードしなくても、他の外部ロジックを使用してアラートからインシデントを作成するかどうかとその方法、およびアラートをグループ化する方法を決定する場合は、アラートでトリガーされる自動化の使用を決定できます。 次に例を示します。

• プレイブックでは、関連付けられたインシデントを持たないアラートによってトリガーされ、他のソースからの情報でアラートのエンリッチを行い、いくつかの外部ロジックに基づいてインシデントを作成するかどうかを決定することができます。

• プレイブックはアラートによってトリガーされ、インシデントを作成する代わりに、アラートを追加するための適切な既存のインシデントを探すことができます。 インシデントの拡張について詳しくは、こちらをご覧ください。

• プレイブックはアラートでトリガーされ、SOC の担当者にアラートを通知するため、チームはインシデントを作成するかどうかを決定できます。

• プレイブックはアラートによってトリガーされ、インシデントの作成と管理のために外部のチケット システムにアラートを送信し、システムで各アラートに対して新しいチケットが作成されます。

条件

複雑な条件のセットを定義して、アクション (以下を参照) を実行するタイミングを制御できます。 これらの条件には、ルールをトリガーするイベント (インシデントの作成または更新、または作成されたアラート)、インシデントのプロパティと エンティティ プロパティ の状態または値 (インシデント トリガーのみ)、インシデントまたはアラートを生成した分析ルールまたはルールが含まれます。

自動化ルールがトリガーされると、ルールで定義されている条件に照らしてトリガーのインシデントまたはアラートがチェックされます。 インシデントの場合、プロパティ ベースの条件は、評価が発生した時点のプロパティの 現在の状態 、またはプロパティの 状態の変化 に応じて評価されます (詳細については、以下を参照してください)。 1 つのインシデントの作成または更新イベントによって複数の自動化ルールがトリガーされる可能性があるため、実行 順序 (下記参照) によって、条件の評価結果の決定に違いがあります。 ルールで定義された アクション は、すべての条件が満たされている場合にのみ実行されます。

インシデント作成トリガー

トリガーを使用して定義されたルールの場合、 インシデントのプロパティの特定のリストの値の 現在の状態 をチェックする条件を定義するには、次の演算子の 1 つ以上を使用します。

• は、 条件で定義された値と 等しいか、等しくない 。
• 条件で定義された値を含むまたは含まない。
• 条件で定義された値で開始するまたは開始しない。
• 条件で定義された値で終了するまたは終了しない。

たとえば、 分析ルール名 を Contains == Cloud PC に対するブルート フォース攻撃として定義した場合、 Azure portal に対するブルート フォース攻撃 を含む分析ルールは条件を満たしていません。 ただし、 分析ルール名 を "== ユーザー資格情報を含まない" として定義した場合、 クラウド PC に対するブルート フォース攻撃 と Azure portal 分析ルールに対するブルート フォース 攻撃の両方が条件を満たします。

インシデント更新トリガー

トリガーを使用して定義されたルールで評価される条件 インシデントが更新されると、インシデント 作成トリガーに一覧表示されているすべての条件が含まれます。 ただし、更新トリガーには、評価できるプロパティがさらに含まれています。

これらのプロパティの 1 つが更新者です。 このプロパティを使用すると、インシデントで変更を加えたソースの種類を追跡できます。 Defender ポータルにワークスペースをオンボードしたかどうかに応じて、インシデントが次のいずれかの値によって更新されたかどうかを評価する条件を作成できます。

たとえば、この条件を使用すると、別の自動化ルールによって行われた場合を除き、インシデントに対して行われた変更に対して実行するようにこの自動化ルールに指示できます。

さらに、更新トリガーでは、インシデント プロパティの値と現在の 状態の状態の変化 をチェックする他の演算子も使用されます。 状態変更条件は、次の場合に満たされます。

インシデント プロパティの値が

• が変更されました (前または後の実際の値に関係なく)。
• は、条件で定義された値から変更されました。
• が条件で定義された値に変更されました。
• が追加されました (これは、値のリストを持つプロパティに適用されます)。

[タグ] プロパティ: 個々とコレクション

インシデント プロパティ Tag は個々のアイテムのコレクションであり、1 つのインシデントに複数のタグを適用できます。 コレクション内の各タグを個別にチェックする条件と、タグのコレクションを 1 つの単位としてチェックする条件を定義できます。

• 個々のタグ 演算子は、コレクション内のすべてのタグに対して条件をチェックします。 評価は、少なくとも 1 つのタグが条件を満たす場合に true になります。
• すべてのタグのコレクションの演算子は、タグのコレクションを1つの単位として条件をチェックします。 評価は、コレクション全体が条件を満たす場合にのみ true です。

この違いは、条件が否定形 (含まない) であり、コレクション内の一部のタグが条件を満たし、その他のタグが満たしていない場合に重要です。

条件の例を見てみましょう。 タグには "2024" が含まれていません。2 つのインシデントがあり、それぞれに 2 つのタグがあります。

この例では、インシデント 1 で次の 操作を行います。

• 条件が各タグを個別にチェックする場合、条件 ("2024" を含まない) を満たすタグが少なくとも 1 つあるため、全体的な条件は true になります。
• 条件がインシデント内のすべてのタグを 1 つの単位としてチェックする場合、 条件を満たさない タグが少なくとも 1 つ存在するため ("2024" が含まれます )、全体的な条件は false になります。

インシデント 2 では、定義されている条件の種類に関係なく、結果は同じです。

サポートされているエンティティのプロパティ

オートメーション ルールの条件としてサポートされるエンティティ プロパティの一覧については、 Microsoft Sentinel の自動化規則のリファレンスを参照してください。

アラート作成トリガー

現在、アラート作成トリガーに対して構成できる条件は、自動化ルールが実行される分析ルールのセットのみです。

アクション

条件 (上記参照) が満たされたときに実行するようにアクションを定義できます。 ルールには多くのアクションを定義できます。また、実行する順序を選択することもできます (下記参照)。 プレイブックの高度な機能を必要とせずに、自動化ルールを使用して次のアクションを定義できます。

• インシデントにタスクを追加する - アナリストがインシデントのトリアージ、調査、修復プロセス全体を通じて従うタスクのチェックリストを作成し、重要な手順を見逃さないようにすることができます。

• インシデントの状態の変更 – ワークフローを最新の状態に保ちます。

  • "closed" に変更する場合は、 終了理由 を指定し、コメントを追加します。 これにより、パフォーマンスと有効性を追跡し、誤検知を減らすための微調整を行うことができます。

• インシデントの重大度の変更 – インシデントに関連するエンティティの存在、非存在、値、または属性に基づいて、再評価や優先順位の変更を行うことができます。

• 所有者へのインシデントの割り当て – これにより、インシデントの種類を最も適した担当者に伝えたり、最も時間のある担当者に送信したりすることができます。

• インシデントへのタグの追加 – これは、インシデントをサブジェクト、攻撃者、またはその他の共通点別に分類する場合に便利です。

また、外部システムを含むより複雑な応答アクションを実行するために、プレイブックを実行するアクションを定義することができます。 自動化ルールで使用できるプレイブックは、プレイブックと自動化ルールの基になるトリガーによって異なります。インシデント トリガーの自動化ルールから実行できるのはインシデント トリガー プレイブックのみであり、アラート トリガーの自動化ルールから実行できるのはアラート トリガープレイブックのみです。 プレイブックを呼び出す複数のアクション、またはプレイブックと他のアクションの組み合わせを定義することができます。 アクションは、ルールに記載された順序で実行されます。

いずれかのバージョンの Azure Logic Apps (Standard または従量課金) を使用したプレイブックは、自動化ルールから実行できます。

有効期限

自動化ルールの有効期限を定義できます。 その日が過ぎると、ルールは無効になります。 これは、侵入テストなど、計画された時間限定のアクティビティによって発生する "ノイズ" インシデントの処理 (つまり、終了) に役立ちます。

注文

自動化ルールを実行する順序を定義できます。 その後の自動化規則は、前の自動化規則によって処理された後の状態に従って、インシデントの状態を評価します。

たとえば、"最初の自動化ルール" によってインシデントの重要度が "中" から "低" に変更され、"第 2 の自動化ルール" が "中" または "高" の重大度のインシデントでのみ実行されるように定義されている場合、そのインシデントでは実行されません。

インシデント タスクを追加する自動化ルールの順序によって、特定のインシデントにタスクが表示される順序が決まります。

更新トリガーに基づくルールには、独自の個別の順序キューがあります。 このようなルールは、(別の自動化ルールによって行われた変更によって) 作成されたばかりのインシデントで実行されるようにトリガーされた場合、作成トリガーに基づいて適用できるすべてのルールの実行完了後にのみ実行されます。

実行順序と優先度に関する注意事項

• 自動化ルールで 順序 番号を設定すると、実行順序が決まります。
• トリガー タイプごとに、独自のキューが保持されます。
• Azure portal で作成されたルールの場合、 注文 フィールドには、同じトリガーの種類の既存のルールで使用される最大数に続く数値が自動的に入力されます。
• ただし、他の方法 (コマンド ライン、API など) で作成されたルールの場合は、 注文 番号を手動で割り当てる必要があります。
• 同じトリガー タイプ内であっても、複数のルールが同じ順序番号を持つことを防ぐ検証メカニズムはありません。
• ルールがどの順序で実行されるかを気にしない場合は、同じトリガー タイプの 2 つ以上のルールに同じ順序番号を持たせることができます。
• 同じ順序番号を持つ同じトリガー タイプのルールに関しては、実行エンジンが、どのルールがどの順序で実行されるかをランダムに選択します。
• インシデント トリガー の種類が異なるルールの場合、 インシデント作成 トリガーの種類に該当するすべてのルールが最初に実行され (注文番号に従って)、次に インシデント更新 トリガーの種類 (順序番号 に従って) のルールのみが実行されます。
• ルールは常に順番に実行され、並列に実行されることはありません。

一般的なユース ケースとシナリオ

インシデント タスク

自動化ルールを使用すると、自動化ルールで設定した条件と基になる分析ルールの脅威検出ロジックに従って、1 つのインシデント、インシデントグループ、またはすべてのインシデントに適用できる タスクを作成 することで、インシデントのトリアージ、調査、修復に必要な手順を標準化および形式化できます。 インシデントに適用されたタスクはインシデントのページに表示されるため、アナリストには、実行する必要があるアクションの一覧全体が目の前に用意されるので、重要な手順を見逃すことがありません。

インシデントとアラートによってトリガーされる自動化

自動化ルールは、インシデントの作成または更新、およびアラートの作成によってトリガーできます。 これらの出現はすべて、プレイブックを含む自動応答チェーンをトリガーできます (特別なアクセス許可が必要です)。

Microsoft プロバイダーのプレイブックをトリガーする

自動化ルールは、アラートから作成されたインシデントにこれらのルールを適用することによって、Microsoft セキュリティ アラートの処理を自動化する方法を提供します。 自動化ルールでは、プレイブックを呼び出して (特別なアクセス許可が必要です)、アラートやエンティティなど、すべての詳細を含むインシデントをそれらに渡すことができます。 一般に、Microsoft Sentinel のベスト プラクティスでは、セキュリティ操作の中心としてインシデント キューを使用します。

Microsoft セキュリティ アラートには、次のものが含まれます。

• Microsoft Entra ID Protection（マイクロソフト エントラ ID 保護）
• Microsoft Defender for Cloud
• クラウドアプリ向けのMicrosoft Defender
• Microsoft Defender for Office 365
• Microsoft Defender for Endpoint（エンドポイント用マイクロソフトディフェンダー）
• Microsoft Defender for Identity
• Microsoft Defender for IoT

1 つのルールで順序付けられた複数のプレイブック/アクション

1 つの自動化ルールで、アクションとプレイブックの実行順序をほぼ完全に制御できるようになりました。 また、自動化ルールの実行順序も制御します。 これにより、プレイブックを大幅に簡素化し、1 つのタスクまたは小規模で簡単な一連のタスクに減らすことができます。また、これらの小さなプレイブックは、さまざまな自動化ルールで異なる組み合わせで組み合わせることができます。

一度に 1 つのプレイブックを複数の分析ルールに割り当てる

外部のチケット発行システムでサポート チケットを作成するなど、すべての分析ルールで自動化するタスクがある場合は、すべての分析ルール (将来のルールを含む) に 1 つのプレイブックを 1 回の操作で適用できます。 これにより、簡単であるものの反復的なメンテナンスとハウスキーピング タスクの手間が省けます。

インシデントの自動割り当て

適切な所有者にインシデントを自動的に割り当てることができます。 SOC に特定のプラットフォームを専門とするアナリストがいる場合、そのプラットフォームに関連するすべてのインシデントを自動的にそのアナリストに割り当てることができます。

インシデントの抑制

ルールを使用して、プレイブックを使用せずに、誤検知または害のないインシデントを自動的に解決できます。 たとえば、侵入テストを実行するとき、スケジュールされたメンテナンスやアップグレードを実行するとき、または自動化手順をテストするときに、SOC が無視する多くの誤検知インシデントを作成することができます。 時間限定の自動化ルールは、作成時にこれらのインシデントを自動的に閉じ、生成の原因の記述子でタグ付けします。

時間限定の自動化

自動化ルールに有効期限を追加できます。 時間限定の自動化を保証するインシデント抑制以外のケースもあります。 特定の期間の特定のユーザー (たとえば、インターンやコンサルタント) に特定の種類のインシデントを割り当てることができます。 時間枠が事前にわかっている場合は、適切なタイミングでルールを無効にすることができます。その場合、そのことを覚えておく必要はありません。

インシデントに自動的にタグを付ける

フリーテキスト タグをインシデントに自動的に追加して、選択した条件に従ってグループ化または分類することができます。

更新トリガーによって追加されたユース ケース

インシデントに加えられた変更によって自動化ルールをトリガーできるようになったので、自動化に対してより多くのシナリオが開かれています。

インシデントの進化時に自動化を拡張する

更新トリガーを使用すると、調査が進行し、アナリストがアラート、コメント、タグを追加するときに、上記のユース ケースの多くをインシデントに適用できます。 インシデントでのアラートのグループ化を制御します。

オーケストレーションと通知を更新する

インシデントに変更が加えられたときにさまざまなチームやその他の担当者に通知して、重要な更新が見逃されないようにします。 インシデントをエスカレートするには、それらを新しい所有者に割り当て、新しい所有者に割り当てを通知します。 インシデントを再び開くタイミングと方法を制御します。

外部システムとの同期を維持する

インシデントの作成時にプレイブックを使用して外部システムでチケットを作成した場合は、update-trigger 自動化ルールを使用して、それらのチケットを更新するプレイブックを呼び出すことができます。

自動化ルールの実行

自動化ルールは、決定した 順序 に従って順番に実行 されます。 各自動化ルールは、前の規則の実行が完了した後に実行されます。 自動化ルール内では、すべてのアクションが、定義されている順序で順番に実行されます。

自動化ルール内のプレイブック アクションは、次の基準に従って、ある状況下では異なって処理されることがあります。

プレイブックを実行するための自動化ルールへのアクセス許可

Microsoft Sentinel オートメーション ルールでプレイブックを実行すると、このアクションに対して特別に承認された特別な Microsoft Sentinel サービス アカウントが使用されます。 (ユーザー アカウントではなく) このアカウントを使用すると、サービスのセキュリティ レベルが向上します。

自動化ルールでプレイブックを実行するには、このアカウントに、プレイブックが存在するリソース グループに対する明示的なアクセス許可が付与されている必要があります。 その時点で、すべての自動化ルールでそのリソース グループ内のすべてのプレイブックを実行できるようになります。

自動化ルールを構成し、 プレイブックの実行 アクションを追加すると、プレイブックのドロップダウン リストが表示されます。 Microsoft Sentinel でアクセス許可を持たないプレイブックは、使用不可として ("淡色表示" で) 表示されます。 [プレイブックのアクセス許可の管理] リンクを選択すると、その場でプレイブックのリソース グループに Microsoft Sentinel のアクセス許可 を付与できます。 これらのアクセス許可を付与するには、それらのリソース グループに対する 所有者 アクセス許可が必要です。 完全なアクセス許可の要件を参照してください。

マルチテナント アーキテクチャにおけるアクセス許可

Automation ルールは、クロスワークスペースデプロイと マルチテナント デプロイ を完全にサポートします (マルチテナントの場合は、 Azure Lighthouse を使用)。

そのため、Microsoft Sentinel デプロイでマルチテナント アーキテクチャを使用している場合、1 つのテナント内のオートメーション ルールに別のテナント内に存在するプレイブックを実行させることができます。ただし、Sentinel がプレイブックを実行するためのアクセス許可は、オートメーション ルールが定義されているテナント内ではなく、プレイブックが存在するテナント内で定義する必要があります。

顧客テナント内でサービス プロバイダー テナントによって Microsoft Sentinel ワークスペースが管理される、マネージド セキュリティ サービス プロバイダー (MSSP) の特殊なケースでは、注意が必要なシナリオが 2 つあります。

• 顧客テナントで作成された自動化ルールは、サービス プロバイダー テナントにあるプレイブックを実行するように構成されます。

  このアプローチは、通常、プレイブック内の知的所有権を保護するために使用されます。 このシナリオは、特に何もしなくても機能します。 自動化ルールでプレイブック アクションを定義し、プレイブックが配置されている関連するリソース グループに対して Microsoft Sentinel のアクセス許可を付与する段階に進むと ([ プレイブックのアクセス許可の管理 ] パネルを使用して)、選択できるリソース グループのうち、サービス プロバイダー テナントに属するリソース グループを確認できます。 ここで概説されているプロセス全体を参照してください。

• 顧客ワークスペースで作成された自動化ルール (サービス プロバイダー テナントにサインインしている間) は、顧客テナントにあるプレイブックを実行するように構成されます。

  この構成は、知的所有権を保護する必要がない場合に使用されます。 このシナリオを機能させるには、プレイブックを実行するアクセス許可を 両方のテナントの Microsoft Sentinel に付与する必要があります。 顧客テナント内では、上記のシナリオと同様に、[プレイブックのアクセス許可の管理] パネル内でそれらを付与します。 サービス プロバイダー テナントで関連するアクセス許可を付与するには、プレイブックが存在するリソース グループに対して、Microsoft Sentinel Automation 共同作成者ロールを持つ Azure Security Insights アプリへのアクセス権を付与する Azure Lighthouse 委任を追加する必要があります。

  シナリオは次のようになります。

  

  これを設定する 手順 を参照してください。

自動化ルールの作成と管理

特定のニーズとユース ケースに応じて、Microsoft Sentinel または Defender ポータルのさまざまな領域から 自動化ルールを作成および管理 できます。

• 自動化ページ

  Automation ルールは、Automation ページの [ Automationルール ] タブで一元的に管理できます。そこから、新しい自動化ルールを作成し、既存のものを編集できます。 また、自動化ルールをドラッグして、実行の順序を変更し、それらを有効または無効にすることもできます。

  [Automation] ページには、ワークスペースで定義されているすべてのルールと、その状態 (有効/無効) と、それらが適用されている分析ルールが表示されます。

  Microsoft Defender XDR または Microsoft Sentinel の多くの分析ルールのインシデントに適用される自動化ルールが必要な場合は、 Automation ページで直接作成します。

• 分析ルール ウィザード

  Microsoft Sentinel 分析ルール ウィザードの [自動応答 ] タブの [Automation ルール] で、ウィザードで作成または編集する特定の分析ルールに適用される自動化ルールを表示、編集、および作成できます。

  ここから自動化ルールを作成すると、[ 新しい自動化ルールの作成 ] パネルに 分析ルール の条件が使用不可として表示されます。このルールは、ウィザードで編集している分析ルールにのみ適用されるように既に設定されているためです。 その他のすべての構成オプションは、引き続き使用できます。

• [インシデント] ページ

  また、[ インシデント ] ページから自動化ルールを作成して、1 つの定期的なインシデントに対応することもできます。 これは、"ノイズの多い" インシデントを自動的に閉じるための抑制ルールを作成する場合に便利です。

  ここから自動化ルールを作成すると、[ 新しい自動化ルールの作成 ] パネルにすべてのフィールドにインシデントの値が設定されます。 このルールには、インシデントと同じ名前を付けて、インシデントを生成した分析ルールに適用し、インシデントで使用可能なすべてのエンティティをルールの条件として使用します。 また、既定では抑制 (終了) アクションが提案され、ルールの有効期限が提案されます。 必要に応じて、条件とアクションを追加または削除したり、有効期限を変更したりできます。

オートメーション ルールのエクスポートとインポートを行う

Microsoft Sentinel デプロイをコードとして管理および制御する一環として、自動化ルールを Azure Resource Manager (ARM) テンプレート ファイルからエクスポートし、それらのルールを同様のファイルにインポートします。 エクスポート操作により、ブラウザーのダウンロード場所に JSON ファイルが作成されます。このファイルは、ファイル名の変更や移動など、他のファイルと同様に処理することができます。

エクスポートされた JSON ファイルはワークスペースに依存しないので、他のワークスペースや他のテナントにもインポートできます。 コードとして、マネージド CI/CD フレームワークでバージョン管理、更新、デプロイすることもできます。

このファイルには、オートメーション ルールで定義されているすべてのパラメーターが含まれています。 任意の種類のトリガーのルールを JSON ファイルにエクスポートできます。

自動化ルールのエクスポートとインポートの手順については、「 Microsoft Sentinel 自動化ルールのエクスポートとインポート」を参照してください。

次のステップ

このドキュメントでは、Microsoft Sentinel のインシデントとアラートに対する応答の自動化を自動化ルールで一元管理する方法について説明しました。

• Microsoft Sentinel 自動化ルールを作成して使用してインシデントを管理します。
• 自動化ルールを使用して、アナリスト向けのタスクのリストを作成します。
• 高度な自動化オプションの詳細については、 Microsoft Sentinel のプレイブックを使用した脅威対応の自動化に関するページを参照してください。
• プレイブックの実装に関するヘルプについては、「 チュートリアル: プレイブックを使用して Microsoft Sentinel で脅威への対応を自動化する」を参照してください。