MiroxMirox
  • Plataforma

    • Filosofía
    • Visión general de la plataforma
    • Recursos de la plataforma
  • Mirox-Cloud

    • Visión general de la nube
    • Microservicios conectados
  • Mirox-Agent

    • Visión general del agente
    • Opciones de despliegue
    • Data Scraper
    • Gemelo digital
  • Detalles técnicos

    • Recopilación de métricas
  • Información

    • Plantas compatibles
  • Tipos de planta

    • Plantas solares
    • Parques eólicos
    • Almacenamiento por baterías
  • Monitorización y visualización

    • Monitorización en tiempo real
    • Gemelo digital
    • Estados de componentes
    • Detección de pérdidas
    • Detección de eficiencia
    • Panel de KPI
  • Gestión de datos

    • Eventos
    • Tickets
    • Previsiones
    • Informes
  • Integración y colaboración

    • Cooperaciones
    • Tokens de API
    • VPN
    • Proxy
  • IA

    • Asistente de IA y asistentes
    • Acceso agéntico (MCP)
  • Facturación

    • Mercado y tarifas
    • Contabilidad y facturación
  • Colaboración

    • Invitaciones
  • Seguridad

    • Autenticación
    • Sistema de permisos
    • Restricciones de cooperación
    • Registro de auditoría de acceso
  • Nodos

    • mrxnode
  • Aplicación

    • Control de puerta
    • Relé genérico
  • Clúster en el borde

    • Orquestación
  • Primeros pasos

    • Primeros pasos
  • Personal

    • Usar la VPN
    • Usar el proxy
    • Autenticación de dos factores
    • Sesiones
    • Tokens de API
  • Por planta

    • Contactos
    • Dispositivos de red
    • Registradores de datos
    • Componentes
    • VPN directa (por agente)
  • Organización

    • Permisos de miembros
    • Cooperaciones
    • Almacenamiento de archivos
  • Exportación de datos

    • API de exportación de métricas
    • MiroxQL — lenguaje de consulta
    • Generación externa de informes
    • Grafana
    • Visión general de la API
  • Soporte

    • Solicitar guía de integración
  • mrxnode

    • Visión general
    • Guías
    • Despliegue de contenedor
    • Referencia de comandos
    • Solución de problemas
  • Generación de informes

    • Generador de informes externo
  • English
  • Deutsch
  • Español
  • Français
  • Português
  • Italiano
  • English
  • Plataforma

    • Filosofía
    • Visión general de la plataforma
    • Recursos de la plataforma
  • Mirox-Cloud

    • Visión general de la nube
    • Microservicios conectados
  • Mirox-Agent

    • Visión general del agente
    • Opciones de despliegue
    • Data Scraper
    • Gemelo digital
  • Detalles técnicos

    • Recopilación de métricas
  • Información

    • Plantas compatibles
  • Tipos de planta

    • Plantas solares
    • Parques eólicos
    • Almacenamiento por baterías
  • Monitorización y visualización

    • Monitorización en tiempo real
    • Gemelo digital
    • Estados de componentes
    • Detección de pérdidas
    • Detección de eficiencia
    • Panel de KPI
  • Gestión de datos

    • Eventos
    • Tickets
    • Previsiones
    • Informes
  • Integración y colaboración

    • Cooperaciones
    • Tokens de API
    • VPN
    • Proxy
  • IA

    • Asistente de IA y asistentes
    • Acceso agéntico (MCP)
  • Facturación

    • Mercado y tarifas
    • Contabilidad y facturación
  • Colaboración

    • Invitaciones
  • Seguridad

    • Autenticación
    • Sistema de permisos
    • Restricciones de cooperación
    • Registro de auditoría de acceso
  • Nodos

    • mrxnode
  • Aplicación

    • Control de puerta
    • Relé genérico
  • Clúster en el borde

    • Orquestación
  • Primeros pasos

    • Primeros pasos
  • Personal

    • Usar la VPN
    • Usar el proxy
    • Autenticación de dos factores
    • Sesiones
    • Tokens de API
  • Por planta

    • Contactos
    • Dispositivos de red
    • Registradores de datos
    • Componentes
    • VPN directa (por agente)
  • Organización

    • Permisos de miembros
    • Cooperaciones
    • Almacenamiento de archivos
  • Exportación de datos

    • API de exportación de métricas
    • MiroxQL — lenguaje de consulta
    • Generación externa de informes
    • Grafana
    • Visión general de la API
  • Soporte

    • Solicitar guía de integración
  • mrxnode

    • Visión general
    • Guías
    • Despliegue de contenedor
    • Referencia de comandos
    • Solución de problemas
  • Generación de informes

    • Generador de informes externo
  • English
  • Deutsch
  • Español
  • Français
  • Português
  • Italiano
  • English
  • Monitorización y visualización

    • Monitorización en tiempo real
    • Gemelo Digital
    • Estados de los componentes
    • Detección de pérdidas
    • Detección de eficiencia (PRRC)
    • Inspector de Red Local
    • Monitorización de accesos
    • Panel de KPI
    • Visualización de gráficos
  • Gestión de datos

    • Eventos
    • Tickets
    • Previsiones
    • Informes
  • Integración y colaboración

    • Cooperaciones
    • Tokens de API
    • VPN
    • Proxy (Acceso web a los dispositivos de la planta)
  • IA

    • Asistente de IA y asistentes guiados
    • Acceso agéntico (MCP)
  • Facturación

    • Mercado y tarifas
    • Contabilidad y facturación
  • Colaboración

    • Invitaciones
  • Seguridad

    • Autenticación
    • Sistema de permisos
    • Restricciones de permisos de cooperación
    • Registro de auditoría de accesos

Registro de auditoría de accesos

La plataforma Mirox mantiene un rastro de auditoría continuo y resistente a manipulaciones de cada acceso remoto a los dispositivos de red de una planta — cada sesión de túnel VPN (capa 3/4) y cada solicitud de Proxy (capa 7, HTTP). Esta página describe exactamente qué se captura, hasta qué nivel de detalle llega, quién tiene permiso para acceder a ello y durante cuánto tiempo se conservan los datos.

El rastro de auditoría es lo que hace que el acceso a los dispositivos de planta de la plataforma sea conforme con las normas alemanas KRITIS y con la directiva NIS2 de la UE. Esas regulaciones determinan la ventana mínima de retención y las categorías de evidencia que el operador debe poder presentar — pero el registro de auditoría es, ante todo, una herramienta de seguimiento de accesos para el operador de la planta.

Por qué existe este registro de auditoría

KRITIS y NIS2 obligan a los operadores de infraestructuras críticas (en nuestro caso, las redes de planta de los parques solares, parques eólicos y emplazamientos de almacenamiento en baterías) a poder responder a las siguientes preguntas para cada acceso remoto, de forma completa e incluso meses después:

  • ¿Quién alcanzó la red interna de esta planta?
  • ¿Cuándo se estableció la conexión — y para cada conexión: ¿cuándo se tocó por primera y por última vez qué subred / qué dispositivo?
  • ¿Cuánto tráfico se transfirió durante la conexión?
  • ¿Qué dispositivo específico y qué servicio se tocó?
  • ¿Qué se hizo allí (en la capa HTTP: qué URLs, qué métodos)?

El rastro de auditoría de Mirox cubre todas estas preguntas y está diseñado para el operador de la planta como la parte con la obligación de información — no para el usuario que accede.

Dos vías de acceso, una auditoría compartida

Ambos mecanismos de acceso de la plataforma se fusionan en una vista unificada de accesos por planta:

VíaCapa capturada¿Qué pregunta responde?
VPNCapa 3/4 (tráfico IP)"¿Quién alcanzó qué subred y qué dispositivo específico, desde dónde — primero cuándo, por última vez cuándo, qué volumen?"
ProxyCapa 7 (HTTP)"¿Qué hizo concretamente el usuario en el dispositivo — qué URLs, qué solicitudes, cuántas solicitudes, qué duración?"

Ambas vías comparten la misma base de identidad (la cuenta Mirox del usuario) y la misma lógica legal de retención y acceso. Desde la perspectiva del operador de la planta hay una lista cronológica de accesos por planta, en la que ambos canales aparecen uno junto al otro y pueden acotarse según sea necesario.

Profundidad de captura

El rastro de auditoría se organiza en varias capas de detalle. Cuanto más profundizas en la jerarquía, más granular se vuelve la información:

Capa 1: certificado / identidad

La capa superior captura, por cada certificado VPN, una instantánea de la identidad del usuario en el momento de emisión y de rotación:

  • Nombre de cuenta anonimizado
  • Dirección de correo electrónico
  • Identificador único del certificado

Aunque el usuario se renombre, se elimine o se revoque el certificado más adelante, esta identidad se conserva.

Capa 2: sesión

Cada conexión se rastrea como una sesión. Una sesión es una secuencia continua de actividad del mismo certificado desde el mismo origen. Las interrupciones breves de menos de diez minutos siguen contando como la misma sesión; las pausas más largas crean una nueva sesión.

Por cada sesión capturamos:

  • Quién está conectado (instantánea de cuenta y correo en el momento de la conexión — conservada aunque la cuenta se elimine más tarde)
  • Hora de conexión
  • Dirección IP de origen y atribución geográfica (ciudad, país)
  • Región y nodo que terminaron la conexión (para análisis de latencia)
  • Volumen total de datos (entrante y saliente)

Capa 3: volumen por subred (solo VPN)

Dentro de una sesión capturamos, por cada subred de planta tocada:

  • Qué parque y qué subred se tocó
  • Volumen de datos transferido y recuento de paquetes por sesión y subred
  • Hora del primer y del último contacto
  • Instantáneas del nombre del parque y de la organización por si la planta se renombra o se elimina más tarde

El ruido como las consultas DNS, el multicast mDNS, los pings ICMP y el comportamiento similar al escaneo de puertos se filtra o se limita por tasa, de modo que el rastro de auditoría solo contiene eventos de uso reales.

Capa 4: contactos con dispositivos (solo VPN)

La capa VPN más fina captura, por cada dispositivo de destino específico:

  • IP del dispositivo, protocolo (TCP, UDP, ICMP, ICMPv6, SCTP) y puerto
  • El dispositivo coincidente del inventario de la planta (nombre, tipo) — cuando está registrado
  • Hora del primer contacto dentro de la sesión
  • Número de eventos de conexión en esta sesión
  • Instantáneas de todos los identificadores en el momento del primer contacto

Las interacciones por debajo del umbral (p. ej., resets TCP aislados por clics erróneos) se capturan de forma conservadora, pero quedan reconocibles como tales.

Capa 4': sesiones HTTP (solo Proxy)

En paralelo, el Proxy captura, por cada sesión en la capa HTTP:

  • Cuenta y correo del usuario que accede
  • Qué destino web o acceso predeterminado al dispositivo se utilizó
  • Dispositivo de destino (nombre, IP) — con instantánea para casos posteriores de eliminación o renombrado
  • Navegador, sistema operativo, dirección IP pública, ubicación geográfica
  • Inicio y fin de la sesión (fin de sesión: 10 minutos de inactividad)
  • Número de solicitudes y sus métodos HTTP (p. ej. {"GET": 42, "POST": 3, "PUT": 1})
  • Volumen de datos entrante y saliente
  • Un rastro de actividad de la sesión basado en URLs (las cadenas de consulta se redactan, limitadas a la actividad más reciente dentro de una asignación fija)
  • Una descripción breve generada por IA de la actividad de la sesión para una clasificación rápida. Si la IA no está disponible al cerrar la sesión, la descripción se rellena más tarde — no es opcional, sino una parte fija de toda sesión de proxy cerrada.

Máxima profundidad de detalle posible

La máxima profundidad de detalle es, por lo tanto:

Ejemplo de acceso VPN:

"El usuario X se conectó por VPN el 2026-05-13 a las 13:44 desde la IP pública 198.51.100.7 (región eu-central, Múnich, DE), direccionó la subred 10.90.69.0/24 del parque 'Solar Park Annaburg' durante esta sesión (12 MB transferidos, primer contacto 13:45, último 13:54), tocando específicamente el dispositivo 'Inverter Block 3' (10.90.69.12, TCP/443) (primer contacto 13:45, 41 conexiones)."

Ejemplo de acceso por Proxy:

"El usuario Y accedió al destino web 'Inverter Block 3 – Service UI' a través del Proxy el 2026-05-13 entre las 13:46 y las 13:55 desde la IP pública 203.0.113.42 (región eu-central, Fráncfort, DE) en Mobile Safari 26.4 / iOS 18.7 (87 solicitudes, de las cuales 84 GET, 3 POST; 2,3 MB de volumen de respuesta, resumen de IA: 'Cambio de configuración en los ajustes del seguidor MPP')."

Tanto la VPN como el Proxy capturan la IP de origen pública, la región de terminación y la atribución geográfica (ciudad, país) de la conexión. Para el Proxy, además entran en el rastro de auditoría la información de navegador y sistema operativo (a través del User-Agent que envía el navegador), ya que de todos modos viajan en la capa HTTP. Para el acceso puramente basado en VPN (capa 3/4), esta información del cliente de aplicación no está disponible por naturaleza — allí la plataforma solo ve el flujo de paquetes IP, no el cliente a nivel de aplicación.

Un nivel de detalle más profundo (contenido de paquetes, cuerpos HTTP completos) deliberadamente no se captura, ya que esto sería tanto problemático para la privacidad como inútil desde el punto de vista operativo.

¿Quién tiene permiso para ver la auditoría?

El acceso al rastro de auditoría se delimita según el rol de trabajo que un usuario tenga en la planta:

  • Un Technical Manager o superior en la planta puede ver el rastro de auditoría de esa planta. En la práctica, esto significa un Operador, un Technical Manager o un Asset Manager en la planta. Los administradores y moderadores cumplen automáticamente, porque su rol de organización se asigna a un trabajo cualificado en cada planta de su organización (consulta el Sistema de permisos para la asignación completa de roles a trabajos).
  • Los cooperadores están incluidos: un técnico que alcanza una planta a través de una cooperación con el rol de trabajo requerido también puede ver el rastro de auditoría de esa planta. La visibilidad de la auditoría sigue la misma puerta de rol de trabajo que el resto de los controles de la planta.
  • Los visualizadores quedan excluidos. Un Visualizador (y cualquiera por debajo del nivel de Technical Manager) no ve ningún rastro de auditoría. El frontend oculta por completo la pestaña de registro de accesos para los usuarios por debajo del umbral.

La plataforma expone la vista de auditoría a través de un endpoint de API dedicado para el registro de accesos y de una vista de interfaz correspondiente. Editar o eliminar registros de auditoría no está permitido.

Período de retención y resistencia a manipulaciones

  • Retención de al menos 730 días para todas las capas de auditoría (certificado, sesión, volumen por subred, contactos con dispositivos, sesiones HTTP). El período de retención está alineado entre capas para que las referencias cruzadas entre ellas siempre se resuelvan dentro de la ventana de auditoría completa.
  • Los campos de instantánea en cada registro de auditoría (p. ej. nombre del parque, nombre del dispositivo, nombre de la organización, cuenta, correo) son de escritura única: se estampan en la primera inserción y nunca se actualizan. Esto garantiza la identidad forense aunque el registro original (usuario, planta, dispositivo) se elimine o se renombre más tarde.
  • Resolución en vivo con respaldo: mientras las entidades referenciadas (usuario, parque, organización, dispositivo) sigan existiendo, la vista de auditoría muestra su nombre actual (p. ej. después de que la planta se haya renombrado). Una vez eliminada la entidad, la vista recurre automáticamente a la instantánea estampada. Así, el rastro de auditoría sigue siendo legible — incluso meses o años después, tras cambios de personal o ventas de plantas.
  • Sin vías de eliminación o edición de cara al usuario: las tablas de auditoría no pueden modificarse mediante operaciones normales de interfaz o de API. Solo las tocan los eventos de auditoría automatizados y el barrido nocturno de retención una vez transcurridos los 730 días.

Comportamiento ante eliminaciones

EventoEfecto sobre el rastro de auditoría
Se elimina el usuarioLos registros de auditoría se conservan. La vista muestra la instantánea de cuenta y correo del certificado o de la sesión.
Se revoca el certificadoLos registros de auditoría se conservan. El certificado se revoca de forma lógica (soft-revoke) y sigue disponible como fuente de resolución durante 730 días.
Se elimina la plantaLos registros de auditoría se conservan. La vista muestra la instantánea del nombre del parque del registro de auditoría.
Se elimina / renombra / cambia la IP de un dispositivoLos registros de auditoría se conservan. La vista muestra la instantánea del nombre del dispositivo; la IP del registro es el identificador forense duradero.
Se elimina la organizaciónLos registros de auditoría se conservan. La vista muestra la instantánea del nombre de la organización.

Protección contra la manipulación de los datos de auditoría

  • Las sesiones que no pueden atribuirse (p. ej. porque se eliminó una cabecera) se capturan igualmente con identidad vacía en lugar de descartarse. Un análisis posterior puede entonces investigar específicamente estos casos.
  • Las sesiones HTTP no las cierran únicamente los componentes del SaaS, sino que las cierra y reporta el propio agente de la planta, de modo que la plataforma SaaS no puede subnotificar en silencio el recuento de solicitudes o el volumen.
  • Las condiciones de carrera de submilisegundos al leer cadenas de contadores se aceptan como "pérdida por diseño" y se documentan como conformes con KRITIS; en el peor de los casos pueden afectar a un único ciclo de contador, nunca a sesiones completas ni a contactos con dispositivos.

Filtrado y búsqueda en la vista de auditoría

La vista de auditoría permite a un usuario autorizado acotar el conjunto de resultados:

  • Por cuenta de usuario
  • Por subred o IP de dispositivo
  • Por protocolo o puerto (vía VPN)
  • Por destino web o dispositivo específico (vía proxy)
  • Por rango de tiempo (desde … hasta …)
  • Orden predeterminado por "visto por última vez"

El orden predeterminado agrupa de forma natural por sesión, de modo que la pregunta "El usuario X tocó los dispositivos A y B en esta sesión 18:43–19:00, y el dispositivo C en una segunda sesión 13:44–14:30" es directamente visible sin necesidad de agrupación adicional en el lado del cliente.

Privacidad y divulgación

Lo que el rastro de auditoría contiene:

  • Campos de identidad derivados de la cuenta Mirox normal (cuenta, correo)
  • Direcciones IP de origen de la conexión (legalmente requeridas para KRITIS)
  • Atribución geográfica del origen (ciudad, país)
  • Volumen de datos, recuento de solicitudes, distribución de métodos, marcas de tiempo

Lo que el rastro de auditoría no contiene:

  • Contenido de los cuerpos HTTP individuales
  • Contenido de los paquetes VPN
  • Pulsaciones de teclas o grabaciones de pantalla
  • Datos no requeridos para la información de KRITIS / NIS2

Qué hacer ante una solicitud regulatoria

Para las solicitudes de información motivadas por incidentes dirigidas a la autoridad competente (p. ej. el BSI bajo KRITIS), todos los datos necesarios están disponibles dentro de la ventana de 730 días a través de la vista de auditoría. Una función de exportación (p. ej. CSV) está planificada como una acción separada y auditada de forma individual, y se proporciona a demanda — una exportación de este tipo es en sí misma una operación digna de auditoría, de modo que quede documentado quién exportó qué datos de auditoría y cuándo ("auditoría de la auditoría").

Funciones relacionadas

  • VPN — túnel personal con captura de auditoría completa de capa 3/4
  • Proxy — acceso basado en navegador con captura de auditoría completa de capa 7
  • Sistema de permisos — la asignación de roles a trabajos que decide quién puede abrir la vista de auditoría
  • Cooperaciones — cómo se concede a un técnico cooperante el acceso a la planta (y cómo se audita)
  • Restricciones de cooperación — los límites que mantienen el acceso compartido dentro del alcance elegido por el propietario
Prev
Restricciones de permisos de cooperación
MIT Licensed | Copyright 2026 Mirox Verwaltungs GmbH