VPN 経由のメールフィルタリング：コンテンツルールが実際に動く場所

この依頼はネットワークの問題のように聞こえます。特定の種類の添付ファイルを社外に出さないようにしたい、VPN はすでにあるのだから使えばよい、という発想です。しかしその枠組みは、フィルターが答えなければならない最初の問いで崩れます。コンテンツルールはメッセージを見る必要があり、メッセージはトンネルとは別の層で見えるようになります。私はパケットから外向きにメールの経路をたどり、必要なデータが実際に存在する最初の地点で止まります。

三つの層は独立しています。VPN の転送、SMTP TLS の接続、そしてメッセージ自身の暗号化です。それぞれ終わる場所が違います。

メッセージを見られる層から始める

VPN のデカプセル化で得られるのは内側のネットワークトラフィックです。メールクライアントが投稿サーバーへ TLS 接続を開いたなら、内側のトラフィックにはその TLS ストリームが含まれるままで、読めるメールではありません。

つまりトンネルの端で取ったパケットキャプチャは、「このメッセージに禁止された添付ファイルが含まれるか」とは別の問いに答えます。

SMTP TLS の終端はエンベロープで終わる

メールサーバーで SMTP TLS を終端すると、その端点に投稿されたままのメッセージが現れます。サーバーはヘッダー、エンベロープ、MIME 構造を見ます。多くのコンテンツルールにはこれで足ります。エンベロープは、サーバーが理解した送信者と受信者を伝えます。

S/MIME で保護されたメッセージには足りません。サーバーが受け取るのは保護された実体であり、該当する鍵がなければ中のコンテンツは読めません。そのまま届く暗号化された添付ファイルにも同じ限界があります。

受動的なキャプチャを読めるようにするために転送の安全性を弱めてはいけません。それはルールをデータのある場所に置くのではなく、アーキテクチャを変えてしまいます。

S/MIME は鍵のある場所で終わる

S/MIME は MIME メッセージのデータを保護するので、その境界は鍵素材と許可された復号の取り決めです。鍵のないフィルターでも、見えるメタデータや保護されたオブジェクトの存在には作用できますが、それは別の結果です。

組織が許可された暗号化ゲートウェイや管理されたエンドポイント制御を運用しているなら、平文がどこに存在するか、どの識別子が検査できるか、鍵と記録がどう保護されるかを文書化してください。VPN を通して通信を流すことで作られるマスター鍵はありません。

誰かが平文の分類を約束する前に、それを書き留めてください。約束は取り消すのが難しい部分です。

ルールをメール基盤に置く

承認されたメールサーバーが読めるメッセージを受け取るなら、その対応するコンテンツフィルター連携が強制の地点です。ファイアウォールを通した SMTP 接続を許可することとは違います。この違いが、ルールが拒否できるのか、隔離できるのか、注記だけなのかを決めます。

たとえば Postfix は キュー投入後のコンテンツフィルタリング を文書化しています。メールはキューに入れられ、フィルターに渡され、配信経路に戻されます。そのキュー投入後の構成は、同じガイドが参照するキュー投入前のプロキシや Milter の選択肢とは異なります。実際に運用しているメールサービスに合った、対応済みの連携と障害時の挙動を選んでください。

添付ファイルのルール一つでは、データ損失対策として不完全です。ブラウザーのアップロード、共有ストレージ、エンドポイントの操作には、それぞれ独自の制御が必要です。

合成メッセージで受け入れテストを書く

承認された合成例でテストします。許可されるメッセージ、禁止されるコンテンツ操作、そしてメッセージレベルの暗号化について宣言された扱いです。フィルターが利用できないときにメールサービスがどうするかも含めます。

有用な結果は、操作、強制の地点、そこで見えるデータを名指しします。「VPN が復号した」は一つの層に答えるだけで、メールアプリケーションのコンテンツと認可のモデルの代わりにはなりません。