Microsoft Sentinel を複数の Log Analytics ワークスペースや複数テナントにまたがって使う場合、2026年4月時点で最初に確認すべきポイントは 「単一ワークスペースで十分か」「Defender ポータル前提で運用するか」「クロスワークスペース検出ルールをどこまで使うか」 の3つです。Microsoft 公式ドキュメント「Extend Microsoft Sentinel across workspaces and tenants」は 2026年4月22日に更新されており、複数ワークスペース運用、テナント横断管理、Azure Lighthouse、Defender ポータルでの統合運用を整理するうえで重要な参照先になっています。(Microsoft Learn)
特に security admins、identity teams、compliance teams は、Microsoft Sentinel を「ログを集める場所」としてだけでなく、インシデント管理、検出ルール、ハンティング、権限委任、監査対応を横断的に設計する基盤として見直す必要があります。
Microsoft Sentinelの最新動向: Extend Microsoft Sentinel across workspaces and tenantsで何が変わったか
今回の公式ドキュメントで押さえるべき要点は、Microsoft Sentinel を単一の Log Analytics ワークスペースに閉じず、複数ワークスペースや複数 Microsoft Entra テナントへ拡張して使う設計が、より明確に整理されている点です。
公式ドキュメントでは、Microsoft Sentinel のオンボード時に最初に選ぶのは Log Analytics ワークスペースであり、通常は単一ワークスペースでも十分な機能を利用できます。一方で、組織構造、規制、データ所有、MSSP、グローバル SOC などの理由がある場合は、複数ワークスペースや複数テナントを横断してクエリ・分析・インシデント管理を行う構成が必要になります。(Microsoft Learn)
実務上の更新ポイントは、次のように整理できます。
| 確認ポイント | 実務での意味 |
|---|---|
| Azure ポータルと Microsoft Defender ポータルの両方に言及 | Sentinel 運用を Defender ポータルへ移行・統合する前提で設計を見直す必要がある |
| 複数ワークスペースのインシデント管理 | SOC が複数環境のインシデントを中央で確認しやすくなる |
workspace() と union による横断クエリ | 複数ワークスペースのログを1つの KQL で相関分析できる |
| スケジュール分析ルールでの制限 | 検出ルールを横断化する場合、最大数・性能・アラート配置先を理解する必要がある |
| Azure Lighthouse によるテナント横断 | MSSP やグループ会社管理で、委任管理モデルを設計しやすくなる |
| Defender ポータルのマルチテナント管理 | SIEM と XDR の統合運用を複数テナントに広げられる |
ここで重要なのは、「複数ワークスペースにできる」こと自体ではありません。どのデータを分け、どの検出を中央化し、どの権限を誰に委任するかを先に決めることです。設計なしに横断クエリだけを増やすと、パフォーマンス低下、誤検知の増加、インシデントの所在不明、監査時の説明不足につながります。
単一ワークスペースで十分か、複数ワークスペースに分けるべきか
Microsoft Sentinel は、まず Log Analytics ワークスペースを選んで利用します。多くの環境では、単一ワークスペースのほうが管理しやすく、クエリもシンプルで、検出ルールやワークブックの保守も容易です。
一方で、次のような条件がある場合は、複数ワークスペース構成を検討する価値があります。
| 要件 | 複数ワークスペースを検討する理由 | 注意点 |
|---|---|---|
| 国・地域ごとのデータ主権 | ワークスペースはリージョンに紐づくため、データ所在地を分けやすい | 検出ルールやハンティングが分散しやすい |
| 子会社・事業部ごとのデータ所有 | 各組織の責任範囲を明確にできる | グローバル SOC の可視性を別途設計する必要がある |
| 複数 Microsoft Entra テナント | テナント境界をまたぐ SaaS・Microsoft サービス連携に対応しやすい | Azure Lighthouse や Defender マルチテナント管理の設計が必要 |
| MSSP 運用 | 顧客ごとの分離を保ちながら中央監視できる | 顧客ごとの権限委任、課金、運用責任を明確にする |
| 監査・コンプライアンス | 保持期間、アクセス制御、データ分離の説明がしやすい | 分離しすぎると運用負荷が増える |
公式ドキュメントでも、複数ワークスペースが必要になる代表例として、規制対応、データ所有、複数 Entra テナント、細かなアクセス制御、課金分離、既存アーキテクチャなどが挙げられています。(Microsoft Learn)
ただし、過去の制約を理由にワークスペースを分けていた環境では、現在の機能で単一ワークスペースに寄せられる場合もあります。たとえば、保持期間やアクセス制御を目的に分割していた場合、テーブル単位の保持設定や RBAC の見直しで改善できるケースがあります。
判断基準は「組織境界」ではなく「運用境界」
よくある失敗は、会社組織や拠点単位で機械的にワークスペースを分けることです。組織図に合わせると一見分かりやすいものの、SOC の運用では不便になる場合があります。
判断基準としては、次の順で考えると失敗しにくくなります。
- 監査上、分離しなければならないデータか
- 別チームに閲覧・運用権限を委任する必要があるか
- 検出ルールやハンティングを中央で実行したいか
- ログ量、保持期間、課金を分ける必要があるか
- Defender ポータルで統合運用する予定があるか
この順序で考えると、「分けるべきデータ」と「中央で見るべきデータ」を混同しにくくなります。
複数ワークスペースのインシデント管理で押さえるポイント
公式ドキュメントでは、Azure ポータルと Defender ポータルの両方で、複数ワークスペースのインシデントを中央管理・監視したり、ワークスペースでフィルターしたりできると説明されています。インシデントの詳細へ進むと、発生元ワークスペースのコンテキストで確認できます。(Microsoft Learn)
実務では、ここが SOC 運用の大きな分岐点になります。
たとえば、グローバル SOC が本社、欧州拠点、APAC 拠点、MSSP 管理環境を監視している場合、複数ワークスペースのインシデントを横断表示できると、初動対応は速くなります。一方で、インシデントの所有者、対応 SLA、証跡管理が曖昧だと、同じアラートを複数チームが処理したり、逆に誰も対応しなかったりするリスクがあります。
インシデント管理で決めておくべき運用ルール
| 項目 | 決めるべき内容 |
|---|---|
| 一次対応者 | グローバル SOC、地域 SOC、MSSP のどこが最初に見るか |
| エスカレーション条件 | 重大度、対象資産、影響範囲、規制対象データの有無 |
| インシデントの所有権 | 発生元ワークスペースの管理者か、中央 SOC か |
| クローズ基準 | 調査完了、誤検知確認、封じ込め完了、再発防止策の登録 |
| 監査証跡 | 誰が、いつ、どのポータルで、どの判断をしたか |
特に compliance teams は、「見えるようになった」だけでは不十分です。監査では、インシデントがどのワークスペースで作成され、誰が対応し、どの基準でクローズされたかを説明できる必要があります。
クロスワークスペースクエリは workspace() と union が基本
複数ワークスペースのログを横断して調査する場合、Microsoft Sentinel では KQL の workspace() 式と union 演算子を使います。公式ドキュメントでは、別ワークスペースのテーブルを参照するために workspace() を使い、複数ワークスペースに同じ処理を適用するために union を組み合わせる方法が示されています。(Microsoft Learn)
たとえば、複数ワークスペースの SecurityEvent を横断して、短時間に多数のログオン失敗が発生していないかを見る場合は、次のような考え方になります。
union
workspace("/subscriptions/<subscription-id>/resourcegroups/<resource-group>/providers/microsoft.OperationalInsights/workspaces/<workspace-a>").SecurityEvent,
workspace("/subscriptions/<subscription-id>/resourcegroups/<resource-group>/providers/microsoft.OperationalInsights/workspaces/<workspace-b>").SecurityEvent
| where TimeGenerated > ago(1h)
| where EventID == 4625
| summarize FailedLogons=count() by Account, bin(TimeGenerated, 10m)
| where FailedLogons >= 10この例では、2つのワークスペースにある Windows セキュリティイベントを横断し、1時間以内のログオン失敗を集計しています。実環境では、対象テーブル名、イベント ID、しきい値、アカウント除外条件を自社環境に合わせて調整します。
関数化すると保守しやすくなる
複数ワークスペースのリソース ID を毎回クエリに書くと、KQL が長くなり、保守ミスが起きやすくなります。公式ドキュメントでは、保存済み関数を使ってクロスワークスペースクエリを簡略化する方法も紹介されています。(Microsoft Learn)
たとえば、次のようにワークスペース参照を関数化しておくと、調査担当者は複雑なリソース ID を意識せずにクエリを書けます。
SecurityEventCustomerA
| where TimeGenerated > ago(24h)
| where EventID in (4624, 4625)実務では、次のような関数を用意しておくと便利です。
| 関数の用途 | 例 |
|---|---|
| 顧客別・拠点別テーブル参照 | SecurityEventCustomerA、SigninLogsEurope |
| 同一テーブルの横断 union | unionSecurityEvent、unionSigninLogs |
| SOC 共通の除外条件 | テストアカウント、監視用端末、既知のスキャナー除外 |
| 監査用の標準集計 | 管理者操作、特権ロール変更、条件付きアクセス失敗 |
関数化の価値は、単なる省略ではありません。検出ルール、ハンティング、ワークブックで同じスコープ定義を再利用できるため、チーム間で調査結果のブレを減らせます。
スケジュール分析ルールでの横断利用は制限を必ず確認する
Microsoft Sentinel では、クロスワークスペースクエリをスケジュール分析ルールに含められます。中央 SOC や、Azure Lighthouse を使うテナント横断環境、MSSP のような運用では便利です。(Microsoft Learn)
ただし、実務で最も注意すべきなのが制限事項です。
| 制限・推奨 | 実務上の影響 |
|---|---|
| 1つのクエリに含められるワークスペースは最大20 | 大規模環境では全拠点を1ルールに詰め込めない |
| パフォーマンス上は5ワークスペース以下が推奨 | 横断対象を絞らないと検出遅延やクエリ負荷が増える |
| 参照先すべてのワークスペースで Sentinel が有効である必要がある | Log Analytics だけのワークスペースを混在させると設計ミスになる |
| アラートとインシデントはルール定義元のワークスペースに作成される | 発生元ワークスペース側には表示されないため、運用通知設計が必要 |
| 複数ワークスペースクエリは性能に影響する可能性がある | 必要なロジックに限定して使うべき |
特に見落としやすいのは、アラートとインシデントが、参照先ではなくルールを定義したワークスペースに作成される点です。たとえば本社ワークスペースに横断検出ルールを置き、海外拠点のログを参照して検出した場合でも、インシデントは本社側のワークスペースに作成されます。発生元拠点の担当者が自分のワークスペースだけを見ていると、重要インシデントに気づけない可能性があります。
横断ルールを使うべきケース、避けるべきケース
| 判断 | 具体例 |
|---|---|
| 使うべき | 複数拠点にまたがる同一アカウントの侵害兆候を検出したい |
| 使うべき | MSSP が顧客ごとのワークスペースを横断して共通 IOC を監視したい |
| 使うべき | グローバル SOC が複数テナントの高重大度イベントだけを中央検出したい |
| 避けるべき | 各拠点で完結する単純なログオン失敗検出 |
| 避けるべき | 大量ログを毎分横断集計するような高負荷ルール |
| 避けるべき | 所有者や対応フローが決まっていない環境 |
横断ルールは「強力な中央監視」ですが、乱用すると運用が複雑になります。まずは高重大度、広域影響、テナント横断の意味がある検出だけに絞るのが現実的です。
Defender ポータルでの複数ワークスペース運用が重要になる理由
Microsoft Sentinel は、Microsoft Defender ポータルでの統合運用が重要になっています。Microsoft の関連ドキュメントでは、Microsoft Sentinel の Azure ポータルでのサポートは 2027年3月31日以降なくなり、Defender ポータルで利用する形になると説明されています。(Microsoft Learn)
そのため、2026年4月時点で複数ワークスペース設計を見直すなら、Azure ポータルだけでなく、Defender ポータルでどう見えるかを前提に考えるべきです。
Defender ポータルでは、Microsoft Sentinel のワークスペースについて、1つのプライマリワークスペースと複数のセカンダリワークスペースという考え方があります。Microsoft Defender XDR と併用する場合、プライマリワークスペースのアラートは Defender XDR データと相関され、統合キューで扱われます。(Microsoft Learn)
プライマリとセカンダリの違いを理解する
| 項目 | プライマリワークスペース | セカンダリワークスペース |
|---|---|---|
| 役割 | Defender ポータルでの中心ワークスペース | 追加で接続される Sentinel ワークスペース |
| Defender XDR との関係 | Defender XDR データとの相関に使われる | Defender インシデント・アラートは同期されない |
| 推奨される用途 | グローバル SOC、中心的な監視基盤 | 自律運用する拠点、部門、顧客環境 |
| 注意点 | 変更時にコネクタ影響を確認する | 中央キューに出ないデータの扱いを決める |
ここでのポイントは、セカンダリワークスペースが「重要度の低いワークスペース」という意味ではないことです。セカンダリは、あくまで Defender ポータル上の統合・相関の文脈での位置づけです。地域 SOC や子会社 SOC が自律運用する環境では、セカンダリとして接続しつつ、必要な情報だけ中央 SOC が横断的に確認する設計が有効です。
テナント横断管理では Azure Lighthouse と Defender マルチテナント管理を使い分ける
複数の Microsoft Entra テナントに Microsoft Sentinel ワークスペースが存在する場合、公式ドキュメントでは Azure Lighthouse を使ってテナント境界を越えたクロスワークスペース操作を拡張できると説明されています。また、Defender ポータルを使う場合は、Microsoft Defender XDR と Microsoft Sentinel のマルチテナント管理により、管理対象テナントを統合ビューで確認できます。(Microsoft Learn)
使い分けの目安は次のとおりです。
| 目的 | 向いている方法 |
|---|---|
| 顧客・子会社テナントの Azure リソースを委任管理したい | Azure Lighthouse |
| 複数テナントの SIEM/XDR インシデントを統合的に確認したい | Defender ポータルのマルチテナント管理 |
| セカンダリワークスペースを別テナントからクエリしたい | Azure Lighthouse の設計が必要 |
| MSSP として複数顧客を横断監視したい | Azure Lighthouse と Defender マルチテナント管理の併用を検討 |
Defender マルチテナント管理では、複数テナントにまたがるインシデント、アラート、ケース、Advanced hunting、カスタム検出ルールなどを扱えます。一方で、別テナントのセカンダリワークスペースを Advanced Hunting や分析ルール、ワークブックなどから参照する場合は Azure Lighthouse が必要になると説明されています。(Microsoft Learn)
identity teamsが確認すべき権限設計
テナント横断運用では、identity teams の役割が非常に重要です。単に SOC メンバーへ広い権限を付与するのではなく、ロール、グループ、委任範囲を分けて設計する必要があります。
公式ドキュメントでは、Azure Lighthouse を使う場合、Microsoft Sentinel のロールごとにグループを作成し、各テナントからそのグループへ権限を委任することが推奨されています。(Microsoft Learn)
実務では、次のようなグループ設計が分かりやすいです。
| グループ例 | 主な権限・用途 |
|---|---|
| Global-SOC-Sentinel-Reader | 複数ワークスペースの閲覧、インシデント確認 |
| Global-SOC-Sentinel-Responder | インシデント更新、担当割り当て、コメント追加 |
| Detection-Engineering-Sentinel-Contributor | 分析ルール、ハンティングクエリ、ワークブックの管理 |
| Compliance-Sentinel-Auditor | 監査用の読み取り、証跡確認、設定レビュー |
| MSSP-CustomerA-Sentinel-Operator | 顧客 A の範囲に限定した運用 |
最小権限の原則を守るには、「管理できる人」と「閲覧できる人」を分けるだけでは不十分です。検出ルールを作れる人、プレイブックを変更できる人、インシデントをクローズできる人、監査ログだけを見られる人を分けると、内部統制上の説明がしやすくなります。
ワークブックとハンティングは「誰が使うか」で設計する
複数ワークスペース環境では、ワークブックとハンティングの設計も変わります。
公式ドキュメントでは、クロスワークスペースのワークブックについて、作成者がクエリを書く方法、ワークスペースセレクターを追加する方法、上級ユーザーが対話的に編集する方法が示されています。(Microsoft Learn)
実務では、利用者のスキルに合わせて作り分けることが重要です。
| 利用者 | 向いている設計 |
|---|---|
| SOC アナリスト | ワークスペース選択をドロップダウン化し、KQL を触らず使えるようにする |
| Detection engineer | 関数化した横断クエリを使い、再利用性を高める |
| Threat hunter | workspace() と union を直接使い、調査対象を柔軟に変える |
| Compliance reviewer | 監査対象、期間、テナントを選ぶだけで結果が出るようにする |
初心者向けのワークブックに複雑な KQL を露出させると、誤った条件変更で調査結果が変わることがあります。逆に、上級者向けに固定化しすぎると、緊急調査で柔軟に使えません。定型監視はワークブック、仮説検証はハンティング、継続検出は分析ルールと役割を分けると、運用が安定します。
複数ワークスペース管理は自動化を前提にする
複数の Log Analytics ワークスペースで Microsoft Sentinel を管理する場合、手作業で分析ルール、ハンティングクエリ、ワークブック、プレイブックをそろえるのは現実的ではありません。公式ドキュメントでも、複数ワークスペースの構成・管理には Microsoft Sentinel management API の利用、リポジトリからのカスタムコンテンツ展開が示されています。(Microsoft Learn)
運用を安定させるには、Sentinel as Code の考え方を取り入れるのが有効です。
自動化すべき対象
| 対象 | 自動化する理由 |
|---|---|
| 分析ルール | ワークスペースごとの差分を減らし、変更履歴を残す |
| ハンティングクエリ | 調査ナレッジを標準化できる |
| ワークブック | SOC や監査チームに同じビューを提供できる |
| プレイブック | インシデント対応手順を統一できる |
| 関数 | クロスワークスペースのスコープ定義を一元管理できる |
| 権限設定 | テナントごとの委任漏れや過剰権限を防ぎやすい |
特に複数テナント環境では、「本番環境では動いているが、別テナントではルールが古い」という状態が起きやすくなります。GitHub や Azure DevOps などのリポジトリで定義を管理し、変更レビュー、承認、展開を標準化すると、監査対応にも役立ちます。
compliance teamsが見るべき監査・データ分離の観点
Microsoft Sentinel の複数ワークスペース設計は、SOC だけの問題ではありません。compliance teams にとっては、データ所在地、アクセス権、保持期間、インシデント証跡、委任管理の説明責任に直結します。
特に確認すべき項目は次のとおりです。
| 観点 | 確認内容 |
|---|---|
| データ所在地 | ワークスペースのリージョンと規制要件が一致しているか |
| データ所有 | 子会社・事業部・顧客ごとの責任範囲が明確か |
| アクセス権 | 中央 SOC、地域 SOC、MSSP、監査担当者の権限が過剰でないか |
| 検出ルール | 横断ルールの結果がどのワークスペースに作成されるか説明できるか |
| インシデント証跡 | 対応履歴、担当者、クローズ理由を追跡できるか |
| 自動化 | ルールやワークブックの変更履歴が残る仕組みがあるか |
複数ワークスペースに分けると、データ分離は説明しやすくなります。一方で、横断クエリや中央管理を導入すると、「誰がどのデータを見られるのか」をより厳密に説明する必要があります。分離と可視化はトレードオフになるため、設計書には必ず例外条件を含めておくべきです。
2026年4月時点で実施したい見直しチェックリスト
Microsoft Sentinel の複数ワークスペース・複数テナント運用をしている組織は、次の順に確認すると効率的です。
| 優先度 | チェック項目 | 対象チーム |
|---|---|---|
| 高 | 単一ワークスペースで足りる環境まで分割していないか | security admins |
| 高 | Defender ポータル移行を前提にプライマリワークスペースを決めているか | security admins |
| 高 | クロスワークスペース分析ルールの作成先と通知先を把握しているか | SOC、security admins |
| 高 | Azure Lighthouse の委任範囲が最小権限になっているか | identity teams |
| 中 | 横断クエリに含めるワークスペース数が過剰でないか | detection engineers |
| 中 | ワークブックが利用者別に設計されているか | SOC、compliance teams |
| 中 | Sentinel コンテンツをリポジトリ管理しているか | security admins |
| 中 | 監査担当者が必要な証跡を確認できるか | compliance teams |
| 低 | 古いワークスペース分割理由が現在も有効か | 全チーム |
最初に着手すべきなのは、横断クエリの高度化ではありません。ワークスペースの分割理由と、インシデントの所有者を明文化することです。ここが曖昧なまま高度な検出ルールを作ると、検出後の対応が遅れます。
よくある失敗と回避策
ワークスペースを分けすぎてSOCが全体像を見失う
規制、組織、課金の都合でワークスペースを細かく分けると、各環境の責任範囲は明確になります。しかし、SOC が全体像を見られなくなると、攻撃者の横展開や複数拠点にまたがる侵害兆候を見逃す可能性があります。
回避策は、すべてを中央集約することではなく、中央 SOC が見るべき高重大度イベントや横断相関だけを定義することです。拠点単位の低重大度アラートはローカル SOC に任せ、特権アカウント侵害、複数拠点ログオン、既知 IOC の一致などは中央で検出する設計が現実的です。
クロスワークスペースルールを増やしすぎる
workspace() と union は便利ですが、横断対象が増えるほどクエリは重くなります。公式ドキュメントでも、複数ワークスペースを同一クエリで照会するとパフォーマンスに影響する可能性があり、必要な場合に限ることが推奨されています。(Microsoft Learn)
回避策は、横断ルールを「高価値な検出」に絞ることです。すべての検出を中央化するのではなく、ローカル検出と中央検出を分担します。
アラートの作成先を誤解する
クロスワークスペース分析ルールでは、アラートとインシデントはルールを定義したワークスペースに作成されます。参照先ワークスペースには表示されません。(Microsoft Learn)
回避策は、ルール作成時に「このインシデントを誰が見るのか」を明記することです。通知、Logic Apps、Teams 連携、チケット連携を使う場合も、発生元ワークスペースと対応チームを分かるようにしておく必要があります。
Defender ポータルのプライマリ設計を後回しにする
Defender ポータルでは、プライマリワークスペースとセカンダリワークスペースの役割が異なります。Microsoft Defender XDR と併用する場合、プライマリワークスペースが統合運用の中心になります。(Microsoft Learn)
回避策は、技術的に最初に接続しやすいワークスペースをプライマリにするのではなく、グローバル SOC、XDR 相関、監査、運用責任の観点からプライマリを決めることです。
次に取るべきアクション
2026年4月更新の「Extend Microsoft Sentinel across workspaces and tenants」は、Microsoft Sentinel を複数ワークスペース・複数テナントで運用する組織にとって、設計見直しの出発点になります。
まずは、現在の Sentinel 環境を次の3つに分類してください。
| 分類 | 次の対応 |
|---|---|
| 単一ワークスペースで問題ない環境 | 無理に分割せず、Defender ポータル移行と権限設計を確認する |
| 複数ワークスペースが必要な環境 | 分割理由、中央監視範囲、横断ルールの作成先を整理する |
| 複数テナントを管理する環境 | Azure Lighthouse、Defender マルチテナント管理、委任グループを設計する |
security admins は、ワークスペース構成と検出ルールの配置を確認します。identity teams は、Azure Lighthouse や Defender ポータルでの委任権限を見直します。compliance teams は、データ所在地、アクセス権、インシデント証跡の説明可能性を確認します。
Microsoft Sentinel の横断運用は、単にログをまとめて検索する機能ではありません。複数の組織、拠点、テナントをまたいで、誰が見て、誰が判断し、どこに証跡を残すのかを設計するための運用基盤です。まずはワークスペース一覧、テナント一覧、検出ルール一覧、権限一覧を棚卸しし、横断すべきものと分離すべきものを切り分けるところから始めるのが最も確実です。
コメント