Microsoft Sentinel / Microsoft Defender delegated access は、MSSPや複数テナントを管理するSOCチームにとって、単なる「権限設定の話」ではありません。結論から言うと、SIEMとXDRがMicrosoft Defenderポータルに統合される流れの中で、誰が、どの顧客テナントに、どの範囲で、どのポータルからアクセスできるかを設計できないと、監視・調査・インシデント対応そのものが止まります。
2026年4月16日時点の更新では、Microsoft SentinelとMicrosoft Defenderの統合運用において、GDAP（Granular Delegated Admin Privileges）が委任アクセス計画の重要な選択肢として扱われるようになりました。Microsoftは、SentinelとDefenderの統合が進む中で、MSSPや複雑なマルチテナント組織にとって、Entra IDとSentinelのAzure Resource Manager管理をまたぐスケーラブルな委任アクセスモデルの不足が大きな障壁になっていると説明しています。(TECHCOMMUNITY.MICROSOFT.COM)
この記事では、Microsoft Sentinel / Microsoft Defender delegated access の最新動向を整理し、MSSP、SOCプラットフォーム管理者、パートナーセキュリティチームが今すぐ見直すべき設計ポイントを実務目線で解説します。
Microsoft Sentinel / Microsoft Defender delegated accessで何が問題になるのか
Microsoft SentinelはSIEM、Microsoft Defender XDRはXDRとして使われます。従来は、SentinelのワークスペースやLog Analytics、Defender XDR、Microsoft Entra ID、Azure Lighthouse、B2B、RBACをそれぞれ別々に考えれば運用できる場面もありました。
しかし、Microsoft SentinelがDefenderポータル側に統合され、インシデント管理、ハンティング、アラート調査、ワークスペース管理を横断的に扱うようになると、権限モデルの分断がそのまま運用の詰まりになります。Microsoft Learnでも、SentinelをDefenderポータルに接続すると、Defender XDRが有効な環境ではHome、Incidents、Advanced HuntingなどでSentinelとDefender XDRのデータが統合表示されると説明されています。(Microsoft Learn)
つまり、現場で起きる問題は次のようなものです。
| 現場の症状 | 起きていること | 運用への影響 |
|---|---|---|
| 顧客AのDefenderインシデントは見えるが、Sentinelのクエリ結果が見えない | Defender側の権限とSentinelワークスペース側の権限がそろっていない | 調査が途中で止まる |
| Azure Lighthouseでは管理できるがDefenderポータル側で権限が足りない | Azure RBACとDefender / Entra側のアクセス管理が分かれている | ポータル移行時に運用手順が崩れる |
| アナリストごとに顧客テナントの見え方が違う | グループ設計、RBAC、委任関係の標準化が不足している | 引き継ぎ・24時間運用が不安定になる |
| 顧客承認が都度必要でオンボーディングが進まない | 委任アクセスの申請・承認・記録の流れが設計されていない | 新規顧客のSOC移行が遅れる |
| 最小権限にしたいが、結局強い管理者権限を渡している | 役割ごとの権限分解ができていない | 監査・コンプライアンスリスクが増える |
特にMSSPでは、1社の設定ミスでは済みません。10社、50社、100社と顧客テナントが増えるほど、委任アクセスの不整合はアナリストの生産性を落とし、SLAやインシデント初動にも影響します。
2026年4月16日の更新ポイント：GDAPがSentinel / Defender統合運用の計画に入ってきた
2026年4月16日時点の更新で注目すべきなのは、GDAPがCSP向けの限定的な文脈だけでなく、Microsoft SentinelとMicrosoft Defenderの統合運用における委任アクセス設計の中心要素として扱われ始めた点です。
Microsoft Tech Communityの投稿では、SentinelとDefenderが統合されたエクスペリエンスへ収束する中で、MSSPや大規模なマルチテナント組織が、包括的でスケーラブルな委任アクセスモデルの不足に直面していると説明されています。さらに、GDAPの拡張により、CSP以外を含むSentinelおよびDefenderの顧客が、Microsoft Defenderポータルから安全で細かな委任アクセス関係を確立できるようになるとされています。(TECHCOMMUNITY.MICROSOFT.COM)
Microsoft Learnの「governance relationships」ドキュメントでも、この機能はプレビューとして説明されており、MTO（multitenant organizations）やMSSPが、Microsoft Defenderポータルを通じて顧客テナントへの委任アクセスを管理するための仕組みとして位置付けられています。(Microsoft Learn)
ここで重要なのは、GDAPが「魔法の単一権限」になるわけではないことです。実務上は、次のように理解すると失敗しにくくなります。
| 項目 | 実務上の意味 |
|---|---|
| GDAP | テナント間で管理権限を委任するための関係性と承認モデル |
| Governance relationship | 管理する側のテナントと管理される側のテナントを結ぶ方向性のある関係 |
| Defender unified RBAC | Microsoft Defenderポータル内の権限を統合的に管理する仕組み |
| Azure RBAC / Sentinelロール | Log AnalyticsワークスペースやSentinelリソースに対する権限 |
| Remote tenant group | 管理側テナントのセキュリティグループを、管理対象テナント側で権限割り当てに使う考え方 |
Microsoft Learnでは、Governance relationshipのテンプレートで管理側テナントのセキュリティグループとEntra組み込みロールを定義し、承認後にそのグループが管理対象テナントで権限を受け取る流れが説明されています。Sentinelについては、関係テンプレートで使ったセキュリティグループを「remote tenant groups」として管理対象テナント側のAzure Resource Managerリソースに割り当て、Sentinel管理機能を有効にする流れが示されています。(Microsoft Learn)
なぜ統合SIEM/XDRの委任アクセスは“本当の運用ブロッカー”になるのか
アナリストの業務はポータル単位ではなくインシデント単位で進む
SOCアナリストは、「今日はDefenderだけを見る」「今日はSentinelだけを見る」という動き方をしません。実際には、インシデントを起点に、エンドポイント、ID、メール、クラウド、ログ、KQLクエリ、プレイブック、チケットを横断します。
そのため、Defenderポータル上でインシデントを開けても、関連するSentinelテーブルをクエリできない、ワークスペースを選択できない、ハンティング結果を保存できない、という状態は致命的です。これはUIの不便さではなく、調査の断絶です。
権限が分断されると、SLAよりも先に運用手順が壊れる
MSSPでは、顧客ごとに契約範囲が異なります。
たとえば、次のような違いがあります。
| 顧客タイプ | MSSPに求められる権限 |
|---|---|
| 監視のみの顧客 | インシデント、アラート、ログの読み取り |
| 一次対応まで委託する顧客 | インシデント更新、コメント、ステータス変更、抑制判断 |
| 検知ルール運用も委託する顧客 | 分析ルール、Automation rules、Content hub、Watchlistの管理 |
| フルマネージドSOC顧客 | Sentinel設定、Defender設定、コネクタ、プレイブック連携まで含む管理 |
これをすべて同じ管理者権限で処理すると、監査上の説明が難しくなります。一方で、細かく分けすぎてアナリストが必要な操作をできない状態になると、初動対応が遅れます。
だからこそ、Microsoft Sentinel / Microsoft Defender delegated accessでは、単に「アクセスできるか」ではなく、業務ロールごとに必要十分な権限を再現できるかが重要になります。
ポータル移行のタイムラインも無視できない
Microsoftは、Microsoft SentinelがMicrosoft Defenderポータルで一般提供されており、2027年3月31日以降はAzureポータルでサポートされず、Defenderポータルのみで利用可能になると案内しています。(Microsoft Learn)
これは、MSSPにとって「いつか対応すればよい移行」ではありません。Azureポータル中心の運用、Azure Lighthouse中心の手順、Defenderポータル上のマルチテナント管理、Unified RBAC、GDAPをどう組み合わせるかを、今から設計しなければなりません。
これまでの委任アクセスモデルを整理する
Microsoft Sentinel / Microsoft Defender delegated accessを設計するには、まず既存モデルの役割を分けて考える必要があります。
| モデル | 主な用途 | 向いている場面 | 注意点 |
|---|---|---|---|
| Azure Lighthouse | AzureリソースやSentinelワークスペースのマルチテナント管理 | 既存のSentinel運用、Azure RBACベースの管理 | Defenderポータル側の権限とは別に考える必要がある |
| Microsoft Entra B2B | 外部ユーザーを顧客テナントに招待してアクセスさせる | 個別顧客に深く関与する運用、例外対応 | ユーザー管理が増え、MSSP大規模運用では煩雑になりやすい |
| GDAP | テナント間の細かな委任管理 | MSSP、パートナー、マルチテナント組織の標準化 | プレビュー機能や対応範囲を事前確認する必要がある |
| Defender unified RBAC | Defenderポータル内の権限管理 | Defender XDR、Sentinel in Defenderの権限制御 | ワークロードごとの有効化や既存RBACとの関係に注意 |
| Azure RBAC / Sentinelロール | Log Analyticsワークスペース、Sentinelリソースの操作 | KQL、インシデント、ルール、ワークスペース管理 | Sentinel側の操作には引き続き重要 |
Microsoft Defender unified RBACは、複数のセキュリティソリューションにまたがる権限管理を中央で行うモデルです。Microsoft Learnでは、Microsoft Sentinelについても、DefenderポータルにオンボードされたSentinelワークスペースの統合アクセス管理をプレビューとしてサポートすると説明されています。ただし、SentinelのDefenderポータル体験は、URBACに加えてARMロールと権限も尊重すると明記されています。(Microsoft Learn)
この点は非常に重要です。つまり、Defender unified RBACだけを整備しても、Sentinelワークスペース側のAzure RBACが不足していれば、期待どおりに操作できない可能性があります。
GDAPを使った新しい委任アクセスの考え方
3ステップの承認モデルで、勝手な委任を防ぐ
Microsoftの説明では、GDAP拡張の委任アクセスは、管理対象テナントと管理側テナントの明示的な承認を必要とするハンドシェイク型のモデルとして設計されています。Tech Communityの投稿では、管理対象テナントが関係を開始し、管理側テナントが必要な権限を含むアクセス要求を作成し、最後に管理対象テナントが承認する流れが説明されています。(TECHCOMMUNITY.MICROSOFT.COM)
Microsoft Learnでも、設定プロセスは大きく次の流れで示されています。(Microsoft Learn)
| 手順 | 実施する側 | 内容 |
|---|---|---|
| 管理対象テナントが招待を送る | 顧客側または管理される側 | Defenderポータルで委任アクセスの招待を開始 |
| 管理側テナントがアクセス要求を作成 | MSSPまたは親組織側 | 必要なEntraロールと対象セキュリティグループを含むテンプレートを作成 |
| 管理対象テナントが承認する | 顧客側または管理される側 | 要求内容を確認し、承認または拒否 |
| Sentinel権限を割り当てる | 管理対象テナント側 | remote tenant groupにSentinel / Log Analytics側の権限を付与 |
このモデルの利点は、MSSPが一方的に権限を取得できないことです。顧客側が、どの管理側テナントに、どの権限を許可したかを把握できます。Microsoft GraphのTenant Governance APIの説明でも、governance relationshipは管理側テナントと管理対象テナントを結ぶ方向性のある接続であり、GDAP技術により、ローカルアカウントやB2Bアカウントを作らずに管理できると説明されています。(Microsoft Learn)
Sentinelでは「GDAPを作ったら終わり」ではない
実務で最も誤解されやすいのがここです。
GDAP関係を作成しても、それだけでSentinelのすべての操作が自動的に許可されるわけではありません。Microsoft Learnでは、関係テンプレートで使ったセキュリティグループを管理対象テナント側のremote tenant groupとして扱い、Log AnalyticsワークスペースのAccess Control（IAM）からMicrosoft Sentinel Contributorなどのロールを割り当てる手順が示されています。(Microsoft Learn)
したがって、運用設計では次の2層を分けて確認してください。
| レイヤー | 確認すべきこと |
|---|---|
| テナント間の委任関係 | GDAP / governance relationshipが成立しているか |
| Sentinelリソースへの操作権限 | remote tenant groupにLog Analytics / Sentinelロールが割り当てられているか |
この2つを混同すると、「委任関係は成立しているのに、アナリストがSentinelを操作できない」という典型的な障害になります。
MSSPが見直すべき権限設計の実務ポイント
まず業務ロールから逆算する
最初に決めるべきなのは、製品側のロール名ではなく、SOC内の業務ロールです。
たとえば、次のように分けます。
| SOC内の役割 | 必要な操作 | 権限設計の方向性 |
|---|---|---|
| Tier 1アナリスト | インシデント確認、アラート確認、基本クエリ | 読み取り中心。更新操作は最小限 |
| Tier 2アナリスト | ハンティング、インシデント更新、証跡確認 | クエリ実行、インシデント操作、必要に応じた限定的な変更 |
| Detection Engineer | 分析ルール、KQL、Content hub、Watchlist | 検知コンテンツ管理に必要な書き込み権限 |
| SOC Platform Admin | ワークスペース、コネクタ、RBAC、統合設定 | 管理操作に限定した強い権限 |
| Customer Success / Reporting | ダッシュボード、レポート確認 | 読み取り専用。調査権限とは分離 |
MSSPでありがちな失敗は、「全員をSecurity Administrator相当にしてから、運用で気を付ける」という設計です。短期的には楽ですが、顧客監査、内部統制、退職者対応、委託範囲の説明で破綻します。
顧客単位ではなく「契約メニュー単位」でテンプレート化する
顧客ごとにゼロから権限を作ると、数十社を超えた時点で管理不能になります。おすすめは、契約メニューに合わせてアクセスパターンをテンプレート化することです。
例として、次のように分けます。
| テンプレート名 | 想定契約 | 含める権限の考え方 |
|---|---|---|
| Monitoring-Read | 監視・通知のみ | インシデント、アラート、基本ログの読み取り |
| Incident-Operate | 一次対応込み | インシデント更新、所有者変更、コメント、調査 |
| Detection-Manage | 検知ルール運用込み | 分析ルール、コンテンツ、Watchlist、ハンティング |
| Platform-Admin | フルマネージド | コネクタ、ワークスペース、権限、統合設定を限定メンバーに付与 |
この粒度にしておくと、新規顧客オンボーディング時に「どの権限が必要か」を毎回議論せずに済みます。顧客説明もしやすくなり、承認フローも短縮できます。
セキュリティグループの条件を事前に確認する
Microsoft Learnでは、関係テンプレート作成時にセキュリティグループが表示されない場合の原因として、サポートされるグループ条件を満たしていないことが挙げられています。条件として、SecurityEnabledがtrue、IsAssignableToRoleがtrue、Microsoft 365グループではないことが示されています。(Microsoft Learn)
これは地味ですが、オンボーディング現場ではよく詰まるポイントです。
特に避けるべきなのは、既存のMicrosoft 365グループやTeams用グループをそのままSOC権限管理に流用することです。委任アクセス用のグループは、次のように最初から目的別に作る方が安全です。
sec-soc-tier1-readers
sec-soc-tier2-operators
sec-soc-detection-engineers
sec-soc-platform-admins
sec-soc-breakglass-review名前に「顧客名」を入れるか「役割名」を入れるかは運用規模によります。少数顧客なら顧客別グループでも管理できますが、MSSPとして拡張するなら、顧客別テンプレートと役割別グループの対応表を持つ方が整理しやすくなります。
導入前に作るべきアクセス設計シート
GDAPやDefender unified RBACの設定画面を開く前に、最低限、次の情報を表にしてください。
| 確認項目 | 記入例 | なぜ必要か |
|---|---|---|
| 顧客テナントID | xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx | 委任関係の対象を誤らないため |
| 管理側テナントID | MSSPのEntraテナントID | governance relationshipの方向を明確にするため |
| 対象ワークスペース | law-prod-sentinel-01 | Sentinel権限割り当ての対象を特定するため |
| Defenderポータル接続状況 | 接続済み / 未接続 | 統合運用の前提を確認するため |
| Primary workspace | あり / なし / 変更予定 | Advanced Huntingや統合表示の影響を確認するため |
| 契約範囲 | Monitoring / Incident / Full SOC | 権限テンプレートを選ぶため |
| SOCロール | Tier1 / Tier2 / Admin | 人に直接権限を付けないため |
| 承認者 | 顧客側Security Admin | 承認待ちで止まるのを防ぐため |
| 監査ログ確認方法 | Entra audit logs / Defender audit | 後から説明できる状態にするため |
このシートがないまま設定すると、あとで「なぜこのMSSPグループにこの権限があるのか」を説明できなくなります。特にグローバル顧客を扱う場合、地域、事業部、規制要件によって委任範囲が変わるため、設計書は運用品質そのものです。
既存のAzure Lighthouse運用からどう移行を考えるべきか
すでにAzure Lighthouseで複数顧客のSentinelを管理しているMSSPは多いはずです。Microsoft Learnでも、Azure Lighthouseを使うMSSPは、自社Azureテナントから顧客のMicrosoft Sentinelリソースを直接管理できると説明されています。(Microsoft Learn)
ただし、Defenderポータルへの統合が進むと、Azure Lighthouseだけで完結する運用から、Defenderポータル、Unified RBAC、GDAP、Sentinelワークスペース権限を組み合わせる運用へ移っていきます。
移行時は、いきなり全顧客を切り替えるのではなく、次の順序がおすすめです。
| フェーズ | やること | 成功基準 |
|---|---|---|
| 棚卸し | 顧客ごとのLighthouse、B2B、GDAP、RBACを一覧化 | 誰がどの顧客に何でアクセスしているか分かる |
| パイロット | 1〜2社でDefenderポータル中心の委任アクセスを検証 | インシデント確認からKQL調査まで通しで動く |
| 権限テンプレート化 | Tier別・契約別にグループとロールを定義 | 新規顧客に再利用できる |
| 運用手順更新 | SOCランブック、オンボーディング手順、退職者対応を更新 | アナリストが迷わず使える |
| 監査確認 | 顧客側・MSSP側のログ確認手順を整備 | 顧客に説明できる |
| 段階展開 | 顧客セグメントごとに展開 | 例外が管理表に残る |
移行の目的は「新機能を使うこと」ではありません。目的は、アナリストがDefenderポータル上で、契約範囲に応じた調査・対応を止まらずに実行できるようにすることです。
よくある失敗と回避策
GDAPだけでSentinelのKQLまで使えると思い込む
GDAPはテナント間の委任関係を作るうえで重要ですが、Sentinelのデータやワークスペース操作には、Log AnalyticsワークスペースやSentinelリソース側の権限が関係します。
回避策は、設定テストを「ログインできるか」ではなく、業務シナリオで行うことです。
たとえば、Tier 2アナリスト用アカウントで次を確認します。
| テスト項目 | 確認内容 |
|---|---|
| インシデント表示 | 顧客テナントのインシデントが見えるか |
| Advanced Hunting | 必要なテーブルに対してクエリできるか |
| Sentinelログ検索 | Log Analytics由来のデータを参照できるか |
| インシデント更新 | 契約範囲内でステータスやコメントを更新できるか |
| 検知ルール編集 | Detection Engineerだけが変更できるか |
| 権限不足時の挙動 | 想定外の顧客データが見えていないか |
既存の管理者ロールをそのまま横流しする
Global AdministratorやSecurity Administratorのような強い権限は便利ですが、MSSPの通常運用に広く配るべきではありません。MicrosoftもGDAPについて、Zero Trustに基づく最小権限アクセスを実現する機能として説明しています。(Microsoft Learn)
回避策は、日常業務ロールと緊急管理ロールを分けることです。
通常のTier 1 / Tier 2アナリストには必要最小限の権限を付与し、強い管理権限はSOC Platform Adminやbreak-glass用に限定します。さらに、強い権限を使った場合は、チケット番号、作業理由、承認者、作業時間を残す運用にします。
顧客承認フローを技術チームだけで進めようとする
委任アクセスは、技術設定であると同時に、顧客との合意事項です。顧客側の承認者が誰か、どの権限を許可するのか、契約上どこまでMSSPが操作できるのかが曖昧だと、設定途中で止まります。
回避策は、技術手順書とは別に、顧客向けの承認説明テンプレートを用意することです。
含めるべき項目は次のとおりです。
| 項目 | 顧客に説明する内容 |
|---|---|
| 管理側テナント | どのMSSPテナントがアクセスするか |
| 権限範囲 | 読み取り、調査、変更、管理のどこまで含むか |
| 対象サービス | Defender XDR、Sentinel、Log Analyticsなど |
| 対象期間 | 継続契約中か、期間限定か |
| 監査方法 | 顧客側でどのログを確認できるか |
| 解除方法 | 契約終了・権限見直し時の手順 |
プレビュー機能を本番前提で固定化する
2026年4月時点で、governance relationshipsを使った委任アクセスはプレビューとして案内されています。Microsoft Learnでも該当機能はpreviewと明記されています。(Microsoft Learn)
プレビュー機能は、仕様、対応範囲、UI、前提条件が変わる可能性があります。したがって、本番運用では次のような前提で計画してください。
| 対応 | 理由 |
|---|---|
| 重要顧客の全面移行前にパイロットを行う | 想定外の制限を早期に見つけるため |
| 既存のB2B / Lighthouse運用をすぐに廃止しない | 切り戻し手段を残すため |
| Microsoft Learnの更新日を確認する | プレビュー仕様が変わる可能性があるため |
| 顧客契約書に「使用するMicrosoft機能が変更される可能性」を含める | 製品更新による運用変更を説明しやすくするため |
| 権限テストを定期実行する | UI変更やRBAC変更による影響を検知するため |
MSSP向けの実装チェックリスト
Microsoft Sentinel / Microsoft Defender delegated accessを設計する際は、次のチェックリストを使うと抜け漏れを減らせます。
| チェック項目 | 完了の目安 |
|---|---|
| 顧客テナント、管理側テナント、対象ワークスペースを一覧化した | テナントIDとワークスペース名で確認できる |
| SentinelがDefenderポータルに接続されているか確認した | Primary / Secondary workspaceも整理済み |
| 契約メニューごとの権限テンプレートを作った | Monitoring、Incident、Detection、Adminなど |
| 管理側テナントのセキュリティグループを役割別に作った | Microsoft 365グループを流用していない |
| governance relationship / GDAPの承認者を決めた | 顧客側の承認担当者が明確 |
| remote tenant groupにSentinelロールを割り当てた | Log AnalyticsワークスペースのIAMで確認済み |
| Defender unified RBACの有効化状況を確認した | ワークロードごとの差異を把握済み |
| Tier別アカウントで業務シナリオテストを行った | インシデント確認、KQL、更新、ルール管理を確認 |
| 権限過多を検出するレビュー手順を作った | 定期レビューと退職者対応を含む |
| 顧客向け説明資料を作った | 権限範囲、監査、解除方法を説明できる |
このチェックリストの中で、特に重要なのは「ログインできた」ではなく「契約したSOC業務を最後まで実行できた」で確認することです。
今後のアクセス設計で重視すべき判断基準
Microsoft SentinelとMicrosoft Defenderの統合が進むほど、MSSPの競争力は、検知ルールやアナリストのスキルだけでなく、マルチテナント運用基盤の設計力にも左右されます。
判断基準は次の3つです。
最小権限と初動速度を両立できるか
権限を絞りすぎると初動が遅れます。広げすぎると監査リスクが増えます。重要なのは、日常業務に必要な権限は迷わず使えるようにし、強い権限は承認付きで使う設計にすることです。
顧客追加時に同じ品質で再現できるか
優れた委任アクセス設計は、新規顧客オンボーディングで差が出ます。毎回個別対応している状態では、MSSPとしてスケールしません。テンプレート、命名規則、承認フロー、テスト項目を標準化することが重要です。
監査時に説明できるか
「なぜこの人がこの顧客のこのデータを見られるのか」を説明できない権限設計は危険です。GDAP、Defender unified RBAC、Azure RBAC、Sentinelロールの関係を図や一覧表で残しておくと、顧客監査や社内レビューに対応しやすくなります。
まとめ：GDAP対応は“設定作業”ではなくSOC運用設計の見直し
Microsoft Sentinel / Microsoft Defender delegated accessの最新動向で重要なのは、GDAPがSentinelとDefenderの統合運用における委任アクセス計画に入ってきたことです。Microsoft SentinelがDefenderポータルへ統合される流れの中で、従来のAzureポータル中心、Azure Lighthouse中心の運用だけでは、MSSPやSOCチームの実務に合わない場面が増えていきます。
ただし、GDAPを有効にすればすべて解決するわけではありません。テナント間の委任関係、Defender unified RBAC、Azure RBAC、Sentinelワークスペース権限、顧客承認、監査ログをまとめて設計する必要があります。
まず着手すべきことはシンプルです。
既存顧客ごとに、誰が、どのテナントへ、どの方式で、どの権限を使ってアクセスしているかを棚卸ししてください。そのうえで、SOCの業務ロール別に権限テンプレートを作り、1〜2社でDefenderポータル中心の委任アクセスを検証します。
この準備を早めに進めておくことで、SentinelとDefenderの統合が進んでも、アナリストの調査を止めず、顧客に説明できる安全なマルチテナントSOC運用へ移行できます。
コメント