Microsoft Defenderポータルの「Multiple workspaces – Microsoft Sentinel in Defender portal」で最初に押さえるべき結論は、Microsoft Sentinelのワークスペースを複数接続できても、Defender XDRと深く連携するプライマリワークスペースは1つだけという点です。セカンダリワークスペースは接続できますが、Defender XDRのアラートやインシデントは基本的にプライマリ側に同期されます。複数拠点・複数部門・複数SOCでMicrosoft Sentinelを運用している管理者は、どのワークスペースをプライマリにするか、既存のデータコネクタや分析ルールが影響を受けないかを事前に確認する必要があります。(Microsoft Learn)
Microsoft DefenderポータルのMultiple workspacesとは
Microsoft Defenderポータルでは、Microsoft Sentinel用に1つのプライマリワークスペースと複数のセカンダリワークスペースを接続できます。ここでいうワークスペースとは、Microsoft Sentinelが有効化されたLog Analyticsワークスペースのことです。(Microsoft Learn)
この機能は、Microsoft SentinelをMicrosoft Defender XDRと組み合わせて、統合セキュリティ運用を行う組織に特に関係します。Microsoft Defender XDRを利用していない場合でも、Defenderポータル上で複数のSentinelワークスペースを管理できますが、Defender XDRのデータや機能は利用できません。(Microsoft Learn)
たとえば、次のような組織では影響が大きくなります。
- グローバルSOCと地域別SOCでMicrosoft Sentinelワークスペースを分けている
- 事業部ごとにLog Analyticsワークスペースを分けている
- 本番環境、検証環境、子会社環境を別ワークスペースで監視している
- 既に複数のSentinelワークスペースでDefender系データコネクタを使っている
- Azure portal中心のSentinel運用からDefenderポータルへ段階的に移行している
重要なのは、「複数ワークスペースを接続できる」ことと、「すべてのワークスペースが同じ扱いでDefender XDRと連携する」ことは別だという点です。
何が変わるのか：管理者が見るべき主要ポイント
今回の公式情報で実務上もっとも重要なのは、プライマリとセカンダリの役割が明確に分かれることです。
| 確認項目 | 変更・仕様の要点 | 管理者への影響 |
|---|---|---|
| プライマリワークスペース | テナントごとに1つだけ選択する | グローバルSOCや主要なインシデント対応基盤をどこに置くか決める必要がある |
| セカンダリワークスペース | 数の上限なく接続可能 | 部門別・地域別の自律運用は維持しやすい |
| Defender XDRアラートとインシデント | プライマリワークスペースにのみ同期 | セカンダリ側ではDefender XDRとの相関を前提にした運用を見直す |
| Defender XDRデータコネクタ | プライマリにのみ接続 | 既存コネクタの切断や再構成が発生する場合がある |
| インシデント相関 | ワークスペースごとに分離 | セカンダリのインシデントは他ワークスペースやDefender XDRデータを含まない |
| 権限管理 | 既存のAzure RBACを引き続き利用 | Entra IDロールとAzureロールの両方を確認する必要がある |
| 高度なハンティング | ワークスペース選択またはworkspace演算子で横断クエリ可能 | クエリ結果にワークスペース名やIDが自動表示されない点に注意 |
Microsoft Defenderポータルでは、Defender XDRのアラートとインシデントはプライマリワークスペースに同期されます。一方、セカンダリワークスペースはMicrosoft Sentinelのワークスペースとしては利用できますが、Defender XDRのインシデントやアラートは同期されません。必要に応じて、Defenderテーブルデータの取り込みを別途構成する必要があります。(Microsoft Learn)
プライマリワークスペースの選び方
プライマリワークスペースは、単に「一番古いワークスペース」や「データ量が多いワークスペース」で選ぶべきではありません。Defender XDRとの統合、インシデント対応の中心、SOCの権限設計を考えて選定する必要があります。
プライマリに向いているワークスペース
次の条件に当てはまるワークスペースは、プライマリ候補になります。
| 判断基準 | プライマリに向く理由 |
|---|---|
| グローバルSOCが日常的に確認する | Defender XDRとSentinelのインシデントを統合して見やすい |
| 主要なインシデント対応フローが集約されている | 状態、割り当て、クローズ理由の同期を活かしやすい |
| Defender XDRデータを中心に相関分析したい | アラート相関や統合キューのメリットが大きい |
| IRMやMicrosoft系セキュリティサービスとの連携が多い | プライマリ側に集約する前提で設計しやすい |
| SOC最適化やワークブックを主要な監視基盤として使う | 一部の表示や機能がプライマリ中心になるため |
Microsoftの公式情報でも、同一Microsoft Entra IDテナント内に複数のMicrosoft Sentinelワークスペースがある場合、グローバルSOC用のワークスペースをプライマリとして使うことが検討されています。(Microsoft Learn)
セカンダリに向いているワークスペース
一方で、次のようなワークスペースはセカンダリとして残す方が自然です。
| 判断基準 | セカンダリに向く理由 |
|---|---|
| 地域別・部門別に独立運用している | グローバルキューにすべてを混ぜずに済む |
| 検証環境やPoC環境である | 本番SOCのインシデント対応にノイズを入れにくい |
| 法規制や契約上、データ管理を分けたい | ワークスペース単位の分離を維持しやすい |
| Defender XDRとの相関が不要 | Sentinel単体の監視・分析を継続できる |
| 独自の分析ルールや自動化を維持したい | ワークスペースごとの自律性を保ちやすい |
ただし、セカンダリワークスペースのインシデントには、他ワークスペースやDefender XDRからのデータは含まれません。セカンダリでもDefender系データを使いたい場合は、テーブル取り込みの設定やクエリ設計を個別に確認する必要があります。(Microsoft Learn)
既存環境への影響範囲
Defender XDRデータコネクタの切断に注意する
複数ワークスペース運用で最も失敗しやすいのが、既存のデータコネクタです。
プライマリワークスペースを選択すると、Defender XDRのインシデントとアラート用データコネクタはプライマリワークスペースにのみ接続されます。以前に他のワークスペースがDefender XDRコネクタに接続されていた場合、それらは切断され、セカンダリワークスペースとして動作します。Defender XDRデータに基づいて作成していた分析ルールや自動化は、テーブル取り込みを構成するまで期待通りに動かない可能性があります。(Microsoft Learn)
特に確認すべきコネクタは次の通りです。
| 対象コネクタ | 確認ポイント |
|---|---|
| Microsoft Defender for Office 365 | セカンダリ側で重複アラートが出ないか |
| Microsoft Entra ID Protection | テナントベースのアラートがプライマリに集約される前提になっているか |
| Microsoft Defender for Cloud Apps | 既存の分析ルールがセカンダリ側で参照していないか |
| Microsoft Defender for Endpoint | 端末アラートの相関先がプライマリで問題ないか |
| Microsoft Defender for Identity | ID関連アラートの運用担当が変わらないか |
| その他のMicrosoft系スタンドアロンコネクタ | オンボード前に切断すべきものがないか |
オンボード時には一部のMicrosoft系スタンドアロンデータコネクタが自動的に切断されます。自動切断されないMicrosoftデータコネクタがある場合は、Defenderポータルへオンボードする前に、重複や相関崩れが起きないかを確認してください。(Microsoft Learn)
インシデントとアラートの見え方が変わる
Microsoft Defenderポータルでは、インシデントとアラートを複数ワークスペースから統合キューで表示したり、ワークスペースで絞り込んだりできます。ただし、アラートの相関はワークスペース単位で分離されます。つまり、複数ワークスペースの情報が常に1つの大きなインシデントとして結合されるわけではありません。(Microsoft Learn)
運用上は、次のような見落としが起きやすくなります。
| よくある誤解 | 実際の動き |
|---|---|
| セカンダリにもDefender XDRインシデントが同期される | 同期されるのはプライマリのみ |
| 複数ワークスペースのアラートが自動で1つに相関される | 相関はワークスペースごとに分離 |
| 統合キューに表示されるのでデータも完全統合されている | 表示とデータ同期は別 |
| セカンダリでも同じ自動化がそのまま動く | コネクタやテーブル参照の変更で停止する可能性がある |
SOCの一次対応者には、「どのワークスペースのインシデントを見ているのか」を意識させる必要があります。特に、地域別SOCや子会社SOCが独自にクローズ判断をしている場合、グローバルSOCとの役割分担を運用ルールとして明文化しておくと混乱を防げます。
権限とRBACで確認すべきこと
Microsoft SentinelをDefenderポータルに接続した後も、既存のAzure RBAC権限に基づいて、アクセスできるMicrosoft Sentinel機能とワークスペースが決まります。Microsoftは最小権限のロール使用を推奨しています。(Microsoft Learn)
管理者は、少なくとも次のロール設計を確認してください。
| 作業 | 主な確認ポイント |
|---|---|
| プライマリワークスペースのオンボード | Microsoft Entra IDのSecurity Administrator以上、および対象スコープのOwnerまたはUser Access Administrator＋Microsoft Sentinel Contributorを確認 |
| セカンダリワークスペースの接続・切断 | サブスクリプション、リソースグループ、ワークスペース単位のAzureロールを確認 |
| プライマリワークスペースの変更 | Entra ID側の権限とAzure側の権限を両方確認 |
| Unified RBACでのSentinelワークスペース有効化・無効化 | Defender側の統合RBAC設計とAzure RBACの整合性を確認 |
| 閲覧・調査担当者のアクセス | プライマリとセカンダリで見えるデータの範囲が違うことを確認 |
注意したいのは、プライマリにアクセスできるユーザーはワークスペースデータとDefender XDRデータを扱える一方、セカンダリにアクセスできるユーザーは基本的にそのワークスペースのデータのみを扱う点です。また、2025年1月中旬より前にAlertInfoやAlertEvidenceテーブルのカスタム検出で作成されたアラートについては、既にワークスペースをDefenderポータルにオンボードしている場合の例外が示されています。(Microsoft Learn)
権限確認では、次の3点をセットで見ると安全です。
| 確認対象 | 見るべき内容 |
|---|---|
| Microsoft Entra IDロール | Security Administrator以上が必要な作業か |
| Azure RBAC | Owner、User Access Administrator、Microsoft Sentinel Contributorなどの割り当て範囲 |
| SOC運用ロール | 閲覧、調査、インシデント更新、プレイブック実行の担当範囲 |
移行・展開前に確認するチェックリスト
Microsoft DefenderポータルへMicrosoft Sentinelを接続する作業自体は、DefenderポータルのSystem > Settings > Microsoft Sentinel > ワークスペースの接続から進められます。ワークスペース選択、プライマリ指定、製品変更内容の確認、接続という流れです。(Microsoft Learn)
ただし、複数ワークスペース環境では、ボタンを押す前の棚卸しが重要です。
| フェーズ | 確認すること | 失敗しやすいポイント |
|---|---|---|
| 事前整理 | 全Sentinelワークスペース、用途、所有者、接続コネクタを一覧化 | 使われていないと思ったワークスペースに重要な分析ルールが残っている |
| プライマリ選定 | グローバルSOC、Defender XDR相関、IRM連携の中心を決める | データ量だけで選び、運用担当と合わなくなる |
| コネクタ確認 | Defender系・Microsoft系スタンドアロンコネクタを確認 | 自動切断後に分析ルールや自動化が動かなくなる |
| 権限確認 | Entra IDロールとAzure RBACの両方を確認 | AzureのOwnerだけで作業できると誤解する |
| クエリ確認 | KQL、関数、ブック、API利用を洗い出す | ワークスペース名やIDが結果に出ない前提を見落とす |
| 自動化確認 | 分析ルール、オートメーションルール、Logic Appsプレイブックを確認 | Defender XDRテーブル参照がセカンダリで切れる |
| 展開後確認 | インシデント件数、アラート件数、同期状態、担当者の見え方を確認 | 統合キューの表示だけ見て正常と判断する |
特に、セカンダリワークスペースでDefenderテーブルデータを使い続けたい場合は、Microsoft XDRコネクタまたはDefenderポータルのMicrosoft Sentinel > Configuration > Tablesで取り込み設定を確認してください。(Microsoft Learn)
プライマリワークスペースを変更するときの注意点
Microsoft SentinelをDefenderポータルにオンボードした後でも、プライマリワークスペースは変更できます。操作はDefenderポータルのSystem > Settings > Microsoft Sentinel > Workspacesから行います。プライマリを切り替えると、Defender XDRコネクタは新しいプライマリに接続され、以前のプライマリからは自動的に切断されます。(Microsoft Learn)
この動作は便利ですが、運用上は大きな変更です。以下を事前に確認してから実施してください。
| 確認項目 | 理由 |
|---|---|
| 旧プライマリの分析ルール | Defender XDRデータを前提にしていたルールが停止する可能性がある |
| 旧プライマリの自動化 | プレイブックや通知先が期待通りに動かない可能性がある |
| 新プライマリのデータ保持期間 | インシデント調査で必要な履歴を保持できるか確認する |
| SOC担当者の権限 | 新プライマリのデータを必要な担当者が見られるか確認する |
| 運用手順書 | 一次対応者が旧ワークスペースを見続けるリスクを減らす |
切り替え後は、最低限、次の確認を行うと実務上の事故を減らせます。
- Defender XDRインシデントが新プライマリ側に表示されるか
- 旧プライマリ側の期待しないアラート欠落や重複がないか
- 自動化ルールやプレイブックがエラーになっていないか
- SOCの担当者が正しいワークスペースでインシデントを確認しているか
- ダッシュボードやブックの表示対象が変わっていないか
高度なハンティングとKQLで注意すべきこと
Microsoft Defenderポータルの高度なハンティングでは、Microsoft Defender XDRやMicrosoft Sentinelのデータを1つのポータルから扱えます。SentinelワークスペースをDefenderポータルにオンボードすると、既存のSentinelワークスペースのクエリや関数にもアクセスできます。(Microsoft Learn)
複数ワークスペースを対象にする場合は、workspace()演算子やunionを使ったクエリ設計が重要です。Microsoft Sentinelの公式情報では、複数ワークスペースを参照する分析ルールでは最大20ワークスペースまで含められますが、パフォーマンス面では5以下が推奨されています。また、ワークスペース間分析ルールで生成されたアラートやインシデントは、ルールが定義されたワークスペースにのみ存在します。(Microsoft Learn)
実務では、次のように「どのワークスペース由来の結果か」を識別できる形でクエリを書くと、調査時の混乱を減らせます。
union
(SecurityIncident
| extend SourceWorkspace = "primary-soc"),
(workspace("00000000-0000-0000-0000-000000000001").SecurityIncident
| extend SourceWorkspace = "secondary-apac"),
(workspace("00000000-0000-0000-0000-000000000002").SecurityIncident
| extend SourceWorkspace = "secondary-emea")
| where CreatedTime >= ago(7d)
| project CreatedTime, Title, Severity, Status, SourceWorkspaceDefenderポータルの高度なハンティングでは、複数ワークスペースをクエリできますが、結果にワークスペース名やIDが自動的に表示されない点も公式情報で示されています。調査証跡や運用メモには、実行対象ワークスペースを残す設計にしておくと安全です。(Microsoft Learn)
ワークブック、SOC最適化、エンティティページの見え方
複数ワークスペース環境では、画面ごとにデータの集約範囲が異なります。
| 機能 | データの見え方 |
|---|---|
| グローバル検索 | 権限のある関連ワークスペースデータを集約表示 |
| インシデント・アラート | 統合キューで表示、またはワークスペースでフィルター可能 |
| エンティティページ | 複数ワークスペースの関連データを集約表示 |
| Advanced Hunting | ワークスペース選択またはworkspace演算子で横断 |
| Microsoft Sentinelセクション | 多くのページで1ページにつき1ワークスペースを表示 |
| Workbooks | プライマリワークスペースに関連するデータのみ表示 |
| SOC optimization | 複数ワークスペースからデータと推奨事項を集約 |
ここで注意したいのは、「インシデント画面では複数ワークスペースが見えるのに、ワークブックではプライマリ中心になる」といった機能差です。監視ダッシュボードを業務報告やSLA確認に使っている場合、移行後に数値の前提が変わっていないか確認してください。(Microsoft Learn)
IRMとMicrosoft Defender for Cloudを使っている場合
Microsoft Purview Insider Risk Management、いわゆるIRMのアラートは、プライマリワークスペースにのみ関連付けられます。Defender XDRでIRMアラートを使う場合は、Defenderポータルへのオンボード前に、プライマリワークスペースのMicrosoft Defender XDRコネクタにIRMを接続する必要があります。セカンダリワークスペースにMicrosoft 365 Insider Risk Managementの直接コネクタが接続されている場合は、オンボード前に切断が必要です。(Microsoft Learn)
Microsoft Defender for Cloudを使っている場合も、テナントベースのDefender for Cloudコネクタをプライマリワークスペースで使うのか、レガシなサブスクリプションベースのコネクタを継続するのかを整理する必要があります。公式のオンボード手順では、テナント内のサブスクリプションをまたいだDefender for Cloudインシデントをプライマリワークスペースにストリーミングする場合の前提が示されています。(Microsoft Learn)
Azure portalからDefenderポータルへの移行も見据える
Microsoft Sentinelは、2027年3月31日以降、Azure portalではサポートされず、Microsoft Defenderポータルでのみ使用できるようになると公式情報で案内されています。現在もAzure portal中心でSentinelを運用している場合、複数ワークスペース設計は「いずれ考えること」ではなく、移行計画の早い段階で決めるべき項目です。(Microsoft Learn)
移行計画では、次の順序で整理すると進めやすくなります。
| 順番 | 作業 | 目的 |
|---|---|---|
| 1 | ワークスペース一覧を作る | どの環境が影響を受けるか明確にする |
| 2 | プライマリ候補を決める | Defender XDR相関とグローバルSOCの中心を決める |
| 3 | 既存コネクタを棚卸しする | 自動切断や重複アラートを防ぐ |
| 4 | 分析ルールと自動化を確認する | Defender XDRテーブル依存の停止を防ぐ |
| 5 | RBACを見直す | 見えるべき人に見え、見えないべき人に見えない状態にする |
| 6 | 検証期間を設ける | インシデント数、アラート数、通知、プレイブックを比較する |
| 7 | 運用手順書を更新する | SOC担当者の画面操作と判断基準を統一する |
移行でありがちな失敗は、「接続できたから完了」と判断することです。実際には、接続後にインシデントの発生場所、相関ルール、通知先、担当者の見え方が変わります。技術設定だけでなく、SOC運用の責任分界まで確認することが重要です。
管理者がすぐ確認すべき実務チェックリスト
最後に、Microsoft DefenderポータルのMultiple workspaces対応で、管理者がすぐ確認すべき項目を整理します。
| 優先度 | 確認項目 | 具体的な確認内容 |
|---|---|---|
| 高 | プライマリワークスペース | グローバルSOCやDefender XDR連携の中心にふさわしいか |
| 高 | Defender XDRコネクタ | プライマリ以外で切断されても問題ないか |
| 高 | Microsoft系スタンドアロンコネクタ | セカンダリ側で重複や停止が起きないか |
| 高 | 分析ルール | Defender XDRデータを参照しているルールがないか |
| 高 | 自動化・プレイブック | テーブル名、ワークスペース、インシデント種別の前提が変わらないか |
| 中 | Advanced Huntingクエリ | workspace演算子や結果識別の設計ができているか |
| 中 | ワークブック | プライマリのみ表示される前提で問題ないか |
| 中 | RBAC | Entra IDロールとAzure RBACが作業内容に合っているか |
| 中 | IRM連携 | プライマリ側に正しく接続されているか |
| 中 | 運用手順 | SOC担当者がプライマリとセカンダリの違いを理解しているか |
複数ワークスペース対応は、単なる画面統合ではありません。Defender XDRの相関、Sentinelの分析ルール、Log Analyticsのデータ設計、RBAC、SOC運用フローがまとめて影響を受けます。
まずは全ワークスペースを棚卸しし、プライマリを「組織の主要なインシデント対応基盤」として選定してください。そのうえで、セカンダリワークスペースは自律運用を続けるのか、Defenderテーブルデータを取り込むのか、段階的に統合するのかを決めると、移行後の混乱を大きく減らせます。
コメント