Microsoft Defender XDRの権限管理は、個別サービスごとのロール設定から、Microsoft Defender unified role-based access control（RBAC）を中心に整理する段階に入っています。特に2026年4月の更新では、Microsoft Sentinelまわりの扱いが明確化され、Security admins、identity teams、compliance teamsが見直すべきポイントが増えました。
結論から言うと、今すぐ確認すべきことは3つです。既存ロールの棚卸し、Unified RBACへの権限マッピング、Microsoft SentinelやMicrosoft Purviewとの権限境界の確認です。単に「新しいRBACに切り替える」だけでは不十分で、Azure RBACやMicrosoft Entra IDロールに残っている強い権限まで含めて見直さないと、想定以上のデータ閲覧が残る可能性があります。
Microsoft公式ドキュメントでは、Microsoft Defender unified RBACはDefender XDR、Defender for Endpoint、Defender for Office 365、Defender for Identity、Defender Vulnerability Management、Defender for Cloud、Microsoft Security Exposure Management、Defender for Cloud Apps、Microsoft Sentinelなどを対象に、複数のセキュリティサービスの権限管理を一元化するモデルとして説明されています。(Microsoft Learn)
Microsoft Defender unified RBACとは何か
Microsoft Defender unified RBACは、Microsoft Defenderポータル上でユーザーやグループの権限をまとめて管理するための仕組みです。従来は、Defender for Endpoint、Defender for Office 365、Defender for Identity、Microsoft Sentinelなどで権限設定の場所や考え方が分かれていました。
Unified RBACでは、ロール、権限、データスコープ、割り当て先を組み合わせて管理します。たとえば、SOCの一次対応者にはアラート閲覧と基本的な対応権限だけを付与し、端末への高度なライブレスポンスやメール本文の閲覧は上位担当者に限定する、といった設計がしやすくなります。
重要なのは、Unified RBACが「すべてのMicrosoft管理者権限を置き換える万能な仕組み」ではないことです。Microsoft Entra IDのグローバルロール、Azure RBAC、Exchange Online関連ロール、Microsoft Purviewの権限は、用途によって引き続き影響します。
2026年4月更新で注目すべきポイント
2026年4月の更新で特に注目したいのは、Microsoft Sentinelに関する説明の明確化です。Microsoft DocsのGitHub履歴では、2026年4月23日にMicrosoft SentinelのUnified RBACに関する記述が更新され、同月27日にも表現の微修正が入っています。(GitHub)
実務上は、次のように整理すると分かりやすくなります。
| 更新・確認ポイント | 内容 | 実務での影響 |
|---|---|---|
| Microsoft Sentinelの扱いが明確化 | Unified RBACの割り当てはAzure RBACと同期され、Azure側でも表示される。ただし有効化後はUnified RBACが権限のソースになる | Sentinelを使うSOCでは、Defender側とAzure側の権限を両方確認する必要がある |
| ARM/Azure RBACの権限も引き続き影響 | DefenderポータルのSentinel体験では、Unified RBACだけでなくARMロールや権限も尊重される | Azure側に強い権限が残っていると、Unified RBACで絞ったつもりでもより多くのデータが見える可能性がある |
| Sentinel data lakeにも関係 | DefenderポータルとMicrosoft Sentinel data lakeにオンボードされた場合、既定ワークスペースの権限管理も対象になる | データレイク利用組織では、分析担当者・SOC・監査担当者のアクセス分離が必要 |
| Microsoft Purviewとの境界 | DLPやInsider Risk Managementなど、コンプライアンス権限で管理される体験はMicrosoft Purview RBACが担当する | compliance teamsはDefender側だけでなくPurview側の権限を別途確認する必要がある |
| Exchange Online PowerShellは対象外 | Exchange Online PowerShellやSecurity & Compliance PowerShellは、Exchange OnlineロールやEmail & Collaborationロールを使い続ける | メールセキュリティ運用では、GUIとPowerShellの権限差を見落とさないことが重要 |
Microsoft公式ドキュメントでも、Microsoft Sentinelはプレビュー扱いで、Unified RBACの割り当てがAzure RBACと同期される一方、有効化後はUnified RBACが権限のソースになると説明されています。また、DefenderポータルのSentinel体験ではARMロールや権限も引き続き考慮されるため、ARM側により強い権限があるユーザーは、Unified RBACで設定した範囲より多くのデータを見られる可能性があります。(Microsoft Learn)
新規テナントではUnified RBAC前提の設計が必要
Microsoft Defender unified RBACは、すでに新規テナントでは既定の権限モデルとして扱われる範囲が広がっています。
Microsoft Defender for Endpointの新規テナントでは2025年2月16日から、Microsoft Defender for Identityの新規テナントでは2025年3月2日からUnified RBACが既定の権限モデルになっています。これらの新規テナントでは、従来モデルからロールや権限をエクスポートできません。一方で、既存テナントは既存のロールと権限構成を維持できます。(Microsoft Learn)
この違いは、M&A、海外拠点追加、新規Microsoft 365テナント構築時に効いてきます。既存テナントで古いRBAC運用に慣れている組織でも、新規テナントでは同じ手順が使えない場合があります。
既存テナントで特に注意すべき点
既存テナントでは、「今まで動いているから問題ない」と判断しがちです。しかし、Defender for Endpoint、Defender for Office 365、Defender for Identity、Sentinelを組み合わせている環境では、権限の実体が複数箇所に分散していることがあります。
たとえば、次のような状態はよくある失敗パターンです。
- 退職・異動した担当者が、古いAzure RBACロールに残っている
- SOC一次対応者に、メール本文や添付ファイルの閲覧権限まで付いている
- ライブレスポンスの高度な操作権限が、広いグループに割り当てられている
- Compliance担当者がDefender RBACだけを確認し、Purview側のDLP権限を見落としている
- Sentinelワークスペースの権限変更を、Unified RBAC有効化後もAzureポータル側で続けている
Unified RBACに移行する前に、既存の管理者ロール、セキュリティロール、Azure RBAC、Exchange関連ロール、Purviewロールを一覧化することが重要です。
対象サービスごとの見方
Microsoft Defender unified RBACは、複数のワークロードを一元的に管理できる点が強みです。ただし、各サービスで「完全に任せられる範囲」と「別ポータルや別RBACが残る範囲」は異なります。
| サービス | Unified RBACで見るべきポイント |
|---|---|
| Microsoft Defender XDR | Defenderポータル内の統合セキュリティ体験に対する権限管理 |
| Microsoft Defender for Endpoint | エンドポイントデータ、アラート、対応操作、デバイスグループのスコープ設計 |
| Microsoft Defender for Office 365 | メール、コラボレーション、検疫、メール本文・添付ファイル閲覧の権限分離 |
| Microsoft Defender for Identity | ID関連データとアクション、スコープアクセスとの組み合わせ |
| Defender Vulnerability Management | 脆弱性データの閲覧、例外処理、修復依頼、アプリケーション制御 |
| Microsoft Defender for Cloud | Defenderポータルで利用できるクラウドセキュリティデータへのアクセス管理 |
| Microsoft Security Exposure Management | Exposure ManagementデータやMicrosoft Secure Score関連の閲覧・管理 |
| Microsoft Defender for Cloud Apps | 一部の組み込みスコープロールがサポートされなくなる点に注意 |
| Microsoft Sentinel | プレビュー扱い。Defenderポータル、Azure RBAC、ワークスペース単位の管理を合わせて確認 |
公式ドキュメントでは、Defender for Endpoint、Defender for Office 365、Defender for Identityなどは各データとアクションに対するサポートが説明されています。一方、Defender for Cloud AppsとMicrosoft Sentinelはプレビューや条件付きの注意点が示されています。(Microsoft Learn)
権限設計で使うべき基本方針
Microsoft Defender unified RBACを導入するときは、最初から細かいロールを大量に作るより、業務単位で必要な操作を整理する方が失敗しにくくなります。
最小権限を前提にする
Microsoftの権限マッピング資料でも、少ない権限のロールを使うことが推奨されています。特にGlobal Administratorは非常に強い権限であり、通常運用ではなく緊急時などに限定すべきロールです。(Microsoft Learn)
実務では、次のように分けると管理しやすくなります。
| 役割 | 付与する権限の考え方 | 避けたい権限 |
|---|---|---|
| SOC Tier 1 | インシデント、アラート、デバイス情報の閲覧。必要に応じてアラート管理 | 高度なライブレスポンス、メール本文閲覧、RBAC管理 |
| SOC Tier 2 | 対応操作、調査、基本的なライブレスポンス | RBAC管理、全社スコープの不要な管理権限 |
| Incident Commander | 重大インシデント時の対応指揮、必要なレスポンス操作 | 日常的な広範囲権限の常時付与 |
| Email Security担当 | 検疫、メールメタデータ、必要に応じたメールコンテンツ確認 | 全ユーザーのメール内容を常時閲覧できる広い権限 |
| Vulnerability Manager | 脆弱性データ閲覧、修復依頼、例外管理 | インシデント対応やメール削除など別業務の権限 |
| RBAC管理者 | ロール作成、割り当て、権限管理 | セキュリティデータやメール本文の不要な閲覧権限 |
権限を「人」に直接付けるより、Microsoft Entra IDのグループに割り当てる方が運用しやすくなります。入退社や異動のたびに個別ユーザーのロールを探す必要がなくなり、監査時にも説明しやすくなります。
Authorization権限は特に絞る
Unified RBACでは、Authorization権限によってロールや割り当てを管理できます。これは便利ですが、付与しすぎると「自分や他人に強い権限を付けられる管理者」が増えることになります。
日常運用では、Authorizationの管理権限を持つグループを小さくし、通常のSOC担当者や脆弱性管理担当者とは分離してください。権限変更はチケット、承認、監査ログ確認とセットで運用するのが現実的です。
Microsoft Sentinel利用組織が最優先で確認すべきこと
2026年4月更新の実務インパクトが大きいのは、Microsoft SentinelをDefenderポータルに統合して使っている組織です。
Unified RBACを有効にすると、Sentinelの権限割り当てはAzure RBACと同期され、Azure側でも見えるようになります。ただし、DefenderポータルのSentinel体験ではARMロールや権限も尊重されます。つまり、Unified RBACで細かく絞ったとしても、Azure側に強い権限が残っていれば、意図した制限にならない可能性があります。(Microsoft Learn)
Sentinelで確認するチェックリスト
| 確認項目 | 具体的に見る場所・観点 |
|---|---|
| SentinelワークスペースのAzure RBAC | Reader、Contributor、Sentinel Contributor、Ownerなどが誰に付いているか |
| Defender Unified RBACの割り当て | Sentinel関連の権限がどのグループに割り当てられているか |
| ARMロールとの重複 | Unified RBACでは制限しているのにAzure側で広い権限が残っていないか |
| データレイク利用有無 | Microsoft Sentinel data lakeの既定ワークスペースにアクセスできるユーザーは誰か |
| 権限変更の運用場所 | Unified RBAC有効化後もAzureポータルで権限変更していないか |
Microsoftの有効化手順では、SentinelワークスペースをUnified RBACで有効にするには、Microsoft Entra IDのSecurity Administratorに加えて、Subscription Owner、またはUser Access AdministratorとSentinel Contributorが必要とされています。また、Unified RBAC有効化後にAzureポータル側でSentinel権限を変更すると同期エラーにつながる可能性があるため、Defenderポータル側で管理する必要があります。(Microsoft Learn)
Compliance teamsはPurviewとの境界を確認する
コンプライアンス担当者が注意すべきなのは、Microsoft Defender unified RBACだけでDLPやInsider Risk Managementの権限まで管理できるわけではない点です。
Microsoft公式ドキュメントでは、DefenderポータルからアクセスできるDLPやInsider Risk Managementのようなコンプライアンス権限で制御される体験は、Microsoft Defender unified RBACではなくMicrosoft Purview RBACで管理されると説明されています。(Microsoft Learn)
そのため、compliance teamsは次の2つを分けて確認する必要があります。
| 領域 | 主に確認する権限 |
|---|---|
| セキュリティ運用 | Defender unified RBAC、Microsoft Entra IDロール、Azure RBAC |
| コンプライアンス運用 | Microsoft Purview RBAC、DLP、Insider Risk Management関連ロール |
たとえば、セキュリティチームがDefender側でアラート調査を行い、コンプライアンスチームがDLPインシデントを扱う場合、両者の閲覧範囲や対応権限を混同しないことが重要です。特にメール本文、ファイル、ユーザー行動に関わるデータは、法務・人事・監査部門との合意が必要になるケースがあります。
Microsoft Defender unified RBACを有効化する流れ
Microsoft Defender unified RBACは、ワークロード単位で有効化できます。いきなり全サービスへ適用するのではなく、対象ワークロードとテストユーザーを決めて段階的に進めるのが安全です。
公式手順では、Microsoft Defenderポータルにサインインし、System > PermissionsからMicrosoft Defender XDRのRolesを開き、バナーまたはWorkload settingsからワークロードを有効化できます。別の経路として、System > Settings > Microsoft Defender XDR > General > Permissions and rolesから有効化ページへ進む方法も示されています。(Microsoft Learn)
推奨手順
| 手順 | 作業内容 | 失敗を防ぐポイント |
|---|---|---|
| 事前調査 | 既存ロール、Azure RBAC、Entra IDロール、Purviewロールを棚卸し | 個別ユーザー割り当てと古い管理者グループを必ず確認 |
| 権限マッピング | 既存ロールをUnified RBACの権限に対応付ける | 旧ロール名だけで判断せず、実際の操作権限を見る |
| カスタムロール作成 | 業務単位でロールを作る | SOC、メール、脆弱性管理、RBAC管理を混ぜない |
| グループ割り当て | Microsoft Entra IDグループにロールを割り当てる | 個人への直接付与を減らす |
| テスト | 検証ユーザーで閲覧・対応・拒否される操作を確認 | 「できること」だけでなく「できないこと」も確認 |
| ワークロード有効化 | Defenderポータルから対象ワークロードを有効化 | Sentinelはワークスペース単位で慎重に進める |
| 運用監査 | 定期的にロールと権限差分を確認 | 異動、退職、組織改編後の放置を防ぐ |
Unified RBACを有効化すると、対象ワークロードのロールと権限はMicrosoft DefenderポータルのUnified RBACモデルによって制御されます。逆に、有効化するまでは既存のRBACモデルが引き続き尊重されます。(Microsoft Learn)
権限カテゴリの具体例
Microsoft Defender unified RBACでは、業務に応じて複数の権限カテゴリを組み合わせます。代表的なカテゴリを理解しておくと、カスタムロールを作りやすくなります。
| 権限カテゴリ | できることの例 | 運用上の注意 |
|---|---|---|
| Security data basics | インシデント、アラート、調査、ハンティング、デバイス、レポートなどの閲覧 | 多くの担当者に必要だが、スコープを広げすぎない |
| Alerts | アラート管理、自動調査の開始、スキャン、デバイスタグ管理など | 一次対応者に付ける場合は対応範囲を明確にする |
| Response | 対応アクション、保留中の修復アクションの承認・却下など | 影響が大きいため、承認フローと組み合わせる |
| Basic live response | リモートでの基本的なライブレスポンス操作 | 端末操作に関わるため、対象デバイススコープを絞る |
| Advanced live response | ファイルアップロードやスクリプト実行を含む高度な操作 | 付与対象を厳しく限定する |
| Email & collaboration content | メール本文や添付ファイルの閲覧・ダウンロード | プライバシーや監査要件に直結するため最小限にする |
| Authorization | ロールや割り当ての閲覧・管理 | RBAC管理者だけに限定する |
| Data operations | Sentinel data lakeなどのデータ保持、分析ジョブ、テーブルやコネクタ管理 | プレビュー機能やデータ分析基盤の権限と合わせて確認 |
公式ドキュメントでは、Security operations、Security posture、Authorization and settings、Data operationsなどの権限グループが示され、アラート管理、レスポンス、ライブレスポンス、メールコンテンツ、脆弱性管理、Authorizationなどの権限をロールに組み込めると説明されています。(Microsoft Learn)
導入時に起こりやすい失敗
Microsoft Defender unified RBACの導入で失敗しやすいのは、設定作業そのものよりも、事前整理と運用設計です。
旧ロールをそのまま再現してしまう
既存ロールをそのままUnified RBACに移すだけでは、最小権限化の機会を逃します。移行時は「今まで誰が何をできたか」ではなく、「今後その業務に本当に必要な操作は何か」で見直してください。
SentinelのAzure RBACを見落とす
Sentinelを使っている場合、Defender側のUnified RBACだけを見ても不十分です。Azure側のOwner、Contributor、Sentinel Contributorなどが残っていると、想定より広いアクセスが残る可能性があります。
メールコンテンツ権限を広く付けすぎる
メール本文や添付ファイルの閲覧は、セキュリティ調査に必要な場面があります。しかし、全SOCメンバーに常時付与する必要があるとは限りません。メールメタデータの閲覧、検疫操作、本文閲覧を分離すると、監査時の説明がしやすくなります。
Global Administratorに頼り続ける
Global Administratorは強力なロールです。日常的なDefender運用のために使い続けると、権限過多になりやすく、監査上も説明が難しくなります。RBAC管理者、セキュリティ運用者、閲覧者を分けて設計することが重要です。
PowerShell側の権限を見落とす
Microsoft Defender unified RBACは、Exchange Online PowerShellやSecurity & Compliance PowerShellには影響しません。これらは引き続きExchange OnlineロールやEmail & Collaborationロールを使います。メールセキュリティの権限を整理する場合は、Defenderポータル上の操作だけでなくPowerShell経由の操作権限も確認してください。(Microsoft Learn)
役割別に今すぐやるべきこと
Security admins
Security adminsは、まずDefenderポータルで現在のロールと割り当てを確認し、SOC業務に必要な権限を業務単位に分けてください。特に、Response、Live response、Email content、Authorizationのような影響の大きい権限は、付与対象を明確にします。
次に、SentinelやDefender for Cloudを使っている場合は、Azure RBACとの重複を確認します。Unified RBACだけを見て「権限を絞った」と判断しないことが重要です。
Identity teams
Identity teamsは、Microsoft Entra IDロールとDefender Unified RBACの関係を整理します。Security AdministratorがUnified RBAC管理に必要になる場面がある一方で、日常的なロール管理をすべて高権限のEntra IDロールに頼る必要はありません。
公式ドキュメントでは、Microsoft Defender unified RBACのロールと権限を管理するには、少なくともMicrosoft Entra IDのSecurity Administratorが必要とされています。また、Authorization権限を使うことで、Microsoft Entraのグローバルロールに依存せずにRBAC管理を委任できる設計も示されています。(Microsoft Learn)
Compliance teams
Compliance teamsは、Defender Unified RBACとMicrosoft Purview RBACの境界を明文化してください。DLP、Insider Risk Management、監査、メール本文閲覧などは、セキュリティ運用とコンプライアンス運用の責任分界があいまいになりやすい領域です。
おすすめは、次のような権限管理表を作ることです。
| データ・操作 | 主担当 | 管理するRBAC | 承認者 |
|---|---|---|---|
| セキュリティアラート閲覧 | SOC | Defender unified RBAC | Security admin |
| 端末への対応操作 | SOC Tier 2以上 | Defender unified RBAC | Incident commander |
| メール本文・添付ファイル閲覧 | Email security / Compliance | Defender unified RBAC、必要に応じてPurview側確認 | Compliance lead |
| DLPインシデント | Compliance | Microsoft Purview RBAC | Compliance manager |
| Sentinelワークスペース | SOC / Cloud security | Defender unified RBAC、Azure RBAC | Security admin / Cloud owner |
まずは小さく始めるのが安全
Microsoft Defender unified RBACは、複数のセキュリティサービスの権限を一元化できる強力な仕組みです。一方で、Microsoft Entra ID、Azure RBAC、Microsoft Purview、Exchange Online関連ロールとの境界を理解しないまま有効化すると、権限の抜け漏れや過剰付与が残ります。
最初にやるべきことは、全社一括の切り替えではありません。まず、対象ワークロードを1つ選び、既存権限を棚卸しし、業務別のカスタムロールを作り、検証ユーザーで「できること」と「できないこと」を確認してください。
特に2026年4月更新で明確化されたMicrosoft Sentinelの扱いは、グローバル組織や複数テナント運用の企業ほど影響が大きくなります。Defender側のUnified RBACだけでなく、Azure側の権限、Purview側の権限、PowerShell経由の権限まで含めて見直すことが、実効性のあるセキュリティ運用につながります。
コメント