Microsoft Defender for Identityのロールグループで最初に押さえるべき結論は、権限管理の主軸がMicrosoft Defender XDRの統合RBACへ移っていることです。特に2025年3月2日以降の新規Microsoft Defender for Identityテナントでは、権限をMicrosoft Defender XDRのUnified Role-Based Access Control、つまり統合RBAC経由で構成する必要があります。既存テナントは従来構成を保持できますが、今後の展開、移行、権限見直しでは統合RBAC前提で設計するのが現実的です。(Microsoft Learn)
この記事では、Microsoft Defender for IdentityのRole groupsに関する公式情報をもとに、変更点、影響範囲、管理者・開発者が確認すべき設定、移行時の注意点を実務目線で整理します。2026年5月のMicrosoft Defender for Identity更新では、拡張RPC監査、センサー上限の拡大、新しいID関連アラートなども追加されており、IDデータを「誰が見られるか」「誰が操作できるか」の設計はますます重要になっています。(Microsoft Learn)
Microsoft Defender for Identityのロールグループで変わったポイント
Microsoft Defender for Identityのロールグループは、Defender for Identityのデータや設定に対するアクセス権を管理する仕組みです。公式ドキュメントでは、セキュリティチーム内で責任を分離し、業務に必要な最小限のアクセスだけを付与するためにロールグループを使うことが推奨されています。(Microsoft Learn)
今回の要点は、「旧来のAzure ATP系セキュリティグループを前提にした運用」から、「Microsoft Defender XDRの統合RBACで一元管理する運用」へ寄せる必要があることです。
| 確認項目 | 変更・重要ポイント | 実務での対応 |
|---|---|---|
| 新規テナントの権限管理 | 2025年3月2日以降の新規Defender for Identityテナントは、Microsoft Defender XDR統合RBACで権限を構成する | 新規導入時は旧ロールグループではなく、Defenderポータルの「アクセス許可」から設計する |
| 既存テナント | 2025年3月2日より前にロールが割り当て済み、またはエクスポート済みのテナントは現行構成を保持できる | 既存グループを棚卸しし、段階的に統合RBACへ移行する計画を作る |
| Microsoft Entra IDのSecurity Administrator | Entra IDでSecurity Administratorを持つユーザーは、自動的にDefender for Identity管理者として扱われる | Entra ID側の特権ロールを必ず再確認する |
| 旧Azure ATPグループ | 3月2日以降、Defender for IdentityはMicrosoft Entra IDのセキュリティグループを新規作成しない | 「Azure ATP 管理者」「Azure ATP ユーザー」「Azure ATP 閲覧者」前提の手順書を見直す |
| スコープ付きアクセス | Active DirectoryドメインやOU単位で、見えるIDデータを制限できる | 拠点別、子会社別、SOC担当範囲別の権限分離に使う |
影響範囲は管理者だけでなくSOC担当者や開発者にも及ぶ
Microsoft Defender for Identityのロールグループ変更は、単に「管理画面の場所が変わる」話ではありません。影響は、アラート対応、センサー管理、レポート閲覧、Advanced Hunting、内部ダッシュボード、SIEM連携の運用確認まで広がります。
| 対象者 | 主な影響 | 確認すべきこと |
|---|---|---|
| セキュリティ管理者 | 統合RBACでロールを作成・割り当てる必要がある | Identityワークロードの統合RBAC有効化状況、既存ロール、Entra ID特権ロール |
| SOC担当者 | アラートの表示、クローズ、抑制、調査に必要な権限が変わる可能性がある | Security operations/Security data/Alerts (Manage) と読み取り権限の有無 |
| ID管理者 | Active DirectoryドメインやOU単位で見える範囲を制限できる | 担当範囲に応じたスコープ付きアクセス設計 |
| 開発者・自動化担当者 | 内部ツールやクエリで参照できるIDデータが変わる可能性がある | Advanced Huntingテーブル、Graph API、SIEM、レポート取得の権限 |
| 監査・コンプライアンス担当者 | 誰がどのIDデータにアクセスできるかを説明する必要がある | ロール名、割り当て先、データソース、スコープの証跡 |
特に見落としやすいのは、Microsoft Entra IDのSecurity Administratorです。このロールを持つユーザーはDefender for Identityへの追加権限なしで管理者になれるため、「Defender側では権限を付けていないから大丈夫」と考えるのは危険です。Entra IDの特権ロール棚卸しもセットで行う必要があります。(Microsoft Learn)
必要な権限を業務別に整理する
Defender for Identityでは、作業内容ごとに必要な権限が異なります。すべての担当者にSecurity Administratorを付与するのではなく、「設定を変更する人」「アラートを処理する人」「閲覧だけの人」を分けることが基本です。
| やりたいこと | 最小限の権限の考え方 | 避けたい設定 |
|---|---|---|
| Defender for Identityをオンボードする | Microsoft Entra IDのSecurity Administratorが必要 | 一時的な作業者に恒久的なSecurity Administratorを残す |
| Defender for Identity設定を変更する | Security Administrator、Security Operator、または統合RBACのSecurity settings/System settings系権限 | 設定変更が不要なSOC担当者に管理権限を付ける |
| Defender for Identity設定を閲覧する | Security Reader、またはSecurity settings/System settingsの読み取り権限 | 閲覧だけの担当者にAll permissionsを付ける |
| アラートとアクティビティを管理する | Security Operator、またはAlerts ManageとSecurity data basics Read | アラート対応担当者にセンサー管理権限まで付ける |
| 応答アクションを実行する | Response manageを含むカスタムロール、またはSecurity Operator | 調査担当者と実行担当者を区別しない |
| セキュリティ評価を確認する | Microsoft Secure Scoreへのアクセス権とSecurity data basics Read | Secure Score側の権限確認を忘れる |
公式情報では、Defender for Identityの設定構成、設定閲覧、アラート管理、応答アクションごとに必要なMicrosoft Entraロールまたは統合RBAC権限が示されています。実務では、ロール名だけで判断せず、「その担当者が実際に行う操作」から逆算して権限を選ぶのが安全です。(Microsoft Learn)
旧ロールグループと統合RBACの違い
従来のDefender for Identityでは、Azure ATP (workspace name) Administrators、Azure ATP (workspace name) Users、Azure ATP (workspace name) Viewers のようなセキュリティグループで権限を管理していました。現在は、Microsoft Defender XDRの統合RBACで、複数のMicrosoft Defenderサービスをまたいだ権限管理が可能になっています。(Microsoft Learn)
| 比較項目 | 旧ロールグループ | Microsoft Defender XDR統合RBAC |
|---|---|---|
| 管理場所 | Azure portalのMicrosoft Entraセキュリティグループ | Microsoft Defenderポータルの「アクセス許可」 |
| 権限の粒度 | 管理者、ユーザー、閲覧者のような大まかな分類 | セキュリティ操作、承認と設定、データソース、スコープ単位で設計可能 |
| 新規テナントでの利用 | 新規作成は前提にしない | 新規Defender for Identityテナントの標準的な権限管理 |
| 複数サービス対応 | Defender for Identity中心 | Defender for Endpoint、Defender for Office 365、Defender for Cloud Apps、Sentinelなども含めた一元管理 |
| スコープ制御 | 限定的 | Active DirectoryドメインやOU単位の可視性制限が可能 |
既存テナントでは旧ロールグループが残っている場合があります。ただし、新規展開や組織再編、SOC権限の見直し、複数Defender製品の統合運用を進めるなら、統合RBACへ寄せた設計に切り替えるべきです。
管理者が最初に確認すべき設定
Microsoft Defender for Identityの権限を見直すときは、いきなりロールを変更せず、現在の権限経路を把握することが重要です。特に既存テナントでは、Entra IDグローバルロール、旧Azure ATPセキュリティグループ、Defender XDR統合RBACが混在していることがあります。
Microsoft Entra IDの特権ロールを棚卸しする
最初に確認すべきなのは、Microsoft Entra ID側のSecurity Administratorです。Defender for Identity側で個別に管理者権限を付けていなくても、Entra IDでSecurity Administratorを持つユーザーはDefender for Identity管理者として扱われます。(Microsoft Learn)
確認時は、次のような観点で棚卸しします。
- 退職者、異動者、外部委託先がSecurity Administratorに残っていないか
- 緊急用アカウントが日常運用で使われていないか
- グループ経由で意図せず特権が付与されていないか
- PIMを使っている場合、常時有効ではなく必要時昇格になっているか
Defenderポータルで統合RBACのロールを確認する
統合RBACのカスタムロールは、Microsoft Defenderポータルの「アクセス許可」から作成・管理します。公式手順では、Microsoft Defender XDR配下の「ロール」からカスタムロールを作成し、権限、ユーザーまたはグループ、データソースを割り当てます。(Microsoft Learn)
確認すべきポイントは、ロール名ではなく中身です。たとえば「SOC Reader」という名前でも、実際には管理権限が含まれているかもしれません。逆に「Identity Admin」という名前でも、Microsoft Defender for Identityのデータソースが割り当てられていなければ、期待した操作ができない可能性があります。
データソースの割り当てを確認する
統合RBACでは、ロールに権限を付けるだけでなく、どのデータソースに対してその権限を使えるかを指定します。Microsoft Defender for Identityを対象にする場合、割り当てのデータソースにMicrosoft Defender for Identityが含まれているかを確認してください。
注意したいのは、「将来のデータソースを自動的に含める」設定です。このオプションを選ぶと、統合RBACでサポートされる将来のデータソースも自動的に割り当てに追加されます。運用を簡略化できる一方、最小権限の観点では意図せずアクセス範囲が広がる可能性があります。(Microsoft Learn)
スコープ付きアクセスを使うべきケース
Microsoft Defender for Identityのスコープ付きアクセスは、Active DirectoryドメインやOU単位で、見えるアラート、ID、アクティビティを制限するための機能です。大規模組織、子会社を含む環境、地域別SOC、委託運用のある企業では特に有効です。(Microsoft Learn)
たとえば、次のようなケースで役立ちます。
| 利用シーン | スコープ設計の例 |
|---|---|
| 子会社ごとにSOC担当を分ける | 子会社のADドメイン単位で可視範囲を制限する |
| 国内拠点と海外拠点で担当を分ける | 地域ごとのOUまたはADドメインでスコープを分ける |
| 外部委託先に一次調査だけ任せる | アラート閲覧・管理権限を限定し、設定変更権限は付けない |
| 特権IDだけ専門チームが監視する | 重要なOUや管理者アカウント群に焦点を当てる |
ただし、スコープ付きアクセスには制限があります。公式情報では、カスタムロールは新しいアラートとアクティビティにのみ適用され、作成前に発生したアラートやアクティビティはさかのぼってタグ付け・フィルター処理されないと説明されています。また、露出管理の一部、Microsoft Entra ID IPアラート、スケジュール済みレポートやGraph APIなど、スコープ付きアクセスでは利用できない、または制限される領域があります。(Microsoft Learn)
移行時の実践手順
既存テナントで旧ロールグループを使っている場合は、いきなり統合RBACへ切り替えるのではなく、業務影響を確認しながら段階的に進めます。
| 手順 | 作業内容 | 確認ポイント |
|---|---|---|
| 現状棚卸し | 旧Azure ATPグループ、Entra IDロール、Defender XDRロールを一覧化する | 誰がどの経路でDefender for Identityにアクセスできるか |
| 業務分類 | 管理、設定変更、アラート対応、閲覧、監査、開発・自動化に分ける | 「できること」ではなく「必要なこと」で分類する |
| 権限設計 | 統合RBACでカスタムロールを作成する | Security operations、Authorization and settings、データソースを最小限にする |
| スコープ設計 | 必要に応じてADドメインまたはOUで可視範囲を制限する | 過去アラートには遡及しない点を関係者に説明する |
| 検証 | 検証用ユーザーでサインインし、アラート閲覧、クローズ、設定変更可否を確認する | 画面表示だけでなく実操作まで確認する |
| 切り替え | 統合RBACを有効化し、旧グループ依存を減らす | 旧手順書、監査資料、運用Runbookを更新する |
| 定期レビュー | 四半期または半期ごとに権限を見直す | 異動、委託契約終了、組織変更を反映する |
統合RBACのカスタムロールは、作成しただけでは十分ではありません。新しいロールまたはインポートしたロールで構成した権限を適用するには、Microsoft Defender統合RBACモデルをアクティブにする必要があります。移行前には、検証ユーザーを使って実際の画面・操作・アラート処理まで確認してください。(Microsoft Learn)
2026年5月のDefender for Identity更新で意識すべき運用影響
2026年5月のMicrosoft Defender for Identity更新では、拡張RPC監査機能のプレビュー、センサー容量の増加、新しいDefender for Identityセキュリティアラートなどが公式に案内されています。Defender for Identityのリリースはテナントごとに段階的に展開されるため、公式情報にある機能が自社テナントでまだ見えない場合もあります。(Microsoft Learn)
| 更新内容 | 管理者への影響 | 権限面の確認 |
|---|---|---|
| 拡張RPC監査機能 | 高度なID検出のために、Extended Sensor Auditタグや最新累積更新プログラムが必要になる | センサー設定を変更できる担当者を限定する |
| センサー上限の拡大 | 1ワークスペースあたり最大1,000センサーまでサポート | 大規模展開時に、センサー管理権限を誰に付けるか確認する |
| 新しいID関連アラート | Entra ID関連のアラートが増え、SOCの確認対象が広がる | アラート閲覧・管理権限とスコープ設定を再確認する |
| 段階的ロールアウト | テナントによって機能の反映時期が異なる | 運用手順書に「未展開の場合の確認手順」を入れる |
ここで重要なのは、機能追加そのものよりも、運用対象となるIDデータが増えることです。新しいアラートやセンサー展開範囲が広がるほど、閲覧できる人、対応できる人、設定を変えられる人を分ける必要があります。
よくある失敗と回避策
Microsoft Defender for Identityのロールグループ見直しでは、次のような失敗が起きやすくなります。
| 失敗しやすいポイント | 起きる問題 | 回避策 |
|---|---|---|
| Security Administratorを広く付与している | Defender for Identity管理者が増えすぎる | Entra IDの特権ロールを最初に棚卸しする |
| 旧Azure ATPグループだけを確認する | 統合RBACやEntra IDロール経由のアクセスを見落とす | 権限経路を3系統で確認する |
| ロール名だけで判断する | 名前と実際の権限が一致しない | 権限、データソース、スコープを必ず確認する |
| すべての読み取り・管理権限を安易に選ぶ | 将来追加される権限まで自動付与される可能性がある | カスタム権限を使い、定期的に見直す |
| スコープ付きアクセスを過信する | 過去アラートや一部機能には制限がある | 制限事項をSOCと監査担当者に共有する |
| Defender for Cloud Apps側の権限を見落とす | Cloud Appsアクティビティログ経由でDefender for Identityデータが見える場合がある | Cloud Apps側の権限と例外条件も確認する |
Defender for Cloud AppsのアクティビティログにはDefender for Identityデータが含まれる場合があり、その内容は既存のDefender for Cloud Apps権限に従います。さらに、Defender for Cloud AppsでDefender for Identityアラートのスコープ付きデプロイを構成している場合、その権限は引き継がれず、関連ユーザーにSecurity data basicsの読み取り権限を明示的に付与する必要があります。(Microsoft Learn)
開発者・自動化担当者が確認すべきこと
開発者や自動化担当者は、管理者権限そのものよりも「必要なデータを安全に参照できるか」を確認する必要があります。たとえば、SOC向けダッシュボード、Advanced Huntingのクエリ、インシデント連携、通知ワークフローを作っている場合、統合RBACやスコープ付きアクセスの変更で取得結果が変わる可能性があります。
特に確認したいのは次の3点です。
| 確認項目 | 理由 |
|---|---|
| Advanced Huntingで使うテーブル | スコープ付きアクセスでは、IdentityInfo、IdentityDirectoryEvents、IdentityLogonEvents、IdentityQueryEventsなどの利用可否に影響が出る場合がある |
| レポート・Graph APIの利用 | スコープ付きアクセスの既知の制限により、スケジュール済みレポートやGraph APIが利用できないケースがある |
| データソースの割り当て | Microsoft Defender for Identityがデータソースに含まれていないと、想定したIDデータにアクセスできない |
内部ツールを作る場合は、開発用の高権限アカウントで動作確認するだけでは不十分です。本番で使うユーザーまたはグループと同じロール、同じスコープでテストし、表示されるデータと表示されないデータを確認してください。
次に取るべきアクション
Microsoft Defender for IdentityのRole groups対応で最初にやるべきことは、ロールを新しく作ることではなく、現在の権限経路を可視化することです。Microsoft Entra IDのSecurity Administrator、旧Azure ATPセキュリティグループ、Microsoft Defender XDR統合RBACの3つを確認し、誰がどの経路でアクセスできるかを一覧化してください。
そのうえで、管理者、SOC担当者、閲覧者、開発・自動化担当者を分け、Microsoft Defender for Identityのデータソースとスコープを必要最小限に設計します。2026年5月以降のDefender for Identity更新では、検出対象やセンサー運用の範囲が広がっているため、権限設計を後回しにすると、意図しない情報露出や運用ミスにつながります。
まずは、Defenderポータルの「アクセス許可」からMicrosoft Defender XDRのロールを確認し、既存の旧ロールグループとEntra ID特権ロールを棚卸ししてください。その結果をもとに、統合RBACへの移行計画、スコープ付きアクセスの利用有無、SOCのテスト手順を整備することが、最も安全で実務的な対応です。
コメント