Threat detection in Microsoft Sentinel でまず押さえるべき結論は、新しい検知ルールは Microsoft Defender XDR の Custom detections を第一候補にし、既存の Microsoft Sentinel analytics rules は棚卸しして Defender ポータル移行に備えることです。Microsoft は、Microsoft Sentinel SIEM と Microsoft Defender XDR をまたぐ新規ルール作成では Custom detections を推奨する流れを明確にしています。一方で、既存の Analytics rules が直ちに使えなくなるという話ではありません。Microsoft Sentinel の運用画面が Azure portal から Defender portal へ集約されること、インシデント生成・相関・自動化・API 連携の前提が変わることを理解しておく必要があります。(Microsoft Learn)
特に重要なのは、2027年3月31日以降、Microsoft Sentinel は Azure portal でサポートされず、Microsoft Defender portal のみで利用する形になる点です。グローバルで Sentinel を運用している組織は、検知ルールだけでなく、データコネクタ、SOC の調査手順、Automation rules、Playbooks、外部チケット連携、権限設計まで含めて移行計画を作る必要があります。(Microsoft Learn)
Threat detection in Microsoft Sentinelで何が変わったのか
Threat detection in Microsoft Sentinel は、Microsoft Sentinel に集約されたログやイベントを分析し、疑わしい活動を検出してアラートやインシデントにつなげる仕組みです。従来は Microsoft Sentinel の Analytics rules を中心に、Scheduled rules、NRT rules、Anomaly rules、Fusion、Threat intelligence などを組み合わせて検知を作るのが基本でした。現在もこの考え方は有効ですが、新規の検知ルール作成では Custom detections を優先的に検討するという判断軸が加わっています。(Microsoft Learn)
実務上の変更点は、次のように整理できます。
| 確認項目 | これまでの考え方 | 今後の実務上の判断 |
|---|---|---|
| 新規検知ルール | Sentinel の Analytics rules で作成することが多い | Defender portal の Custom detections を第一候補にする |
| 既存ルール | Sentinel の Analytics 画面で管理 | Defender portal 上で継続管理しつつ、必要なものから見直す |
| Defender XDR データとの連携 | Sentinel 側へデータを取り込んで分析する設計が多い | Custom detections で Defender XDR と Sentinel データを横断する設計を検討 |
| インシデント相関 | Sentinel 側のルール設定や Fusion を意識 | Defender XDR の相関エンジンによる統合インシデントを前提にする |
| 管理ポータル | Azure portal 中心 | 2027年3月31日以降は Defender portal が前提 |
重要なのは、「Analytics rules から Custom detections へ全件を即時移行する」という単純な話ではない点です。既存ルールには、インシデントを作成しないアラート運用、細かいアラートグルーピング、Automation rules、Content hub のテンプレート、ARM テンプレートや API による管理など、組織固有の運用が組み込まれていることがあります。まずは既存ルールの棚卸しを行い、新規作成ルール、改修予定ルール、現状維持するルールに分けるのが安全です。
Microsoft Sentinelの脅威検出ルールの全体像
Threat detection in Microsoft Sentinel を理解するには、どの種類のルールが何を担当しているのかを把握しておく必要があります。Microsoft Sentinel では、Analytics ページで有効なルール、テンプレート、Anomaly rules を確認できます。追加のテンプレートは Content hub のソリューションから導入できます。(Microsoft Learn)
| ルール種別 | 主な用途 | 管理者が見るべきポイント |
|---|---|---|
| Scheduled rules | KQL クエリを定期実行し、しきい値を超えた結果からアラートを生成 | 最も一般的。既存の独自検知やテンプレート利用が多い |
| Near-real-time rules | 1分ごとに近い頻度で検知 | 低遅延が必要な検知向け。ただし制約を確認する |
| Anomaly rules | 機械学習で通常時のベースラインを作り、逸脱を検出 | それ自体でアラートを作るのではなく、Anomalies テーブルに記録される |
| Microsoft security rules | 他の Microsoft セキュリティ製品のアラートから Sentinel インシデントを作成 | Defender XDR 統合や Defender portal オンボード時は利用不可になり、Defender XDR がインシデントを作成する |
| Threat intelligence | Microsoft Threat Intelligence のドメイン、IP、URL などの指標とログを照合 | CEF、Syslog、Windows DNS などのデータ活用時に重要 |
| Fusion | 複数の低信頼度アラートやイベントを相関し、高信頼度インシデントを作成 | Defender portal では Defender XDR の相関エンジンが役割を担う |
| ML behavior analytics | SSH、RDP ログオンなどの異常行動を検出 | Preview 扱いの機能が含まれるため、本番運用では状態確認が必要 |
特に Microsoft security rules と Fusion は、Defender XDR 統合時に挙動が変わりやすい領域です。Microsoft Sentinel が Defender portal にオンボードされている場合、Microsoft security rules は利用できず、既存の該当ルールは自動的に無効化されます。また、Fusion についても Defender portal では Microsoft Defender XDR のインシデント作成・相関機能が代替します。(Microsoft Learn)
Custom detectionsとAnalytics rulesの使い分け
Custom detections は、Advanced hunting のクエリをもとに定期的または継続的に検知を行い、アラート生成や対応アクションにつなげる機能です。Microsoft は、Sentinel と Defender XDR を横断する新規検知ルールの作成では Custom detections を推奨しています。理由は、Defender XDR データとの統合、リアルタイム検知、Defender 側の修復アクション、エンティティマッピング、取り込みコスト削減にあります。(Microsoft Learn)
一方で、Analytics rules にも引き続き強みがあります。公式比較では、Analytics rules は MITRE ATT&CK の詳細な表現、アラート抑制、アラートだけを作成してインシデントを作成しない運用、Content hub からのルール作成、Bicep やリポジトリ連携など、一部の管理・運用機能で Custom detections より先行している領域があります。Custom detections 側は多くの機能が対応済みまたは対応予定ですが、すべてが完全に同一ではありません。(Microsoft Learn)
| 判断軸 | Custom detectionsを選びやすいケース | Analytics rulesを残しやすいケース |
|---|---|---|
| 新規検知 | Defender XDR と Sentinel データを横断したい | Sentinel の既存テンプレートをそのまま使いたい |
| コスト | Defender XDR データを追加で Sentinel に取り込まずに検知したい | すでに Sentinel 側に必要データを集約している |
| リアルタイム性 | Continuous NRT を使いたい | 既存の Scheduled / NRT rules で十分 |
| 自動対応 | Defender XDR の修復アクションを活用したい | Sentinel Automation rules や Playbooks を中心にしている |
| 既存運用 | 新しい標準ルールとして設計したい | 既存の SOC 手順、チケット連携、抑制条件と強く結び付いている |
| IaC 管理 | API 管理を中心にする | ARM、Bicep、リポジトリ連携など既存資産を重視する |
実務では、まず新規ルールを Custom detections で作る方針に切り替えます。そのうえで、既存の Analytics rules は「移行すべきもの」と「残すべきもの」に分けます。たとえば、Defender for Endpoint のデバイスイベントと Sentinel に取り込んだプロキシログを突き合わせるような検知は Custom detections の候補です。反対に、Content hub のテンプレートを微調整して使っている Sentinel 専用ルールや、既存の Automation rules に強く依存するルールは、急いで移行せず Defender portal 上で動作確認する方が現実的です。
設定変更で影響が出やすいポイント
ポータルの場所が変わる
Microsoft Sentinel は Defender portal で一般提供されており、Microsoft Defender XDR や E5 ライセンスがない顧客でも利用できます。ただし、Defender サービスなしで Sentinel のみを使う場合、Exposure Management、Custom detection rules、Action center など一部の Defender 由来機能は制限または利用不可になる可能性があります。(Microsoft Learn)
Defender portal では、従来 Azure portal の「Analytics」に相当する管理は、主に次の場所で確認します。
| Azure portalでの場所 | Defender portalでの場所 |
|---|---|
| Logs | Investigation & response > Hunting > Advanced hunting |
| Incidents | Investigation & response > Incidents & alerts > Incidents |
| Threat intelligence | Threat intelligence > Intel management |
| Content hub | Microsoft Sentinel > Content management > Content hub |
| Data connectors | Microsoft Sentinel > Configuration > Data connectors |
| Analytics | Microsoft Sentinel > Configuration > Analytics、または Investigation & response > Hunting > Custom detection rules |
| Automation | Microsoft Sentinel > Configuration > Automation |
SOC の手順書や教育資料に Azure portal の画面パスが残っている場合、移行後に初動対応が遅れる原因になります。グローバル SOC では、リージョン別・拠点別の手順書を統一し、Defender portal のナビゲーションを前提に更新しておくことが重要です。(Microsoft Learn)
データコネクタとワークスペース構成の見直し
Microsoft Sentinel を Defender portal に統合しても、Log Analytics へのデータ保存や検索の基本構造がすべて変わるわけではありません。ただし、Microsoft セキュリティ製品のアラート取り込みは、個別の Microsoft セキュリティ製品コネクタではなく Microsoft Defender XDR connector 経由に変わる点があります。マルチワークスペース構成では、Defender XDR connector はプライマリワークスペースに接続され、重複アラートを避けるために一部のスタンドアロンコネクタがセカンダリワークスペースで自動切断される場合があります。(Microsoft Learn)
このため、グローバル企業では次の確認が必要です。
| 確認項目 | 確認する理由 |
|---|---|
| プライマリワークスペース | Defender XDR アラートがどのワークスペースに集約されるかを明確にする |
| セカンダリワークスペース | 個別コネクタの自動切断で監視ギャップが出ないか確認する |
| 地域別データ保持 | 国・地域ごとのデータ保存要件や調査権限に影響する |
| 重複アラート | 旧コネクタと新コネクタの併存で同じアラートが二重化しないか確認する |
| 外部SIEM連携 | Sentinel から転送しているアラート形式や項目が変わらないか確認する |
特に注意したいのは、移行後に「アラートが消えた」のではなく、表示場所やインシデントへの相関方法が変わっているだけのケースです。運用テストでは、既知のテストアラートを発生させ、どのテーブル、どのインシデントキュー、どの外部連携先に届くかを追跡してください。
インシデント相関とFusionの考え方が変わる
Defender portal では、Microsoft Defender XDR の相関エンジンが複数の検知ソースを横断してインシデントを統合します。そのため、Azure portal 時代に Analytics rules で設定していたアラートグルーピングがそのまま見た目に反映されるとは限りません。複数の Analytics rules が「それぞれ別インシデントを作る」ように設定されていても、Defender XDR の相関ロジックにより、攻撃ストーリーとして1つのインシデントに統合される可能性があります。(Microsoft Learn)
これは悪い変更ではありません。むしろ、端末、ID、メール、クラウド、サードパーティログを横断して攻撃全体を見やすくするための変更です。ただし、既存の SOC 運用が「インシデント1件＝単一ルールの検知結果」という前提で設計されている場合、担当チームの振り分け、SLA、重大度判定、チケット発行条件を見直す必要があります。
Automation rulesとPlaybooksの条件を見直す
Defender portal へのオンボード後は、Automation rules と Playbooks にも影響があります。たとえば、すべてのインシデントの provider が Microsoft XDR として扱われるため、従来の Microsoft Sentinel や Microsoft 365 Defender を前提にした条件分岐は期待どおり動かない可能性があります。また、SecurityIncident テーブルの Description フィールドが移行後に含まれないため、この項目を条件にしている自動化は修正が必要です。(Microsoft Learn)
外部チケットシステムと連携している場合は、特に次の条件を確認してください。
| 見直す条件 | 失敗しやすい理由 |
|---|---|
| Incident provider | 移行後は Microsoft XDR 前提になり、従来の条件分岐が崩れる |
| Incident title | Defender の相関によりインシデント名が変わる場合がある |
| Description | 移行後の SecurityIncident テーブルで使えない場合がある |
| Analytics rule name | 特定の Sentinel ルール由来のインシデントに絞る条件として有効 |
| Tags | 自動化対象を安定して識別する補助条件として使いやすい |
| 実行タイミング | インシデント同期や自動化実行に遅延が出る場合がある |
実務では、インシデントタイトルではなく、Analytics rule name やタグを条件にする方が安定します。タイトルは人間には分かりやすい一方、相関や統合により変更される可能性があるため、自動化のキーには向きません。
API連携はMicrosoft GraphとSentinel APIを使い分ける
Defender portal の統合体験では、インシデントやアラートの自動化には Microsoft Graph Security API の利用が推奨されます。一方で、Analytics rules や Automation rules など Microsoft Sentinel リソースそのものを扱う操作では、Microsoft Sentinel API が引き続き使われます。(Microsoft Learn)
外部チケットシステム、SOAR、独自ダッシュボードを持っている場合は、API レスポンスの項目名も確認してください。たとえば、Defender portal 側では providerName が Microsoft XDR になり、serviceSource、detectionSource、productName など、Azure portal 時代には存在しなかった情報が含まれる場合があります。既存の JSON パース処理が固定フィールド前提だと、移行後にチケット作成や重大度判定が失敗する可能性があります。(Microsoft Learn)
Custom detections作成時の実務ポイント
Custom detections は強力ですが、作成時にはいくつかの実務上の制約を確認する必要があります。まず、ルールを管理するには、対象データに応じた Defender 側および Sentinel 側の権限が必要です。Microsoft Sentinel データを対象にする場合は、Microsoft Sentinel Contributor 以上のロールが必要になります。Defender データと Sentinel データを横断する検知では、両方の権限がそろっていないと運用が分断されます。(Microsoft Learn)
Custom detections のクエリでは、結果に Timestamp または TimeGenerated を含めることが推奨されています。Defender for Endpoint のテーブルでは、DeviceId や DeviceName を含めることで、デバイススコープやプロセスツリー表示が正しく機能しやすくなります。また、ルール1回の実行で生成できるアラート数には上限があるため、通常業務の大量イベントに反応する粗い条件のまま本番化すると、重要な検知が埋もれる可能性があります。(Microsoft Learn)
Custom detections の頻度は、24時間、12時間、3時間、1時間、Continuous NRT、Custom などから選べます。Continuous NRT は低遅延の検知に有効ですが、クエリが単一テーブルを参照すること、join や union などを使わないことなどの条件があります。複数データソースを結合する高度な検知では、Continuous NRT にこだわらず、実行頻度とルックバック期間のバランスを設計してください。(Microsoft Learn)
また、Microsoft Sentinel のスコープ設定を使っている場合、SentinelScope_CF をクエリで返す必要があります。この列を返さないと、スコープ付きアナリストからアラートが見えなくなる可能性があります。MSSP や地域別 SOC で担当範囲を分けている組織では、移行テスト時の重要チェック項目です。(Microsoft Learn)
移行期限とスケジュールの考え方
Microsoft Sentinel の Azure portal サポート終了日は、2027年3月31日です。この日以降、Microsoft Sentinel は Microsoft Defender portal のみで利用する形になります。既存ワークスペースを Defender portal へ移行すること自体に追加費用は発生せず、Sentinel の利用量に基づく課金は通常どおり継続されます。(Microsoft Learn)
ただし、期限まで余裕があるように見えても、グローバル運用では早めに着手すべきです。理由は、ポータル切り替えだけでなく、SOC 手順、権限、API、チケット連携、監査証跡、データ保持、プレイブック、検知ルールの所有者確認まで関係するためです。
| 時期の目安 | 実施内容 |
|---|---|
| すぐに実施 | Analytics rules、Automation rules、Playbooks、外部連携、利用ポータルの棚卸し |
| 2026年内 | Defender portal で代表的なインシデント対応をパイロット運用 |
| 2026年末まで | 新規検知ルールの作成方針を Custom detections 優先へ切り替え |
| 2027年第1四半期 | 本番 SOC の手順書、監査資料、API 連携、権限設計を Defender portal 前提に統一 |
| 2027年3月31日前 | Azure portal 依存の運用を停止し、例外運用を解消 |
グローバル企業では、Microsoft の期限日をそのまま社内期限にしない方が安全です。時差、変更凍結期間、監査対応、地域ごとの承認プロセスを考慮し、社内の実質的な移行完了日は数週間から数か月前に設定するのが現実的です。
管理者が確認すべきチェックリスト
移行や設定変更を始める前に、次の項目を確認してください。
| 確認項目 | 具体的に見るもの | 判断基準 |
|---|---|---|
| 既存のAnalytics rules | ルール名、KQL、重大度、MITRE、データソース、所有者 | 廃止、継続、Custom detections化の候補に分類 |
| 新規ルール作成方針 | SOC 標準、開発ルール、レビュー手順 | Custom detections を第一候補にするか明文化 |
| Defender XDR連携 | Defender XDR connector、プライマリワークスペース | Microsoft 製品アラートの重複や欠落がないか確認 |
| インシデント相関 | Fusion、Microsoft security rules、アラートグルーピング | Defender XDR 相関後のインシデント単位で運用できるか確認 |
| Automation rules | provider、title、description、rule name、tag 条件 | 変更に弱い条件を減らす |
| Playbooks | Logic Apps、外部チケット、Teams/メール通知 | 同期遅延や項目変更に耐えられるか確認 |
| API連携 | Microsoft Graph、Sentinel API、SecurityInsights API | インシデント・アラート系とリソース管理系を分離 |
| RBAC | Azure RBAC、Defender RBAC、Sentinel Contributor | 管理者、アナリスト、MSSP の権限差を再確認 |
| マルチテナント | Azure Lighthouse、MTO、GDAP、ワークスペース分割 | どのテナント・ワークスペースで検知と調査を行うか明確化 |
| データ保護 | データ保存場所、CMK、地域要件 | Defender portal 利用時のポリシー差分を確認 |
特に、クロスサブスクリプションまたはクロステナントで Sentinel を運用している場合、ルール作成者の資格情報に依存するケースがあります。作成者が対象ワークスペースへのアクセスを失うと、ルールが動作しなくなる可能性があります。MSSP やグローバル SOC では、個人アカウントに依存した検知ルールを減らし、所有者、権限、レビュー手順を明確にしてください。(Microsoft Learn)
よくある失敗と回避策
Custom detectionsを完全な置き換えだと思い込む
Custom detections は新規ルール作成の有力な標準ですが、Analytics rules と完全に同じ機能セットではありません。特に、アラート抑制、アラートのみ作成してインシデントを作らない運用、Content hub からのルール作成、リポジトリ連携、Bicep 対応などは、公式比較上も差分や今後対応予定の領域があります。(Microsoft Learn)
回避策は、既存の Analytics rules を一括移行しないことです。まずは「Defender XDR データと Sentinel データを組み合わせる新規検知」「取り込みコスト削減効果が大きい検知」「リアルタイム性が必要な検知」から Custom detections 化を検討します。
アラートだけ作るルールがDefender portalで見えない
Microsoft Sentinel の Analytics rules でインシデント作成を無効にし、アラートだけを作る設定にしている場合、Defender portal ではそれらのアラートが表示されない点に注意が必要です。(Microsoft Learn)
回避策は、アラートのみ運用しているルールを洗い出し、インシデント化するか、別の監視・通知経路を残すかを事前に決めることです。検知精度が低く、インシデント化するとノイズになるルールは、クエリ改善や抑制条件の見直しも同時に行うべきです。
インシデント名やprovider名に依存した自動化を残す
Defender portal では相関エンジンによりインシデント名が変わる場合があります。また、providerName は Microsoft XDR 前提になります。これらに依存した Automation rules や外部連携は、移行後に期待どおり動かない可能性があります。(Microsoft Learn)
回避策は、安定した条件を使うことです。Analytics rule name、タグ、重大度、エンティティ、製品名、検知ソースなど、移行後も意味が保たれる項目を条件にします。インシデントタイトルは人間の判読用と割り切り、自動化の主キーにしない方が安全です。
低遅延検知にこだわりすぎてクエリが複雑になる
Continuous NRT は魅力的ですが、利用できるクエリには制約があります。複数テーブルの join や union を使うような高度な相関検知では、Continuous NRT にできない場合があります。(Microsoft Learn)
回避策は、検知の目的を分けることです。初動対応が必要な単一イベント検知は Continuous NRT に寄せ、複数ログを突き合わせる調査寄りの検知は Scheduled または Custom frequency で設計します。すべてをリアルタイム化するより、重要度に応じて頻度を分けた方が運用負荷を抑えられます。
データ保護とCMKの差分を後回しにする
Defender portal への移行では、データストレージ、処理、保持、共有のポリシー確認が必要です。また、CMK を有効にしている場合、Log Analytics ワークスペース内のログや Sentinel コンテンツは暗号化が継続される一方、オンボード後のアラートやインシデントは CMK 暗号化の対象外になる点が示されています。(Microsoft Learn)
グローバル組織では、これは単なる技術設定ではなく、監査・法務・データ所在地要件に関わる論点です。移行プロジェクトには、SOC 管理者だけでなく、クラウド基盤、セキュリティガバナンス、法務・監査担当を含めるべきです。
次に取るべき行動
Threat detection in Microsoft Sentinel の更新ポイントは、単に「新しい検知機能が増えた」という話ではありません。Microsoft Sentinel の検知ルール作成、Defender XDR との統合、インシデント相関、ポータル移行、SOAR、API、権限設計が同時に変わる運用上の転換点です。
まず行うべきことは、既存の Analytics rules と自動化の棚卸しです。次に、新規の検知ルール作成では Custom detections を標準候補にし、Defender XDR データと Sentinel データをどう横断するかを設計します。そのうえで、2027年3月31日の Azure portal サポート終了に向けて、Defender portal でのインシデント対応、権限、データコネクタ、外部連携を段階的に検証してください。
移行で最も避けたいのは、「画面が変わっただけ」と考えて自動化や相関ルールの差分を見落とすことです。検知ルール、インシデント、Playbooks、API、チケット連携を1本の運用フローとして確認すれば、Microsoft Sentinel と Defender XDR の統合メリットを活かしながら、移行時の監視ギャップを最小化できます。
コメント