Dashboard

Emona MFT Dashboard

Una página web para todos sus servidores y clientes Emona MFT: quién está en línea, qué se envió y cuándo, qué falló, cuánto espacio en disco queda, alertas por correo electrónico o syslog, y un registro de incidentes para cada alerta.

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

Cómo funciona

El dashboard es un programa independiente que se instala junto a sus servidores Emona MFT. Cada servidor y cada cliente recibe su propia clave y envía sus eventos y una señal de vida (heartbeat) al dashboard por un enlace de agente cifrado (puerto TCP 9100 por defecto). El dashboard se abre en el navegador.

• Solo lectura respecto a servidores y clientes. El dashboard nunca cambia su configuración ni les envía órdenes. Los agentes solo envían datos; el dashboard solo responde con un acuse de recibo.
• Nunca detiene una transferencia. Si no se puede acceder al dashboard, los eventos esperan en memoria (hasta 10.000) y se envían cuando vuelve a estar disponible. Un dashboard detenido o una clave incorrecta solo se notan en el registro.
• Sin base de datos ni framework. Un único JAR y datos en archivos sencillos en su disco. Los agentes se añaden en un archivo simple y los cambios se aplican sin reiniciar.
• Los eventos se guardan una sola vez. Cada evento lleva un número de secuencia, de modo que los eventos reenviados tras perderse un acuse de recibo se omiten, también después de un fallo o reinicio del dashboard.

Qué verá

• Vista general: servidores y clientes en línea, archivos guardados y problemas de hoy, el menor espacio libre en disco, alertas abiertas, archivos guardados en las últimas 24 horas y las últimas transferencias. Los recuentos de transferencias se guardan por intervalos de 15 minutos, así que los totales del día siguen su zona horaria.
• Clientes y detalle de cliente: último contacto, último archivo, archivos en espera, directorios de origen, y archivos y problemas de los últimos días.
• Servidores: almacenamiento y espacio libre por cliente, transferencias activas y configuración.
• Transferencias: búsqueda por día, cliente, nombre de archivo y resultado en todos los días conservados. La página muestra las 500 transferencias más recientes de un día junto con el total del día, y la exportación CSV las incluye todas.
• Alertas: alertas abiertas y pasadas. Los operadores y administradores las confirman.
• Agentes (administradores): cada servidor y cliente con su ID de agente, huella de la clave, rol, estado, último contacto y dirección.
• Registro de incidentes: cada alerta con su confirmación, resolución, notas e historial, exportable por periodo en CSV o JSON (administradores y auditores).
• Auditoría, Usuarios, Licencia (administradores) y Cuenta para cada usuario, con inicio de sesión en dos pasos.

Las páginas se actualizan solas cada 30 segundos.

Registro de eventos y pista de auditoría

Los servidores y clientes de Emona MFT escriben un registro de eventos legible por máquina: una línea JSON por evento y un archivo por día. Registra cada transferencia completada, rechazada o fallida con cliente, nombre de archivo, tamaño, hash SHA-256, protocolo y duración, además de arranques y paradas, un servidor inaccesible y un directorio de origen que falta. Nunca se escriben en él claves ni contenidos de archivos.

• Vinculado al agente real. El dashboard registra cada evento con el ID de agente de la conexión autenticada, de modo que ningún servidor o cliente puede enviar eventos en nombre de otro. El rol y la etiqueta de cliente de un agente son fijos, solo los servidores informan de transferencias, y los eventos de un cliente siempre cuentan para su propia etiqueta.
• Registro de auditoría encadenado por hash. Cada inicio de sesión, intento fallido, cambio de usuario, confirmación de alerta, nota de alerta, exportación y cambio de licencia va al registro de auditoría del dashboard. Cada línea lleva el hash SHA-256 de la línea anterior, de modo que una línea modificada o eliminada en mitad de un archivo queda a la vista.
• Sellos. Los registros de eventos, el registro de auditoría y el registro de incidentes reciben líneas de sello cada hora (configurable), al final de cada día y al detenerse. Comparados con la copia de su SIEM, los sellos también muestran líneas eliminadas al final de un archivo y una cadena recalculada.
• Autocomprobación cada hora. Servidores, clientes y el dashboard comprueban sus propias cadenas de hash al abrir un archivo y cada hora. Una cadena rota genera una alerta crítica: «Event log changed», «Audit log changed» o «Incident register changed».
• Verificación. La página «Audit» muestra la integridad de cada archivo diario, marca los archivos sellados y permite a administradores y auditores descargarlos. Una comprobación por línea de comandos verifica cualquier archivo de eventos, auditoría o incidentes, opcionalmente frente a la copia del SIEM.

Los registros son a prueba de manipulaciones en el sentido de que las detectan, no de que las impidan: quien tenga acceso de escritura a los archivos puede seguir modificándolos. Los sellos hacen visible ese cambio cuando los archivos se comparan con una copia guardada en otro lugar, así que trate la copia de su SIEM como la de referencia.

Reenvío a SIEM y syslog

• Cada línea a su SIEM. Con siem.host definido, el dashboard envía cada evento de todos los servidores y clientes y cada línea de auditoría a su SIEM o servidor de registros como syslog RFC 5424 por UDP, TCP o TLS.
• Nada se pierde en una caída. Las líneas se leen de los archivos y se guarda la posición, de modo que las líneas escritas mientras el SIEM estaba caído o el dashboard se reiniciaba se envían después. Se detecta un SIEM que deja de leer y se abre la alerta «SIEM forwarding failing».
• También sin el dashboard. Los servidores y clientes pueden enviar sus propias líneas de eventos directamente a un receptor syslog.
• Búsquedas preparadas. La documentación enumera los eventos que merecen una regla, con búsquedas de ejemplo para Splunk, Elastic y Microsoft Sentinel.

Alertas

Cada alerta se envía una vez al abrirse y otra al terminar, por correo electrónico a través de su relé SMTP y a syslog (RFC 5424), si están configurados. Las repeticiones se cuentan, no se reenvían. Operadores y administradores confirman alertas y añaden notas, por ejemplo qué se encontró y qué se hizo.

Registro de incidentes

Cada alerta es también un incidente. El dashboard registra cada apertura, reapertura, confirmación, resolución y nota, con el usuario y el estado del incidente en ese momento, en archivos accesibles solo para su propietario, encadenados por hash y sellados, que se conservan tres años por defecto.

• Para las notificaciones de NIS2. El registro aporta los momentos (abierto, confirmado, resuelto), quién gestionó el incidente, las notas y el historial que necesita para una alerta temprana, una notificación o un informe final (art. 21 y 23 de NIS2). Decidir si un incidente es significativo y notificarlo sigue siendo cosa suya; no se envía nada a ninguna autoridad.
• Exportación por periodo. Administradores y auditores exportan todos los incidentes de un periodo en CSV o JSON desde la página «Alerts». Cada exportación queda registrada en el registro de auditoría.

Usuarios, roles e inicio de sesión

• Roles. Los lectores ven las páginas que tienen permitidas. Los operadores, además, confirman alertas y añaden notas. Los administradores, además, gestionan usuarios, ven el registro de auditoría y los agentes, instalan la licencia y exportan el registro de incidentes. Los auditores, pensados para auditores internos o externos y delegados de protección de datos, ven y descargan el registro de auditoría y exportan el registro de incidentes, pero no pueden cambiar nada. Un usuario puede limitarse a algunos clientes y entonces solo ve esos clientes y sus transferencias.
• Inicio de sesión en dos pasos. Cada usuario puede activar códigos de una app de autenticación (TOTP: Google Authenticator, Microsoft Authenticator, Aegis, 1Password y otras) escaneando un código QR, con 10 códigos de recuperación de un solo uso. Los administradores deciden qué roles deben usarlo; las instalaciones nuevas lo exigen a los administradores.
• Single sign-on. Los usuarios pueden iniciar sesión con Microsoft Entra ID, Okta, Keycloak, Google Workspace, ADFS o cualquier proveedor OpenID Connect (flujo de código con PKCE). Los grupos del proveedor se asignan a roles y clientes, y un modo solo SSO mantiene a los administradores locales como acceso de emergencia.
• Contraseñas. Al menos 10 caracteres, guardadas como hashes PBKDF2-SHA256. En el primer arranque, el dashboard crea un usuario admin con una contraseña aleatoria que debe cambiarse en el primer inicio de sesión.
• Bloqueo por usuario y dirección. Tras 5 contraseñas o códigos incorrectos desde una dirección, el usuario queda bloqueado 15 minutos solo desde esa dirección; desde otras direcciones puede seguir iniciando sesión.
• Limitación durante un ataque. Tras 20 contraseñas incorrectas para un usuario desde todas las direcciones juntas, los navegadores nuevos en direcciones nuevas comparten un intento comprobado cada 5 segundos para ese usuario, lo que limita las adivinanzas a unas 12 por minuto, use el atacante las direcciones que use. Los navegadores y direcciones desde los que el usuario ya inició sesión se siguen comprobando, así que la contraseña correcta sigue funcionando.
• Detrás de un proxy inverso. Indique en ui.trusted.proxy la dirección del proxy y el bloqueo contará cada dirección de usuario a partir de su cabecera X-Forwarded-For. Sin este ajuste, la cabecera se ignora.
• Sesiones y páginas. Las sesiones terminan tras 30 minutos sin uso. Las cookies son HttpOnly y SameSite=Strict (y Secure con HTTPS), cada formulario tiene un token CSRF y las páginas se envían con una Content Security Policy estricta y X-Frame-Options: DENY.

Instalación y límites

• Java 8u92 o posterior en Linux, macOS o Windows, con Apache Log4j 2 como única dependencia. Un heap de 256 MB basta para la configuración predeterminada.
• Local por defecto. La interfaz web solo escucha en 127.0.0.1 salvo que configure otra cosa. HTTPS funciona con su propio almacén de claves (keystore).
• Enlace de agente. Una clave por agente, claves de sesión HKDF-SHA256 y AES-256-GCM, de modo que una conexión grabada no puede reproducirse ante el dashboard.
• Archivos solo para el propietario. En Linux y macOS, todo lo que el dashboard escribe en su carpeta de datos solo lo puede leer la cuenta que lo ejecuta, y los archivos de claves que otros usuarios pueden leer se notifican al arrancar y como alerta.
• Licencia comprobada sin conexión. El archivo de licencia de BLUEGEM está firmado y se comprueba sin ninguna conexión a internet. Los servidores y clientes de Emona MFT nunca se detienen ni cambian su comportamiento por la licencia del dashboard.
• Preparado para conexiones lentas. El servidor web cierra las conexiones que no han enviado una solicitud completa en 5 segundos y añade hilos según sea necesario, hasta unas 1.000 conexiones lentas a la vez. Si el dashboard es accesible desde internet, coloque delante un proxy inverso (nginx, Apache, IIS).
• Exportaciones CSV. Como máximo dos descargas en curso por usuario, con un límite configurable del espacio temporal que usan, para que una cuenta no pueda llenar el disco.
• Correo electrónico. Las alertas se envían a través de un relé SMTP sin TLS, así que use un relé de su red local.