Microsoft SentinelをMSSPとして複数テナント管理している場合、まず確認すべき結論は明確です。Azure Lighthouseで顧客テナントのSentinelリソースを管理できるか、必要なリソースプロバイダーが登録済みか、そしてMicrosoft Defenderポータルへの移行計画があるかを点検してください。2026年5月14日に更新されたMicrosoft Learnでは、MSSPが自社のAzureテナントから顧客のMicrosoft Sentinelリソースを管理する前提、確認手順、制限事項が整理されています。特に、Microsoft Sentinelは2027年3月31日以降Azure portalではサポートされず、Microsoft Defender portalで利用する流れになるため、単なる手順確認ではなく運用移行として捉える必要があります。(Microsoft Learn)
この記事では、Microsoft Defender／Microsoft Sentinelを運用するMSSP、SOC管理者、テナント管理者、開発・自動化担当者向けに、複数テナント管理で確認すべき設定、影響範囲、移行時の注意点を実務目線で整理します。
Microsoft Defenderのセキュリティ更新で管理者が最初に見るべきポイント
今回確認すべき中心テーマは、Defender for Endpointの端末設定変更ではありません。Microsoft Defender portal上でMicrosoft Sentinelを含む統合セキュリティ運用を行うための、MSSP向け複数テナント管理の整備です。
Microsoftの公式情報では、Azure Lighthouseを使うことで、MSSPは顧客テナントへ個別にサインインし直すことなく、自社のAzureテナントから顧客のMicrosoft Sentinelリソースを管理できると説明されています。これはSOCの運用効率を上げる一方で、権限委任、ワークスペース設計、コネクタ展開、ポータル移行の設計ミスがそのまま監視漏れにつながる領域です。(Microsoft Learn)
| 確認項目 | 公式情報で示されている要点 | 管理者が取るべき対応 |
|---|---|---|
| Azure Lighthouse | MSSPが自社テナントから顧客のMicrosoft Sentinelリソースを管理する前提になる | 顧客ごとに委任スコープ、ロール、対象サブスクリプションを棚卸しする |
| リソースプロバイダー | MSSP側と顧客側でMicrosoft.OperationalInsightsとMicrosoft.SecurityInsightsの登録確認が必要 | 未登録の場合はAzure portalから登録し、全顧客テナントで一覧化する |
| Defender portal移行 | 2027年3月31日以降、SentinelはAzure portalではサポートされずDefender portalのみになる | SOC手順書、教育資料、ブックマーク、API連携、監視フローをDefender portal前提に更新する |
| コネクタ展開 | Azure Lighthouseだけで構成された管理ワークスペースからはSentinelコネクタを展開できない | コネクタ展開担当、GDAP設定、顧客側作業の分担を事前に決める |
| 自動化・API | Defender portalでは統合インシデント管理や高度なハンティングが中心になる | チケット連携、SecurityInsights API利用条件、トリガー条件を再検証する |
対象になる組織と影響範囲
今回の確認対象は、MSSPだけではありません。複数のMicrosoft Entraテナント、Azureサブスクリプション、Microsoft Sentinelワークスペースを横断して運用している組織は影響を受けます。
具体的には、次のような環境です。
- MSSPが複数顧客のMicrosoft Sentinelを監視している
- グループ会社や海外拠点ごとにテナントが分かれている
- 顧客ごとにLog AnalyticsワークスペースやSentinelワークスペースが分かれている
- Microsoft Defender XDRとMicrosoft Sentinelのインシデントを統合して扱う予定がある
- 分析ルール、ハンティングクエリ、プレイブック、データコネクタをCI/CDで配布している
Microsoft Defender portalのMSSP向け実装ガイドでは、インシデント管理、脅威ハンティング、ワークロード管理を複数の顧客テナントにまたがって扱う統合セキュリティ運用プラットフォームとしてDefender portalが位置付けられています。つまり、今後の運用は「Azure portalでSentinelを見る」だけではなく、「Defender portalでSentinel、Defender、サードパーティのシグナルをまとめて扱う」設計に寄っていきます。(Microsoft Learn)
Azure LighthouseでMicrosoft Sentinelを複数テナント管理する基本
Azure Lighthouseは、サービスプロバイダーが顧客のAzureリソースを自社テナントから管理するための仕組みです。顧客は、どのスコープを委任するか、どの権限を許可するかを制御できます。Azure Lighthouseでは、顧客のサブスクリプションまたはリソースグループを管理テナント側のユーザー、グループ、サービスプリンシパルに委任できます。(Microsoft Learn)
MSSPがMicrosoft Sentinelを管理する場合、実務上は次の順序で考えると失敗しにくくなります。
管理対象を先に棚卸しする
Azure Lighthouseの設定前に、以下を顧客ごとに整理します。
| 棚卸し項目 | 確認する内容 | 失敗しやすいポイント |
|---|---|---|
| 顧客テナント | Microsoft EntraテナントID、契約上の管理範囲 | 顧客名だけで管理し、テナントIDの取り違えが起きる |
| Azureサブスクリプション | SentinelワークスペースがあるサブスクリプションID | 監視対象外のサブスクリプションまで委任してしまう |
| リソースグループ | Log Analyticsワークスペース、Sentinel関連リソース | サブスクリプション全体委任が不要な環境で過剰権限になる |
| Sentinelワークスペース | ワークスペース名、リージョン、用途、データ保持方針 | 顧客別・用途別の命名ルールがなく運用で混乱する |
| 運用権限 | L1、L2、開発、自動化アカウントごとの必要権限 | 個人ユーザーへ直接ロール付与して退職・異動時に残る |
| 自動化 | 分析ルール、プレイブック、Logic Apps、CI/CD | ポータル手動変更がリポジトリ配布で上書きされる |
特に重要なのは、人ではなくセキュリティグループに権限を割り当てる設計です。MicrosoftのAzure Lighthouseオンボード手順でも、可能な限り個別ユーザーではなくMicrosoft Entraユーザーグループを使うこと、最小権限の原則に従うことが推奨されています。(Microsoft Learn)
Azure Lighthouseのオンボードで確認すること
顧客をAzure Lighthouseへオンボードするには、管理側テナントと顧客テナントの両方で作業が必要です。手動でテンプレートを作成する場合、サービスプロバイダー側のテナントID、顧客側のテナントID、管理対象のサブスクリプションIDやリソースグループ名を把握しておく必要があります。(Microsoft Learn)
実務では、以下のように役割を分けると運用しやすくなります。
| 役割 | 主な権限設計 | 代表的な作業 |
|---|---|---|
| L1 SOC | 読み取り中心 | インシデント確認、一次切り分け、顧客連絡 |
| L2 SOC | Sentinel Contributor相当の操作が必要な範囲 | 調査、コメント、タスク更新、封じ込め判断 |
| コンテンツ管理者 | 分析ルール、ハンティング、ブック、ウォッチリスト管理 | ルール展開、検知ロジック更新、誤検知調整 |
| 自動化担当 | プレイブック、Logic Apps、サービスプリンシパル管理 | 自動対応、チケット連携、CI/CD |
| 権限管理者 | 委任解除やロール設計 | 顧客オンボード、オフボード、監査対応 |
注意したいのは、Azure Lighthouseのオンボードは対象スコープごとに考える必要がある点です。Microsoftの手順では、オンボードするサブスクリプションごとに個別のデプロイが必要であり、異なるサブスクリプション内の複数リソースグループをオンボードする場合も別デプロイが必要とされています。(Microsoft Learn)
リソースプロバイダー登録は最優先で確認する
Microsoft Sentinelの複数テナント管理で見落としやすいのが、リソースプロバイダーの登録状態です。
Microsoft Learnでは、複数テナントを適切に管理するには、MSSPテナントの少なくとも1つのサブスクリプションと、各顧客テナントでMicrosoft Sentinel関連のリソースプロバイダーが登録されている必要があると説明されています。確認対象はMicrosoft.OperationalInsightsとMicrosoft.SecurityInsightsです。(Microsoft Learn)
確認手順はシンプルです。
| 手順 | 操作 |
|---|---|
| 1 | Azure portalで「Subscriptions」を開く |
| 2 | 関連するサブスクリプションを選択する |
| 3 | 左側メニューの「Settings」から「Resource providers」を開く |
| 4 | Microsoft.OperationalInsightsとMicrosoft.SecurityInsightsを検索する |
| 5 | 状態がNotRegisteredなら「Register」を選択する |
ここで重要なのは、MSSP側だけ確認して終わらせないことです。顧客テナント側で未登録の場合、ワークスペースが見えない、Sentinel操作が期待通りに動かない、オンボード後の検証で手戻りが起きる可能性があります。新規顧客のオンボードチェックリストに、必ずリソースプロバイダー確認を入れてください。
管理対象テナントへアクセスできるか検証する
リソースプロバイダーの確認後は、実際に管理対象テナントのMicrosoft Sentinelワークスペースが見えるか確認します。
Microsoft Learnでは、Azure portalの「Directory + subscription」から委任されたディレクトリと、顧客のMicrosoft Sentinelワークスペースがあるサブスクリプションを選択し、その後Microsoft Sentinelを開くと、選択したサブスクリプション内のワークスペースを操作できると説明されています。(Microsoft Learn)
検証時は、単にワークスペースが表示されるかだけでは不十分です。次の観点でチェックしてください。
| 検証項目 | 確認内容 |
|---|---|
| 表示 | 顧客ごとのSentinelワークスペースが一覧に出るか |
| 読み取り | インシデント、アラート、ログ、ブックを確認できるか |
| 書き込み | コメント、タスク、分析ルール変更など必要な操作ができるか |
| 自動化 | プレイブックやLogic Apps実行に必要な権限があるか |
| 監査 | 顧客側のアクティビティログで誰が何をしたか確認できるか |
| オフボード | 契約終了時に委任解除できる運用になっているか |
顧客側が「MSSPに何が見えているか」を説明できない状態は、監査や契約更新時のリスクになります。委任スコープとロールは、契約書や運用設計書と突き合わせて管理しましょう。
Defender portal移行は2027年3月31日を期限として逆算する
今回の更新で最も見逃せないのは、Microsoft Sentinelのポータル移行です。Microsoftは、2027年3月31日以降Microsoft SentinelはAzure portalでサポートされず、Microsoft Defender portalでのみ利用可能になると明記しています。Azure portalでSentinelを使っている顧客は、Defender portalへの移行計画を開始することが推奨されています。(Microsoft Learn)
これは「URLが変わる」だけの話ではありません。SOC運用では、次のような影響が出ます。
| 影響領域 | 具体的な見直し内容 |
|---|---|
| SOC手順書 | インシデント確認、ハンティング、設定変更の画面遷移をDefender portal前提に更新する |
| 教育 | L1/L2アナリストにDefender portalでのトリアージ手順を再教育する |
| 権限 | Sentinel Reader、Sentinel Contributor、Owner、User Access Administratorなど必要権限を再確認する |
| ワークスペース設計 | プライマリワークスペースとセカンダリワークスペースの扱いを決める |
| チケット連携 | Defender側の統合インシデントキューと既存チケットシステムの同期条件を見直す |
| 自動化 | SecurityInsights APIやGraph APIを使う処理の条件分岐を検証する |
Microsoft SentinelをDefender portalへ接続する手順では、Defender portalの「System > Settings > Microsoft Sentinel > Connect a workspace」からワークスペースを接続し、プライマリワークスペースを選択します。接続後は、Defender portalの左ナビゲーションにMicrosoft Sentinelが表示され、Defender XDRを利用している場合はHome、Incidents、Advanced Huntingなどで統合されたデータを扱えます。(Microsoft Learn)
Azure Lighthouse、B2B、GDAPを混同しない
MSSPの複数テナント管理では、Azure Lighthouse、Microsoft Entra B2B、GDAPが混同されやすいです。しかし、それぞれ役割が異なります。
| 方式 | 主な用途 | 注意点 |
|---|---|---|
| Azure Lighthouse | 顧客のAzureリソース、SentinelワークスペースをMSSPテナントから管理する | Sentinelの複数テナント管理やクロステナント操作の土台になる |
| Microsoft Entra B2B | 顧客テナントへのゲストアクセス、Sentinelデータアクセス | Defender portalで複数テナントのSentinelデータを扱う場合に重要 |
| GDAP | パートナーに対する細かな委任管理、期限付き・最小権限アクセス | Microsoft Sentinelデータへのアクセス方式として万能ではない |
GDAPは、パートナーが顧客ワークロードへ最小権限かつ期限付きでアクセスするための機能です。顧客が明示的に権限を付与するため、高い権限を広く持たせる従来型の運用よりもセキュリティ要件に合わせやすい仕組みです。(Microsoft Learn)
ただし、Microsoft Defenderのマルチテナント管理要件では、Microsoft SentinelデータへのアクセスはMicrosoft Entra B2B認証で利用可能であり、GDAPは現時点でMicrosoft Sentinelデータをサポートしないと説明されています。(Microsoft Learn)
一方で、2026年5月14日更新のMicrosoft Learnでは、Azure Lighthouseだけで構成された管理ワークスペース内からMicrosoft Sentinelのコネクタを展開できず、その方法でコネクタを展開するにはGDAPも構成する必要があるとされています。(Microsoft Learn)
このため、実務では次のように整理すると安全です。
| やりたいこと | 優先して確認する仕組み |
|---|---|
| 顧客のSentinelワークスペースをMSSPテナントから管理したい | Azure Lighthouse |
| Defender portalで複数テナントのSentinelデータを扱いたい | Microsoft Entra B2B、Azure RBAC、MTO要件 |
| Defenderデータや顧客ワークロードにパートナー権限でアクセスしたい | GDAP |
| コネクタ展開までMSSP側で完結させたい | Azure Lighthouseだけで足りるかを確認し、必要に応じてGDAPや顧客側作業を設計する |
ポイントは、「GDAPを設定すればSentinelの全操作ができる」と考えないことです。アクセス方式、対象データ、操作内容ごとに必要条件を分けて確認してください。
コネクタ展開とデータ取り込みで注意すべきこと
Microsoft Sentinelの運用では、データコネクタの展開ミスが検知漏れに直結します。MSSPが顧客環境をまとめて管理する場合、既存のワークスペースを見るだけでなく、新しいデータソースを追加する権限と手順が必要です。
特に注意したいのは、Azure Lighthouseだけでは一部のコネクタ展開が完結しない点です。公式情報では、Azure Lighthouseだけで構成された管理ワークスペース内からコネクタを展開できないため、その方式で展開するにはGDAPも構成する必要があるとされています。(Microsoft Learn)
そのため、顧客オンボード時には以下を明文化しましょう。
| 項目 | 決めておくこと |
|---|---|
| コネクタの初期設定者 | MSSPが設定するのか、顧客管理者が設定するのか |
| 必要権限 | Azure RBAC、Microsoft Entraロール、GDAP、B2Bのどれが必要か |
| 変更申請 | 新しいコネクタ追加時の承認フロー |
| 検証方法 | データがLog Analyticsテーブルへ到達しているか、何分後に確認するか |
| 障害時対応 | コネクタ停止時に誰へ通知し、どのSLAで復旧するか |
顧客ごとにコネクタの種類が違う場合、共通テンプレートだけでは不十分です。Microsoft 365、Defender for Cloud、サードパーティ製品、オンプレミスログなど、データソース単位で「誰が設定し、誰が保守するか」を分けてください。
コンテンツ管理は「誰が編集するか」を先に決める
MSSP環境では、分析ルール、ハンティングクエリ、パーサー、プレイブック、ウォッチリスト、ブックなどのSentinelコンテンツを複数顧客へ展開します。MicrosoftのMSSP向けガイドでは、Defender portalのネイティブなマルチテナント配布、Microsoft Sentinel repositories、カスタムCI/CDパイプラインなど、複数の管理方法が示されています。(Microsoft Learn)
実務で重要なのは、方法の選択よりも編集権限の衝突を防ぐことです。Microsoftのガイドでも、MSSPと顧客が同じコンテンツを管理する場合、content-as-codeリポジトリからの更新がポータル上の変更を上書きする可能性があると説明されています。対策として、MSSPだけが一元管理する方式、またはMSSP管理項目に命名規則のプレフィックスを付ける方式が推奨されています。(Microsoft Learn)
おすすめの運用ルールは次のとおりです。
| 運用パターン | 向いている環境 | 注意点 |
|---|---|---|
| MSSP一元管理 | 標準化されたSOCサービスを提供する場合 | 顧客が独自に変更したい場合の申請窓口が必要 |
| 共通リポジトリ＋顧客別リポジトリ | 共通ルールと顧客固有ルールを分けたい場合 | 顧客別差分のレビュー負荷が増える |
| 顧客別リポジトリ | 高度にカスタマイズされた監視が必要な場合 | 顧客数が増えると保守コストが高い |
| ポータル手動管理 | 小規模・短期検証 | 変更履歴、再現性、横展開に弱い |
公開運用では、最低でも分析ルール名にMSSP-Common-、MSSP-CustomerA-のような接頭辞を付け、誰が管理しているルールか一目で分かる状態にしておくとトラブルを減らせます。
インシデント運用とAPI連携の見直しポイント
Defender portalでは、Microsoft Sentinel、Microsoft Defender、サードパーティソースの情報を統合したインシデントキューで扱う流れになります。MicrosoftのMSSP向けガイドでは、統合インシデントキューやアラート相関により、ポータルを切り替えずにトリアージしやすくなる一方、アナリストの再教育やSOCプロセスの更新が必要になる可能性があるとされています。(Microsoft Learn)
外部チケットシステムを使っている場合は、特に注意が必要です。Microsoftは、外部チケットシステムがアラートやインシデントを同期する場合、Microsoft Graph REST API v1.0の利用を推奨しています。また、Microsoft Sentinel SecurityInsights APIでSentinelインシデントを扱っている場合、応答本文の変更により自動化条件やトリガー条件の更新が必要になる可能性があります。(Microsoft Learn)
開発者や自動化担当者は、以下を確認してください。
| 確認対象 | 見直す内容 |
|---|---|
| チケット起票条件 | Defender統合インシデントとSentinelインシデントの重複起票がないか |
| APIレスポンス | 既存スクリプトが想定しているフィールド名、ステータス、検出元 |
| プレイブック | Defender portal移行後もトリガー条件が成立するか |
| 相関・マージ | 複数アラートが1つのインシデントに統合された場合の処理 |
| 顧客通知 | 顧客別の通知先、重大度、SLA判定が崩れないか |
特に、従来の「Sentinelのインシデント1件＝チケット1件」という前提で設計している場合は、Defender側の統合インシデント管理に合わせた再設計が必要になることがあります。
展開時に避けたい失敗パターン
複数テナント管理は、最初の設定よりも「顧客が増えた後の保守」で差が出ます。以下の失敗は現場で起きやすいため、事前にチェックリスト化しておきましょう。
| 失敗パターン | 起きる問題 | 回避策 |
|---|---|---|
| 全顧客へ一括展開する | 権限不足やコネクタ不備が広範囲に発生する | 1〜2顧客でカナリア展開してから横展開する |
| 個人アカウントへ権限付与する | 異動・退職後にアクセス管理が破綻する | Microsoft Entraのセキュリティグループへ付与する |
| Azure portal前提の手順書を残す | 2027年以降の運用で混乱する | Defender portal前提に画面、URL、手順を更新する |
| GDAPとAzure Lighthouseを同一視する | Sentinelデータやコネクタ展開の前提を誤る | 操作内容ごとに必要な委任方式を分ける |
| 顧客とMSSPが同じルールを編集する | CI/CD配布でポータル変更が上書きされる | 命名規則、管理者、変更フローを明文化する |
| API変更を後回しにする | チケット起票や自動対応が止まる | Defender portal移行前にテスト環境で連携検証する |
管理者が今すぐ実施すべきチェックリスト
Microsoft Defender／Microsoft Sentinelの複数テナント管理を安定させるには、次の順で確認すると効率的です。
- 顧客ごとのテナントID、サブスクリプションID、Sentinelワークスペースを一覧化する
- MSSP側と顧客側で
Microsoft.OperationalInsightsとMicrosoft.SecurityInsightsの登録状態を確認する - Azure Lighthouseの委任スコープ、ロール、セキュリティグループを見直す
- Azure portalではなくDefender portalでSentinelワークスペースを扱う手順を検証する
- コネクタ展開にAzure Lighthouse以外の設定が必要か確認する
- 分析ルール、プレイブック、ハンティングクエリの管理者と配布方式を決める
- 外部チケット、Graph API、SecurityInsights API、自動化トリガーを再検証する
- L1/L2アナリスト向けのトリアージ手順をDefender portal前提に更新する
今回のポイントは、単にMicrosoft Sentinelを複数テナントで表示できるかではありません。2027年3月31日以降のDefender portal前提の運用に向けて、Azure Lighthouse、B2B、GDAP、Azure RBAC、CI/CD、API連携を分解して確認することです。
まずは、管理対象テナントとワークスペースの棚卸し、リソースプロバイダー登録、Azure Lighthouse委任の確認から始めてください。そのうえで、Defender portal上で実際のインシデント確認、ハンティング、コネクタ展開、チケット連携まで一通り検証すれば、移行時の手戻りを大きく減らせます。
コメント