Realizar copias de seguridad de HIN Mailgateway y restaurarlo tras una avería

Muchos HIN Mailgateways en producción funcionan como clúster. Si falla un nodo, el otro toma el relevo. Sin embargo, esta redundancia no ayuda frente a una regla errónea, un certificado eliminado o una importación dañada: Los datos relevantes para el sistema se replican en todos los nodos, incluidos los cambios no deseados.

Por ello, para una recuperación fiable se requiere una copia de seguridad independiente. Dado que HIN Mailgateway se basa técnicamente en una appliance SEPPmail con GINA, se aplican sus mecanismos documentados de copia de seguridad y restauración.

Qué datos se almacenan en el gateway

El gateway procesa correos entrantes y salientes según un conjunto central de reglas y los cifra, según el destinatario, mediante S/MIME, OpenPGP o TLS; para destinatarios sin material de claves propio se utiliza el procedimiento web GINA. Para la copia de seguridad es crucial que el contenido de los mensajes no se almacene de forma persistente en el gateway: la appliance procesa los correos en tránsito, sin archivarlos.

Qué replica el clúster

SEPPmail admite varias modalidades de clúster: alta disponibilidad, balanceo de carga y clúster geográfico; los parámetros del sistema, los datos de usuarios y el material de claves se sincronizan entre todos los nodos. En el clúster frontend/backend, el frontend no dispone de una base de datos de configuración propia: puede funcionar en una DMZ sin almacenamiento de datos y recibe solo los datos necesarios para el procesamiento actual; la base de datos, junto con las claves, reside en el backend. Para Large File Transfer (LFT) existe una excepción: a cada participante, incluidos los frontends, se le asigna un disco del mismo tamaño y los datos LFT se sincronizan en todos los nodos.

Por qué la replicación no es una copia de seguridad

La replicación copia el estado actual, incluido el defectuoso. Una copia de seguridad conserva un estado conocido y funcional.

Una importación errónea, una clave eliminada o un dominio desactivado se replica en segundos en el nodo asociado. Sin una copia de seguridad independiente, deja de existir un punto de recuperación. La estrecha relación entre disponibilidad y consistencia en el clúster se evidenció con los problemas de inicio de sesión tras la actualización a 15.0.5, causados por una replicación de clúster alterada.

Qué incluye la copia de seguridad y qué no

La copia de seguridad de SEPPmail es deliberadamente ligera: comprende exclusivamente la configuración y el material de claves criptográficas: sin mensajes, sin cola de correo y expresamente sin registros (por ello, los registros deben enviarse mediante Syslog a un sistema externo). Desde el firmware 14.0.0, la appliance genera la copia de seguridad automáticamente a medianoche como backup.tgz; puede obtenerse mediante Download, Send Backup (correo electrónico al grupo de copias de seguridad) o SCP.

De ello se deduce que, como el sistema operativo no está incluido en la copia de seguridad de configuración, una estrategia completa de recuperación ante desastres requiere además una forma de restaurar la base de la appliance (nuevo despliegue desde la imagen del fabricante o instantánea de VM). Posteriormente, la copia de seguridad de configuración restablece la configuración y las claves.

Las instantáneas no son una copia de seguridad del clúster

Desde el firmware 14.0.0, la appliance también crea instantáneas locales, aunque solo si existe una partición LFT con base de datos. Los domingos se crea una instantánea completa y, de lunes a sábado, una incremental cada día; la retención es de 14 días.

Lo decisivo para la planificación de recuperación ante desastres: aunque estas instantáneas se ejecutan en segundo plano en un clúster, no se ofrece restauración a partir de ellas. Por tanto, las instantáneas son una ayuda local para revertir cambios en sistemas individuales, no una recuperación de clúster. La protección fiable sigue siendo la copia de seguridad de configuración cifrada.

Configurar la copia de seguridad

El requisito para cualquier método de obtención es establecer una contraseña de copia de seguridad en Administración › Copia de seguridad › Cambiar contraseña; sin esta contraseña no se descarga, envía ni proporciona mediante SCP. De forma predeterminada, la copia nocturna se envía por correo electrónico al grupo «backup (Backup Operator)»; un usuario dedicado a copias de seguridad necesita una dirección de correo interno válida.

• Establecer la contraseña de copia de seguridad y guardarla separada de la copia: la copia contiene claves privadas.

• Para el almacenamiento automatizado, recuperar las copias mediante SCP: almacenar la clave pública SSH-RSA- en la administración y descargar mediante el usuario del sistema operativo backup el archivo backup.tgz disponible a medianoche.

• Proteger los registros por separado (Syslog externo), ya que deliberadamente no forman parte de la copia de seguridad.

Estrategia de copia de seguridad en clúster

En un clúster, son decisivas una copia ordenada y una gestión coherente de versiones.

• Diariamente: recuperar la copia de seguridad de configuración cifrada mediante SCP y almacenarla externamente con control de versiones

• Semanalmente: copia de seguridad completa de VM o sistema de ambos nodos, escalonada en el tiempo en lugar de simultánea (el sistema operativo no forma parte de la copia de seguridad de configuración)

• Antes de mantenimiento o actualización: detener la aceptación de correo mediante Preempt: los correos entrantes se rechazan temporalmente con un código de retorno SMTP configurable (predeterminado 421); la configuración sigue activa incluso tras reiniciar.

Respecto a la gestión de versiones: en un clúster frontend/backend, SEPPmail actualiza el frontend antes que el backend, y en actualizaciones de varias fases todos los participantes deben tener la misma versión antes de pasar a la siguiente versión. Tras una actualización mayor, puede ser necesario regenerar el conjunto de reglas (mensaje «Current ruleset created for another version»).

Restauración y recuperación ante desastres

El caso básico es sencillo: Importar archivo de copia de seguridad, reiniciar y, a continuación, el gateway funciona con todas sus prestaciones. Debe tenerse en cuenta la regla de versiones: solo se puede importar en la versión actual la copia de seguridad de la versión de firmware inmediatamente anterior (después debe regenerarse el conjunto de reglas); no es posible importar la copia de una versión de firmware más reciente en una versión anterior.

En el clúster existe una limitación importante:

• No restaurar nunca directamente un nodo individual: no está previsto restaurar un único participante del clúster. En su lugar, retire la máquina defectuosa del clúster, cree una nueva VM y vuelva a añadirla: la configuración y las claves llegan automáticamente por replicación desde el participante intacto.

• Pérdida total en todos los nodos: vuelva a desplegar la appliance desde la imagen base, importe después la última copia de seguridad de configuración conocida y funcional, y reinicie.

Una copia de seguridad es tan fiable como la última prueba de restauración realizada con éxito. Debe realizarse una restauración de prueba al menos dos veces al año en un entorno aislado, no contra el clúster de producción.

Lista de comprobación de restauración para casos de emergencia

1. Retirar el nodo defectuoso del clúster (sin restauración directa de un participante).

2. Crear una nueva VM o, en caso de pérdida total, proporcionar la appliance desde la imagen base/instantánea de VM.

3. Solo en caso de pérdida total: importar la última copia de seguridad de configuración funcional (tener preparada la contraseña y respetar la regla de versiones).

4. Comprobar el nodo de forma aislada: aceptación SMTP, TLS, GINA, conjunto de reglas.

5. Incorporarlo al clúster y observar la replicación; si aparece el aviso, regenerar el conjunto de reglas.

6. Documentar el incidente y actualizar el intervalo de copia de seguridad y las versiones.

Dos acciones de mantenimiento requieren especial cautela y siempre una copia de seguridad previa: ampliar la partición LFT apaga la appliance, y el restablecimiento de fábrica sobrescribe el disco duro diez veces (la consulta de seguridad exige introducir el código en orden inverso).

Qué cambia con «Stargate»

HIN está sustituyendo gradualmente el Mailgateway actual por el nuevo HIN Gateway (proyecto «Stargate», gestionado como «Verimesh» por Vereign AG). No se trata de una sustitución uno a uno de la appliance, sino de un cambio arquitectónico que afecta fundamentalmente a la copia de seguridad y a la recuperación ante desastres:

• De centralizado a descentralizado: los nodos se comunican directamente entre sí; desaparece un centro de distribución central.

• Gestión descentralizada de claves (DKMS): cada organización administra su propia identidad criptográfica, sin una autoridad de certificación central.

• Cifrado de extremo a extremo con fragmentación de los mensajes.

• Resiliencia desde la red: si falla un nodo, la malla sigue funcionando.

• Implementación de referencia abierta: la Vereign Client Library (vcl) es de código abierto bajo AGPLv3.

Calendario: la infraestructura descentralizada está en producción en el sector sanitario suizo desde abril de 2025; para 2026 está prevista la sustitución gradual de los Mailgateways actuales y un despliegue amplio. Las organizaciones con dominios propios de HIN (@hin.ch, @verband-hin.ch) funcionan en infraestructura de HIN y apenas se ven afectadas por la transición.

Para el manual de operaciones, esto significa que la disciplina clásica de «exportar la configuración y las claves de la appliance y restaurarlas en un nodo de sustitución» pierde importancia. En su lugar entran el registro de nodos, la custodia de identidades y claves en la malla, y la reincorporación de nodos a la red.

La separación más importante

Mientras HIN MGW funcione con tecnología SEPPmail, se aplica lo siguiente: el clúster compensa los fallos de hardware, pero la responsabilidad por la integridad de la configuración y las claves permanece en el operador. La copia de seguridad ligera de configuración debe protegerse independientemente del clúster (mediante SCP, con control de versiones y contraseña almacenada por separado); las instantáneas no la sustituyen en el clúster, las versiones deben permanecer sincronizadas y la restauración debe probarse periódicamente de forma aislada. La migración a Stargate debe incorporarse pronto a la planificación de recuperación ante desastres, ya que desplaza la resiliencia y la custodia de claves a la red descentralizada.