Microsoft Defender for Endpointの「Device control」は、USBメモリを一律で禁止するだけの機能ではありません。リムーバブルメディア、プリンター、Bluetooth、Windows Portable Deviceなどの周辺機器に対して、読み取り・書き込み・実行・印刷といった操作単位でアクセスを制御するための仕組みです。
管理者がまず確認すべきポイントは、どのデバイスを制御対象にするか、既定動作をAllowにするかDenyにするか、Intuneまたはグループポリシーのどちらで展開するかの3つです。設定を誤ると、USBストレージだけを制限するつもりがプリンターまで止まる、監査だけのつもりが既定動作に引きずられる、といった業務影響が起きます。
2026年6月2日時点のMicrosoft Defender for Endpoint公式情報とDevice control関連ドキュメントを踏まえると、今回管理者が重点的に見るべきなのは「新機能の有無」よりも、デバイス制御を既存のUSB対策・DLP・Intune運用にどう組み込むかです。Defender for Endpointはエンドポイントの防御、検出、調査、対応を担う基盤であり、Device controlはその中でデータ持ち出しや外部機器経由のリスクを抑える実務的な設定領域です。(Microsoft Learn)
Microsoft DefenderのDevice controlで何ができるのか
Device control in Microsoft Defender for Endpointは、ユーザーがPCに接続・利用できる周辺機器を制御する機能です。公式ドキュメントでは、USBメモリなどのリムーバブルストレージ、CD/DVD、プリンター、Bluetoothデバイス、その他の周辺機器の利用制御が例示されています。(Microsoft Learn)
代表的な制御例は次のとおりです。
| やりたいこと | Device controlでの考え方 | 実務での例 |
|---|---|---|
| 未承認USBを使わせない | 特定デバイス以外を拒否 | 会社支給USBのみ読み書き許可 |
| USBは読めるが書き込ませない | 操作単位で書き込みを拒否 | 取引先から受領した媒体は読み取りのみ許可 |
| 暗号化済み媒体だけ許可 | BitLocker暗号化状態を条件にする | BitLocker未暗号化のUSBには書き込み不可 |
| プリンター利用を制限する | プリンター種別やVID/PIDなどで制御 | 社外プリンターや仮想プリンターへの出力を制限 |
| 監査から始める | Advanced huntingやレポートで利用状況を確認 | いきなりブロックせず、接続実態を棚卸し |
重要なのは、Device controlを「USB禁止スイッチ」と考えないことです。現場では、経理部門だけUSB書き込みを許可する、開発部門の一部端末では検証機器を許可する、役員PCは外部記憶媒体を原則拒否する、といった例外設計が必要になります。
変更点として見るべきポイント
今回の公式情報で管理者が押さえるべき変更点は、単一のボタンや画面変更というより、Device controlの位置づけがより明確になっている点です。Defender for Endpoint全体では、エンドポイントからのシグナルをMicrosoft Defenderポータルに集約し、ID、メール、クラウドなどのアラートと相関してインシデント全体を把握する方向性が示されています。(Microsoft Learn)
Device controlについては、次の観点で再確認が必要です。
| 確認観点 | 管理者への影響 |
|---|---|
| Windows標準のデバイスインストール制限との違い | ドライバーインストールを止めたいのか、接続後の読み書きを制御したいのかを分けて設計する |
| Defender for EndpointのDevice control | デバイス種別、操作、ユーザー、ネットワーク条件、ファイル種別など、より細かい制御が可能 |
| Endpoint DLPとの使い分け | 「機器を制御する」のか「機密ファイルのコピーや印刷を制御する」のかを分ける |
| Intune管理 | Attack surface reduction配下でDevice Controlプロファイルを作成し、ポリシーを展開する |
| GPO管理 | ADMX、XML、ネットワーク共有、XML検証を含む運用が必要になる |
特に注意したいのは、Microsoftのデバイス制御機能が「Windowsのデバイス制御」「Defender for EndpointのDevice control」「Endpoint DLP」の3つに整理されている点です。どれか一つで全要件を満たすのではなく、目的ごとに使い分ける必要があります。(Microsoft Learn)
Device controlの影響範囲
Device controlの影響範囲は、単にUSBメモリを挿したときだけではありません。ポリシー設計によっては、プリンター、CD/DVD、スマートフォン、カメラ、外付けSSD、Bluetooth関連の利用にも影響します。
公式情報では、Defender for EndpointのDevice controlが制限できる対象として、Windows Portable Devices、Removable Media、CD/DVD、Printersが挙げられています。Windowsでは「リムーバブルメディアデバイス」はすべてのUSB機器を意味するわけではなく、Windows上でE:ドライブのようなディスクを作成するデバイスが主な対象になります。(Microsoft Learn)
影響を受けやすい業務
| 業務・部門 | 起きやすい影響 | 事前確認すべきこと |
|---|---|---|
| 営業・フィールドサポート | 顧客先で受け取ったUSBが読めない | 読み取り専用の例外が必要か |
| 開発・検証部門 | 評価用デバイスや外部ストレージが使えない | VID/PIDやInstancePathIdで許可できるか |
| 経理・総務 | 銀行・行政手続き用媒体が使えない | 特定端末・特定ユーザーのみ許可するか |
| 印刷業務 | プリンターやPDF出力が制限される | プリンター制御を対象に含めるか |
| セキュリティ監査 | イベントが大量に出る | レポートとAdvanced huntingの確認範囲を決める |
特に外付けSSDやスマートフォンは、デバイスマネージャー上で複数のエントリとして認識される場合があります。公式ドキュメントでも、物理デバイスに関連するすべてのエントリにアクセス許可を与える必要があると説明されています。1つのIDだけ許可しても、ユーザーから見ると「許可したはずなのに使えない」という状態になり得ます。(Microsoft Learn)
Windowsのデバイスインストール制限、Device control、Endpoint DLPの使い分け
Device controlを導入する前に、似た機能との違いを整理しておくと設計ミスを減らせます。
| 機能 | 主な目的 | 向いているケース | 注意点 |
|---|---|---|---|
| Windowsのデバイスインストール制限 | デバイスやドライバーのインストールを許可・拒否 | 特定種類のUSBデバイスをPCに認識させたくない | 接続後のファイル操作制御とは別物 |
| Defender for EndpointのDevice control | 接続されたデバイスへのアクセスを細かく制御 | USBを読み取り専用にする、特定USBだけ許可する | 既定動作や対象デバイス種別の設定ミスに注意 |
| Endpoint DLP | 機密情報のコピー・印刷・保存を制御 | 機密ラベル付きファイルのUSBコピーを止めたい | 機器そのものの許可・拒否とは目的が異なる |
たとえば「すべてのUSBストレージを禁止したい」ならDevice controlで実現できます。一方、「個人情報を含むExcelファイルだけUSBコピーを禁止したい」ならEndpoint DLPの領域です。プリンターについても同じで、「非社内プリンターを制限したい」のか「機密文書の印刷を止めたい」のかで選ぶべき機能が変わります。
管理者が最初に確認すべき設定
Device controlの展開で最も危険なのは、検証不足のままDefault Denyを広範囲に適用することです。USBだけを止めるつもりでも、対象デバイス種別や既定動作の組み合わせによっては想定外のデバイスがブロックされます。
確認すべき基本設定
| 設定項目 | 確認内容 | 判断基準 |
|---|---|---|
| Device controlの有効化 | DeviceControlEnabledが有効か | まずパイロット端末だけで有効化 |
| 既定の強制動作 | AllowかDenyか | 初期は監査または限定Denyが安全 |
| 対象デバイス種別 | RemovableMediaDevices、CdRomDevices、WpdDevices、PrinterDevicesなど | USBストレージだけなら対象を絞る |
| 許可・拒否ルール | Included Devices、Excluded Devices、Accessの定義 | 例外デバイスを明示的に除外 |
| 監査設定 | イベント送信や通知の有無 | 展開初期は監査ログを必ず確認 |
| 管理方式 | Intune、GPO、OMA-URIのどれを使うか | クラウド管理中心ならIntuneを優先 |
Intuneでは、Endpoint securityのAttack surface reductionからDevice Controlプロファイルを作成できます。設定画面ではDefender、Device Control、Device Installation Restrictions、Removable Storage Access、Storage、Connectivity、Bluetoothなど複数の設定カテゴリが表示されますが、公式ドキュメントでは最初からすべてを構成する必要はなく、Device Control設定から始める考え方が示されています。(Microsoft Learn)
Intuneで展開する場合の注意点
Microsoft IntuneでDevice controlを管理する場合、基本的な流れは「プロファイル作成」「設定」「スコープタグ」「割り当て」「確認」です。公式手順では、Intune管理センターのEndpoint security > Attack surface reductionからポリシーを作成し、PlatformにWindows、ProfileにDevice Controlを選択します。(Microsoft Learn)
Intune展開で失敗しやすいポイント
| 失敗例 | 原因 | 対策 | |
|---|---|---|---|
| 監査ポリシーだけ作ったのに動作が想定と違う | 監査だけの場合、権限は既定の強制設定を継承する | AllowまたはDenyポリシーもセットで設計する | |
| ルールの順番で制御できると思っていた | UI上の順番は強制処理の順序として保持されない | 対象外デバイスをExcluded Devicesで明示する | |
| Default Denyでプリンターまで止まる | 対象デバイス種別や例外ルールが不足 | ストレージだけ管理したい場合はプリンター許可を設計 | |
| OMA-URIが反映されない | 共同管理環境でIntune側にワークロードがない | Configuration Managerとのワークロード管理を確認 | |
| デバイス種別の文字列が正しくない | 区切り文字やスペースの誤り | RemovableMediaDevices | CdRomDevicesのように空白なしで指定 |
IntuneのDevice Controlプロファイルでは、各行が1つのDevice controlポリシーとして扱われます。Included Devices、Excluded Devices、Accessを組み合わせて制御します。Microsoftは、監査ポリシーを追加する場合でも、予期しない結果を避けるためAllowまたはDenyポリシーを併用することを推奨しています。(Microsoft Learn)
グループポリシーで展開する場合の注意点
オンプレミスActive Directory中心の環境では、グループポリシーでDevice controlを展開するケースもあります。公式ドキュメントでは、Computer Configuration > Administrative Templates > Windows Components > Microsoft Defender Antivirus > Features > Device Controlから有効化する手順が示されています。(Microsoft Learn)
グループポリシー運用では、IntuneよりもXMLファイル管理の比重が大きくなります。グループ定義とポリシールールをそれぞれXMLで作成し、ネットワーク共有に配置してGPOから参照します。
GPO展開で確認すべきこと
| 確認項目 | 内容 |
|---|---|
| ADMXの有無 | GPO項目が見えない場合、WindowsDefender.admx/admlが必要 |
| XMLのルート要素 | グループはPolicyGroups、ルールはPolicyRules |
| ネットワーク共有 | 対象端末がXMLファイルを読み取れる権限を持つか |
| XMLコメント | コメントは最初のXMLタグの内側に置く |
| XML検証 | MpCmdRun.exe -DeviceControl -TestPolicyXmlで事前検証 |
| Default Denyの影響 | CD/DVD、WPD、PrinterDevicesまで影響しないか確認 |
GPOでは、対象デバイス種別をパイプ記号で区切った単一文字列として指定します。スペースを入れると正しく解析されず、予期しない動作につながる可能性があるため注意が必要です。(Microsoft Learn)
ポリシー設計の考え方
Device controlのポリシーは、ざっくり言えば「どのデバイスに対して」「どの操作を」「許可・拒否・監査するか」を定義するものです。公式ドキュメントでは、ポリシーはルールとグループで構成され、対象デバイスがIncluded Groupsに含まれ、Excluded Groupsに含まれない場合に適用されると説明されています。該当ルールがない場合は既定の強制動作が適用されます。(Microsoft Learn)
おすすめの設計順序
| 手順 | 作業 | 目的 |
|---|---|---|
| 現状把握 | Device control reportやAdvanced huntingで接続実態を確認 | どのUSB、プリンター、WPDが使われているか把握 |
| 対象整理 | 業務上必要なデバイスを分類 | 全社許可、部門限定、禁止に分ける |
| 既定動作決定 | Allowから始めるかDenyにするか決める | 業務影響とセキュリティ要求のバランスを取る |
| 例外設計 | 許可デバイス、読み取り専用デバイスを定義 | 一律禁止による業務停止を防ぐ |
| 監査展開 | パイロット端末でイベントを確認 | 誤検知や不足ルールを修正 |
| 段階展開 | 部門・端末グループ単位で拡大 | 問い合わせと業務影響を抑える |
初心者がやりがちな失敗は、「すべて拒否して、必要なものだけ後から許可すればよい」と考えることです。セキュリティ上は正しそうに見えますが、実務では承認済みUSBの識別情報が不十分だったり、複合デバイスの一部エントリを見落としたりして、業務が止まることがあります。
最初は「監査で実態を把握」「読み取りだけ許可」「書き込みだけ制限」のように、業務影響が読みやすい設計から始めるのが現実的です。
デバイス識別で見るべきプロパティ
Device controlでは、デバイスをグループ化するために複数のプロパティを使います。代表的なものは、VID、PID、VID_PID、SerialNumberId、InstancePathId、HardwareId、FriendlyNameIdなどです。(Microsoft Learn)
| プロパティ | 特徴 | 使いどころ |
|---|---|---|
| VID/PID | ベンダーIDと製品IDの組み合わせ | 同一型番のUSBをまとめて制御 |
| SerialNumberId | 個体を識別しやすい | 会社支給の特定USBだけ許可 |
| InstancePathId | デバイスインスタンスパス | 詳細な個体識別に使う |
| HardwareId | ハードウェア種別の識別 | 同種デバイスの分類 |
| FriendlyNameId | 表示名ベース | 補助的な識別に向く |
| DeviceEncryptionStateId | BitLocker暗号化状態 | 暗号化済み媒体だけ許可する場合 |
特にSerialNumberIdとInstancePathIdは、許可デバイスを絞り込むうえで有効です。ただし、InstancePathIdの末尾にはスロット情報など変わり得る要素が含まれる場合があるため、公式ドキュメントではワイルドカードの利用例も示されています。(Microsoft Learn)
Advanced huntingとレポートで確認する
Device controlは、展開して終わりではありません。運用では、イベントを見て「何がブロックされたか」「誰がどのデバイスを使おうとしたか」「許可ルールが期待どおり機能したか」を確認する必要があります。
Microsoft Defenderポータルでは、Advanced huntingやDevice control reportでデバイス制御イベントを確認できます。Device controlポリシーがトリガーされると、ユーザー操作またはシステム起因にかかわらずAdvanced huntingでイベントを確認できます。(Microsoft Learn)
DeviceEvents
| where ActionType == "RemovableStoragePolicyTriggered"
| extend parsed=parse_json(AdditionalFields)
| extend RemovableStorageAccess = tostring(parsed.RemovableStorageAccess)
| extend RemovableStoragePolicyVerdict = tostring(parsed.RemovableStoragePolicyVerdict)
| extend MediaBusType = tostring(parsed.BusType)
| extend MediaClassName = tostring(parsed.ClassName)
| extend MediaDeviceId = tostring(parsed.DeviceId)
| extend MediaInstanceId = tostring(parsed.DeviceInstanceId)
| extend MediaName = tostring(parsed.MediaName)
| extend RemovableStoragePolicy = tostring(parsed.RemovableStoragePolicy)
| extend MediaProductId = tostring(parsed.ProductId)
| extend MediaVendorId = tostring(parsed.VendorId)
| extend MediaSerialNumber = tostring(parsed.SerialNumber)
| project Timestamp, DeviceName, InitiatingProcessAccountName, RemovableStorageAccess,
RemovableStoragePolicyVerdict, MediaClassName, MediaName,
RemovableStoragePolicy, MediaVendorId, MediaProductId, MediaSerialNumber
| order by Timestamp descAdvanced huntingでは、RemovableStoragePolicyTriggeredイベントに対して1デバイスあたり1日300件の制限があるとされています。より多くのデータを確認する場合はDevice control reportを併用します。(Microsoft Learn)
Device control reportでは、監査イベントとポリシーイベントを確認できます。USBのマウント・アンマウント、Plug and Playイベント、リムーバブルストレージアクセス制御のAudit・Block・Allowなどを把握できるため、展開前の棚卸しにも役立ちます。(Microsoft Learn)
移行・展開時のチェックリスト
既存のUSB制御、グループポリシー、サードパーティ製DLP、Intune構成プロファイルから移行する場合は、単に設定を置き換えるのではなく、現在の制御意図を分解してから再設計することが重要です。
移行前に確認すること
| チェック項目 | 確認内容 |
|---|---|
| 現行ルールの目的 | インストール禁止なのか、読み書き制御なのか、機密データ保護なのか |
| 対象端末 | Windows 10/11、macOS、サーバーのどれか |
| 管理基盤 | Intune、GPO、Configuration Manager共同管理の状況 |
| 例外デバイス | 会社支給USB、検証機器、業務プリンター、スマートフォン |
| 例外ユーザー | 情シス、経理、開発、役員など |
| 監査要件 | 誰が、いつ、どの媒体に、何をしたか確認する必要があるか |
| ユーザー通知 | ブロック時の問い合わせ導線を用意しているか |
公式ドキュメントでは、Device control in Defender for Endpointの前提条件として、Windows 10またはWindows 11で、anti-malware client version 4.18.2103.3以降が必要とされています。また、現時点でサーバーはサポート対象外とされています。(Microsoft Learn)
ただし、Defender for Endpoint全体としてはサーバー向けライセンスやオンボーディングの説明も存在します。ここで混同しやすいのは、「Defender for Endpointでサーバーを保護できること」と「Device controlの対象にサーバーを含められること」は別問題だという点です。Device controlの展開計画では、必ず対象機能ごとのサポート範囲を確認してください。(Microsoft Learn)
開発者・情シスが注意すべき実務ポイント
Device controlはセキュリティ部門だけの設定ではありません。開発者、ヘルプデスク、端末管理担当にも影響します。
開発・検証環境での注意
開発部門では、評価ボード、外付けSSD、スマートフォン、カメラ、デバッグ用端末など、一般部門より多様なデバイスを使います。一律Denyにすると、ビルド成果物の受け渡しや実機検証が止まる可能性があります。
対策として、開発部門向けには次のような分離が現実的です。
| 対象 | 推奨ルール例 |
|---|---|
| 会社支給外付けSSD | SerialNumberIdでフルアクセス許可 |
| 検証用USB | 特定端末・特定ユーザーだけ書き込み許可 |
| 私物USB | 読み取りも書き込みも拒否 |
| スマートフォン接続 | WPDとして必要範囲のみ許可 |
| 顧客提供媒体 | 読み取り専用、書き込み拒否 |
開発者向けには、ブロックされた場合の申請手順も用意しておくべきです。問い合わせ時に必要な情報として、端末名、接続時刻、デバイス名、VID/PID、SerialNumberId、利用目的をテンプレート化しておくと、例外登録の判断が速くなります。
ヘルプデスクでの注意
Device control導入後は、「USBが壊れた」「プリンターが消えた」「スマホが認識されない」といった問い合わせが増えやすくなります。ヘルプデスクは、まず物理故障ではなくポリシー適用の可能性を確認できるようにしておく必要があります。
確認の流れは次のとおりです。
| 手順 | 確認内容 |
|---|---|
| 端末名とユーザーを確認 | 対象ポリシーが割り当てられているか |
| 接続時刻を確認 | Advanced huntingやレポートでイベントを探す |
| Verdictを確認 | Allow、Deny、Auditのどれか |
| MediaClassNameを確認 | USB、WPD、Printerなど対象種別を確認 |
| 例外要否を判断 | 業務上必要なら申請フローへ |
段階展開のおすすめパターン
実務では、次の順序で展開すると失敗を減らせます。
| フェーズ | 内容 | 成功条件 |
|---|---|---|
| 監査フェーズ | Device control reportで現状の接続状況を収集 | 業務で使われている媒体を把握できる |
| パイロットフェーズ | 情シス端末や少数ユーザーでDenyを検証 | 想定外のブロックを洗い出せる |
| 部門展開 | 高リスク部門または統制しやすい部門から適用 | 問い合わせ対応手順が機能する |
| 全社展開 | 例外申請と監査運用を整えて拡大 | 業務停止なく制御が定着する |
| 定期見直し | 許可デバイスと例外ユーザーを棚卸し | 不要な例外を削除できる |
最初から全社Default Denyにするのは避けたほうが安全です。セキュリティ要件が厳しい場合でも、まずは監査ログから接続実態を把握し、業務上必要な媒体を分類してから拒否ルールを展開する方が、結果的に早く安定します。
管理者が今すぐ確認すべきこと
Microsoft DefenderのDevice controlを導入済み、またはこれから導入する管理者は、次の順番で確認するとよいでしょう。
- Device controlが有効化されている端末と未設定端末を把握する
- Default enforcementがAllowかDenyかを確認する
- 対象デバイス種別にPrinterDevicesやWpdDevicesが含まれていないか確認する
- 監査だけのポリシーになっていないか確認する
- Allow/Denyルールの対象と除外が重複していないか確認する
- Intuneの割り当てがユーザーグループ条件と二重管理になっていないか確認する
- Advanced huntingとDevice control reportで直近のブロックイベントを確認する
- ヘルプデスク向けに問い合わせテンプレートを用意する
特に、ユーザー条件を使う場合は注意が必要です。公式ドキュメントでは、ユーザーやユーザーグループ条件をルール内に設定する方法と、Intuneのユーザーグループターゲットを併用しないよう警告されています。また、Microsoft Entra IDを参照するユーザー条件は、Entra IDへの接続が安定している環境で使うべきとされています。(Microsoft Learn)
Device controlは「禁止」ではなく「業務に合わせた制御」として設計する
Device control in Microsoft Defender for Endpointは、USBメモリ、外付けストレージ、プリンター、Bluetooth、Windows Portable Deviceなどを細かく制御できる強力な機能です。一方で、既定動作や対象デバイス種別、例外ルールを誤ると、業務に直結するトラブルを起こします。
管理者が次に取るべき行動は、いきなり全社ブロックを設定することではありません。まずDevice control reportとAdvanced huntingで利用実態を確認し、業務上必要なデバイス、禁止すべきデバイス、読み取り専用でよいデバイスを分類してください。そのうえで、IntuneまたはGPOでパイロット展開し、ログと問い合わせを見ながら段階的に適用範囲を広げるのが現実的です。
Microsoft DefenderのDevice controlは、正しく設計すればデータ持ち出し対策、マルウェア侵入経路の削減、監査証跡の強化に役立ちます。逆に、設計を省略すると「止めたいものは止まらず、使いたいものだけ止まる」状態になりかねません。導入時は、セキュリティ要件だけでなく、部門ごとの業務フローまで含めてルール化することが成功のポイントです。
コメント