Filtrado de correo sobre una VPN: dónde se ejecutan realmente las reglas de contenido

Esta petición suena a problema de red: impida que cierto tipo de adjunto salga del edificio, y la VPN ya está ahí, así que úsela. Ese planteamiento se rompe en la primera pregunta que el filtro debe responder. Las reglas de contenido necesitan ver el mensaje, y el mensaje se hace visible en una capa distinta de la del túnel. Recorro la ruta del correo hacia fuera desde el paquete y me detengo en el primer punto donde los datos necesarios existen de verdad.

Tres capas son independientes: el transporte VPN, la conexión SMTP TLS y el cifrado propio del mensaje. Cada una termina en un lugar distinto.

Empiece por la capa que puede ver el mensaje

La desencapsulación de la VPN le da el tráfico de red interno. Si el cliente de correo abrió una conexión TLS a un servidor de envío, el tráfico interno todavía contiene ese flujo TLS, no correo legible.

Por tanto, una captura de paquetes tomada en el borde del túnel responde a una pregunta distinta de «¿contiene este mensaje un adjunto prohibido?».

La terminación de SMTP TLS termina en el sobre

Terminar SMTP TLS en el servidor de correo expone el mensaje tal como se envió a ese punto. El servidor ve las cabeceras, el sobre y la estructura MIME. Eso basta para muchas reglas de contenido. El sobre le dice el remitente y los destinatarios tal como el servidor los entendió.

No basta para un mensaje protegido con S/MIME. El servidor recibe una entidad protegida y, sin las claves correspondientes, no puede leer el contenido de su interior. El mismo límite se aplica a un adjunto cifrado que llega intacto.

No debilite la seguridad del transporte para hacer legible una captura pasiva. Eso cambia la arquitectura en lugar de colocar la regla donde están los datos.

S/MIME termina donde están las claves

S/MIME protege los datos del mensaje MIME, así que su frontera es el material de claves y el acuerdo de descifrado autorizado. Un filtro sin esas claves todavía puede actuar sobre metadatos visibles o sobre la presencia de un objeto protegido, pero es un resultado distinto.

Si la organización opera una pasarela de cifrado autorizada o un control gestionado de puntos finales, documente dónde existe texto claro, qué identidad puede inspeccionarlo y cómo se protegen las claves y los registros. No hay ninguna clave maestra creada por encaminar tráfico a través de una VPN.

Escriba eso antes de que alguien prometa clasificación de texto claro. La promesa es la parte difícil de retirar.

Ponga la regla en la plataforma de correo

Si el servidor de correo aprobado recibe el mensaje legible, su integración de filtrado de contenido compatible es el punto de aplicación. Eso es distinto de permitir una conexión SMTP a través de un cortafuegos. Esa distinción decide si la regla puede rechazar, poner en cuarentena o solo anotar.

Postfix, por ejemplo, documenta el filtrado de contenido después de la cola: el correo se encola, se pasa a un filtro y se devuelve a la ruta de entrega. Su disposición después de la cola es distinta de las opciones de proxy antes de la cola y Milter a las que se refiere la misma guía. Elija la integración compatible y el comportamiento ante fallos para el servicio de correo que realmente opera.

Una regla de adjuntos no es un programa completo contra la pérdida de datos. Las subidas desde el navegador, el almacenamiento compartido y las acciones en los puntos finales necesitan sus propios controles.

Escriba la prueba de aceptación con mensajes sintéticos

Pruebe con ejemplos sintéticos aprobados: un mensaje permitido, una acción de contenido prohibida y el tratamiento declarado del cifrado a nivel de mensaje. Incluya qué hace el servicio de correo cuando su filtro no está disponible.

El resultado útil nombra la acción, el punto de aplicación y los datos visibles allí. «La VPN lo descifró» responde a una capa y no puede sustituir el modelo de contenido y autorización de la aplicación de correo.