Microsoft Defender for Endpoint（MDE）で「調査や一時的な切り分けは任せたいが、セキュリティポリシーは変更させたくない」場合は、単純にSecurity Administratorや広い管理者権限を渡してはいけません。結論は、Microsoft Entra IDグループ、最小権限のDefender XDRカスタムロール、MDEデバイスグループを組み合わせ、Troubleshooting Modeを使えるユーザーと対象デバイスを明確に絞る設計にすることです。
2026年4月13日時点で注目すべき更新として、Microsoft Tech Communityでは、Microsoft Defender for EndpointのTroubleshooting Mode専用アクセスを最小権限で設計する方法が公開されています。そこでは、Security Readerで調査権限を維持しつつ、Troubleshooting Modeに必要な権限だけをカスタムロールで付与し、さらにデバイスグループで対象端末を限定する構成が示されています。(TECHCOMMUNITY.MICROSOFT.COM)
結論：MDEのトラブルシューティング専用アクセスは「誰が」「何を」「どの端末で」を分けて設計する
MDEのTroubleshooting Modeは、Microsoft Defender Antivirusの問題調査や互換性確認に役立つ機能です。一方で、改ざん防止や組織ポリシーで保護されている設定に一時的な変更を加えられるため、広く許可すると構成ドリフトや責任範囲の曖昧化につながります。Microsoft Learnでも、Troubleshooting Modeは既定で無効であり、デバイスまたはデバイスグループ単位で一定時間だけ有効化する機能だと説明されています。(Microsoft Learn)
実務では、次のように分けて考えると失敗しにくくなります。
| 設計対象 | 推奨する考え方 | 避けたい設定 |
|---|---|---|
| ユーザー | 専用のEntra IDグループに対象者だけを入れる | 個人単位で都度ロールを直接付与する |
| 基本権限 | Security Readerなど、調査に必要な読み取り権限を中心にする | Security AdministratorやGlobal Administratorを常用する |
| Troubleshooting Mode権限 | 必要最小限のDefender XDRカスタムロールで付与する | ポリシー作成・変更まで可能な権限をまとめて渡す |
| 対象デバイス | MDEデバイスグループで端末範囲を限定する | すべてのデバイスに対して有効化できる状態にする |
| 監査 | Action Center、Device Timeline、Advanced Huntingで確認する | 「誰かが作業したはず」という運用メモだけに頼る |
ポイントは、Troubleshooting Modeのボタンを表示させることではありません。ポリシー変更の入り口を開かず、必要な端末だけで一時的な調査を許可することが本来の目的です。
Troubleshooting Modeを安易に許可してはいけない理由
Troubleshooting Modeは、誤検知、アプリケーションブロック、パフォーマンス問題などを切り分ける場面で便利です。たとえば、Defender Antivirusのリアルタイム保護、クラウド保護、改ざん防止が影響している可能性を調べるときに、通常はポリシーで固定されている設定を一時的に確認・変更できます。Microsoft Learnでは、アプリケーション互換性や誤検知の調査にTroubleshooting Modeを使えることが説明されています。(Microsoft Learn)
ただし、便利さの裏側にはリスクがあります。改ざん防止が有効な環境では、通常は特定のMicrosoft Defender Antivirus設定が変更できません。しかしTroubleshooting Modeを使うと、必要な調査のために一時的な変更が可能になります。Microsoft Learnでも、改ざん防止によって必要な管理作業が妨げられる場合にTroubleshooting Modeを検討できる一方、モード終了後には保護対象の設定変更が構成済み状態へ戻るとされています。(Microsoft Learn)
つまり、Troubleshooting Modeは「調査用の安全弁」であり、「現場担当者に自由なポリシー変更を許可する仕組み」ではありません。
最小権限RBACで作るべき全体像
Microsoftが公開した設計の要点は、次の3層でアクセスを制御することです。
| レイヤー | 役割 | 実務での設計例 |
|---|---|---|
| Entra IDグループ | 誰に許可するかを管理 | SG-MDE-Troubleshooting-Operators のような専用グループを作る |
| Defender XDRカスタムロール | 何を許可するかを管理 | Troubleshooting Modeに必要な最小限のセキュリティ設定権限を付与する |
| MDEデバイスグループ | どの端末で許可するかを管理 | サーバー、VIP端末、検証端末などをタグや命名規則で分ける |
Microsoft Tech Communityの設計例では、対象ユーザーにSecurity ReaderとカスタムDefender XDRロールを割り当て、同じEntra IDグループをMDEデバイスグループにも関連付けることで、対象デバイス上ではTroubleshooting Modeを使えるが、MDEポリシーの作成や変更はできない状態にしています。(TECHCOMMUNITY.MICROSOFT.COM)
ここで重要なのは、ロールだけで完結させないことです。Microsoft Defender unified RBACではロールとデータソースの割り当てを設計できますが、MDEのデバイス単位の可視性やアクション範囲は引き続きデバイスグループが重要な役割を持ちます。Microsoft Learnでも、MDEデバイスグループはUnified RBACと併用され、割り当てられたユーザーがどのデバイスを表示・操作できるかを決めると説明されています。(Microsoft Learn)
実装手順：ポリシー変更を許可せずTroubleshooting Modeだけ使わせる
対象ユーザーを専用Entra IDグループに集約する
まず、Troubleshooting Modeを使う可能性があるユーザーを専用のMicrosoft Entra IDグループにまとめます。SOCの一次調査担当、Windowsインフラ担当、エンドポイント運用担当など、業務上の必要性があるユーザーだけを入れます。
おすすめは、グループ名から用途が分かるようにすることです。
| グループ名の例 | 用途 |
|---|---|
SG-MDE-TSMode-Operators | Troubleshooting Modeを使う運用担当者 |
SG-MDE-TSMode-Servers | サーバー系デバイスの一時調査担当者 |
SG-MDE-TSMode-Workstations | クライアント端末の一時調査担当者 |
この段階で、グループの参加条件も決めておきます。たとえば「SOCリードの承認が必要」「四半期ごとにメンバーを棚卸しする」「退職・異動時に自動的に外す」といった運用ルールです。
Security Readerなどの調査用権限をベースにする
Troubleshooting Mode専用アクセスを作る場合でも、対象ユーザーにはデバイス情報やアラートを確認するための読み取り権限が必要です。一般的には、Security Readerをベースにし、調査に必要な範囲だけを見せます。
ここでSecurity AdministratorやGlobal Administratorを使うと、目的に対して権限が大きすぎます。Microsoft Learnでも、Microsoftは最小権限のロール利用を推奨しており、Global Administratorは既存ロールで対応できない緊急時に限定すべき高権限ロールだと説明しています。(Microsoft Learn)
Defender XDRカスタムロールで必要な権限だけを付与する
次に、Microsoft Defenderポータルでカスタムロールを作成します。狙いは、Troubleshooting Modeを有効にするために必要なセキュリティ設定系の権限だけを付与し、ポリシー作成・変更、ロール管理、システム設定変更などを含めないことです。
Microsoft Learnでは、Troubleshooting Modeを有効にするにはMicrosoft Defender for Endpointの「Manage security settings」権限が必要だと説明されています。Unified RBACの権限定義では、Authorization and settings配下にCore security settings、Authorization、Detection tuning、System settingsなどの権限が整理されています。(Microsoft Learn)
実務では、次のように判断します。
| 権限カテゴリ | 付与判断 | 理由 |
|---|---|---|
| Security data basics / 読み取り系 | 必要に応じて付与 | デバイス状態やアラート確認に必要 |
| Core security settingsの管理系 | Troubleshooting Modeに必要な範囲で検討 | TS Mode有効化に関係するため |
| Authorizationの管理 | 原則付与しない | ロールやデバイスグループ管理まで可能になる恐れがある |
| System settings | 原則付与しない | Defenderポータル全体の設定変更につながる |
| Detection tuning | 調査専用なら原則付与しない | 検知調整や除外運用と責任範囲が異なる |
| Intuneのポリシー管理権限 | 付与しない | エンドポイントセキュリティポリシー変更を防ぐため |
画面や権限名はテナントのRBACモデル、言語設定、Microsoft Defenderポータルの更新状況によって変わる可能性があります。権限名だけで判断せず、「このロールで何が作成・変更できるか」をテストアカウントで確認してください。
MDEデバイスグループで端末範囲を制限する
カスタムロールだけでは不十分です。対象端末を限定するため、MDEデバイスグループを作成します。
Microsoft Learnでは、MDEデバイスグループを使うことで、特定のMicrosoft Entraユーザーグループに対して、関連するアラートやデータへのアクセス、特定アクションの実行範囲を制御できると説明されています。デバイスグループは、デバイス名、ドメイン、タグ、OSプラットフォームなどの条件で構成できます。(Microsoft Learn)
おすすめは、デバイスタグを使ったスコープ設計です。
| スコープ例 | デバイスグループ条件の例 | 向いている用途 |
|---|---|---|
| 検証端末のみ | MDE-TS-Testタグ | 権限設計の初期検証 |
| 特定サーバー群 | サーバー名プレフィックスやタグ | アプリ障害・性能問題の切り分け |
| 特定地域・部門端末 | 命名規則、ドメイン、タグ | グローバル運用での責任分界 |
| 重要端末を除外した一般端末 | タグと除外設計 | 影響範囲を抑えた運用 |
注意点として、MDEデバイスグループにEntra IDグループを割り当てない場合、ポータルアクセスを持つすべてのユーザーにアクセス可能になる既定動作があります。また、デバイスが複数グループに一致した場合は最上位ランクのグループにのみ追加されます。デバイスグループのランクと未分類デバイスの扱いは、必ず本番適用前に確認してください。(Microsoft Learn)
テストアカウントで「できること」と「できないこと」を確認する
設定後は、対象ユーザーで実際にログインし、次の観点を確認します。
| 確認項目 | 期待する結果 |
|---|---|
| スコープ内デバイスのデバイスページを開けるか | 開ける |
| Troubleshooting Modeを有効化できるか | 有効化できる |
| スコープ外デバイスで同じ操作ができるか | できない、または対象デバイスが見えない |
| MDEポリシーやAVポリシーを作成・変更できるか | できない |
| Intuneのエンドポイントセキュリティポリシーを変更できるか | できない |
| Advanced HuntingやDevice Timelineでイベントを確認できるか | 調査権限の範囲内で確認できる |
Microsoft Tech Communityの設計例でも、構成後のユーザーはスコープ対象デバイスでTroubleshooting Modeを利用できる一方、MDEポリシーの作成・変更はできない状態になると説明されています。(TECHCOMMUNITY.MICROSOFT.COM)
運用ルールで決めておくべきこと
Troubleshooting Mode専用アクセスは、RBAC設定だけで終わらせると危険です。SOC、Windows運用、エンドポイントセキュリティ設計者の間で、最低限次のルールを決めておきましょう。
| ルール | 決める内容 | 理由 |
|---|---|---|
| 利用条件 | 誤検知、性能劣化、アプリ互換性など、利用してよいケース | 「とりあえず無効化」を防ぐ |
| 承認 | 誰の承認で使えるか | 作業責任を明確にする |
| 対象範囲 | どのデバイスグループで許可するか | 影響範囲を限定する |
| 作業記録 | チケット番号、対象端末、開始・終了時刻、変更内容 | 事後調査に備える |
| 期限 | グループ参加や作業許可の有効期限 | 恒久的な強権化を防ぐ |
| レビュー | 月次または四半期でメンバーと利用履歴を確認 | 権限の残留を防ぐ |
特に重要なのは、Troubleshooting Modeの利用者と、MDE/Intuneのポリシー管理者を分けることです。調査担当者が「一時的に設定を変えて原因を確認する」ことと、管理者が「組織の標準ポリシーを変更する」ことは別の権限として扱うべきです。
監査はAction CenterとAdvanced Huntingを組み合わせる
Troubleshooting Modeを安全に運用するには、誰が、いつ、どの端末で有効化したのかを追跡できる状態にしておく必要があります。
Microsoft Learnでは、Troubleshooting Modeの開始と終了はMicrosoft DefenderポータルのデバイスページのDevice Timelineで確認でき、Advanced Huntingで関連イベントをクエリできると説明されています。また、Troubleshooting Modeは有効化後4時間で自動的に終了し、1デバイスあたり1日最大8時間という制限があります。(Microsoft Learn)
Advanced Huntingでは、まず次のようなクエリでTroubleshooting Mode関連イベントを確認します。
DeviceEvents
| where Timestamp > ago(7d)
| where ActionType == "AntivirusTroubleshootModeEvent"
| extend props = parse_json(AdditionalFields)
| project
Timestamp,
DeviceName,
DeviceId,
State = tostring(props.TroubleshootingState),
Reason = tostring(props.TroubleshootingStateChangeReason),
AdditionalFields
| order by Timestamp desc監査で注意したいのは、イベントだけで完全なユーザー帰属を断定しないことです。Microsoft Tech Communityの設計例では、改ざん防止やTroubleshooting Mode関連イベントはMDEテレメトリで確認できる一方、特定のイベント項目には開始ユーザー名が記録されない場合があると説明されています。そのため、Action Centerの情報やEntra IDサインインイベントとの時間相関も併用して確認する設計が紹介されています。(TECHCOMMUNITY.MICROSOFT.COM)
実務では、次の3点をセットで見ると精度が上がります。
| 確認先 | 見る内容 | 注意点 |
|---|---|---|
| Device Timeline | 対象デバイスでTS Modeが開始・終了した時刻 | デバイス単位の事実確認に向く |
| Action Center | 実行されたアクションと状態 | ユーザー確認に役立つ場合がある |
| Entra IDサインインログ | 同時刻にDefenderポータルへアクセスしたユーザー | 時間相関であり、単独では実行者の証明にしない |
よくある失敗と回避策
| 失敗例 | 起きる問題 | 回避策 |
|---|---|---|
| Security Administratorを付与して済ませる | ポリシー変更や広い管理操作まで可能になる | カスタムロールで必要権限だけを付与する |
| デバイスグループを設定しない | 対象端末が広がりすぎる | タグや命名規則でスコープを作る |
| Entra IDグループとデバイスグループの対応が曖昧 | 誰がどの端末を操作できるか分からなくなる | グループ名と説明欄に用途・範囲を書く |
| Intune側の権限を同時に渡す | エンドポイントセキュリティポリシーを変更できてしまう | TS Mode担当者とポリシー管理者を分離する |
| 監査クエリだけで実行者を断定する | 誤った責任追及につながる | Action Center、チケット、サインインログを突き合わせる |
| 本番全体に一気に適用する | 想定外の表示・操作が可能になる | 検証用デバイスグループで先に確認する |
| グループメンバーを棚卸ししない | 異動後も権限が残る | 定期レビューと期限付き運用を入れる |
Unified RBACと従来RBACの違いにも注意する
MDEのRBAC設計では、テナントがUnified RBACを使っているか、従来のMDE RBACを使っているかで画面や設定箇所が変わる場合があります。Microsoft Learnでは、2025年2月16日以降の新しいMicrosoft Defender for Endpoint顧客はUnified RBACのみを利用し、既存顧客は現在のロールと権限を保持すると説明されています。(Microsoft Learn)
そのため、手順書を作るときは「Settings > Permissions > Roles」とだけ書くのではなく、次の情報も入れておくと現場で迷いません。
| 手順書に書くべき項目 | 例 |
|---|---|
| 対象RBACモデル | Unified RBAC / 従来のMDE RBAC |
| 対象データソース | Microsoft Defender for Endpoint |
| 割り当てるEntra IDグループ | SG-MDE-TSMode-Operators |
| 対象デバイスグループ | DG-MDE-TSMode-Workstations |
| 許可する操作 | Troubleshooting Modeの有効化、調査に必要な閲覧 |
| 禁止する操作 | MDE/Intuneポリシー作成、ロール管理、システム設定変更 |
この設計が向いているケース、向いていないケース
Troubleshooting Mode専用アクセスは、すべての運用課題を解決する万能策ではありません。使うべき場面と使うべきでない場面を分けることが重要です。
| ケース | 利用判断 |
|---|---|
| Defender Antivirusが業務アプリを誤検知している可能性がある | 向いている |
| MsMpEng.exeなどの影響で性能問題を切り分けたい | 向いている |
| 改ざん防止により一時的な確認作業ができない | 向いている |
| 標準の除外設定やAVポリシーを恒久変更したい | 向いていない |
| 全社端末で一斉に保護設定を緩めたい | 向いていない |
| 誰が操作したか追跡できない環境で使いたい | 向いていない |
恒久的な設定変更が必要な場合は、Troubleshooting Modeで回避し続けるのではなく、Intune、Configuration Manager、MDEセキュリティ設定管理など、正式なポリシー管理プロセスで変更すべきです。
導入前チェックリスト
本番導入前に、次のチェックリストを使うと抜け漏れを減らせます。
| チェック項目 | 確認 |
|---|---|
| 対象ユーザーを専用Entra IDグループに集約した | □ |
| Security Readerなどの読み取り権限とTS Mode用権限を分けた | □ |
| カスタムDefender XDRロールに不要な管理権限を含めていない | □ |
| MDEデバイスグループで対象端末を限定した | □ |
| スコープ外デバイスで操作できないことを確認した | □ |
| MDE/Intuneポリシーを作成・変更できないことを確認した | □ |
| Action Center、Device Timeline、Advanced Huntingで監査できる | □ |
| 利用条件、承認者、作業記録、期限を運用ルールにした | □ |
| グループメンバーの定期レビューを決めた | □ |
| 検証デバイスで先に動作確認した | □ |
まとめ：最初に作るべきものは「強い管理者ロール」ではなく「狭い作業レーン」
MDEでTroubleshooting Modeだけを使わせたい場合、管理者権限を広げるのではなく、作業レーンを狭く設計することが重要です。
実装の軸は明確です。専用のEntra IDグループを作り、Troubleshooting Modeに必要な最小限のDefender XDRカスタムロールを割り当て、MDEデバイスグループで対象端末を限定します。そのうえで、IntuneやMDEポリシー変更権限は渡さず、Action CenterやAdvanced Huntingで監査できる状態にします。
まず着手すべきことは、対象ユーザー、対象デバイス、禁止したい操作を1枚に書き出すことです。その後、検証用デバイスグループでテストし、「TS Modeは使えるが、ポリシーは変更できない」ことを確認してから本番展開すると、SOCとインフラ運用の両方にとって扱いやすい最小権限設計になります。
コメント