Configurar el cifrado de correo SPX en Sophos Firewall

Con Secure PDF Exchange, o SPX, Sophos Firewall convierte un correo saliente y sus archivos adjuntos en un PDF protegido con contraseña. El destinatario no necesita un cliente de cifrado propio. Según el modelo de contraseña seleccionado, recibe una contraseña de un solo uso, utiliza una contraseña almacenada o registra una personalmente.

Para un funcionamiento fiable deben coordinarse cuatro elementos: una plantilla SPX, un activador inequívoco, un canal seguro para la contraseña y, si se necesita, el SPX Reply Portal. Después se prueban un flujo positivo y otro negativo. La mera entrega de un PDF no demuestra que se haya activado la política correcta ni que funcionen el registro de contraseña y la respuesta segura.

SPX en ocho pasos

1. Comprobar la licencia Email Protection, el flujo de correo MTA, la compatibilidad del modelo y el certificado.
2. Decidir si el cifrado se activa por un dominio protegido, una coincidencia de Data Control o el remitente.
3. Crear una plantilla propia en Email > Encryption > SPX templates > Add.
4. Elegir de forma consciente el tipo de contraseña, el cifrado del PDF, la notificación y el Reply Portal.
5. Proteger el FQDN, las redes permitidas y el puerto en Email > Encryption > SPX portal settings.
6. Asignar la plantilla en la política SMTP route and scan o como plantilla predeterminada deliberada.
7. Probar el PDF, el canal de contraseña, el registro y la respuesta con un destinatario externo.
8. Realizar una prueba negativa sin activador SPX y documentar Mail logs, los registros MTA y la reversión.

⚠️ Un campo Allowed networks vacío en el SPX Portal no significa «sin acceso», sino que vuelve a Any. Sophos también recomienda un puerto dedicado para el Reply Portal. Por eso, el FQDN del portal, el certificado, los orígenes permitidos y el canal de contraseña deben estar definidos antes de la prueba en producción.

Cuándo encaja SPX

SPX es útil cuando los destinatarios externos deben recibir contenido confidencial como PDF protegido sin instalar un cliente de cifrado. Puede utilizarse tanto en MTA mode como en Legacy mode. Este procedimiento usa MTA mode porque permite relacionar de forma clara el dominio, Data Control y el enrutamiento dentro de la política SMTP.

SPX no es cifrado de transporte entre servidores de correo ni cifrado de extremo a extremo entre dos clientes de correo. La firewall procesa el texto sin cifrar, genera el PDF y controla la contraseña o el registro. Después, el PDF puede seguir existiendo fuera de la firewall en buzones, archivos o descargas. El alcance de destinatarios, la retención y la entrega de contraseñas forman por tanto parte del diseño de seguridad.

Los requisitos son:

• una licencia Email Protection válida;
• un flujo de correo saliente ya probado a través de Sophos Firewall;
• un destinatario externo de prueba documentado;
• un FQDN de confianza y un certificado adecuado para los portales SPX utilizados;
• un canal seguro independiente para las contraseñas cuando no las registra el destinatario;
• una vía de recuperación que permita retirar las asignaciones de plantilla y política.

Según la ayuda actual de Sophos, SPX no está disponible en XGS 87/87w. Además, MTA mode completo no está disponible en XGS 88/88w. Configurar Mail Protection en MTA mode explica el flujo de correo, la licencia, el relay y los límites de modelo.

Definir el activador y la prioridad

SPX puede activarse de tres maneras. Si se configuran varios métodos, Sophos Firewall aplica este orden en MTA mode:

1. Dominio protegido: La plantilla SPX seleccionada en Domains and routing target se aplica a los mensajes salientes del dominio protegido coincidente.
2. Data control list: Solo si no hay una plantilla SPX a nivel de dominio, una coincidencia de Data Control puede aplicar la plantilla seleccionada para la lista.
3. Activador del remitente: Solo cuando ni el dominio ni Data Control proporcionan una plantilla se aplica el método del remitente configurado en Default SPX template.

La asignación por dominio es amplia y solo resulta adecuada cuando realmente deben cifrarse todos los mensajes salientes coincidentes. Data Control es apropiado para tipos de contenido definidos, pero debe probarse con ejemplos positivos y negativos reales para detectar falsos positivos. El activador del remitente deja la decisión en sus manos, pero exige un proceso de cliente de correo bien documentado.

Antes de configurar se define un único activador principal para cada flujo de correo. Un segundo método no debe imponerse silenciosamente a otro.

Crear la plantilla SPX

El ejemplo utiliza la plantilla Finance-SPX-Recipient. El nombre es un valor de documentación y debe adaptarse al propósito y a la organización.

1. Abrir Email > Encryption > SPX templates.
2. Seleccionar Add.
3. Introducir un nombre como Finance-SPX-Recipient.
4. Establecer el nombre de la organización para las notificaciones.
5. Elegir Encryption standard y PDF page size según los requisitos propios.
6. En Password type, seleccionar el modelo de contraseña previsto.
7. Revisar el asunto, el cuerpo del mensaje y las instrucciones para el destinatario, y adaptarlos si es necesario.
8. Si se requieren respuestas seguras, activar Enable SPX reply portal.
9. Activar Include original body into reply solo si se permite incluir el mensaje original en la respuesta.
10. Guardar la plantilla.

Elegir conscientemente el modelo de contraseña

Sophos Firewall ofrece cuatro modelos:

• Specified by sender: El remitente establece la contraseña. La firewall la elimina antes del envío y no la almacena. Debe llegar al destinatario por un canal seguro independiente.
• Generate one-time password for every email: La firewall genera una contraseña nueva para cada mensaje y la envía al remitente. Este la entrega por separado al destinatario. La contraseña no se almacena.
• Generated and stored for recipient: La firewall genera una contraseña específica para el destinatario, la envía al remitente y la reutiliza hasta que caduca.
• Specified by recipient: Un destinatario aún no registrado recibe un enlace de registro, define su contraseña y la utiliza hasta que caduque para otros mensajes SPX de la organización.

Para una relación continuada con un partner, Specified by recipient suele ser el proceso más fácil de entender. Una contraseña de un solo uso puede resultar más adecuada para un envío único especialmente sensible. No conviene mezclar sin planificación distintos modelos de contraseña almacenada para el mismo destinatario, porque este tendría que identificar la contraseña correspondiente a cada mensaje.

Con Specified by sender, el asunto puede usar el patrón [secure:<password>]<subject text>. Después, el remitente debe entregar la contraseña por separado. Para Microsoft Outlook, Sophos ofrece un Outlook Add-in en Authentication > Client downloads.

La ayuda actual de Sophos utiliza dos grafías distintas del encabezado para otros clientes de correo: X-Sophos-SPXEncrypt: yes en la página de la plantilla y X-Sophos-SPX-Encrypt: yes en la página general Encryption. Esta discrepancia no se trata como una receta para copiar y pegar. Antes de desplegarlo en producción, hay que verificar qué grafía funciona en el build de SFOS utilizado. Siempre que sea posible, una política, Data Control o el Sophos Outlook Add-in ofrece un activador más trazable.

Diseñar la notificación sin crear otra fuga de datos

Las variables disponibles para las notificaciones incluyen:

• ENVELOPE_TO
• PASSWORD
• ORGANIZATION_NAME
• SENDER
• REG_LINK

Se admiten formato HTML sencillo y enlaces. El texto debe explicar quién envía el mensaje, cómo se obtiene la contraseña de forma segura y durante cuánto tiempo son posibles el registro o la respuesta. Las credenciales o el contenido confidencial del correo no deben copiarse además en una notificación sin protección.

Proteger los portales SPX

El registro de contraseñas y el acceso al portal se definen en Email > Encryption > SPX portal settings:

1. En Hostname, introducir el FQDN mediante el que los destinatarios externos acceden realmente al portal.
2. En Allowed networks, definir solo las redes de origen necesarias. Any solo es apropiado cuando cualquier destinatario externo debe acceder al portal y se acepta conscientemente el riesgo.
3. Documentar el puerto. El Password Registration Portal utiliza de forma predeterminada TCP 8094.
4. Utilizar un puerto dedicado para el SPX Reply Portal.
5. Establecer los periodos de validez de contraseñas no utilizadas, respuestas seguras y enlaces de registro.
6. Introducir los destinatarios de las notificaciones de error SPX.

Si Allowed networks queda vacío, SFOS utiliza Any, porque el SPX Reply Portal está activado de forma predeterminada en la zona WAN. Si no se necesita el Reply Portal, Sophos documenta como método de desactivación el uso de una dirección privada de confianza sin utilizar, por ejemplo 169.254.0.1, como única red permitida. Este valor de documentación no debe coincidir con una dirección utilizada en producción.

CAPTCHA está siempre activo en el SPX Portal y no puede desactivarse. Controlar conscientemente CAPTCHA en Sophos Firewall explica los límites de la configuración CAPTCHA de otros portales.

WebAdmin, User Portal, VPN Portal, Captive Portal y los dos portales SPX utilizan la misma selección central de certificado. Por tanto, un cambio puede afectar a varios servicios al mismo tiempo. El certificado, los SAN, la vía de recuperación y la URL real del portal deben planificarse con Gestionar certificados en Sophos Firewall. Para un nombre público puede encajar un certificado Let’s Encrypt en Sophos Firewall.

Conectar la plantilla con la política SMTP

Para MTA mode, la plantilla SPX se selecciona en la política SMTP route and scan correspondiente bajo Email > Policies and exceptions.

Usar un dominio como activador

En Domains and routing target, se asigna la plantilla al dominio protegido. A partir de entonces se aplica a los mensajes salientes coincidentes. Una asignación amplia por dominio se prueba primero con un remitente piloto y un destinatario externo de prueba.

Usar Data Control como activador

1. Crear una lista con un nombre claro en Email > Data control list o revisar la lista existente.
2. Activar Data protection en la política SMTP route and scan.
3. Asignar la plantilla SPX prevista a la Data Control List.
4. Realizar una prueba positiva de contenido y otra negativa similar.

Si ya existe una plantilla SPX en Domains and routing target, esta tiene prioridad sobre la plantilla de Data Control. Además, una coincidencia de la Data Control List solo demuestra la coincidencia de contenido configurada. El flujo de correo real debe confirmar si se cifró el mensaje correcto.

Utilizar un activador del remitente

En Email > Encryption > SPX configuration, se selecciona un Default SPX template. Solo se aplica al cifrado SPX activado por el remitente si la política SMTP no proporciona ya una plantilla a nivel de dominio o Data Control. None desactiva esta vía predeterminada.

Validar el flujo de correo cifrado

Se anotan la hora de la prueba, el remitente, el destinatario, el asunto y el activador esperado. Después se prueban como mínimo estos casos:

1. Prueba positiva: Un mensaje saliente activa exactamente la plantilla SPX prevista.
2. Prueba de contraseña: El destinatario recibe la contraseña o el enlace de registro por el canal previsto y puede abrir el PDF.
3. Prueba de contenido: El asunto, el cuerpo y los archivos adjuntos aparecen en el PDF como se espera y son legibles.
4. Prueba de respuesta: Si está activado, el enlace de respuesta conduce al FQDN esperado y una respuesta de prueba llega al remitente original.
5. Prueba negativa: Un mensaje similar sin activador no se envía como PDF SPX.
6. Prueba de caducidad: El registro, la contraseña almacenada y el periodo de respuesta se comportan de forma previsible después de la validez definida.
7. Prueba de certificado: El navegador y el destinatario externo reciben una cadena de certificados completa y de confianza para el FQDN del portal utilizado.

Para la primera correlación se utilizan Email > Mail logs, Log Viewer y los archivos MTA smtpd_main.log, smtpd_error.log y smtpd_panic.log. Un mensaje de error se correlaciona con el mismo correo de prueba y la misma hora. Servicios y registros de Sophos Firewall explica el acceso y otros archivos de registro.

En HA, los registros se encuentran en el nodo que ha procesado el tráfico. Después de un failover controlado se prueban por separado un nuevo correo SPX, el registro de contraseña y la respuesta. No se presupone que una sesión de portal existente o un proceso de registro en curso continúen sin interrupción. Los fundamentos se explican en Clústeres HA de Sophos Firewall.

Acotar los errores de forma sistemática

El mensaje no se cifra

Comprobar la dirección, el dominio protegido, la política SMTP route and scan real y la prioridad de los activadores. Para Data Control, revisar también Data protection, la coincidencia de la lista y la asignación de plantilla. Para un activador del remitente debe existir una plantilla predeterminada y no debe estar sobreescrita por una plantilla de dominio o Data Control. Las dos grafías documentadas del encabezado no justifican desplegar ambas sin probarlas en producción.

El enlace de registro o el portal no es accesible

Comprobar el FQDN, la resolución DNS pública, el puerto, el certificado, Allowed networks y la validez del enlace. Un valor vacío de Allowed Networks se trata como Any y, por tanto, no es un estado de desactivación seguro. Si el cliente llega a otro host o portal, la URL, NAT o la asignación de certificado no coinciden con la ruta prevista.

El PDF no se puede abrir

Primero hay que asociar el tipo de contraseña con el mensaje concreto. Una contraseña de un solo uso solo es válida para ese correo. En contraseñas almacenadas o registradas, la causa puede ser la caducidad o la mezcla de varios modelos. Después de un SPX Password Reset, el remitente debe volver a entregar la nueva contraseña al destinatario de forma segura.

La respuesta segura no llega

Comprobar Enable SPX reply portal en la plantilla, el periodo de respuesta, el FQDN del portal, el puerto, el certificado y los orígenes permitidos. Después, revisar Mail logs y los registros MTA para la respuesta concreta. Abrir correctamente el PDF no demuestra que funcione el canal de retorno.

La validación DKIM falla después de SPX

SPX modifica el cuerpo y los archivos adjuntos. Si un mensaje se firma antes de ese cambio, la firma puede resultar inválida en el destinatario. Debe definirse si el servidor de correo interno, Sophos Firewall o un gateway posterior firma después de todas las modificaciones previstas. La cadena de procesamiento y una prueba externa deben validarse conjuntamente.

Revertir de forma segura

1. Retirar primero la asignación SPX concreta de Domains and routing target o de la Data Control List.
2. Si se utiliza, establecer Default SPX template en None.
3. Realizar una prueba negativa saliente y confirmar que no se genera ningún PDF SPX nuevo.
4. Retirar el Reply y Registration Portal solo si ninguna otra política SPX activa depende de ellos.
5. Restaurar los accesos temporales públicos de puerto, DNS o portal al estado anterior documentado.
6. Eliminar la plantilla solo cuando ninguna política ni proceso operativo activo haga referencia a ella.
7. Conservar Mail logs y los registros MTA de la última prueba cifrada y la primera sin cifrar.

Antes de modificar rutas de correo y portales en producción se crea un backup actual de Sophos Firewall. SPX puede seguir funcionando en entornos air gap, pero las dependencias externas de DNS, certificados y portal deben seguir siendo accesibles por separado. Los límites del producto se explican en Funciones de SFOS sin acceso a internet.

Lista de comprobación operativa

• Se han comprobado la licencia, el modelo, el flujo de correo MTA y el destinatario externo.
• El activador y su prioridad están documentados.
• El tipo de contraseña y el canal seguro de entrega encajan con el caso de uso.
• El FQDN del portal, el certificado, el puerto y Allowed Networks tienen un alcance estricto.
• La asignación de dominio, Data Control o predeterminada es inequívoca.
• Se han superado las pruebas positiva, negativa, de contraseña, PDF y respuesta.
• Mail logs y los registros MTA se pueden correlacionar con el mensaje de prueba.
• El failover HA y los registros locales de cada nodo forman parte del procedimiento operativo.
• El responsable, las caducidades, la fecha de revisión y la reversión están documentados.

Preguntas frecuentes