Filtrado de correo sobre unha VPN: onde se executan realmente as regras de contido

Esta petición soa a problema de rede: impida que certo tipo de anexo saia do edificio, e a VPN xa está aí, así que úsea. Ese enfoque rompe na primeira pregunta que o filtro debe responder. As regras de contido necesitan ver a mensaxe, e a mensaxe faise visible nunha capa distinta da do túnel. Percorro a ruta do correo cara a fóra desde o paquete e deteñome no primeiro punto onde os datos necesarios existen de verdade.

Tres capas son independentes: o transporte VPN, a conexión SMTP TLS e o cifrado propio da mensaxe. Cada unha remata nun lugar distinto.

Comece pola capa que pode ver a mensaxe

A desencapsulación da VPN dálle o tráfico de rede interno. Se o cliente de correo abriu unha conexión TLS a un servidor de envío, o tráfico interno aínda contén ese fluxo TLS, non correo lexible.

Por tanto, unha captura de paquetes tomada na bordo do túnel responde a unha pregunta distinta de «contén esta mensaxe un anexo prohibido».

A terminación de SMTP TLS remata no sobre

Terminar SMTP TLS no servidor de correo expón a mensaxe tal como se enviou a ese punto. O servidor ve as cabeceiras, o sobre e a estrutura MIME. Iso basta para moitas regras de contido. O sobre dille o remitente e os destinatarios tal como o servidor os entendeu.

Non basta para unha mensaxe protexida con S/MIME. O servidor recibe unha entidade protexida e, sen as claves correspondentes, non pode ler o contido do seu interior. O mesmo límite se aplica a un anexo cifrado que chega intacto.

Non debilite a seguridade do transporte para facer lexible unha captura pasiva. Iso cambia a arquitectura en lugar de colocar a regra onde están os datos.

S/MIME remata onde están as claves

S/MIME protexe os datos da mensaxe MIME, así que a súa fronteira é o material de claves e o acordo de descifrado autorizado. Un filtro sen esas claves aínda pode actuar sobre metadatos visibles ou sobre a presenza dun obxecto protexido, pero é un resultado distinto.

Se a organización opera unha pasarela de cifrado autorizada ou un control xestionado de puntos finais, documente onde existe texto claro, que identidade pode inspeccionalo e como se protexen as claves e os rexistros. Non hai ningunha clave mestra creada por encamiñar tráfico a través dunha VPN.

Escriba iso antes de que alguén prometa clasificación de texto claro. A promesa é a parte difícil de retirar.

Poña a regra na plataforma de correo

Se o servidor de correo aprobado recibe a mensaxe lexible, a súa integración de filtrado de contido compatible é o punto de aplicación. Iso é distinto de permitir unha conexión SMTP a través dun firewall. Esa distinción decide se a regra pode rexeitar, poñer en corentena ou só anotar.

Postfix, por exemplo, documenta o filtrado de contido despois da cola: o correo ponse na cola, pásase a un filtro e devólvese á ruta de entrega. A súa disposición despois da cola é distinta das opcións de proxy antes da cola e Milter ás que se refire a mesma guía. Escolla a integración compatible e o comportamento ante fallos para o servizo de correo que realmente opera.

Unha regra de anexos non é un programa completo contra a perda de datos. As subidas desde o navegador, o almacenamento compartido e as accións nos puntos finais necesitan os seus propios controis.

Escriba a proba de aceptación con mensaxes sintéticas

Probe con exemplos sintéticos aprobados: unha mensaxe permitida, unha acción de contido prohibida e o tratamento declarado do cifrado a nivel de mensaxe. Inclúa que fai o servizo de correo cando o seu filtro non está dispoñible.

O resultado útil nomea a acción, o punto de aplicación e os datos visibles alí. «A VPN descifrouna» responde a unha capa e non pode substituír o modelo de contido e autorización da aplicación de correo.