Microsoft Defenderの権限管理を見直すなら、最初に確認すべきポイントは「Microsoft Defender unified role-based access control (RBAC) を有効化すると、対象ワークロードの権限管理がMicrosoft Defenderポータル側に集約される」という点です。これは検知エンジンや保護機能そのものの変更ではなく、管理者・SOC担当者・開発者が「どのデータを見られるか」「どの操作を実行できるか」に関わる重要なアクセス制御の変更です。
特に、Microsoft Defender XDR、Defender for Endpoint、Defender for Office 365、Defender for Identity、Microsoft Sentinelなどを組み合わせて運用している組織では、既存ロールの棚卸し、ワークロード単位の有効化、Microsoft Entra IDロールとの関係、SentinelやPowerShell運用への影響を事前に確認する必要があります。この記事では、2026年6月時点で確認しておきたいMicrosoft Defender unified RBACの変更点、影響範囲、移行・展開時の注意点を実務目線で整理します。Microsoft公式ドキュメントでは、unified RBACは複数のDefender関連サービスの権限管理を1か所で扱うためのモデルとして説明されています。(Microsoft Learn)
Microsoft Defender unified RBACとは
Microsoft Defender unified role-based access control (RBAC) は、Microsoft Defenderポータル上の権限管理を統合するための仕組みです。従来は、Defender for Endpoint、Defender for Office 365、Defender for Identity、Microsoft Sentinelなどで権限管理の場所や考え方が分かれがちでした。unified RBACでは、これらのセキュリティワークロードに対するロール、アクセス許可、割り当てをMicrosoft Defenderポータル側で集中管理できます。(Microsoft Learn)
重要なのは、unified RBACが「誰に何を許可するか」を細かく設計するための機能であり、単に管理画面を新しくするだけの変更ではないことです。たとえば、インシデント対応担当者にはアラートの閲覧と調査だけを許可し、セキュリティ設定の変更は管理者グループだけに許可する、といった最小権限の設計がしやすくなります。
一方で、有効化の順序を誤ると、これまで見えていたアラートやデバイス、メール脅威データが一部ユーザーから見えなくなる可能性があります。導入前には「既存権限をそのまま移す」のではなく、「現在の業務に必要な権限だけを再設計する」視点が必要です。
今回押さえるべき変更点
Microsoft Defender unified RBACで管理者が押さえるべき変更点は、主に次の5つです。
| 変更点 | 内容 | 管理者が確認すべきこと |
|---|---|---|
| 権限管理の統合 | 複数のDefender関連サービスのアクセス許可をMicrosoft Defenderポータルで管理できる | どのワークロードをunified RBACで管理するかを決める |
| 新規テナントでの既定化 | 2025年以降、新しいDefender for EndpointおよびDefender for Identityテナントではunified RBACが既定の権限モデルになる | 新規構築時に旧モデル前提の手順書を使わない |
| ワークロード単位の有効化 | unified RBACは対象ワークロードを有効化して初めて権限が適用される | 有効化前にロール、グループ、データソースを準備する |
| Sentinelはワークスペース単位 | Microsoft Sentinelはワークスペースごとに有効化を検討する必要がある | Azure RBAC、ARM権限、サービスプリンシパル利用を事前確認する |
| 一部ポータル・PowerShellは対象外 | Microsoft Purview、Exchange Admin Center、Exchange Online PowerShellなどは別の権限モデルが残る | Defenderポータルの権限だけで全管理権限が変わると誤解しない |
公式情報では、Microsoft Defender unified RBACを有効化するまで、Microsoft Defender XDRは既存のRBACモデルを引き続き尊重します。一方、有効化したワークロードでは、ロールとアクセス許可がMicrosoft Defenderポータル内のunified RBACで制御されます。(Microsoft Learn)
影響範囲：どのサービスとユーザーに関係するのか
Microsoft Defender unified RBACの影響は、単一サービスの管理者だけにとどまりません。Microsoft Defender XDRを中心に、エンドポイント、メール、ID、クラウド、SIEM運用まで関係します。
| 対象 | 主な影響 | 確認ポイント |
|---|---|---|
| Microsoft Defender XDR | Defenderポータル体験の権限を集中管理 | インシデント、アラート、ハンティング、設定変更の担当範囲 |
| Defender for Endpoint | エンドポイントデータと操作に対応 | デバイスグループによるスコープ制御を別途確認 |
| Defender for Office 365 | メール脅威関連のデータと操作に対応 | Exchange Online PowerShellやSecurity & Compliance PowerShellは別管理 |
| Defender for Identity | ID関連データと操作に対応 | スコープ付きアクセス、Cloud Apps側の権限との関係 |
| Defender Vulnerability Management | 脆弱性管理機能の権限を集中管理 | セキュリティ態勢管理担当に必要な権限を分離 |
| Defender for Cloud | Defenderポータルで扱うクラウドデータへのアクセス管理 | Azure側の権限設計との整合性 |
| Microsoft Security Exposure Management | Exposure ManagementやSecure Score関連に対応 | スコア閲覧だけか、改善操作まで許可するか |
| Defender for Cloud Apps | unified RBACとの統合が進む一方、一部の組み込みスコープロールに注意 | 既存ロールをマッピングしてから移行 |
| Microsoft Sentinel | Defenderポータルにオンボード済みワークスペースのアクセス管理に対応 | Azure RBACとの重複、同期、サービスプリンシパル制限 |
Microsoftの公式情報では、Microsoft Defender for Cloud Appsの権限統合やDefender for Cloudとの統合、Sentinel data lakeの権限連携など、unified RBACの対象範囲は段階的に広がっています。最新の構成では、単に「Defender for Endpointの権限管理」と捉えるのではなく、Defenderポータル全体の権限基盤として扱う必要があります。(Microsoft Learn)
管理者が最初に確認すべき設定
Microsoft Defender unified RBACを有効化する前に、管理者は少なくとも次の項目を確認してください。特に既存環境では、現在のロールをそのままインポートするだけでは、過剰権限や不要な閲覧範囲を引き継ぐ可能性があります。
既存ロールとグループの棚卸し
最初に行うべき作業は、既存の管理者、SOC担当者、ヘルプデスク担当者、監査担当者がどの権限を持っているかを洗い出すことです。
確認対象は次の通りです。
- Microsoft Entra IDの管理者ロール
- Defender for Endpointの既存ロール
- Defender for Office 365やEmail & Collaboration関連ロール
- Microsoft SentinelのAzure RBACロール
- セキュリティグループのメンバー
- 退職者、異動者、使われていないグループ
- 一時的に付与したまま残っている高権限ロール
実務では、個人ユーザーに直接ロールを割り当てるよりも、Microsoft Entra IDのセキュリティグループにロールを割り当てる方が管理しやすくなります。たとえば「SOC-L1-Analysts」「SOC-L2-Incident-Responders」「Defender-Admins」「Security-Auditors」のように、役割ごとにグループを分けると、入退社や異動時のメンテナンスが容易です。
Microsoft Entra IDの前提権限
Microsoft Defender unified RBACを管理するには、少なくともMicrosoft Entra IDのSecurity Administratorが必要です。公式情報では、DefenderポータルのPermissions and rolesへの初期アクセス、ロールと権限の管理、Authorization権限を持つカスタムロール作成にSecurity Administrator以上が必要とされています。(Microsoft Learn)
注意したいのは、Global Administratorであっても、unified RBAC上のすべてのワークスペース権限を自動的に持つわけではない点です。Global Administratorは自分を含むユーザーに権限を割り当てる権限を持てますが、特にMicrosoft Sentinelワークスペースの閲覧・操作権限は別途確認が必要です。(Microsoft Learn)
ワークロードのアクティブ化状態
unified RBACは、ロールを作成しただけでは対象ワークロードに適用されません。Microsoft Defenderポータルでワークロードを有効化して初めて、作成済みまたはインポート済みのロールと割り当てが適用されます。
確認場所は主に2つです。
| 確認場所 | 操作の流れ |
|---|---|
| Permissions and rolesページ | Microsoft Defenderポータルにサインインし、System > Permissions > Microsoft Defender XDR > Rolesへ進む |
| Microsoft Defender XDR設定 | System > Settings > Microsoft Defender XDR > General > Permissions and rolesへ進む |
有効化は、すべてのワークロードを一度に切り替えるよりも、影響の少ない範囲から段階的に行うのが安全です。たとえば、まず閲覧中心の監査ロールでテストし、次にSOC担当者、最後に管理者ロールを確認すると、業務停止のリスクを抑えられます。
移行前に決めておくべきロール設計
既存ロールをunified RBACへ移行する前に、ロール設計を見直しましょう。おすすめは「人」ではなく「業務」でロールを切ることです。
| 役割例 | 付与する権限の考え方 | 避けたい設定 |
|---|---|---|
| SOC一次対応 | アラート、インシデント、関連データの閲覧を中心にする | セキュリティ設定の変更権限まで付ける |
| SOC二次対応 | 調査、封じ込め、必要な対応操作を許可する | 全ワークロードの管理権限をまとめて付ける |
| 脆弱性管理担当 | Defender Vulnerability Managementやセキュリティ態勢関連を中心にする | インシデント対応権限と無関係に混在させる |
| メールセキュリティ担当 | Defender for Office 365の調査・対応範囲に絞る | Exchange管理全般の権限と混同する |
| 監査担当 | 読み取り専用を基本にする | 対応操作や設定変更を許可する |
| Defender管理者 | ロール管理、設定変更、ワークロード有効化を許可する | 日常調査用アカウントと兼用する |
unified RBACのカスタムロールでは、Security operations、Security posture、Authorization and settings、Data operationsなどの権限グループから必要な権限を選択できます。また、ユーザーまたはグループに対して、どのデータソースへアクセスできるかを割り当てられます。(Microsoft Learn)
ここで注意したいのが「All read-only permissions」や「All read and manage permissions」の扱いです。公式情報では、これらを選択した場合、将来そのカテゴリに追加される新しい権限も自動的にロールへ割り当てられると説明されています。最小権限を厳密に守りたいロールでは、便利さよりも権限拡張リスクを優先して、必要なカスタム権限だけを選ぶ判断も必要です。(Microsoft Learn)
既存ロールのインポートと移行手順
既存環境では、個別ワークロードで使っていたロールをMicrosoft Defender unified RBACへインポートできます。公式情報では、インポートにより既存ロールの権限とユーザー割り当てがunified RBACモデルへ移行され、移行後にインポート済みロールを編集できると説明されています。(Microsoft Learn)
安全に移行するなら、次の順序がおすすめです。
| 手順 | 作業内容 | 完了の判断基準 |
|---|---|---|
| 現状把握 | 既存ロール、ユーザー、グループ、ワークロードを一覧化する | 不要な個人割り当てや退職者が見つかっている |
| ロール設計 | 業務別に必要な権限を決める | 閲覧、調査、対応、設定変更、権限管理が分離されている |
| 既存ロールのインポート | 必要な製品からロールを取り込む | インポート対象ロールの権限と割り当てを確認済み |
| カスタムロール作成 | 過剰権限を整理し、必要な権限だけに調整する | 役割ごとの最小権限に近づいている |
| テスト割り当て | 少人数の検証グループへ割り当てる | 実際のポータル表示と操作可否を確認済み |
| ワークロード有効化 | 対象ワークロードを段階的にアクティブ化する | 業務影響がないことを確認してから範囲拡大 |
| 監査と定期レビュー | 権限の過不足を確認し、変更履歴を残す | 四半期や半期ごとの見直しサイクルがある |
インポート時に「Roles not eligible for import」に表示されるロールがある場合、削除済みユーザーや存在しないグループが割り当てに残っている可能性があります。この場合は、元のRBACモデル側で不要な割り当てを削除してから再度インポートを検討します。また、同じロールを複数回インポートすると重複ロールが作成されるため、再インポート前に既存のインポート済みロールを確認しておきましょう。(Microsoft Learn)
Sentinelを利用している組織の注意点
Microsoft SentinelをMicrosoft Defenderポータルへ統合している組織では、unified RBACの影響を特に慎重に見てください。Sentinelはワークスペース単位で有効化を検討する必要があり、有効化後はDefenderポータル側の権限管理とAzure側の権限管理が関係します。
公式情報では、Microsoft Sentinelをunified RBACで有効化すると、Unified RBACで行ったSentinelロール割り当てがAzure RBACと同期され、表示上も確認できる一方、有効化後はunified RBACが権限のソースになると説明されています。ただし、DefenderポータルのSentinel体験ではARMロールと権限も引き続き尊重されるため、ARM側でより広い権限を持つユーザーは、unified RBACで意図した範囲より多くのデータを見られる場合があります。(Microsoft Learn)
また、Microsoft SentinelではサービスプリンシパルやGDAPユーザーグループへの権限割り当てがunified RBACでサポートされない点にも注意が必要です。自動化やMSSP運用でこれらを使っている場合は、すぐにSentinelをunified RBACへ切り替えず、Azure RBACを継続する判断が現実的です。(Microsoft Learn)
Defender for Endpointではデバイスグループを忘れない
Defender for Endpointでは、unified RBACのロールだけでなく、デバイスグループによるスコープ制御も重要です。公式情報では、Defender for Endpointのすべてのロールはデバイスグループのスコープと互換性があり、デバイスグループごとの権限制限はDevice Groupsページで行うと説明されています。(Microsoft Learn)
たとえば、国内拠点担当のSOCチームには日本拠点の端末だけを見せ、海外拠点の端末はグローバルSOCだけが扱う、といった設計が可能です。逆に、unified RBAC側でロールを細かく設計しても、デバイスグループ側のスコープ確認を忘れると、想定より広い端末情報が見えてしまう場合があります。
確認すべきポイントは次の通りです。
- デバイスグループの条件が現在の組織構成に合っているか
- 旧運用で使っていたグループが放置されていないか
- 管理者用ロールと日常調査用ロールを分けているか
- 地域、部門、重要サーバーなどで閲覧範囲を分ける必要があるか
- MDEのライブレスポンスやファイル取得など、強い操作権限を誰に許可するか
特にサーバーや重要端末を扱う環境では、「閲覧できる範囲」と「操作できる範囲」を分けてテストすることが重要です。
Defender for Office 365とPowerShell運用の注意点
Defender for Office 365では、unified RBACによりメール脅威関連のデータや操作を統合管理しやすくなります。ただし、Exchange Online PowerShellやSecurity & Compliance PowerShellは、引き続きExchange OnlineロールやEmail & Collaborationロールを使用します。Microsoft Defender unified RBACは、これらのPowerShell権限には影響しません。(Microsoft Learn)
この点は、メールセキュリティ運用でよく誤解されます。Defenderポータルで操作できないようにしたからといって、PowerShell経由の操作権限まで必ず制限されたとは限りません。逆に、PowerShellで権限があるユーザーでも、Defenderポータル上で必要な調査画面が見えないことがあります。
管理者は次のように分けて確認してください。
| 確認対象 | 権限確認の観点 |
|---|---|
| Defenderポータル | unified RBACのロール、データソース、割り当て |
| Exchange Admin Center | Exchange側の管理ロール |
| Exchange Online PowerShell | Exchange Onlineロール |
| Security & Compliance PowerShell | Email & Collaboration関連ロール |
| 自動化スクリプト | 実行アカウントが使う権限モデル |
メール脅威対応を自動化している組織では、ポータル権限とPowerShell権限の差分を表にしておくと、障害時の切り分けが容易になります。
Microsoft Purviewの権限は別管理と考える
Microsoft Defenderポータルからアクセスできる機能であっても、すべてがMicrosoft Defender unified RBACで管理されるわけではありません。公式情報では、DLPやInsider Risk Managementなど、コンプライアンス権限で制御される体験はMicrosoft Purviewポータル側のRBACで管理されると説明されています。(Microsoft Learn)
つまり、Defenderポータル内に表示される画面だからといって、Defender unified RBACだけを見ればよいわけではありません。特に、セキュリティ部門とコンプライアンス部門が分かれている企業では、どちらの部門がどの権限を管理するかを明確にしておく必要があります。
開発者・自動化担当者が確認すべきポイント
Microsoft Defender unified RBACは管理者向けの話に見えますが、開発者や自動化担当者にも影響します。特に、運用スクリプト、SOAR連携、チケット連携、監査レポート作成、MSSP運用では、どの権限モデルを参照しているかを確認してください。
確認すべきポイントは次の通りです。
| 項目 | 確認内容 | よくある失敗 |
|---|---|---|
| 実行アカウント | ユーザー、サービスプリンシパル、マネージドIDのどれを使っているか | ユーザー権限では動くが自動化アカウントでは失敗する |
| Sentinel連携 | Sentinelワークスペースをunified RBACで管理するか | サービスプリンシパルがサポート対象外である点を見落とす |
| PowerShell | Exchange OnlineやSecurity & Compliance系の権限を別途確認する | Defenderポータル権限だけで十分だと誤解する |
| 監査ログ | 権限変更の記録を残す運用になっているか | 誰がロールを変更したか追跡できない |
| 環境差分 | 本番、検証、MSSP管理テナントで同じ設計か | 検証環境では成功したが本番でデータソースが違う |
| 将来データソース | Include future data sources automaticallyを使うか | 新しいデータソース追加時に想定外の閲覧範囲が広がる |
開発者目線では、「APIやスクリプトが成功するか」だけでなく、「そのアカウントに本当に必要な権限だけが付いているか」を確認することが大切です。SOC自動化では、調査に必要な読み取り権限と、封じ込め・修復に必要な操作権限を分けると、事故時の影響範囲を抑えられます。
導入判断の目安
unified RBACは便利ですが、すべての組織が同じタイミングで一気に切り替えるべきとは限りません。次の基準で判断すると、導入の優先度を決めやすくなります。
| 状況 | 判断 |
|---|---|
| 複数のDefender製品を横断して運用している | 導入優先度は高い |
| SOC、メール管理、脆弱性管理、ID管理で担当が分かれている | ロール整理の効果が大きい |
| 新規テナントを構築している | unified RBAC前提で設計する |
| 既存ロールが複雑で、誰が何を見られるか分からない | いきなり有効化せず棚卸しから始める |
| SentinelでサービスプリンシパルやGDAPユーザーグループを使っている | Sentinelの有効化は慎重に検討する |
| Exchange Online PowerShell中心の運用が多い | Defenderポータル権限とは別に権限表を作る |
| PurviewのDLPやInsider Risk Managementを扱う | Purview側のRBACも並行して確認する |
既存環境で最も安全なのは、「ロール設計」「インポート」「検証グループでテスト」「一部ワークロードを有効化」「監査」の順に進める方法です。一括切り替えは短時間で完了するように見えますが、閲覧不可や操作不可の問い合わせが一気に発生するリスクがあります。
展開時に失敗しやすいポイント
Microsoft Defender unified RBACの展開でよくある失敗は、機能の理解不足よりも、移行順序と権限の棚卸し不足です。
| 失敗しやすいポイント | 起きる問題 | 対策 |
|---|---|---|
| ロール作成前にワークロードを有効化する | ユーザーが必要な画面を見られなくなる | 先にロールと検証グループを準備する |
| 既存ロールをそのまま移す | 過剰権限も一緒に移行される | インポート後に業務別ロールへ再設計する |
| Global Administratorを万能権限と考える | Sentinelワークスペース権限で想定外の挙動になる | Entra IDロールとワークスペース権限を分けて確認する |
| ARM権限を見落とす | Sentinelで想定より広いデータが見える | Azure RBACとunified RBACの差分を確認する |
| PowerShell権限を見落とす | ポータル制限後もスクリプト操作が残る | Exchange OnlineやSecurity & Compliance側の権限を別途棚卸しする |
| 将来データソースの自動追加を安易に有効化する | 新機能追加時にアクセス範囲が広がる | 高権限ロール以外では慎重に使う |
| 個人ユーザーへ直接割り当てる | 異動・退職時に権限が残りやすい | セキュリティグループ単位で割り当てる |
特に「今まで問題なく見えていたから大丈夫」という判断は危険です。unified RBACでは、ワークロード有効化後に権限の効き方が変わるため、実際のユーザーでサインインして、インシデント、アラート、デバイス、メール、ID、Sentinelワークスペースの見え方を確認してください。
実務で使える確認チェックリスト
展開前の確認には、次のチェックリストを使うと抜け漏れを減らせます。
| チェック項目 | 確認結果 |
|---|---|
| 既存のDefender関連ロールを一覧化した | 未確認 / 確認済み |
| Microsoft Entra IDの管理者ロールを確認した | 未確認 / 確認済み |
| 個人ユーザーへの直接割り当てを整理した | 未確認 / 確認済み |
| SOC、監査、管理者、脆弱性管理など業務別ロールを設計した | 未確認 / 確認済み |
| Defender for Endpointのデバイスグループを確認した | 未確認 / 確認済み |
| Defender for Office 365とExchange Online PowerShellの権限差分を確認した | 未確認 / 確認済み |
| Sentinelワークスペースごとの有効化方針を決めた | 未確認 / 確認済み |
| サービスプリンシパルやGDAPユーザーグループ利用の有無を確認した | 未確認 / 確認済み |
| Purview側で管理するDLPやInsider Risk Management権限を確認した | 未確認 / 確認済み |
| 検証用グループでポータル表示と操作可否をテストした | 未確認 / 確認済み |
| 有効化後の問い合わせ窓口と切り戻し手順を決めた | 未確認 / 確認済み |
このチェックリストは、移行作業の承認資料にも使えます。セキュリティ部門だけでなく、メール管理、ID管理、クラウド管理、SOC運用、監査部門にも確認してもらうと、切り替え後の認識違いを減らせます。
まとめ：最初にやるべきこと
Microsoft Defender unified role-based access control (RBAC) は、Defender製品群の権限管理を整理し、最小権限を実現しやすくする重要な仕組みです。特に複数のDefenderワークロードを使っている組織では、管理場所が集約されることで運用の見通しが良くなります。
ただし、unified RBACは「有効化すれば自動的に安全になる」機能ではありません。既存ロールをそのまま移すだけでは、過剰権限を引き継ぐ可能性があります。逆に、準備不足のまま有効化すると、SOC担当者が必要なデータを見られなくなることもあります。
まず行うべきことは、既存ロールとグループの棚卸しです。そのうえで、業務別に必要な権限を整理し、検証グループで表示・操作を確認してから、ワークロード単位で段階的に有効化してください。Sentinel、Exchange Online PowerShell、Microsoft Purviewを利用している環境では、Defender unified RBACの対象外または注意が必要な権限モデルも併せて確認することが重要です。
コメント