Microsoft Purview Endpoint DLPでUSBへのコピーを禁止しても、NAS（SMB共有）から直接USBやDropbox/Google Driveへ持ち出せるケースがあります。本記事では「なぜすり抜けるのか」を整理し、JIT保護、USBデバイス制御、感度ラベル、iSCSIなど現実的な塞ぎ方を具体例付きで解説します。
結論：Endpoint DLPだけでNAS起点の持ち出しを完全に止めるのは難しい。だから“組み合わせ”が正解
Microsoft Purview Endpoint DLP（以下、Endpoint DLP）は、端末上のファイル操作を検知して「USBへのコピー禁止」「外部クラウドへのアップロード禁止」などを実現する強力な仕組みです。ただし、監視・制御の中心は端末のローカルであり、NASやファイルサーバーの共有フォルダ（SMB共有）上のファイルを直接操作する経路は、ポリシーが“見えない”ことがあります。
その結果、次のような現象が発生します。
- ローカル（C:など）→ USB：ブロックできる
- NAS（SMB共有）→ USB：ブロックされずコピーできてしまう
- NAS上のファイルを直接選択してDropbox/Google Driveへアップロード：ブロックされない
このギャップを埋めるには、Endpoint DLP単体に期待するのではなく、JIT保護で監視対象へ引き寄せるか、USBデバイス制御やネットワーク制御で出口を塞ぐといった補完策を組み合わせる必要があります。
まずは切り分け：同じファイルでも「どこから操作したか」で結果が変わる
対策を決める前に、現象を再現しながら「どの条件で効かないのか」を特定すると、最短で原因に辿り着けます。DWGなどの拡張子でブロックしている場合でも、基本は同じです。
現場でよく効く切り分け手順
- NAS上の対象ファイル（例：sample.dwg）をいったんC:へコピーし、C:からUSBへコピーしてみる（ブロックされるか）
- 同じ端末で、NAS上の同じファイルをNASから直接USBへコピーしてみる（ブロックされるか）
- NAS上の同じファイルを、ブラウザでDropbox/Google Driveのアップロード画面から選択してアップロードしてみる（ブロックされるか）
- 同期型クライアント（Dropbox/Google Drive Desktop等）を使う場合は、ローカル同期フォルダ経由でも同じ検証を行う
この切り分けで「C:経由は止まるが、NAS直は止まらない」なら、ポリシーの作り込み不足ではなく、監視範囲（テレメトリ取得範囲）の問題である可能性が高いです。
なぜNAS→USB/外部クラウドがすり抜けるのか
Endpoint DLPは端末上のエージェントがファイル操作を検知して制御します。ローカルドライブ上の読み書きは検知しやすい一方、NAS（SMB共有）のようなネットワーク上の場所は、端末から見た操作が「ネットワーク越しのアクセス」になり、DLPの監視モデルから外れやすくなります。
ここで混同されやすいのが、Purviewの設定にあるNetwork Share Groups（ネットワーク共有グループ）です。ネットワーク上の場所を分類する仕組みとしては便利ですが、これを設定しただけでNAS上の操作を常時監視できるようになるわけではありません。設定があるのに止まらない、と感じる場合はこのギャップを疑うのが近道です。
つまり根本原因は「ルールが弱い」ではなく、ルールを適用する前提となる“見える化”ができていない点にあります。解決策は、ポリシーを増やすことではなく、データの流れを監視できる形に作り直すことです。
監視範囲を整理：Endpoint DLPが得意な場所、苦手な場所
実務では、まず監視対象を正しく理解しておくと設計がブレません。
| 場所/経路 | 監視しやすさ | 代表例 | コメント |
|---|---|---|---|
| ローカルドライブ | 高い | C:、D:（物理/仮想ディスク） | Endpoint DLPの基本土俵。USB禁止などが効きやすい |
| 対応クラウドと同期されたローカルフォルダ | 高い | OneDrive/SharePoint同期フォルダ | “ローカルに実体がある”ため扱いやすい |
| NAS/ファイルサーバーのSMB共有 | 低い（抜け道になりやすい） | \\server\share | NAS上の直操作は見えにくく、経路対策が必要 |
| USBストレージ（出力先） | 出口としては強制力を持たせやすい | リムーバブルメディア | DLPだけでなくデバイス制御が強い |
| 外部クラウド（SaaS）へのWebアップロード | 中〜低 | Google Drive、Dropbox | 経路やアプリ次第。ネットワーク/Cloud Appsで補完すると強い |
対策の全体像：DLP＋複数レイヤーで“抜け道”を塞ぐ
NAS中心の環境で「持ち出しを止める」には、次のレイヤーを組み合わせるのが最も現実的です。
| レイヤー | 狙い | 強い領域 | 弱い/注意点 |
|---|---|---|---|
| Endpoint DLP | データ分類に基づく制御 | ローカル上のコピー/アプリ操作 | NAS直操作など“見えない経路”が残りやすい |
| JIT保護 | NASアクセスを監視下へ引き寄せる | NAS→USB/外部クラウドの抜け道縮小 | 性能・アプリ相性・キャッシュ挙動の検証が必須 |
| USBデバイス制御（MDE/Intune） | 物理デバイスへの書き込み制限 | NAS起点でも確実に止められる | 業務上必要な例外（受け渡し等）の設計が難しい |
| 感度ラベル（MIP） | ファイルに機密度を付与 | 移動しても“守るべき意図”を維持しやすい | ラベル付与の徹底（自動/既定/教育）が必要 |
| ネットワーク/プロキシ/Cloud Apps | 外部SaaSへの通信経路を制御 | Webアップロードの抑止、シャドーIT対策 | 例外管理と“業務に必要なSaaS”整理が必須 |
| ストレージ戦略 | 監視しやすい保管場所へ寄せる | SharePoint/OneDrive等との統合運用 | 移行コスト、性能、互換性の検討が必要 |
対策① USBデバイス制御で「出口」を先に固める
NAS→USBのすり抜けを最短で塞ぐなら、Microsoft Defender for Endpoint（MDE）やIntuneのデバイス制御でUSBへの書き込み自体を制限する方法が効果的です。DLPが見えない経路でも、最終的にUSBへ書き込む瞬間は端末側で発生するため、端末単位で強制力を持たせられます。
よく使うポリシーパターン
| パターン | 内容 | 向いている組織 | 副作用/注意点 |
|---|---|---|---|
| 全面禁止 | USBストレージへの書き込みを一律ブロック | 持ち出しが原則不要な部門（設計/開発/管理） | 例外が出た瞬間に運用が破綻しやすい |
| 許可リスト方式 | 指定したUSBデバイスIDのみ書き込み許可 | 業務でUSBが必要だが管理下に置ける | 調達/交換/故障時の登録フローが必要 |
| 暗号化必須 | 暗号化されたUSBのみ許可（未暗号化はブロック） | 協力会社との受け渡しが多い | 相手先の運用/対応OSの制約が出る |
| 読み取り専用 | USBからの読み込みは許可、書き込みは禁止 | 外部メディア参照が必要 | マルウェア対策（読み取り側）とセットで考える |
DWGを含む重要データの持ち出しを考えると、USBは「最後の出口」になりやすいです。まずは監査（Audit）で業務影響を把握し、次にブロックへ移行する段階設計が現実的です。
対策② 感度ラベル＋DLPで「ファイルそのもの」に守りを持たせる
NAS中心の環境は「保存場所で守る」発想になりがちですが、持ち出し対策ではファイル自体に機密度を刻むほうが強力です。Microsoft Purview Information Protectionの感度ラベルを、ファイルがNASへ置かれる前（作成・編集段階）で付ける設計にすると、後段のDLPや例外運用が一気に整理しやすくなります。
ラベル運用を成功させるコツ
- DWGは既定でラベル付与：拡張子や保存場所、キーワードなどで推奨/自動ラベルを検討する
- 例外は理由付きで：ラベル変更やポリシー例外は、理由入力や承認フローを型化する
- “公式の共有手段”を先に用意：禁止だけ先に入れると現場は別経路を探すため、Teams/SharePoint等の代替をセットにする
ラベル＋DLPで作る“よくあるルールセット”
| ルール例 | 対象 | アクション | 運用のポイント |
|---|---|---|---|
| 社外秘ラベルはUSB書き込み禁止 | 社外秘/機密ラベル | ブロック（または警告＋承認） | 期限付き例外の申請フローを作る |
| 機密ラベルは非公式クラウドへアップロード禁止 | 機密ラベル | ブロック/監査 | 業務で必要なSaaSは明確に“公式”として定義 |
| 図面ファイルは印刷/スクリーンショットも制限 | .dwg など | 警告/ブロック（要件次第） | 業務影響が大きいので段階導入が必須 |
重要なのは、ラベルが“形だけ”にならないことです。ラベルが正しく付いていれば手戻りが減る、共有が楽になるなど、ユーザーにメリットが返る設計に寄せると定着します。
対策③ Just-in-Time（JIT）保護でNAS直アクセスを監視下に取り込む
PurviewのJust in time protection（JIT保護）を有効にすると、NAS→USBやNAS→Google Driveの操作がブロックされるように見える場合があります。これは、JITがNAS上のファイルを端末側で扱いやすい形に変換し、Endpoint DLPの監視モデルに“寄せる”ためです。
JIT保護のイメージ（何が起きているか）
- ユーザーがNAS上のファイルにアクセスする
- JITがファイルを一時的に端末の監視対象ローカルパスへ取り込み（キャッシュ/一時コピー）する
- Endpoint DLPから見える操作として扱われやすくなり、USB禁止/外部クラウド禁止などが効く
この動きが噛み合うと、Endpoint DLP単体では埋めにくい「NAS直アクセスの抜け道」を大きく縮められます。つまり、DLP＋JITの併用は、NAS中心の環境で最も現実的な解決策のひとつです。
導入前に必ず検証したいチェックリスト
| 観点 | 確認したいこと | 起きがちなトラブル |
|---|---|---|
| 性能 | 大容量DWG/多数ファイルを開くときの体感速度 | 「NASが遅い」と誤解される（実際はローカル取り込み待ち） |
| 共同編集 | 複数人が同一図面を触る運用で整合性が崩れないか | 最新版が分からなくなる/差分が消える事故 |
| アプリ相性 | CAD/プラグインが一時パス経由でも正常動作するか | パス前提のアドインが動かず業務停止 |
| ログ/運用 | 監査ログの見方、ブロック成功の判断基準 | 担当者が変わると運用が属人化する |
JITは便利ですが、従来の運用を変える可能性があります。いきなり全社展開せず、部署・端末・共有パスを絞ったパイロットで検証するのが安全です。
対策④ NASをiSCSIでマウントする案は“監視”には効くが、運用要件とセットで判断する
iSCSIで提供されるボリュームはOSから見るとローカルディスク（D:など）として扱われるため、Endpoint DLPの監視対象に乗りやすくなります。監視モデルの観点では筋が通った回避策です。
一方で、iSCSIは本質的にブロックストレージです。SMB共有のように多数のクライアントが同じフォルダを共有して運用する用途とは相性が良くないことがあり、導入は「できる/できない」だけでなく「運用要件に合うか」で決める必要があります。
SMB共有とiSCSIの比較
| 項目 | SMB共有（一般的なNAS運用） | iSCSIマウント（ローカルディスク化） |
|---|---|---|
| DLPの見え方 | 監視外になりやすい | 監視対象になりやすい |
| 共同利用 | 得意 | 設計次第で難しい（整合性問題に注意） |
| 導入・運用 | 既存運用を踏襲しやすい | 構成変更が大きく、運用再設計が必要 |
| おすすめ | 一般的な部門共有 | 限定端末・限定用途でローカル運用に寄せられる場合 |
JITとiSCSI、どちらを先に検討すべき？（判断早見表）
| 判断軸 | JITが向く | iSCSIが向く |
|---|---|---|
| 既存の共有運用を大きく変えたくない | ◎ | △ |
| 端末台数が多い（一般ユーザー中心） | ◎ | △ |
| 対象端末/用途を限定できる | ○ | ◎ |
| 性能と互換性を優先したい | △（要検証） | ○（設計次第） |
| インフラ構成変更が難しい | ○ | △ |
現実的には、まずはJIT＋USB制御で対策を固め、どうしても要件を満たせない限定領域だけiSCSIのような“ローカル化”を検討する、という順番が失敗しにくいです。
対策⑤ オンラインストレージへのアップロードはネットワーク/Cloud Appsでも抑止する
NAS上のファイルをそのままDropbox/Google Driveへアップロードできる場合、Endpoint DLPの監視外になりやすいことに加えて、そもそも社内端末が外部SaaSへ自由に通信できることが根本原因になっていることがあります。
そのため、次のようなネットワークレベルの制御を併用すると、DLPの穴を補いやすくなります。
- 社内プロキシで許可するSaaSをホワイトリスト化し、不要なSaaSは遮断する
- ファイアウォール/URLフィルタでDropbox等の通信を制御する
- Microsoft Defender for Cloud Apps等でSaaS利用を可視化し、必要に応じて制御する
「業務で使うGoogle Driveは許可、個人アカウントは不可」など境界線が複雑な場合ほど、ネットワーク/Cloud Appsで“公式ルート”を定義してあげると運用が安定します。
対策⑥ 長期解：ストレージ戦略を見直し、DLPと統合しやすい場所へ寄せる
最終的に「NASだけが監視の穴」という状態を減らすには、ストレージ戦略の見直しが効きます。特に機密度が高く、外部共有が発生しやすいデータは、SharePoint OnlineやOneDrive for Businessなど、Purviewと統合しやすいストレージへ集約したほうがポリシー運用がシンプルになります。
一方で、DWGのような大容量・高頻度アクセスがあるデータは、クラウド移行が最適解とは限りません。そこでおすすめは、データを機密度×業務特性で層分けし、守り方を変える方法です。
| データ層 | 例 | 保管場所の考え方 | 推奨コントロール |
|---|---|---|---|
| 最重要 | 最新版の設計図、顧客情報、契約 | DLP統合しやすい場所へ優先移行 | ラベル必須、DLP強め、外部共有は原則禁止 |
| 重要 | 協力会社と共有する図面、見積 | ハイブリッド運用（共有手段を一本化） | 期限付き共有、監査ログ、USB例外の統制 |
| 一般 | テンプレ、公開資料 | 現状のNASでも可 | 最低限のアクセス制御、教育 |
現場を止めずに進める導入手順（おすすめの順番）
NASの抜け道対策は、セキュリティだけで決めると業務が止まりがちです。次の順番で進めると、混乱を抑えつつ効果を出しやすくなります。
- 経路の棚卸し：NAS→USB、NAS→クラウド、ローカル→クラウドなど、実際の持ち出し経路を洗い出す
- 出口の固定：USBデバイス制御で“持ち出しの出口”を先に固める（監査→段階的ブロック）
- データ分類：DWGや重要文書に感度ラベルを付与し、ルール適用の軸を作る
- JITのパイロット：影響の少ない部門・共有からJITを適用し、性能・互換・運用を検証する
- ネットワーク制御：許可するSaaSを整理し、不要な外部アップロード経路を閉じる
- 例外の制度化：期限・理由・承認・ログの型を決め、例外が裏道にならないようにする
よくある質問
「NAS上のファイルはC:にだけコピーOK、USBはNG」はDLPで実現できる？
考え方としては可能ですが、NAS直操作が監視外になりやすい以上、通常のEndpoint DLPポリシーだけで“完全に”やり切るのは難しくなります。現実的には、JITでNASアクセスをローカル経由に寄せたうえでDLPを効かせる、またはUSBデバイス制御で書き込み先を塞ぐという組み合わせが効果的です。
JITを有効にすると、通常のDLPと挙動が違うのはなぜ？
JITは、監視対象外の経路を監視可能な形に変換するため、端末上では一時ファイルやキャッシュが関与します。その結果、アクセス速度やファイルロック、パスの扱いが変わり、従来の運用と差が出ることがあります。導入時は、CAD業務のピーク時間帯や共同編集を含めて検証するのが安全です。
iSCSIにすれば万事解決？
監視の観点ではプラスですが、運用の観点では注意が必要です。iSCSIは共有ファイル用途と相性が悪い場合があり、構成次第では同時編集やバックアップの設計が難しくなります。まずはJITやUSB制御など、既存運用を大きく変えない手段から検討するのが現実的です。
まとめ：Endpoint DLPを中心に、JIT・デバイス制御・運用設計で“持ち出しにくい仕組み”を作る
NAS（SMB共有）を中心に運用している環境では、Endpoint DLP単体で「NAS→USB」「NAS→外部クラウド」を完全に止めるのは難しいケースがあります。だからこそ、次の組み合わせが効きます。
- USBデバイス制御で物理的な出口を固める
- 感度ラベル＋DLPで守るべきデータを定義し、ルール適用の軸を作る
- JIT保護でNAS直アクセスの抜け道を縮め、DLPを効かせる
- 必要に応じてネットワーク/Cloud Appsで外部アップロード経路も抑える
- 長期的にはストレージ戦略を見直して「監視の穴」を減らす
目指すべきは「全部を止める」ではなく、業務を回しながら持ち出しの成功確率を限りなく下げるアーキテクチャです。NASを守りたいほど、DLPを中心に据えつつ周辺レイヤーを組み合わせる設計が、結果的に強く・運用しやすい対策になります。
コメント