Seguridad

Seguridad

Cómo protegen Emona MFT y el núcleo jFiltra sus archivos, y cuáles son sus límites técnicos.

Por el equipo de BLUEGEM · Actualizado el 4 de noviembre de 2026

Incluido en el núcleo jFiltra

• Autoalojado. Los archivos van de sus clientes a su propio servidor. No se envía nada a BLUEGEM ni a ningún servicio en la nube.
• Comprobación de integridad. Cada archivo recibe un hash SHA-256; el servidor lo verifica tras descifrarlo y el cliente borra el original o lo mueve a sent/ solo después de una entrega confirmada y verificada.
• Compresión y cifrado del contenido. El contenido se comprime con GZIP y se cifra con AES con una clave única para cada cliente.
• Separación por cliente. El servidor guarda los archivos de cada cliente en su propio directorio. Rechaza etiquetas de cliente desconocidas y cualquier nombre de archivo que contenga una ruta (como ../), así que un cliente no puede escribir fuera de su directorio.
• Límites de conexión. Tiempos de espera para cabeceras y transferencias, un límite de conexiones por IP y un tamaño máximo de archivo impiden que una sola conexión acapare el servidor.
• Filas de base de datos, con seguridad. Desde jFiltra 1.1, un cliente de BD independiente envía el resultado de una consulta SQL como archivo CSV, TSV o JSON Lines y ejecuta su SQL posterior a la transferencia solo cuando el servidor ha confirmado el archivo; cualquier fallo revierte la transacción. Las contraseñas en URL JDBC y mensajes de error se enmascaran en los registros.
• Funciona casi en cualquier sitio. Java 8 o posterior (cualquier compilación de OpenJDK, probado con 8, 11, 17, 21 y 25) en Linux, macOS o Windows, con Apache Log4j 2 como única dependencia.
• Código fuente que puede revisar. El código fuente del núcleo está disponible en GitHub bajo PolyForm Noncommercial 1.0.0, así que puede comprobar exactamente qué hace.

Lo que no incluye el núcleo jFiltra

• La conexión no se cifra con TLS, así que las etiquetas de cliente, los nombres de archivo, los tamaños y los hashes viajan en texto claro. jFiltra lo deja fuera a propósito para seguir siendo sencillo.
• El contenido de los archivos usa AES en modo ECB, no un cifrado autenticado, y las claves se derivan de una frase de contraseña sin una función de derivación de claves lenta y con sal.
• Los clientes no se autentican con certificados y no hay protección contra la repetición de transferencias.

Recomendación: ejecute el núcleo jFiltra solo dentro de una red de confianza, una VPN o un túnel SSH (el README de jFiltra explica cómo) y no exponga su puerto a internet.

Añadido en Emona MFT: protocolos 2 y 3

• Autenticación mutua. Cliente y servidor demuestran que conocen la clave del cliente antes de enviar datos de archivo; el cliente borra un archivo solo tras una respuesta que únicamente el servidor real puede generar.
• Cifrado autenticado. Los nombres y el contenido de los archivos se cifran con AES-256-GCM en registros numerados de 64 KB, de modo que se detectan cambios, reordenaciones y truncamientos.
• Protección contra repetición. Claves de sesión nuevas en cada conexión (HKDF-SHA256 sobre nonces aleatorios), de modo que una transferencia grabada no puede volver a enviarse.
• Protocolo 2 por defecto. Las instalaciones nuevas usan el protocolo 2. El protocolo 1 original se rechaza salvo que se permita expresamente. Una discrepancia se rechaza, se comunica al cliente y se registra. En la red solo es visible la etiqueta del cliente.
• Protocolo 3: intercambio de claves poscuántico híbrido. Opcional desde 1.7.0. Cada conexión añade un nuevo intercambio de claves X25519 y ML-KEM-768 (NIST FIPS 203), vinculado a un hash de todo el handshake. Las claves de sesión necesitan la clave del cliente y ambos secretos intercambiados, y las claves privadas del intercambio solo existen en memoria, de modo que el tráfico grabado no se puede descifrar después ni siquiera con la clave del cliente (forward secrecy).
• Sin degradación. Un servidor puede aceptar los protocolos 2 y 3 a la vez, para que los clientes migren uno a uno, pero un cliente configurado con el protocolo 3 nunca vuelve al protocolo 2, así que un atacante en la red no puede forzar un protocolo más débil.
• Rotación de claves sin interrupciones. Durante un cambio de clave, el servidor acepta la clave nueva y la anterior de un cliente, vuelve a leer su archivo de claves sin reiniciar, registra qué clave usó cada conexión e informa de los clientes que siguen con la clave antigua.

Emona MFT no usa TLS para las transferencias. Con los protocolos 2 y 3, un observador sigue viendo las etiquetas de cliente, el tamaño aproximado de los archivos y los tiempos; una VPN o un túnel SSH también los oculta. Quien conozca la clave de un cliente puede enviar archivos como ese cliente, así que proteja las claves. Un handshake del protocolo 3 cuesta al servidor más CPU que el protocolo 2 (unas 1,4 veces en una prueba con una avalancha de conexiones), así que mantenga los límites de conexiones y una regla de cortafuegos para el puerto. Los enlaces simbólicos nunca se envían y los límites de tamaño de archivo son configurables tanto en jFiltra como en Emona MFT.

El servidor también reserva una cantidad configurable de espacio libre en cada disco de almacenamiento (min.free.space.mb) y rechaza con Insufficient storage los archivos que lo llenarían, de modo que un disco lleno no puede detener a otros clientes ni dañar archivos guardados.

Archivos guardados

• Cifrado en reposo opcional. El servidor puede guardar cifrados con AES-256-GCM los archivos de algunos o de todos los clientes. Cada archivo recibe su propia clave aleatoria, envuelta con una clave maestra; se detectan bytes modificados, archivos truncados, bloques movidos o intercambiados, archivos renombrados y claves erróneas. Está desactivado por defecto, porque los programas que recogen los archivos deben descifrarlos primero, con la herramienta incluida emonamft-decrypt o una API Java.
• Rotación de la clave maestra. Una nueva clave maestra se adopta sin reiniciar, y los archivos anteriores pueden volver a envolverse con ella sin descifrar sus datos.
• Retención. Los archivos recibidos de un cliente pueden eliminarse automáticamente tras un número de días fijado, con una prueba en seco que solo informa de lo que se eliminaría. Cada eliminación se registra como evento.
• Permisos. Los archivos con claves, contraseñas o datos personales que escribe Emona MFT se crean solo para el propietario, los registros solo para el propietario y el grupo, y los archivos recibidos pueden recibir permisos restringidos. Los archivos de claves que otros usuarios pueden leer se notifican al arrancar.

El cifrado en reposo no oculta el tamaño de un archivo, y el registro de eventos conserva el tamaño y el SHA-256 del texto en claro, así que proteja el registro de eventos igual que los archivos. Haga una copia de seguridad aparte del archivo de la clave maestra: sin él nadie puede descifrar los archivos, tampoco BLUEGEM. El cifrado de disco del sistema operativo sigue siendo buena idea para discos robados y copias de seguridad.

Registros y supervisión

• Registros a prueba de manipulaciones. Los registros de eventos de servidores y clientes, y el registro de auditoría y el registro de incidentes del dashboard, están encadenados por hash y se sellan a intervalos regulares. Se comprueban cada hora y una cadena rota genera una alerta crítica.
• Reenvío a SIEM. Cada línea de evento y de auditoría puede enviarse a su SIEM o servidor de registros como syslog RFC 5424 por UDP, TCP o TLS, directamente desde servidores y clientes o desde el dashboard. Las líneas escritas durante una caída se envían después.
• Verificación frente a la copia. Una comprobación por línea de comandos compara los archivos con la copia del SIEM y muestra líneas modificadas, añadidas o eliminadas, también al final de un archivo.
• Datos personales. Los nombres de archivo pueden escribirse en el registro de eventos como hashes HMAC-SHA256 con clave (seudonimización). Las claves y el contenido de los archivos nunca se registran; en su lugar se registran las huellas de las claves.

A prueba de manipulaciones significa que los cambios se detectan, de forma fiable cuando los archivos se comparan con una copia guardada en otro lugar; no impide que alguien con acceso de escritura modifique los archivos. Guarde la copia del SIEM donde los operadores del servidor no puedan llegar.

Dashboard

Cada instalación de Emona MFT incluye al menos una instancia del dashboard web, y todos los servidores Emona MFT con licencia se conectan a ella. Servidores y clientes le envían eventos por su propio enlace AES-256-GCM con una clave por agente; el dashboard nunca les envía órdenes. El inicio de sesión admite autenticación en dos pasos (TOTP) y single sign-on con OpenID Connect, los inicios de sesión se bloquean por usuario y dirección, cada inicio de sesión y cambio va a un registro de auditoría encadenado por hash, y la interfaz web solo escucha en 127.0.0.1 salvo que configure otra cosa. Consulte la página del dashboard para ver detalles y límites.

Versiones y cadena de suministro

• Versiones firmadas. Cada versión tiene un archivo SHA256SUMS firmado sin conexión con ML-DSA-65 (FIPS 204, poscuántico) y ECDSA P-256. Las claves privadas nunca están en GitHub; las huellas de las claves públicas figuran en el archivo SECURITY.md de cada versión.
• SBOM. Cada versión incluye una lista de materiales de software CycloneDX con la versión, la licencia y el SHA-256 de cada componente.
• Dos bibliotecas, fijadas. Emona MFT solo usa Apache Log4j 2 y, para el protocolo 3, Bouncy Castle. Sus versiones y hashes están fijados y se comprueban cada semana contra Maven Central.
• Comprobado en cada cambio. Análisis estático con CodeQL, Dependabot y pruebas básicas de los protocolos 1, 2 y 3 y del dashboard en Java 8, 11, 17, 21 y 25.

Cómo informar de un problema de seguridad

Si encuentra un problema de seguridad en Emona MFT, jFiltra o en este sitio web, comuníquelo en privado y no en una incidencia pública: escriba a rumanko@bluegem.sk con un asunto que empiece por [Emona MFT security], o contacte con BLUEGEM a través de bluegem.sk. Para Emona MFT confirmamos la recepción en 3 días laborables y damos una primera valoración en 10 días laborables. Los problemas de gravedad crítica o alta se corrigen en los 30 días siguientes a su confirmación, antes si se están explotando activamente. Acordamos con usted la fecha de divulgación y le damos crédito salvo que prefiera no ser nombrado.

Este sitio web

emonamft.com es un sitio estático con una Content Security Policy estricta y sin fuentes de terceros. Google Analytics es el único script de terceros y solo se carga después de que acepte las cookies de análisis. Los pedidos se escriben en un archivo de nuestro propio servidor y se envían por correo electrónico a BLUEGEM; consulte el aviso de privacidad.