DLPルール一致と外部共有通知を混同しない：イベント分類の設計

まず考えたい問い

同じ送信者から届くアラートでも、意味は同じとは限りません。DLPポリシーへの一致と、外部共有操作の通知を合算すると、「違反件数」という数字が実態から離れてしまいます。

対象は、この領域を実装・運用する技術者と、仕組みを学びたい方です。

設計の要点

イベント種別は送信元だけで決めず、活動の種類と本文の項目から分類します。未知の形式を無理に既存分類へ押し込まないことも品質です。

*図は処理と検証の関係を示す模式図です。実測値や性能比較ではありません。*

仕組みと判断の分かれ目

分類器にUNKNOWNを置く

たとえばDLPRuleMatchはルール一致、ExternalFileSharingは共有操作として扱う設計が考えられます。ただし実際の通知形式をサンプルで確認し、件名の日本語・英語やHTML変更にも備えます。必要項目が欠けた通知はUNKNOWNへ送り、件数と未分類理由を残します。

分母と重複の定義を共有する

外部共有通知1件が1ファイル・1ユーザー・1操作のどれを意味するかで、集計結果の解釈が変わります。同じ通知が転送された場合と、同じファイルで別操作が行われた場合も分けます。ルール一致・共有操作・未分類の3表を作り、重大度や処理結果は別の属性として保持します。

コード・データで表すと

次は設計を読み解くための例です。疑似コードや概念表記を含み、環境へそのまま貼り付けるための完成コードではありません。

activity == "DLPRuleMatch"       → DLP_MATCH
activity == "ExternalFileSharing" → SHARE_EVENT
otherwise                        → UNKNOWN
# 分類不能を黙って破棄しない

ここまで試してから、動いたと判断する

正常系の確認だけでなく、失敗時に残るデータ、外部への副作用、再実行の可否も記録します。確認した対象・版・日時を残すと、後から同じ条件で追試できます。

小さな演習

架空の通知から、件名だけで分類する版とActivityも使う版を作り、未知の通知が来たときの違いを説明してください。

試験結果を「観測した事実」「そこからの判断」「まだ確かめていない条件」に分けて書いてみてください。実装を説明する力は、動く理由と止まる理由を言葉にすることで磨かれます。

適用範囲と確認事項

設計例です。自社環境での適用前に、権限・製品仕様・既存データへの影響を検証してください。 本記事は2026年10月時点の対応・設計検討を一般化した解説です。内部環境の識別子や実データは掲載していません。

参考資料

• 公式・技術資料 1