Microsoft Defender の「Set up Microsoft Defender multitenant management」は、複数のテナントをまたいで Microsoft Defender XDR と Microsoft Sentinel のセキュリティ運用を一元化するための初期設定ガイドです。結論から言うと、今回確認すべきポイントは「Add tenants を押すだけで終わり」ではありません。Microsoft Entra B2B、GDAP、Azure Lighthouse、各テナントのRBAC、Sentinelワークスペースの Defender ポータル接続、そして移行期限に関わる自動化・KQLの見直しまで含めて準備する必要があります。(Microsoft Learn)
特にMSSP、グローバルSOC、複数の子会社・地域テナントを持つ企業では、Microsoft Defender multitenant management を使うことで、インシデント、アラート、ケース、Advanced hunting、脆弱性情報を横断的に確認しやすくなります。一方で、アクセス権やデータ境界が自動的に緩和されるわけではないため、権限設計を誤ると「見えるはずのデータが出ない」「Sentinelだけ検索できない」「自動化が想定どおり動かない」といった問題につながります。
Microsoft Defender multitenant managementで何が変わるのか
Microsoft Defender multitenant management は、複数テナントを管理するSOC担当者や管理サービス事業者が、Microsoft Defenderポータル上で複数環境のセキュリティ情報をまとめて確認するための機能です。Microsoft Learnでは、Microsoft Defender XDR と Microsoft Sentinel in the Microsoft Defender portal を対象に、複数テナントのインシデント調査や Advanced hunting を一元的に行えると説明されています。(Microsoft Learn)
実務上の変化は、単なる画面統合ではありません。テナントごとにログインし直してインシデントを確認する運用から、管理対象テナントを横断して優先順位付けし、必要に応じて個別テナントの詳細画面へ移動する運用に変わります。
| 確認項目 | これまで起きやすかった課題 | multitenant managementで期待できること |
|---|---|---|
| インシデント確認 | テナントごとにポータルを切り替える必要がある | 複数テナントのインシデントを横断的に確認しやすくなる |
| アラート調査 | 顧客・地域・子会社単位で状況把握が遅れる | 重要度や発生元テナントを見ながらトリアージできる |
| Advanced hunting | テナントごとにKQLを実行し、結果を手作業で突き合わせる | 複数テナント・ワークスペースをまたいだ調査を設計しやすくなる |
| MSSP運用 | 顧客ごとの確認漏れ、対応遅延が起きやすい | 単一ビューで複数顧客の状況を把握しやすくなる |
| 権限管理 | 過剰権限または不足権限になりやすい | 各テナントのRBACを尊重しながら統合ビューを使える |
重要なのは、Microsoft Defender multitenant management は「権限をまとめて付与する仕組み」ではなく、「付与済みの権限で見える範囲を統合的に表示・操作する仕組み」だという点です。Microsoft Learnでも、マルチテナントユーザーが実行できる操作は、管理対象テナントが付与した権限によって決まると説明されています。(Microsoft Learn)
影響範囲：誰が確認すべきか
今回の更新ポイントを優先的に確認すべきなのは、次のような環境です。
- 複数のMicrosoft Entraテナントを持つグローバル企業
- 子会社、地域法人、買収先企業のセキュリティ運用を本社SOCで統合したい組織
- Microsoft Defender XDR と Microsoft Sentinel を併用している環境
- MSSPとして複数顧客のMicrosoft Defender環境を管理している事業者
- Sentinelワークスペースを複数テナントまたは複数ワークスペースで運用している組織
- Azureポータル中心のMicrosoft Sentinel運用からDefenderポータルへ移行中の組織
商用クラウドだけでなく、GCC、GCC High、DoDなどの政府系クラウドでも利用可能なシナリオが示されており、クロスクラウド管理にも関係します。ただし、クラウド種別やテナント間の信頼設定によって利用できる範囲が変わるため、グローバル運用ではデータ所在地、プライバシー、ロール設計を事前に確認する必要があります。(Microsoft Learn)
設定前に確認すべき前提条件
Microsoft Defender multitenant management を設定する前に、少なくとも次の前提条件を確認します。ここを飛ばすと、テナントを追加できてもデータが表示されない、Sentinelの横断検索だけ動かない、特定のアナリストだけ操作できない、といった問題が起きやすくなります。
| 項目 | 確認する内容 | 実務上の注意点 |
|---|---|---|
| Microsoft Defender XDRの前提条件 | 対象テナントがDefender XDRの要件を満たしているか | ライセンス、サービス有効化、ポータルアクセスを確認する |
| マルチテナントアクセス | DefenderデータにはGDAPまたはMicrosoft Entra B2Bを使用 | MSSPはGDAP、企業グループ内はB2Bを検討しやすい |
| Microsoft Sentinelデータ | Sentinelデータの横断利用にはB2BやAzure Lighthouseの設計が重要 | GDAPだけでSentinelデータまで扱えると決めつけない |
| Azure Lighthouse | Sentinelのクロステナントクエリやworkspace()演算子利用で必要になる場合がある | 特に別テナントのセカンダリワークスペースを検索する場合に確認する |
| テナントごとのRBAC | 各テナントで必要なロールが割り当てられているか | 統合ビュー側ではなく、個別テナント側の権限不足が原因になることが多い |
| Sentinelワークスペース | Microsoft SentinelワークスペースがDefenderポータルにオンボードされているか | SIEMデータを含めたい場合は必須の確認項目 |
| MFA trust | テナントごとの多要素認証信頼設定 | 設定不足により一部データが欠落する可能性がある |
Microsoft Learnでは、Defenderデータの表示・管理にはGDAPまたはMicrosoft Entra B2B認証が必要であり、SentinelデータのクロステナントクエリにはAzure Lighthouseの設定が必要になる例が示されています。また、Microsoft SentinelデータへのアクセスについてはB2B認証が示され、GDAPの扱いは制限やプレビュー状況を含めて確認が必要です。(Microsoft Learn)
初期設定の流れ
Microsoft Defender multitenant management の初期設定は、画面上はシンプルです。ただし、実務では「事前準備」「アクセス確認」「テナント追加」「運用検証」を分けて進めると失敗しにくくなります。
| 手順 | 作業内容 | 確認ポイント |
|---|---|---|
| 1 | 管理対象テナントを棚卸しする | テナントID、表示名、契約種別、担当チーム、Sentinelワークスペース有無を一覧化する |
| 2 | アクセス方式を決める | DefenderデータはGDAPまたはB2B、SentinelデータはB2BやAzure Lighthouseを含めて設計する |
| 3 | 各テナントで権限を確認する | Security Reader、Security Operator、Security Administratorなど、必要な操作に応じてロールを確認する |
| 4 | SentinelワークスペースをDefenderポータルに接続する | SIEMデータを統合ビューに含める場合は、対象ワークスペースを事前にオンボードする |
| 5 | Microsoft Defender multitenant managementにサインインする | 初回利用時は管理したいテナントを追加する |
| 6 | Add tenantsから対象テナントを選択する | 追加後、ナビゲーションにマルチテナント管理機能が表示されるか確認する |
| 7 | インシデント、アラート、Advanced huntingをテストする | 代表的なテナントで表示・検索・操作権限を検証する |
| 8 | テナントグループを設計する | 顧客別、地域別、事業部別、本番・検証別などで絞り込みやすくする |
公式手順では、初回利用時にMicrosoft Defender multitenant managementへサインインし、Add tenantsから管理対象テナントを選択して追加します。追加後、利用可能なマルチテナント管理機能がナビゲーションバーに表示されます。なお、Microsoft Learnではマルチテナントビューの対象テナント数に現在100テナントの制限があると説明されています。(Microsoft Learn)
テナントグループの使いどころ
2026年6月下旬の関連情報として特に実務上重要なのが、テナントグループです。テナントグループは、管理対象テナントを名前付きの集合として整理し、表示対象を切り替えるための機能です。たとえば「APAC拠点」「欧州子会社」「重要顧客A」「金融業界顧客」「本番環境」などの単位でグループ化できます。(Microsoft Learn)
注意したいのは、以前の「tenant groups」がコンテンツ配布用途で使われていた文脈とは意味が変わっている点です。Microsoft Learnでは、従来のコンテンツ配布用途は「distribution profiles」に整理され、現在のtenant groupsはマルチテナントビューの切り替え用グループを指すと説明されています。(Microsoft Learn)
テナントグループ設計の具体例
| グループ設計 | 向いている組織 | メリット |
|---|---|---|
| 地域別 | グローバル企業 | タイムゾーンや地域SOCごとに対応しやすい |
| 顧客別 | MSSP | 契約範囲やSLAごとの監視に向く |
| 重要度別 | 大規模組織 | 重要システムを持つテナントを優先監視できる |
| 事業部別 | 持株会社・複数子会社 | 管理責任や費用配賦と合わせやすい |
| 本番・検証別 | セキュリティ運用チーム | 検証テナントのノイズを本番監視から切り離せる |
ただし、テナントグループは権限を増やす機能ではありません。ユーザーはB2BまたはGDAPなどでアクセスできるテナントだけを参照できます。グループに含まれていても、そのユーザーに権限がなければ対象データは見えません。(Microsoft Learn)
Microsoft Sentinel移行期限との関係
今回の話はMicrosoft Defenderだけで完結しません。Microsoft SentinelをAzureポータル中心で運用している組織は、Defenderポータルへの移行計画と合わせて確認する必要があります。
Microsoft Learnの「What’s new in Microsoft Sentinel」では、Microsoft SentinelはMicrosoft Defenderポータルで一般提供されており、2027年3月31日以降はAzureポータルではサポートされず、Microsoft Defenderポータルでのみ利用可能になると案内されています。(Microsoft Learn)
また、2026年7月1日以降の重要な変更として、Microsoft SentinelのアカウントエンティティにおけるAccount Nameの扱いが標準化され、フルUPNがマップされた場合でもAccount NameはUPNプレフィックスになると説明されています。これにより、AccountNameに[email protected]のようなフルUPNが入る前提で組まれた自動化、Logic Appsプレイブック、KQL、ワークブック、カスタム連携は見直しが必要です。(Microsoft Learn)
管理者が意識すべき期限
| 日付 | 内容 | 取るべき対応 |
|---|---|---|
| 2026年7月1日以降 | Account NameがUPNプレフィックス中心の扱いに標準化 | AccountName == "[email protected]"のような条件を見直し、UPNプレフィックスやUPNSuffixを使う |
| 2027年3月31日以降 | Microsoft SentinelはAzureポータルでサポートされず、Defenderポータルでのみ利用可能 | Sentinel運用、SOC手順、権限、プレイブック、API連携をDefenderポータル前提に移行する |
2026年7月時点でまだAccount Name変更への対応を確認していない場合は、移行計画とは別に優先対応が必要です。特にServiceNowなどの外部チケット連携、Logic Appsの条件分岐、KQLの検知ロジック、ユーザー名をキーにした通知処理は、実データでテストしてください。
Defenderポータル移行で変わる運用ポイント
Microsoft SentinelをDefenderポータルへ移行すると、見た目の場所だけでなく、データコネクタ、インシデント相関、自動化、API応答の一部にも影響があります。Microsoft Learnでは、Defenderポータルへの移行自体は非E5ユーザーにも追加費用なしで提供され、Sentinelの利用は従来どおり消費量に基づいて課金されると説明されています。(Microsoft Learn)
一方で、Microsoftセキュリティ製品からのアラート取り込みは、従来の個別セキュリティ製品コネクタではなくMicrosoft Defender XDRコネクタ経由になるなど、運用上の見直しが必要です。複数ワークスペース環境では、Defender XDRコネクタはプライマリワークスペースに接続され、重複防止のため一部のスタンドアロンコネクタがセカンダリワークスペースで自動的に切断される場合があります。(Microsoft Learn)
移行時に壊れやすい設定
| 対象 | 起きやすい問題 | 確認方法 |
|---|---|---|
| 自動化ルール | 条件に使っているフィールドが変わり、想定どおり実行されない | 代表的なインシデントでトリガー条件を再テストする |
| Logic Appsプレイブック | AccountNameやインシデント説明などの参照先が変わる | 実行履歴と入力JSONを比較する |
| 外部チケット連携 | インシデントURL、プロバイダー名、説明フィールドの扱いが変わる | ServiceNowやJiraなどの連携項目を再マッピングする |
| KQLクエリ | ユーザー名やワークスペース参照の前提が崩れる | 本番適用前に非本番ワークスペースで検証する |
| Microsoft系コネクタ | 重複防止のため接続状態やアラート流入先が変わる | プライマリワークスペースとセカンダリワークスペースの流入状況を確認する |
| Fusion・相関 | Defender XDR側の相関エンジンによりインシデントのまとまり方が変わる | SOCのトリアージ手順を更新する |
Defenderポータルでは、インシデントの相関や統合がMicrosoft Defender XDRのエンジンで処理されます。そのため、従来のMicrosoft Sentinel側で想定していた「1つの分析ルールにつき1つのインシデント」という考え方が、そのまま当てはまらない場面があります。自動化条件にインシデント名を使っている場合は、分析ルール名やタグなど、より安定した条件に置き換えるのが安全です。(Microsoft Learn)
設定変更で失敗しやすいポイント
テナント追加と権限付与を混同する
Add tenantsでテナントを追加しても、そのユーザーに必要な権限がなければデータは表示されません。特にMSSPでは、Partner Center上で顧客が見えていることと、Defenderポータルで必要な操作ができることは別物です。各テナントで実際にDefenderポータルへサインインし、インシデント、アラート、Advanced hunting、設定画面のどこまで操作できるか確認してください。
SentinelデータをGDAPだけで扱えると思い込む
DefenderデータとSentinelデータでは、必要なアクセス設計が異なります。DefenderデータはGDAPまたはB2Bを使えますが、Sentinelデータの横断検索や複数ワークスペース検索ではB2BやAzure Lighthouseが重要になります。workspace()演算子を使う高度な検索や分析ルールを設計する場合は、Lighthouseの委任範囲も確認してください。(Microsoft Learn)
プライマリワークスペースを軽く決めてしまう
Microsoft SentinelをDefenderポータルで使う場合、テナントごとに1つのプライマリワークスペースと複数のセカンダリワークスペースを接続できます。プライマリワークスペースはDefender XDRとの相関やMicrosoft系アラートの取り込みに関わるため、「最も重要なワークスペース」「SOCの主運用ワークスペース」「Microsoft系アラートを集約したいワークスペース」を基準に慎重に選ぶべきです。(Microsoft Learn)
100テナント制限を後から知る
Microsoft Learnでは、Microsoft Defender multitenant viewには現在100のターゲットテナント制限があるとされています。大規模MSSPや多数の子会社を持つグローバル企業では、全テナントを1人の担当者が常時見る設計ではなく、担当範囲、地域、重要度、契約単位で運用を分ける設計が必要です。(Microsoft Learn)
管理者向けチェックリスト
公開前、移行前、または本番運用前に、次の項目を確認してください。
- [ ] 管理対象テナントの一覧を作成した
- [ ] 各テナントのアクセス方式をGDAP、B2B、Azure Lighthouseのどれで実現するか整理した
- [ ] DefenderデータとSentinelデータで必要な権限の違いを確認した
- [ ] 各テナントで実際にDefenderポータルへサインインできることを確認した
- [ ] SentinelワークスペースがDefenderポータルにオンボード済みか確認した
- [ ] プライマリワークスペースとセカンダリワークスペースの役割を整理した
- [ ] Microsoft系セキュリティコネクタの重複や切断影響を確認した
- [ ]
AccountNameを使うKQL、プレイブック、外部連携を点検した - [ ] インシデントURL、provider名、説明フィールドを使う連携を再テストした
- [ ] テナントグループを地域、顧客、重要度などの運用単位で設計した
- [ ] 100テナント制限を前提に担当範囲を分けた
- [ ] SOCアナリスト向けにDefenderポータルでのトリアージ手順を更新した
- [ ] Azureポータル中心のSentinel運用からDefenderポータル中心の運用へ移行計画を作成した
実務でのおすすめ導入順序
いきなり全テナントを追加するのではなく、段階的に進めるのが安全です。
| フェーズ | 対象 | 目的 |
|---|---|---|
| PoC | 代表的な1〜3テナント | アクセス方式、表示内容、Advanced huntingの動作を確認する |
| パイロット | 1地域または1顧客群 | SOC手順、権限、テナントグループ設計を検証する |
| 部分展開 | 重要度の高いテナントから順次 | インシデント対応の優先度が高い環境を先に統合する |
| 全体展開 | 管理対象全体 | 運用ルール、監査、定例レビューを標準化する |
最初のPoCでは、あえて「権限が不足しているユーザー」「Sentinelワークスペースが未接続のテナント」「セカンダリワークスペースを持つテナント」を含めると、運用開始後のトラブルを早めに発見できます。
よくある疑問
Microsoft Defender multitenant managementを有効化すると、全テナントのデータが自動的に見えるようになりますか？
自動的には見えません。管理対象テナント側で付与された権限、B2BやGDAPの状態、Sentinelワークスペースの接続状態によって表示できるデータが決まります。統合ビューは便利ですが、権限境界をなくすものではありません。
Microsoft Sentinelを使っていない場合でも関係ありますか？
Microsoft Defender XDRだけを複数テナントで管理している場合も関係あります。ただし、SIEMデータ、複数ワークスペース、Azure Lighthouse、Sentinel移行期限に関する論点は、Microsoft Sentinelを使っている組織ほど重要です。
既存のAzureポータル上のSentinel環境はすぐ使えなくなりますか？
Microsoft Learnでは、2027年3月31日以降はMicrosoft SentinelがAzureポータルでサポートされず、Microsoft Defenderポータルでのみ利用可能になると案内されています。そのため、すぐに全機能が停止するというより、期限までに運用、権限、自動化、API連携をDefenderポータル前提へ移す計画が必要です。(Microsoft Learn)
テナントグループを作れば100テナント制限を回避できますか？
テナントグループは表示対象を整理する機能であり、公式に示されているターゲットテナント数の制限そのものをなくす機能ではありません。大規模環境では、担当者、地域、顧客単位で管理範囲を分ける設計を検討してください。
まとめ：まずは権限、Sentinel、期限の3点を確認する
Microsoft Defender の「Set up Microsoft Defender multitenant management」は、複数テナントのセキュリティ運用をDefenderポータルへ集約するための重要な設定情報です。導入効果が大きい一方で、成功の鍵はポータル上の追加操作ではなく、事前の権限設計とSentinel移行準備にあります。
まず行うべきことは、管理対象テナントとSentinelワークスペースを一覧化し、各テナントでB2B、GDAP、Azure Lighthouse、RBACがどう設定されているかを確認することです。そのうえで、1〜3テナントを使って小さく検証し、インシデント表示、アラート操作、Advanced hunting、テナントグループ、自動化ルールをテストします。
特にMicrosoft Sentinelを利用している組織では、2026年7月1日以降のAccount Name標準化と、2027年3月31日以降のAzureポータルサポート終了を前提に、KQL、Logic Apps、外部チケット連携、SOC手順を早めに見直してください。マルチテナント管理は、設定すれば終わりの機能ではなく、グローバルなセキュリティ運用を標準化するための運用基盤として設計することが重要です。
コメント