USB 制限 GPO, デバイス制御 Windows, 情報漏洩対策

1 はじめに
2 「禁止だけ」の落とし穴
3 3層設計（関所を重ねる）
4 例外運用（“許す”の設計）
5 監査と可視化（“記録する”）
6 インシデント対応フロー
7 導入順序（安全ロールアウト）
8 よくある誤解（短文FAQ）
9 付録（コピペ可の最小セット）
- 9.1 A. 最小GPO一覧（日本語UI名）
- 9.2 B. MDE Advanced Hunting クエリ雛形
10 まとめ
11 公式注釈

はじめに

「USB は禁止」だけでは、業務継続と説明責任を同時に満たしにくい状況が生まれます。

実効性を持たせるには、止める（既定で拒否）・許す（例外の設計）・記録する（監査）をひとつの仕組みとして運用する必要があります。

本記事では、GPOでインストールとアクセスを分けて制御し、必要に応じて Defender Device Control で粒度を上げる方法をまとめます。

例外は個人裁量ではなく「構成（グループ）」として定義し、期限付きで付与・失効させる前提でまとめます。

前提（IT 部門向け）

・対象読者：オンプレミス Active Directory（GPO）を運用する企業の情報システム部門の方です。
・対象 OS：Windows 11（Pro / Enterprise / Education）
・制御範囲：USB 等のリムーバブル媒体に加え、WPD（スマートフォン MTP/PTP） と CD/DVD を含みます。
・オプション：Microsoft Defender for Endpoint は任意です（導入済みであれば Device Control と Advanced Hunting を活用します）。
・方針：管理者上書き不可を前提に、AD グループやInclude/Excludeで例外を表現し、監査 → ReadOnly → 既定 Deny の順で段階導入します。

はじめに

単純な「全面禁止」は、実運用で必ず破綻します。

・正規業務の停止: オフライン環境へのパッチ適用、ベンダー提供の診断ツール、大容量データの物理受領など、IT部門の正規業務が停止します。
・抜け道と誤爆: [リムーバブルディスク] だけを禁止すると、WPD (スマートフォン) が抜け道になります。逆に [すべてのリムーバブル記憶域クラス] を禁止すると、USB接続のプリンターやライセンスドングルまで誤爆・停止するリスクがあります。
・説明責任の欠落: 監査ログと例外プロセスをセットで設計しなければ、インシデント発生時に「なぜ例外が許可されていたか」または「なぜ制御が失敗したか」の説明責任を果たせません。

「禁止だけ」の落とし穴

「止める」機能は、目的の異なる複数の「層」で設計します。

3層設計（関所を重ねる）

・目的: 未知のデバイスがOSに認識（インストール）されるのを防ぐ、最も強力な関所です。
・GPO:
- -[他のポリシー設定で記述されていないデバイスのインストールを防止する (Prevent installation of devices not described by other policy settings)] = 有効
- -[これらのデバイス ID と一致するデバイスのインストールを許可する (Allow installation of devices that match any of these device IDs)] = 有効 (社用USBのVID/PIDリストを指定)
- -[管理者がデバイスのインストール制限ポリシーを上書きできるようにする (Allow administrators to override Device Installation Restriction policies)] = 無効 (ローカル管理者による上書きを禁止します)
- -[デバイスのインストールの制限ポリシーの評価順序を適用する (Apply layered order of evaluation...)] = 有効

A. デバイス導入抑止 (Device Installation Restrictions)

・目的: レイヤAでインストールを許可したデバイスの「使い方（読み書き）」を制御します。
・GPO:
- -基本: [すべてのリムーバブル記憶域クラス: すべてのアクセスを拒否する (All Removable Storage classes: Deny all access)] = 有効 (読み書き双方を拒否。個別設定より優先される強力な設定です)
- -緩和策: 読み取りのみ許可する場合は、上記を「未構成」にし [リムーバブルディスク: 書き込みアクセスを拒否する (Removable Disks: Deny write access)] = 有効にします。(※この緩和策を採用する場合でも、WPDデバイスの拒否は別途必須です)
- -抜け道対策: [WPD デバイス: 読み取りアクセスを拒否する (WPD Devices: Deny read access)] および [WPD デバイス: 書き込みアクセスを拒否する (WPD Devices: Deny write access)] = 有効 (WPDは別クラスのため明示的な拒否が必須です)

B. 記憶媒体アクセス抑止 (Removable Storage Access) ＋WPD

・目的: レイヤBの緩和策（書き込み許可）を採用する場合に、暗号化を強制します。
・GPO: [BitLocker で保護されていないリムーバブルドライブへの書き込みアクセスを拒否する (Deny write access to removable drives not protected by BitLocker)] = 有効
・注記: この設定は、レイヤBの [リムーバブルディスク: 書き込みアクセスを拒否する] が有効な場合、そちらの「絶対拒否」が優先され、無視されます。

B-補. 暗号前提 (BitLocker To Go)

・目的: GPOより詳細な（シリアル番号単位、ユーザー単位）制御と監査を実現します。
・導入: 初期は Default Enforcement = Allow ＋ Audit ルールでテレメトリ（利用実態）を収集します。
・移行: 例外ルールを整備した後、Default Enforcement = Deny (既定拒否) へ切り替えます。
・注意: DefaultDeny はプリンターやBluetoothなども対象です。業務停止を防ぐため、プリンタークラス等を Allow (許可) するルールを必ず先に配置してください。

C. 高度化 (Defender Device Control：任意)

「原則禁止」を維持しつつ、業務に必要な許可を安全に実装します。

・単位: 役職、部門、または端末（ADのセキュリティグループ）単位で例外を定義します。
・種別: 社用USB（特定のVID/PIDやシリアル番号）に限り、Write (書き込み可)、ReadOnly (読み取り専用)、または期限付きで許可します。
・実装: GPOの場合は「セキュリティフィルター処理」やOUリンクで適用範囲を制御します。MDEの場合は Include (対象) / Exclude (除外) グループで定義します。
・最重要注意点: GPOで例外を実装する場合、例外適用先のOUに対しても [WPD デバイス...拒否] ポリシーを**必ず再宣言（別途リンク）**してください。(これを怠ると、WPD（スマホ）が抜け道として開通します)

例外運用（“許す”の設計）

制御の動作証跡（ブロック、許可）を取得し、説明責任を果たします。

・GPO (必須): Advanced Audit Policy Configuration (高度な監査ポリシーの構成) を有効化します。
- -[PnP アクティビティの監査 (Audit PnP Activity)] (成功) → Event ID 6416: デバイスが差し込まれた証跡。
- -[リムーバブル記憶域の監査 (Audit Removable Storage)] (成功/失敗) → Event ID 4663/4656: ファイルアクセスや拒否の証跡。
・MDE (任意): Advanced Hunting (AH) で DeviceEvents テーブルを検索します。
- -主なイベント: PnpDeviceConnected (PnP)、RemovableStoragePolicyTriggered (ポリシー発動)。(UsbDriveMounted/Unmounted は補助的に使用します)
・仕様注記:
- -通知: 拒否時のトースト通知は、初回拒否後は概ね1時間に1回に制限されます。監査 (Audit) のみではユーザー通知は出ません。
- -AH上限: RemovableStoragePolicyTriggered イベントは、短時間に多発した場合、1端末/日あたり約300件に集約される可視化上限があります。(詳細はデバイスコントロールレポートを参照してください)

監査と可視化（“記録する”）

検知: 監査ログ (4663の失敗多発等) やMDEアラート (RemovableStoragePolicyTriggered) をトリガーに検知します。
封じ込め: (MDE利用時) 端末を デバイスの分離 (Isolate device) します。(GPOのみの場合) 該当端末のネットワーク隔離（ポートシャットダウン等）を実施します。
初動調査: 監査ログ (6416/4663) やAHクエリで、「いつ」「どのデバイスが」「何をしたか」を特定します。
原因特定: GPOの例外設定ミス、VID/PIDの登録漏れ、BitLocker要件の不備など、設計の穴を特定します。
再発防止: GPO/Defenderのルールを修正し、必要に応じて例外許可を失効させます。

インシデント対応フロー

いきなり全社拒否せず、必ず段階的に導入します。

監査フェーズ (2–4週): 拒否 (Deny) せず、まずは「監査 (Audit)」モードで全社適用します。イベントログ (6416/4663) やAHで「現在利用されているデバイス」の棚卸しを行います。
ReadOnly パイロット: IT部門など影響範囲の少ない部署で「書き込みのみ拒否 (Deny write)」を先行適用し、業務影響を測定します。
例外整備: Step 1の棚卸し結果に基づき、必須デバイス（プリンター等）のAllowルールや、社用USBの許可リスト（レイヤA/C）を整備します。
既定拒否 (Deny All) 切替: 整備した例外ルールを適用した上で、全社に対して「既定拒否 (Deny all)」ポリシー（レイヤBまたはC）へ切り替えます。

導入順序（安全ロールアウト）

Q：管理者ならGPOを一時的に外せばいいですか？
- A：不可です。本設計はレイヤAで [管理者が上書きできるようにする] を無効にすることが前提です。例外は個人の裁量ではなく、「構成（ADグループ）」として定義し、期限付きで付与・失効させるプロセスが必須です。
Q：監査モードでもユーザーに通知（トースト）は出ますか？
- A：出ません。ユーザー通知は、ポリシーによってアクセスが 拒否 (Block) された時のみ表示されます。（初回拒否後は約1時間に1回です）
Q：WPD（スマホ）はUSBメモリと同じ制御で止まりますか？
- A：止まりません。WPDは「リムーバブルディスク」とは 別クラス のデバイスです。レイヤBで [WPD デバイス...拒否] を個別に設定する必要があります。
Q：ネットワークプリンターは影響しますか？
- A：GPO の Removable Storage だけなら通常影響しません。 ただし Defender Device Control を DefaultDeny にすると USB プリンター は止まります。Allow ルールを先に適用します。
Q：『すべてのリムーバブル記憶域クラス：すべてのアクセスを拒否』と『書き込み拒否』の違いは何ですか？
- A：前者は読み取りも含め全面禁止（個別設定より優先）、後者は書き込みのみ拒否で読み取りは可能です。
Q：BitLocker To Go の“未暗号は書き込み拒否”と『書き込み拒否』を両方有効にするとどうなりますか？
- A：『書き込み拒否』が優先します。暗号条件での許可を使う設計時はこの優先関係を前提にします。
Q：例外はユーザー単位／端末単位のどちらで運用すべきですか？
- A：どちらも可能です。 役職・部門はユーザーグループ、特定 PC はコンピューターグループで切り、GPO のセキュリティフィルターや Device Control の Include／Exclude に反映します。
Q：反映タイミングはどの程度ですか？
- A：既定は約 90 分＋ランダムオフセットです。必要に応じて gpupdate /force や再起動で前倒しします。
Q：SD カードや内蔵カードリーダーは対象ですか？
- A：対象です。 リムーバブル記憶域クラスに含まれるため、同様に制御されます。
Q：USB ハブやドッキングステーションを経由すると回避されませんか？
- A：されにくいです。 制御はデバイスクラス／デバイス IDに基づくため、経路が変わってもストレージは同クラスとして扱われます。
Q：ライセンスドングルは影響しますか？
- A：一般に“記憶域”でないドングルは影響しません。 ただし仮想 CD/DVD としてマウントするタイプは影響を受けます。その場合は Deny write での運用や個別許可の検討が必要です。
Q：許可する USB を特定メーカー／機種に限定できますか？
- A：可能です。 GPO では VID/PID（デバイス ID） を許可リストに登録します。個体（シリアル）単位の厳密化が必要なら Device Control を用います。
Q：ポリシーが効いているか簡単に確認する方法はありますか？
- A：あります。 gpresult /h report.html で適用状況を確認し、Event ID 6416／4663／4656 が記録されているかをイベントビューアで確認します。
Q：監査ログ（4663）が多すぎます。どう扱えばよいですか？
- A：範囲を絞ります。 対象ドライブ（例：リムーバブルドライブのドライブレター）や操作種別でフィルタし、定常監視は失敗中心＋サンプリングに寄せます。
Q：OU で例外にしたら WPD が開いてしまいました。
- A：よくある落とし穴です。 例外側の OU にも [WPD 読み取り／書き込みを拒否] を再宣言します。WPD は別クラスのため、リンクを外すと抜け道になります。
Q：『いきなり全社既定拒否』はダメですか？
- A：推奨しません。 監査 → ReadOnly → 既定 Deny の段階導入とし、既定 Deny 前にプリンター等の Allowを先置きします。
Q：通知が出たり出なかったりします。仕様ですか？
- A：仕様です。 通知は拒否時のみで、初回拒否後は概ね 1 時間に 1 回に制限されます。監査のみでは表示されません。
Q：Advanced Hunting でイベントが欠けることがあります。
- A：既知の上限があります。 RemovableStoragePolicyTriggered は 1 端末／日約 300 件に集約されます。Device control report を併用します。

よくある誤解（短文FAQ）

付録（コピペ可の最小セット）

[デバイスのインストールの制限] > [他のポリシー設定で記述されていないデバイスのインストールを防止する] (有効)
[デバイスのインストールの制限] > [これらのデバイス ID と一致するデバイスのインストールを許可する] (有効)
[デバイスのインストールの制限] > [管理者がデバイスのインストール制限ポリシーを上書きできるようにする] (無効)
[デバイスのインストールの制限] > [デバイスのインストールの制限ポリシーの評価順序を適用する] (有効)
[リムーバブル記憶域へのアクセス] > [すべてのリムーバブル記憶域クラス: すべてのアクセスを拒否する] (有効)
[リムーバブル記憶域へのアクセス] > [WPD デバイス: 読み取りアクセスを拒否する] (有効)
[リムーバブル記憶域へのアクセス] > [WPD デバイス: 書き込みアクセスを拒否する] (有効)
[BitLocker ドライブ暗号化] > [BitLocker で保護されていないリムーバブルドライブへの書き込みアクセスを拒否する] (有効)
[高度な監査ポリシーの構成] > [PnP アクティビティの監査] (成功)
[高度な監査ポリシーの構成] > [リムーバブル記憶域の監査] (成功, 失敗)

A. 最小GPO一覧（日本語UI名）

// PnP接続イベント（デバイス接続）
DeviceEvents | where ActionType == "PnpDeviceConnected" | take 10

// PnP接続イベント（デバイス接続）

DeviceEvents | where ActionType == "PnpDeviceConnected" | take 10

// ポリシー発動イベント（ブロックまたは監査）
DeviceEvents | where ActionType == "RemovableStoragePolicyTriggered" | take 10

// ポリシー発動イベント（ブロックまたは監査）

DeviceEvents | where ActionType == "RemovableStoragePolicyTriggered" | take 10

まとめ

禁止設定そのものは容易でも、運用を破綻させずに続けるには設計が必要です。

止める・許す・記録するを最初から一体で設計すると、現場を止めずに統制を強化できます。要点は次のとおりです。

層で停止：
A）Device Installation Restrictions で未知デバイスの導入を抑止します。
B）Removable Storage で読み書きを制御し、WPD は別クラスとして明示的に拒否します。
C）必要に応じて Device Control で周辺機器まで一元管理します。
構成で許可：
例外は AD グループや Device Control の Include/Exclude に明文化し、期限付きで付与します。管理者が手作業で外す運用は採用しません。
証跡による保証：
6416／4663／4656 と（導入済みであれば）DeviceEvents を定常的に可視化します。ユーザー通知は拒否時のみで、監査のみでは表示されません。
段階導入を徹底：
監査 → ReadOnly → 既定 Deny の順で進め、DefaultDeny 前にプリンター等の Allow を先に定義します。