はじめに
「このファイル、社外に送って大丈夫でしたっけ？」
現場でよくある質問ですが、本当に怖いのは、送る人が悪意を持っているケースだけではありません。
むしろ多いのは、次のような“うっかり”です。
- メールの宛先を間違える
- TeamsやSlackに顧客情報を貼る
- 生成AIに調査用データを投入する
- CSVを個人端末にダウンロードする
- 検証環境に本番データをコピーする
- 共有リンクを「全員」にしてしまう
こうした情報漏えいを防ぐための代表的な仕組みが、DLPです。
DLPは、Data Loss Preventionの略で、日本語では「情報漏えい防止」や「データ損失防止」と呼ばれます。Microsoft Purviewの公式ドキュメントでも、DLPは、ユーザーが本来共有すべきでない相手へ機密情報を不適切に共有するリスクを減らすための仕組みとして説明されています1。
本稿では、DLPを「機微情報を漏らさないための運用設計」として整理します。
1. DLPは“出口を塞ぐ製品”ではなく“情報の扱い方を設計する仕組み”
DLPというと、メール添付をブロックする製品、USBコピーを禁止する製品、というイメージを持たれがちです。
もちろん、それもDLPの一部です。
ただし、DLPの本質はもっと広く、次の4つを組み合わせて機微情報を守ることにあります。
| 領域 | 役割 | 例 |
|---|---|---|
| 分類 | 何が危ない情報かを定義する | 個人情報、要配慮個人情報、認証情報、営業秘密 |
| 検知 | 危ない情報を見つける | 正規表現、辞書、機械学習、ラベル |
| 制御 | 危ない操作を止める | 送信ブロック、警告、暗号化、隔離 |
| 改善 | 誤検知・過検知を調整する | 監査ログ、アラート分析、例外ルール |
Microsoft Purviewでは、DLPポリシーにより、機密情報を識別・監視し、条件に合致した場合に保護アクションを実行できます。対象はメール、SharePoint、OneDrive、Teams、端末、オンプレミスリポジトリなどに広がります1。
ここで大事なのは、DLPを「最後の関門」だけにしないことです。
出口で止める前に、そもそも機微情報がどこにあり、誰が、どの業務で、どの経路に流すのかを把握する必要があります。
2. 守るべき“機微情報”を定義する
DLPの失敗は、たいてい「何を守るのか」が曖昧なところから始まります。
機微情報という言葉は広く使われますが、現場では最低でも次のように分けておくと設計しやすくなります。
| 分類 | 具体例 | 主なリスク |
|---|---|---|
| 個人情報 | 氏名、住所、電話番号、メールアドレス、顧客ID | なりすまし、迷惑連絡、プライバシー侵害 |
| 要配慮個人情報 | 病歴、健康診断結果、犯罪被害情報など | 差別・偏見・重大な不利益 |
| 認証情報 | パスワード、APIキー、秘密鍵、トークン | 不正アクセス、権限奪取 |
| 金融情報 | クレジットカード番号、口座番号、請求情報 | 不正利用、金銭被害 |
| 営業秘密 | 見積、原価、顧客リスト、未公開資料 | 競争力低下、契約違反 |
| システム情報 | 構成図、脆弱性一覧、ログ、IPアドレス表 | 攻撃準備に使われる |
日本の個人情報保護法では、「要配慮個人情報」は、不当な差別や偏見その他の不利益が生じないよう、取扱いに特に配慮を要する情報とされています。個人情報保護委員会のFAQでは、病歴、健康診断結果、診療・調剤が行われた事実などが例示され、取得には原則として本人同意が必要であり、オプトアウトによる第三者提供は認められないとされています2。
つまり、DLPで守るべき情報は、単に「個人情報っぽいもの」ではありません。
業務影響、法令影響、契約影響、攻撃悪用可能性を見て、情報ごとに重み付けする必要があります。
3. DLPの基本アーキテクチャ
DLPを構成する要素は、次のように整理できます。
[データ]
↓
[分類・ラベル付け]
↓
[検知ルール]
↓
[ポリシー判定]
↓
[制御アクション]
↓
[ログ・改善]
3.1 分類・ラベル付け
最初に行うのは、情報の分類です。
Microsoft Purviewでは、情報を分類する方法として、ユーザーによる手動分類、機密情報の種類によるパターン認識、機械学習が挙げられています3。
たとえば、次のようなラベルを用意します。
| ラベル | 意味 | 典型的な制御 |
|---|---|---|
| Public | 公開してよい情報 | 制限なし |
| Internal | 社内限定 | 社外共有時に警告 |
| Confidential | 機密 | 社外共有ブロック、暗号化 |
| Restricted | 厳秘 | 特定部門のみ、コピー・印刷制限 |
ラベル設計で重要なのは、細かくしすぎないことです。
分類が10種類も20種類もあると、現場は使い分けられません。最初は3〜4段階に抑え、運用しながら調整する方が現実的です。
3.2 検知ルール
DLPの検知には、主に次の方法があります。
| 検知方法 | 内容 | 向いている情報 |
|---|---|---|
| 正規表現 | 文字列パターンで検知 | マイナンバー、電話番号、カード番号 |
| 辞書 | 単語リストで検知 | 社内プロジェクト名、顧客名 |
| チェックサム | 番号の妥当性を検証 | クレジットカード番号 |
| ラベル | 文書に付与された分類を参照 | 機密資料、社外秘文書 |
| 機械学習 | 文脈から判断 | 契約書、人事資料、知財資料 |
ただし、正規表現だけに頼ると限界があります。
たとえば、次のような文字列はパターン上は電話番号に見えても、実際にはサンプルかもしれません。
03-1234-5678
090-0000-0000
一方で、次のような文は、固定パターンでは検知しにくいですが、文脈上は機微情報です。
田中さんは来月から休職予定です。診断書は人事フォルダに格納済みです。
そのため、DLPでは「パターン」「文脈」「ラベル」「件数」「送信先」を組み合わせて判定するのが基本です。
3.3 制御アクション
DLPの制御は、いきなり全面ブロックにしない方がよいです。
代表的な制御には、次のものがあります。
| 制御 | 内容 | 使いどころ |
|---|---|---|
| 警告 | ユーザーに注意を出す | 初期導入、軽微なリスク |
| 理由入力付き許可 | 理由を書けば送信できる | 業務上の例外がある場合 |
| 上長承認 | 承認後に共有可能 | 高リスクだが業務上必要な場合 |
| 自動暗号化 | 添付やファイルを暗号化 | 社外送付が避けられない場合 |
| ブロック | 操作自体を禁止 | 認証情報、要配慮個人情報、大量個人情報 |
| 隔離 | ファイルを安全な場所へ移動 | 不適切な保存場所の是正 |
Microsoft Purview DLPでも、ポリシー条件に合致した場合、ポリシーヒントの表示、共有ブロック、ユーザーによる上書きと理由取得、上書き不可のブロック、隔離などのアクションが説明されています1。
ポイントは、制御を段階化することです。
すべてをブロックすると業務が止まります。すべてを警告だけにすると、慣れによって無視されます。リスクに応じて、警告、理由入力、承認、ブロックを使い分けるべきです。
4. 漏らさないための実装テクニック
ここからは、現場で効きやすい実装テクニックを整理します。
4.1 “送信先”でリスクを変える
同じファイルでも、社内共有と社外共有ではリスクが違います。
たとえば、次のように制御を分けます。
| 操作 | 制御例 |
|---|---|
| 社内の同一部門へ共有 | 許可 |
| 社内の別部門へ共有 | 警告 |
| 取引先ドメインへ共有 | 理由入力付き許可 |
| 個人メールアドレスへ送信 | ブロック |
| フリーメールへ送信 | ブロック |
| 未管理クラウドストレージへアップロード | ブロック |
DLPは「何が含まれるか」だけでなく、「どこへ出るか」を見ることで精度が上がります。
同じ顧客情報でも、契約済みの委託先へ暗号化して送る場合と、個人のGmailへ送る場合では、扱いを変えるべきです。
4.2 件数しきい値を使う
1件の個人情報と、1万件の個人情報では、事故時の影響が違います。
そのため、DLPポリシーでは件数しきい値を設けます。
個人情報が1〜4件: 警告
個人情報が5〜99件: 理由入力付き許可
個人情報が100件以上: ブロックまたは承認必須
この設計にすると、過剰なブロックを避けつつ、大量漏えいを止めやすくなります。
4.3 認証情報は最優先で止める
個人情報と同じくらい、あるいはそれ以上に危ないのが認証情報です。
特に次の情報は、DLPで強めに制御すべきです。
- パスワード
- APIキー
- アクセストークン
- 秘密鍵
- SSH秘密鍵
- 接続文字列
-
.envファイル - クラウドのサービスアカウントキー
認証情報は、漏れた瞬間に侵入経路になります。
そのため、個人情報のように「件数が多いから危険」と考えるのではなく、1件でも危険と考えます。
APIキーらしき文字列を検知
↓
外部チャット、メール、Gitリポジトリ、生成AI入力をブロック
↓
セキュリティチームへ通知
↓
キーのローテーションを実施
DLPは、データ保護だけでなく、侵害拡大防止にも効きます。
4.4 マスキングとトークナイズを使う
検証環境や分析環境では、本番データをそのまま使わないのが原則です。
Google Cloud Sensitive Data Protectionでは、個人を識別する情報を削除・マスク・置換する非識別化の手法として、文字の置換、トークンへの置換、暗号化して置換する方法などが説明されています4。
たとえば、次のように変換します。
| 元データ | マスキング後 | 用途 |
|---|---|---|
| 山田太郎 | 山田○○ | 画面表示 |
| taro@example.com | t***@example.com | 問い合わせ対応 |
| 090-1234-5678 | 090-****-5678 | 一部確認 |
| 顧客ID: C12345 | 顧客ID: T9X8A2 | 分析・検証 |
| クレジットカード番号 | 下4桁のみ表示 | 決済確認 |
ここで注意したいのは、マスキングと匿名化は同じではないことです。
マスキングしても、他の情報と組み合わせることで個人が再識別される可能性があります。そのため、分析用途では、単純な伏字だけでなく、トークナイズ、集計化、k-匿名性、アクセス制御を組み合わせる必要があります。
4.5 生成AIへの入力を制御する
最近のDLPで重要なのが、生成AIへの入力制御です。
ユーザーは、悪意なく次のような情報をAIに貼り付けます。
- 顧客とのメール本文
- 障害ログ
- 契約書
- 議事録
- ソースコード
- APIキー
- 社内設計資料
Microsoft PurviewのDLPドキュメントでは、インラインWebトラフィックの対象例として、ChatGPT、Google Gemini、DeepSeek、Microsoft Copilotなどのクラウドアプリへの過剰共有を監視・保護する説明があります1。
生成AI対策としては、次の制御が現実的です。
| リスク | 対策 |
|---|---|
| 個人情報を貼る | 個人情報を検知して警告またはブロック |
| ソースコードを貼る | リポジトリ名、秘密情報、社外秘ラベルで制御 |
| 契約書を貼る | Confidential以上は社外AIに投入禁止 |
| ログを貼る | IP、メール、トークン、Cookieを自動マスク |
| 業務上必要なAI利用 | 会社管理のAI環境へ誘導 |
生成AIは便利ですが、「便利だから全部貼る」運用にすると、DLPの抜け道になります。
そのため、DLP設計では、メール、ファイル共有、USBだけでなく、AI入力経路も明示的に対象にするべきです。
4.6 “社外秘”という文字だけに頼らない
よくある失敗が、「社外秘」と書いてあるファイルだけを止める設計です。
しかし、実際には次のような資料もあります。
【取扱注意】
顧客別単価一覧
2026年度 人員計画
退職予定者リスト
障害報告書_暫定版
「社外秘」という文字がなくても、内容は機微情報です。
そのため、DLPでは次のような複合条件を使います。
条件1: ファイルに個人情報が10件以上含まれる
条件2: ファイル名に「顧客」「人事」「給与」「契約」「障害」「見積」を含む
条件3: 送信先が社外ドメイン
条件4: ラベルがInternal以上
↓
警告またはブロック
単語だけでなく、情報の種類、ファイル名、ラベル、送信先、操作内容を組み合わせるのが重要です。
4.7 最初はシミュレーションモードで始める
DLPをいきなり本番ブロックにすると、業務が止まります。
Microsoft Purviewの公式ドキュメントでも、より制限的なモードで実行する前に、シミュレーションモードでポリシーを展開し、影響を評価することが推奨されています1。
導入順序は、次のようにすると安全です。
1. 監視のみ
2. 警告のみ
3. 理由入力付き許可
4. 一部条件でブロック
5. 高リスク情報を全面ブロック
この段階設計により、誤検知、業務例外、抜け道を確認できます。
DLPは“作って終わり”ではありません。ログを見ながら育てる仕組みです。
5. DLPポリシー設計のサンプル
ここでは、実装イメージとして、DLPポリシーを疑似コードで表現します。
5.1 個人情報の社外送信制御
policy_name: Personal Data External Sharing Control
target:
- Exchange Online
- SharePoint
- OneDrive
- Teams
condition:
sensitive_info:
- personal_name
- phone_number
- email_address
- address
count:
threshold: 10
destination:
external_domain: true
action:
- show_policy_tip
- require_business_justification
- notify_security_team
exception:
allowed_domains:
- trusted-partner.example.com
このポリシーは、個人情報が一定件数以上含まれるデータを社外に送る場合に、警告と理由入力を求める設計です。
最初からブロックではなく、ログを集めながら運用します。
5.2 要配慮個人情報の強制ブロック
policy_name: Sensitive Personal Data Block
target:
- Exchange Online
- SharePoint
- OneDrive
- Endpoint
condition:
sensitive_info:
- health_record
- medical_certificate
- disability_information
- criminal_history
destination:
external_domain: true
action:
- block_without_override
- notify_security_team
- create_incident
要配慮個人情報は、漏えい時の影響が大きく、個人情報保護委員会への報告や本人通知が必要となる場合があります2。
そのため、通常の個人情報より強い制御にします。
5.3 認証情報の持ち出し防止
policy_name: Credential Leakage Prevention
target:
- Endpoint
- Browser Upload
- Git Repository
- Email
- Chat
condition:
sensitive_info:
- password
- api_key
- private_key
- access_token
- connection_string
count:
threshold: 1
action:
- block_without_override
- notify_security_team
- recommend_secret_rotation
認証情報は1件でも危険です。
したがって、件数しきい値を高くせず、即時ブロックを基本にします。
6. DLPを失敗させない運用ポイント
DLPは技術だけでは成功しません。
むしろ、技術、業務、教育、例外管理のバランスが重要です。
6.1 現場を敵にしない
DLPを「禁止の仕組み」として導入すると、現場は抜け道を探します。
たとえば、メール添付が禁止されると、個人のクラウドストレージや私物端末を使うようになるかもしれません。
これは本末転倒です。
そのため、DLP導入時には次の説明が必要です。
- 何を守るための仕組みか
- どの操作が止まるのか
- 業務上必要な場合はどう申請するのか
- 誤検知時は誰に連絡するのか
- 安全な代替手段は何か
DLPは「止める仕組み」ではなく、「安全なやり方へ誘導する仕組み」として設計するべきです。
6.2 例外ルールを放置しない
DLPでは、必ず例外が発生します。
問題は、例外を作ることではありません。例外を放置することです。
| 例外 | 放置した場合のリスク | 対策 |
|---|---|---|
| 特定ユーザーを除外 | 退職・異動後も権限が残る | 定期棚卸し |
| 特定ドメインを許可 | 委託終了後も送信可能 | 契約終了時に削除 |
| 特定フォルダを除外 | 機微情報の置き場になる | 保存データを定期スキャン |
| 理由入力で常に許可 | 形式的な理由で通る | 理由文を監査対象にする |
例外は、期限、責任者、理由をセットで管理します。
例外ルール = 対象 + 理由 + 期限 + 承認者 + 棚卸し日
この形式にしないと、DLPポリシーは徐々に穴だらけになります。
6.3 アラートを“鳴らして終わり”にしない
DLPのアラートは、放置すると意味がありません。
見るべき観点は、次の4つです。
| 観点 | 確認内容 |
|---|---|
| 誰が | 特定ユーザーに偏っていないか |
| 何を | どの情報種別が多いか |
| どこへ | 社外メール、クラウド、AI、USBのどれか |
| なぜ | 業務上必要か、操作ミスか、ルール不足か |
アラートは、インシデント対応だけでなく、業務改善の材料にもなります。
たとえば、毎月同じ部署で同じ警告が出るなら、その部署の業務プロセス自体を見直すべきです。
おわりに
DLPは、単に「漏えいを防ぐツール」ではありません。
本質的には、機微情報の扱い方を組織として定義し、危ない操作を検知し、安全な方法へ誘導する仕組みです。
重要なのは、次の順番です。
守る情報を決める
↓
情報を分類する
↓
検知ルールを作る
↓
業務に合わせて制御する
↓
ログを見て改善する
特にこれからのDLPでは、メールやファイル共有だけでなく、生成AI、クラウドストレージ、SaaS、エンドポイントまで含めた設計が必要になります。
最初から完璧なDLPを作る必要はありません。
まずは、次の3つから始めるのが現実的です。
- 認証情報の外部送信を止める
- 個人情報の大量持ち出しを検知する
- 要配慮個人情報の社外共有を強く制御する
DLPは、現場を縛るための仕組みではありません。
現場が安心してデータを使うための、ガードレールです。
参考
-
Microsoft Learn - Learn about data loss prevention
DLPの定義、対象範囲、ポリシーアクション、シミュレーションモード、対象ワークロードの根拠 ↩ ↩2 ↩3 ↩4 ↩5 -
個人情報保護委員会 - 「要配慮個人情報」とはどのようなものを指しますか
要配慮個人情報の定義、本人同意、オプトアウト第三者提供不可、漏えい時対応の根拠 ↩ ↩2 -
Microsoft Learn - 機密情報の種類に関する詳細情報
機密情報の識別方法、パターンベース分類子、手動分類、機械学習の根拠 ↩ -
Google Cloud - De-identifying sensitive data
マスキング、トークン化、暗号化による非識別化手法の根拠 ↩