Microsoft DefenderでMicrosoft Sentinelを使う運用は、単なる画面移動ではありません。結論から言うと、既存のMicrosoft SentinelワークスペースをMicrosoft Defenderポータルに接続することで、インシデント管理、高度なハンティング、Microsoft Defender XDRとの相関分析を同じ場所で扱えるようになります。一方で、プライマリワークスペース、Azure RBAC、Defender XDRコネクタ、Microsoft PurviewやDefender for Cloud連携の設定を確認せずに進めると、SOC運用やクエリ、インシデント対応に影響が出る可能性があります。
特に重要なのは、Microsoft SentinelがMicrosoft Defenderポータルで一般提供されており、Microsoft Defender XDRやE5ライセンスがない環境でも利用できる点です。また、2027年3月31日以降、Microsoft SentinelはAzure portalではサポートされず、Microsoft Defenderポータルでのみ利用する流れになります。既存環境の管理者は、今すぐ「接続できるか」ではなく、「接続後に誰が何を操作できるか」「どのワークスペースをプライマリにするか」「既存の自動化やクエリがどう変わるか」を確認しておくべきです。(Microsoft Learn)
Microsoft DefenderポータルへのMicrosoft Sentinel接続で何が変わるのか
今回の要点は、Microsoft SentinelをMicrosoft Defenderポータルに接続し、SIEMとXDRの運用を統合しやすくすることです。Microsoftの公式情報では、Microsoft SentinelをDefenderポータルで利用すると、インシデント管理や高度なハンティングなどを統合でき、ツールの切り替えを減らせると説明されています。(Microsoft Learn)
これまでAzure portalを中心にMicrosoft Sentinelを運用していた組織では、分析ルール、データコネクタ、ワークブック、ハンティング、インシデント対応をAzure側で確認する流れが一般的でした。Defenderポータルへ接続すると、調査担当者の主な作業場所がMicrosoft Defender側へ寄ります。
ただし、すべてが同じ場所に移るだけではありません。Microsoft Defender XDRを有効にしている場合、ホーム、インシデント、高度なハンティングなどのページで、Microsoft SentinelのプライマリワークスペースとDefender XDRのデータが統合されます。Defender XDRを有効にしていない場合は、Microsoft Sentinel由来のデータだけが表示されます。(Microsoft Learn)
| 変更点 | 実務上の意味 | 管理者が確認すべきこと |
|---|---|---|
| Microsoft SentinelをDefenderポータルで利用可能 | SOC担当者の作業画面がDefender中心になる | 既存の運用手順書、教育資料、ブックマークを更新する |
| インシデントやハンティングを統合 | SIEMとXDRの調査をまたいで実施しやすくなる | 既存のKQL、保存済みクエリ、検知ルールの動作を確認する |
| プライマリワークスペースの概念が重要になる | Defender XDRとの相関対象が明確に分かれる | どのワークスペースをプライマリにするか決める |
| Azure RBACが引き続き影響 | 接続後も権限管理はAzure RBACを無視できない | Sentinel Reader、Contributor、Ownerなどの割り当てを棚卸しする |
| オフボード時にDefender XDRコネクタへ影響 | 切断操作がデータ連携に影響する可能性がある | 検証環境で切断手順と影響範囲を確認する |
影響範囲は「管理画面」だけでなくSOC運用全体に及ぶ
Microsoft Defenderポータルへの接続は、画面の見た目やメニュー構成の変更にとどまりません。影響を受けるのは、インシデント対応、権限管理、データ検索、コネクタ設定、自動化、ワークスペース設計です。
インシデント対応への影響
Microsoft Defenderポータルに接続すると、Microsoft Sentinelは左側のナビゲーションに表示されます。Defender XDRが有効な環境では、インシデントや高度なハンティングなどでSentinelとDefender XDRのデータをまとめて扱えます。(Microsoft Learn)
SOC担当者にとっては、メール、ID、エンドポイント、クラウド、SIEMログを横断して調査しやすくなるのがメリットです。たとえば、Microsoft Defender for Endpointで検出された端末アラートと、Microsoft Sentinelに取り込んだファイアウォールログやAzure Activityログを、同じ調査導線で確認しやすくなります。
一方で、既存の運用ルールがAzure portal前提の場合、次のような混乱が起きやすくなります。
| 起きやすい問題 | 原因 | 対策 |
|---|---|---|
| 担当者が旧ポータルのメニューを探してしまう | 手順書がAzure portal前提のまま | 画面遷移をDefenderポータル基準に書き換える |
| インシデントの確認場所が部署で分かれる | 一部メンバーだけ新ポータルを使う | 移行期間中の一次確認場所を明文化する |
| 調査結果の共有がばらつく | Defender側とAzure側で見ている情報が異なる | 主要な調査フローを1つに統一する |
| 既存のKQLが期待通りに使えない | テーブルや保持期間、データソースの違い | 代表クエリを事前にテストする |
高度なハンティングへの影響
Microsoft Defenderの高度なハンティングでは、Microsoft Sentinelワークスペースを接続することで、Microsoft Defender XDRとMicrosoft Sentinelのデータを横断して調査できます。公式情報では、単一ポータルから異なるデータセットへクエリできることで、コンテキスト切り替えを減らせると説明されています。(Microsoft Learn)
ただし、注意点があります。Microsoft Sentinelデータを含むクエリを実行するには、少なくともMicrosoft Sentinel Readerロールが必要です。また、Defender XDRデータをMicrosoft Sentinel側でもクエリできるようにするには、単に統合ポータルを使うだけでは不十分で、Defender XDRの生データ取り込み設定が別途必要です。(Microsoft Learn)
開発者や検知エンジニアは、次の観点で検証してください。
| 確認項目 | 確認する理由 |
|---|---|
| 既存のKQLクエリがAdvanced huntingで実行できるか | Microsoft Sentinelでは動いていたクエリでも、ポータル側の制約に影響される場合がある |
SecurityAlertを使うクエリの扱い | スキーマ上はAlertInfoやAlertEvidence中心になるが、既存クエリ互換の考慮がある |
| 時刻フィルターの指定方法 | クエリ内で時間条件を固定すると、想定より不完全な結果になる可能性がある |
| カスタム検知の対応範囲 | Sentinelデータを含む検知では、近リアルタイム検知やカスタム関数に制限がある |
| GCC-Mなど特殊クラウド環境 | SentinelとDefender XDRテーブルを同時参照するクエリに制限がある |
接続前に確認すべき前提条件
Microsoft SentinelをMicrosoft Defenderポータルへ接続する前に、まずワークスペース、権限、ライセンス、テナント構成を確認します。公式ドキュメントでは、Microsoft Sentinelが有効なLog Analyticsワークスペースと、オンボードやサポート要求に必要な適切なロールを持つAzureアカウントが必要とされています。(Microsoft Learn)
ワークスペース構成を確認する
Defenderポータルでは、1つのMicrosoft Entraテナントに対して、1つのプライマリワークスペースと複数のセカンダリワークスペースへの接続がサポートされています。Microsoft Sentinelをオンボードする時点でワークスペースが1つだけの場合、そのワークスペースがプライマリとして扱われます。(Microsoft Learn)
複数ワークスペースを使っている組織では、ここが最も重要です。プライマリワークスペースは、Defender XDRとの統合やインシデント相関の中心になります。なんとなく最初に作ったワークスペースをプライマリにするのではなく、次の基準で判断してください。
| 判断基準 | 推奨される考え方 |
|---|---|
| SOCの主な監視対象 | 全社SOCが見る中心ワークスペースを優先する |
| データ量とコスト | 大量データを扱う場合、保持期間と課金影響を確認する |
| Defender XDRとの相関 | エンドポイント、ID、メールの調査と組み合わせたいデータを含むワークスペースを選ぶ |
| 法規制・データ主権 | 地域別、子会社別に分けている場合は安易に統合しない |
| 権限分離 | 部門別SOCやMSSP運用では、アクセス範囲が過剰にならないよう確認する |
必要なロールを確認する
Microsoft DefenderポータルにMicrosoft Sentinelを接続するには、操作内容ごとに必要なロールが異なります。公式情報では、オンボードにはOwner、またはUser Access AdministratorとMicrosoft Sentinel Contributorの組み合わせなどが示されています。閲覧やクエリ実行にはMicrosoft Sentinel Reader、調査アクションにはMicrosoft Sentinel Contributor相当の権限が必要です。(Microsoft Learn)
| 作業 | 必要な権限の目安 | 注意点 |
|---|---|---|
| Microsoft SentinelをDefenderポータルへ接続 | Owner、またはUser Access AdministratorとMicrosoft Sentinel Contributor | 複数ワークスペース環境ではMicrosoft Entra ID側のSecurity Administrator以上も確認 |
| Sentinelデータの閲覧 | Microsoft Sentinel Reader | 閲覧だけの担当者にContributorを付けない |
| インシデントへの調査アクション | Microsoft Sentinel Contributor相当 | コメント、タスク、関連付け変更などの操作権限を確認 |
| プライマリワークスペース変更 | Security Administrator以上とAzure側の必要権限 | 変更時にDefender XDRコネクタの接続先が変わる |
| サポート要求作成 | Owner、Contributor、Support request contributorなど | 運用担当者が問い合わせできる体制にする |
権限設計では「とりあえずOwnerを付ける」は避けるべきです。Microsoftも、可能な限り少ない権限のロールを使うことを推奨しています。(Microsoft Learn)
Microsoft Defender XDRとの統合条件を確認する
Microsoft Defender XDRとMicrosoft Sentinelのセキュリティ運用を統合するには、Defender XDRのライセンス、同じMicrosoft Entraテナントに属するアカウント、Defenderポータルへのアクセス権が必要です。(Microsoft Learn)
ここで誤解しやすいのは、Microsoft SentinelをDefenderポータルで使えることと、Defender XDRとの完全な統合運用ができることは同じではない点です。Microsoft Sentinel単体でもDefenderポータルで利用できますが、Defender XDRの信号を含めた相関、アクションセンター、Defender XDR由来のカスタム検知などは、環境やライセンス、サービス有効化状況に依存します。
オンボード手順と管理者向けチェックポイント
Microsoft Sentinel対応ワークスペースをDefenderポータルへ接続する基本手順は、Defenderポータルにサインインし、System > Settings > Microsoft Sentinel > Connect a workspaceから対象ワークスペースを選択し、プライマリワークスペースを指定して接続する流れです。(Microsoft Learn)
基本手順
| 手順 | 操作 | チェックポイント |
|---|---|---|
| 1 | Microsoft Defenderポータルへサインイン | 作業者が必要なAzure RBACとEntraロールを持っているか確認 |
| 2 | System > Settings > Microsoft Sentinelへ移動 | 対象ワークスペースが表示されるか確認 |
| 3 | Connect a workspaceを選択 | 表示されない場合は権限不足やテナント違いを疑う |
| 4 | 接続するワークスペースを選択 | 本番・検証・部門別ワークスペースを取り違えない |
| 5 | プライマリワークスペースを選択 | Defender XDRとの相関対象を意識して選ぶ |
| 6 | 製品変更を確認して接続 | 影響範囲を運用チームに共有してから実行する |
| 7 | 接続後のホーム画面とメニューを確認 | Sentinelセクション、データコネクタ数、自動化ルールなどを確認 |
接続後は、DefenderポータルのホームページにMicrosoft Sentinel由来のメトリックを含む新しいセクションが表示されます。左側ナビゲーションにもMicrosoft Sentinelが表示されるため、SOC担当者には接続完了後の画面を共有しておくと混乱を減らせます。(Microsoft Learn)
接続後すぐに確認する項目
接続が完了しても、そこで作業を終えてはいけません。次の確認まで行って初めて、実運用に乗せられる状態になります。
| 確認項目 | 確認方法 | 問題がある場合の例 |
|---|---|---|
| Sentinelメニューが表示されるか | Defenderポータル左ナビゲーションを確認 | RBAC不足、テナント違い |
| インシデントが見えるか | Investigation & response配下を確認 | Reader権限不足、ワークスペース選択ミス |
| 高度なハンティングでSentinelテーブルが見えるか | Advanced huntingのSchemaを確認 | ワークスペース未接続、権限不足 |
| データコネクタが期待通りか | Microsoft Sentinel > Configuration > Data connectorsを確認 | 旧コネクタの残存、プライマリ設定違い |
| 自動化ルール・プレイブックが動くか | テストインシデントで確認 | Logic Apps権限、接続情報、実行条件の不一致 |
| ワークブックが表示・編集できるか | Threat management > Workbooksを確認 | 権限不足、参照先クエリの不整合 |
Microsoft PurviewとDefender for Cloudを使う環境の注意点
公式ドキュメントでは、Microsoft Purview Insider Risk ManagementやMicrosoft Defender for Cloudを使っている場合の前提条件も示されています。これらの設定は、接続後のデータ統合やインシデント相関に影響するため、見落としやすいポイントです。(Microsoft Learn)
Microsoft Purview Insider Risk Management
Microsoft Purview Insider Risk Managementを使っている組織では、Microsoft 365 Insider Risk Managementデータコネクタをプライマリワークスペースで有効にする必要があります。一方、Defenderポータルにオンボード予定のセカンダリワークスペースでは、そのコネクタを無効にする必要があります。(Microsoft Learn)
実務では、複数ワークスペースに同じコネクタを有効化したままにしてしまい、データの重複や調査導線の混乱が起きることがあります。移行前に、Purview関連のデータがどのワークスペースへ入っているかを棚卸ししてください。
Microsoft Defender for Cloud
Defender for Cloudのインシデントをテナント全体で相関し、Microsoft Sentinelのプライマリワークスペースへストリーミングしたい場合は、プライマリワークスペースでテナントベースのMicrosoft Defender for Cloudデータコネクタを接続し、従来のサブスクリプションベースのDefender for Cloudアラートコネクタを切断する必要があります。(Microsoft Learn)
ただし、相関済みのテナントデータをプライマリワークスペースへ流したくない場合は、従来のサブスクリプションベースのコネクタを使い続ける選択肢もあります。つまり、正解は一律ではありません。全社SOCで一元監視したいのか、サブスクリプションや部門ごとに運用を分けたいのかで判断してください。
プライマリワークスペース変更時の注意点
Defenderポータルに接続できるプライマリワークスペースは一度に1つですが、後から変更できます。変更はSystem > Settings > Microsoft Sentinel > Workspacesから対象ワークスペースを選び、Set as primaryを実行する流れです。(Microsoft Learn)
重要なのは、プライマリワークスペースを切り替えると、Defender XDRコネクタが新しいプライマリへ接続され、以前のプライマリからは自動的に切断される点です。(Microsoft Learn)
これは検証環境では便利ですが、本番環境では大きな影響を持ちます。たとえば、旧プライマリワークスペースを前提にした分析ルール、ワークブック、データ取り込み、SOCレポートがある場合、切り替え後に期待したデータが見えなくなる可能性があります。
変更前チェックリスト
| 項目 | 確認内容 |
|---|---|
| Defender XDRコネクタの接続先 | 変更後にどのワークスペースへ接続されるか |
| 既存の分析ルール | 旧プライマリ前提のルールがないか |
| インシデント管理 | 未解決インシデントの調査導線が変わらないか |
| ワークブック | 参照先ワークスペースやクエリが変更後も正しいか |
| 自動化ルール | プレイブック、Logic Apps、通知先が変わらないか |
| 運用連絡 | SOC、クラウド管理者、監査担当者へ事前周知したか |
オフボードは「切断するだけ」と考えない
Microsoft DefenderポータルからMicrosoft Sentinelワークスペースをオフボードする場合、DefenderポータルのMicrosoft Sentinel設定からワークスペースを切断します。公式情報では、ワークスペースにMicrosoft Defender XDRコネクタが構成されている場合、DefenderポータルからのオフボードによってMicrosoft Defender XDRコネクタも切断されると説明されています。(Microsoft Learn)
切断後は、Defenderポータル左側のナビゲーションからMicrosoft Sentinelセクションが削除され、ホームページにもMicrosoft Sentinel由来のデータが含まれなくなります。(Microsoft Learn)
本番環境でオフボードする場合は、少なくとも次の順で進めるべきです。
| フェーズ | 実施内容 |
|---|---|
| 事前確認 | Defender XDRコネクタ、データコネクタ、分析ルール、自動化ルールの依存関係を確認 |
| 周知 | SOC、監査、クラウド運用、インシデント対応担当に作業日時を共有 |
| バックアップ | 重要なKQL、ワークブック、ルール、プレイブック構成を記録 |
| 切断 | Defenderポータルの設定からワークスペースを切断 |
| 事後確認 | ナビゲーション、ホーム画面、データ連携、インシデント表示を確認 |
| 復旧計画 | 別ワークスペースへ接続する場合の手順を準備 |
Azure portalからの移行を見据えた実務対応
Microsoft SentinelはMicrosoft Defenderポータルで一般提供されており、2027年3月31日以降はAzure portalでサポートされなくなる予定です。公式の更新情報でも、Azure portalを使っている場合はDefenderポータルへの移行計画を始めることが推奨されています。(Microsoft Learn)
移行で失敗しやすいのは、技術的な接続作業よりも、運用設計の更新です。特に以下のような組織は、早めに移行計画を作るべきです。
| 組織・環境 | 早めに対応すべき理由 |
|---|---|
| 複数ワークスペースを使っている | プライマリとセカンダリの設計が必要 |
| MSSPや複数テナントを管理している | Azure LighthouseやB2B認証、テナント分離の確認が必要 |
| 独自のKQLや検知ルールが多い | Advanced huntingでの互換性確認に時間がかかる |
| 自動化ルールやプレイブックが多い | Logic Apps、権限、インシデントトリガーの検証が必要 |
| 監査レポートを定期作成している | 画面、データ参照先、レポート手順が変わる可能性がある |
開発者・検知エンジニアが確認すべきポイント
Microsoft Defenderポータルへの統合は、管理者だけでなく、KQLを書く開発者、検知エンジニア、SOC自動化担当者にも影響します。特にAdvanced hunting、カスタム検知、保存済みクエリ、ワークブック、プレイブックを扱う担当者は、次の観点で確認してください。
KQLクエリの互換性
Microsoft Defenderの高度なハンティングでは、Microsoft Sentinelのテーブルや関数、共有クエリ、サンプルクエリを参照できます。ただし、既存クエリがすべて同じ体験で動くと考えるのは危険です。公式情報では、SecurityAlertテーブルはスキーマタブではAlertInfoとAlertEvidenceに置き換わる一方、既存クエリが壊れないようエディターではSecurityAlertを使用できるとされています。(Microsoft Learn)
検知エンジニアは、よく使うクエリを次の3段階で分類すると移行しやすくなります。
| 分類 | 例 | 対応 |
|---|---|---|
| そのまま使えるクエリ | 基本的なログ検索、単一テーブル集計 | 実行結果と件数を確認 |
| 修正が必要なクエリ | 時間条件、スキーマ差分、列名依存があるクエリ | Defender側のスキーマに合わせて調整 |
| 代替手段が必要なクエリ | ブックマーク依存、未対応カスタム関数依存 | SentinelのHunting機能や別運用に分ける |
カスタム検知の制限
Microsoft Sentinelデータを含むカスタム検知では、近リアルタイム検知頻度が利用できない、Microsoft Sentinelで作成・保存したカスタム関数がサポートされないなどの制限があります。(Microsoft Learn)
そのため、移行時は「クエリが実行できるか」だけではなく、「検知ルールとして運用できるか」まで確認してください。特に、重要度の高い検知ロジックは、検知頻度、通知先、インシデント生成、プレイブック実行まで含めたテストが必要です。
時刻と保持期間の扱い
高度なハンティングのデータ保持や時間指定にも注意が必要です。Advanced huntingではMicrosoft Defender XDRの多くの生データを最大30日まで探索でき、Microsoft Sentinelワークスペースを接続するとSentinelテーブルも扱えます。一方で、Defender XDRテーブルをMicrosoft Sentinelへストリーミングして長い保持期間を設定している場合など、クエリ対象や時間フィルターの使い方で結果が変わることがあります。(Microsoft Learn)
実務では、以下のような検証クエリを用意すると安全です。
SecurityIncident
| summarize Count = count() by bin(TimeGenerated, 1d)
| order by TimeGenerated descAlertInfo
| summarize Count = count() by SeverityDeviceEvents
| summarize Count = count() by bin(Timestamp, 1d)
| order by Timestamp descこれらを移行前後で比較し、データ件数、時間範囲、対象テーブル、権限による見え方の差を確認します。
管理者向けの移行・展開チェックリスト
Microsoft DefenderポータルへのMicrosoft Sentinel接続を安全に進めるには、いきなり本番ワークスペースを接続するのではなく、確認項目を分けて進めるのが現実的です。
| フェーズ | 確認項目 | 完了の目安 |
|---|---|---|
| 現状把握 | ワークスペース数、テナント、データコネクタ、分析ルールを棚卸し | 影響を受ける資産一覧がある |
| 権限確認 | Azure RBAC、Entraロール、Sentinelロールを確認 | 作業者、閲覧者、調査者の権限が明確 |
| プライマリ設計 | どのワークスペースをプライマリにするか決定 | Defender XDRとの相関対象が説明できる |
| 検証接続 | 検証環境または影響の小さいワークスペースで接続 | メニュー、インシデント、ハンティングが確認済み |
| クエリ検証 | 主要KQL、保存済みクエリ、検知ルールを実行 | 件数や結果の差分が把握済み |
| 自動化検証 | 自動化ルール、プレイブック、通知をテスト | インシデント発生から通知まで確認済み |
| 運用更新 | 手順書、教育資料、監査資料を更新 | SOC担当者がDefenderポータルで作業できる |
| 本番展開 | 接続作業を実施 | 作業ログとロールバック手順が残っている |
よくある失敗と回避策
ワークスペースが表示されない
Defenderポータルで接続対象のワークスペースが表示されない場合、まず権限を疑います。公式情報では、必要なアクセス許可がないワークスペースはDefenderポータルに表示されないとされています。(Microsoft Learn)
対策として、作業者にOwner、User Access Administrator、Microsoft Sentinel Contributorなど必要な権限が適切なスコープで割り当てられているか確認してください。サブスクリプション、リソースグループ、ワークスペース単位のどこに権限が付いているかも重要です。
複数ワークスペースでプライマリを誤る
複数ワークスペース環境では、プライマリワークスペースの選択が運用全体に影響します。プライマリを後から変更できるとはいえ、変更時にはDefender XDRコネクタの接続先も変わります。(Microsoft Learn)
回避策は、接続前に「どのデータを全社インシデント対応の中心にするか」を決めることです。単にデータ量が多いワークスペースではなく、SOCが最も頻繁に使う調査コンテキストを基準に選びます。
コネクタ重複でデータが分散・重複する
PurviewやDefender for Cloudのように、プライマリワークスペース側での有効化や、セカンダリ・旧コネクタ側の無効化が必要になるケースがあります。(Microsoft Learn)
回避策は、接続前にデータコネクタ一覧を出し、どのコネクタがどのワークスペースにデータを送っているかを表にしておくことです。特に本番移行では、作業前後でデータ取り込み量が急に増減していないかも確認してください。
Azure portal前提の手順書が残る
Microsoft Sentinelの機能はDefenderポータル側に統合されつつありますが、Azure portalとDefenderポータルではメニューの場所が異なります。たとえば、ログはDefenderポータルでは高度なハンティング、インシデントはInvestigation & response配下、データコネクタはMicrosoft SentinelのConfiguration配下に移ります。(Microsoft Learn)
回避策は、移行直後に運用手順書を修正するのではなく、接続前から「新旧メニュー対応表」を作ることです。SOC担当者には、画面キャプチャ付きの短い手順書を配布すると定着しやすくなります。
今回の更新で管理者が取るべき次の行動
Microsoft DefenderポータルへのMicrosoft Sentinel接続は、今後のMicrosoftセキュリティ運用の中心になる変更です。まず行うべきことは、接続作業そのものではなく、現在のMicrosoft Sentinel環境を棚卸しすることです。
具体的には、次の順番で進めてください。
- Microsoft Sentinelワークスペースの一覧を作る
- プライマリにすべきワークスペースを決める
- Azure RBACとMicrosoft Entraロールを確認する
- Defender XDR、Purview、Defender for Cloudのコネクタ構成を確認する
- 主要なKQL、検知ルール、ワークブック、自動化ルールをテストする
- SOC担当者向けのDefenderポータル手順書を更新する
- 本番接続後にインシデント、ハンティング、データ取り込みを確認する
Microsoft DefenderとMicrosoft Sentinelの統合は、適切に設計すれば調査スピードと運用効率を高められます。一方で、権限、ワークスペース、コネクタ、自動化の確認を省くと、見えるはずのデータが見えない、検知が想定通り動かない、インシデント対応の導線が分断されるといった問題につながります。まずは小さな検証から始め、プライマリワークスペースと権限設計を固めたうえで、本番展開へ進めるのが安全です。
コメント