DLPでは防げない誤送信メールも確実に防止

ほとんどのセキュリティチームはデータ損失防止（DLP）プログラムを運用しており、その多くは設計通りに機能しています。しかし、パターンルールはメッセージの内容のみを判断し、受信者を考慮しないため、機密データが誤った相手にメールで届いてしまうことがあります。誤送信メール防止は、このギャップを埋めるものです。

たとえば、To欄に40名の名前が表示された顧客リストが送信されたり、退職予定者が個人のGmailアカウントに契約書を転送したり、ドメイン名を1文字間違えて入力した場合などが考えられます。送信者は権限を持ち、ファイルの送信も許可されていますが、どのルールにも該当せず、データ自体は問題ありませんが、受信者が誤っています。

この記事では、パターンベースのDLPが対応できない範囲、Kiteworks AgentとHuman Error Prevention（AHEP）がメッセージ作成中に受信者をどのようにチェックするか、導入前に自社のインシデント履歴でどのようにテストできるかを解説します。

エグゼクティブサマリー

パターンベースDLPと受信者チェックは、異なる問いに答えます。DLPは「メッセージに含まれてはいけないデータがあるか」を確認します。AHEP（Kiteworks Data Policy Engineの機能）は、「この受信者がこのメッセージにふさわしいか」を、送信者がまだ修正できるタイミングで問いかけます。セキュリティリーダーにとっての価値は、既存ツールでは見えないリスクカテゴリに対するコントロールを、すでに機密データの流通を管理しているプラットフォーム上で実現できる点です。Report Onlyモードを使えば、警告が表示される前にリスクの露出度を測定できます。

主なポイント

1. DLPはデータのみをチェックし、受信者は確認しません。許可されたデータが誤った相手に送信されても、すべてのパターンルールを通過してしまうため、受信者エラーには専用のコントロールが必要です。DLPルールの調整だけではこのギャップは埋まりません。
2. メール誤送信は一般的で、よく記録されているインシデントです。Osterman Researchによるデータ保護当局へのインシデント報告の分析では、全体の21％で最も多く、Abnormalが調査した300人以上のリーダーの96％が損失を報告しています。
3. 各AHEPポリシーは特定の条件でのみ発動します。受信者タイプ、外部宛先数、ID一致、添付ファイルの有無などが3つの事前構築済みポリシーに反映されており、アラートが頻発しないため送信者が真剣に対応できます。
4. Report Onlyモードで、誰にもアラートが表示される前にリスクを測定できます。すべてのメッセージが静かに評価・記録され、ポリシーごとの検知件数を自社のインシデントログやDLPの検出結果と比較できます。
5. すべてのアラートと判断は監査ログに記録されます。ポリシー、指示内容、受信者、対応、タイムスタンプが記録され、コントロールが機能した証拠として監査対応をサポートします。

パターンベースDLPが誤った受信者を検知できない理由

DLPは重要な役割を担っており、決して無効にすべきではありません。DLPはカード番号や識別子、マークされた文書など、本来外部に出るべきでないデータをメッセージや添付ファイルから検出します。しかし、データの送信自体は許可されていても、受信者が誤っている場合には問題が発生します。ルールに該当しないため検知されず、実際の受信者から返信があったり、顧客から苦情が来て初めてインシデントが発覚します。

パターンルールが評価する内容

パターンルールはメッセージ自体、すなわち本文・添付ファイル・ラベルを評価します。「このメッセージに制限対象のデータが含まれているか？」という問いには有効で、情報の持ち出しやメールで送信すべきでないデータの漏洩防止に役立ちます。しかし、正当な文書が意図しない相手に届く場合には対応できません。

パターンルールが評価できない内容

隣接するツールカテゴリでもこのギャップは埋まりません。DSPMは保存中の機密データを発見・分類します。IAMは誰がサインインできるかを決定します。ゼロトラストは誰が何にアクセスできるかを制御します。いずれも有用ですが、「To欄の相手が送信者の意図した人物か」という問いには答えません。この問いはメッセージ作成時にしか確認できないため、受信者チェックは作成ウィンドウ内で行う必要があります。

Kiteworks AHEPが送信前に受信者をチェックする方法

AHEPはKiteworks Data Policy Engineの一部で、リリース9.5が必要です。メッセージ作成中に評価を行い、送信者が受信者を追加・削除したりファイルを添付した際にも再評価します。メールはクライアントからメールサーバーへ直接送信されます。AHEP Validation Serviceはメッセージのみを評価し、自身でメールを送信することはありません。

よくある受信者エラーに対応する3つの事前構築済みポリシー

3つのポリシーがすぐに利用可能です。1つは、外部受信者数が管理者設定の閾値を超えた場合にBCCを推奨します。1つは、既知の個人用ドメイン・送信者とのID一致・インラインでない添付ファイルが揃った場合に個人メールアドレスへの送信を防止します。1つは、既知の消費者向けドメインに1文字違いのドメインや有効なMXレコードがないドメインを検知します。管理者は各ポリシーの状態（Off/On/Report Only）と指示（Suggest/Warn）を設定できます。カスタム開発は不要です。

アラートが読み飛ばされない理由

個人アドレス向けポリシーは3つの条件がすべて揃った場合のみ発動するため、添付ファイルのない個人アドレスには反応しません。この抑制は意図的です。アラートが頻繁に出ると人は読まなくなりますが、条件が揃ったときだけ表示される警告は行動につながります。アラートが表示された場合、修正は作成ウィンドウ内で完結します。外部受信者をBCCに移動、ドメイン修正、該当受信者の削除などです。Suggestでは送信者がそのまま進められますが、Warnでは警告を解決または却下しないと送信できません。何も強制的にブロックされることはありません。

AHEPを自社インシデントデータでテストする方法

ベンダーの数値を鵜呑みにする必要はありません。各ポリシーを数週間Report Onlyで運用してください。AHEPはすべてのメッセージを評価・記録し、ユーザーには何も表示しません。その後、検知件数を自社のインシデントログや同期間のDLP検出件数と比較します。両者の差分が自社のリスク数値となり、予算決裁者への強力な根拠となります。

パイロット前に確認すべきポイント

運用範囲を事前に計画しましょう。アラートはKiteworks Web AppとOutlook Classicで動作します。AHEPにはKiteworksのコンテナサービスレイヤー（RKE2）とValidation Serviceが必要で、Kiteworksテクニカルサポートが有効化します。ユーザー名が標準フォーマットで、ビジネスアドレスがfirstname.lastname@companyのような形式だと検知精度が高まります。カスタムドメインの個人アドレスなど、すべての個人アドレスが検知されるわけではありません。これらの点をメッセージング担当チームと事前に合意すれば、パイロットで有益な結果が得られます。

Kiteworks Data Control Planeで受信者ギャップを解消

ポスチャーツールは機密データの所在やアクセス可能者を可視化します。DLPは外部送信内容を検査します。残るステップは、データが流通する瞬間、つまり人やAIエージェントが受信者を選ぶタイミングでの能動的な保護です。これがKiteworks Data Control Planeの役割です。AHEPは、すでにメール・ファイル共有・SFTP・MFT・フォームを管理するData Policy Engineに組み込まれており、他チャネルで運用するデータ認識型ポリシーと並んで受信者チェックを実施します。バリデーションは自社環境内で動作し、すべてのアラート・却下・判断は改ざん防止の監査ログに記録され、SIEMツールにも連携可能です。

DLP、DSPM、IAMへの投資を置き換えるのではなく、補完する仕組みです。Kiteworks Web AppとOutlook Classicで3つのポリシーが動作する様子を確認したい場合は、カスタムデモを予約し、実際のインシデント例をご持参ください。