El detonante fue un hallazgo formal de auditoría, no una iniciativa estratégica. Una empresa de energía nórdica de tamaño mediano que opera sistemas de gestión de red en tiempo real recibió una evaluación previa de su autoridad nacional competente indicando que su arquitectura cloud actual no cumpliría los requisitos de NIS2 para operadores de servicios esenciales. El punto conflictivo era concreto: la telemetría SCADA de activos de red en producción se estaba procesando en infraestructura operada por un hiperescalador con sede en Estados Unidos, sujeta a jurisdicción estadounidense y al alcance de la legislación federal de ese país. La organización tenía aproximadamente cuatro meses para demostrar una ruta de remediación creíble antes de que se abriera la ventana de auditoría formal.

NIS2 endurece las obligaciones de los operadores de servicios esenciales en energía, transporte, agua y varios otros sectores, y lo hace con consecuencias reales. Para un operador de red, los puntos de presión relevantes son la seguridad de las redes y sistemas de información, las obligaciones de notificación de incidentes y, de forma crítica, el riesgo en la cadena de suministro. Enrutar datos operacionales en tiempo real a través de un proveedor que puede ser obligado por un gobierno extranjero a revelar o interceptar esos datos no es un riesgo teórico bajo la directiva: es una deficiencia arquitectónica que los auditores están formados para identificar. El equipo legal y de cumplimiento de la empresa había señalado esta exposición jurisdiccional con anterioridad, pero el coste y la complejidad de la migración la habían mantenido en el backlog. El hallazgo de auditoría la colocó en lo más alto de la agenda de la noche a la mañana.

El reto técnico no era trivial. El pipeline existente ingería telemetría de subestaciones y activos de distribución a intervalos de menos de un segundo, la procesaba a través de una capa de procesamiento de flujos para detección de anomalías y previsión de carga, y escribía los resultados en un almacén de series temporales consumido por el centro de operaciones de red. La tolerancia a la latencia era ajustada: el equipo de operaciones necesitaba los datos procesados en menos de dos segundos desde la ingesta. Cualquier arquitectura de migración debía preservar ese presupuesto de latencia mientras trasladaba cada componente a infraestructura inequívocamente dentro de la jurisdicción de la UE y sujeta a la legislación europea.

Arquitectura: bare metal, event streaming y una frontera jurisdiccional clara

La participación de DIVERSITY comenzó con una revisión de arquitectura de cuatro semanas. El datacenter HEL1 de Helsinki fue el ancla natural para la carga de trabajo: geográficamente cercano a los activos de red de la empresa en la región nórdica y operando bajo legislación finlandesa y de la UE sin ninguna empresa matriz extranjera en la cadena de propiedad. Una presencia secundaria en MUN1 (Múnich) proporcionó el nodo de recuperación ante desastres, con replicación exclusiva en la UE que garantiza que los datos nunca salgan de la jurisdicción europea ni siquiera en un escenario de failover.

El núcleo de la nueva arquitectura fue un clúster de event streaming en bare metal funcionando en HEL1, en sustitución del servicio gestionado de Kafka que la empresa utilizaba en su proveedor anterior. La infraestructura de event streaming de DIVERSITY ejecuta Apache Kafka, lo que significa que los productores y consumidores existentes de la empresa solo necesitaron reconfiguración de endpoints en lugar de reescrituras de código. Esa decisión recortó semanas del calendario de migración. La capa de procesamiento de flujos, un conjunto de operadores con estado que realizaban agregaciones por ventanas para la puntuación de anomalías, se redespleó en nodos bare metal dedicados en lugar de infraestructura virtual compartida. El bare metal eliminó la varianza de latencia por efecto vecino ruidoso que ocasionalmente había provocado que la empresa superara su presupuesto de procesamiento de dos segundos en la plataforma anterior.

El almacén de series temporales se migró a la infraestructura de DIVERSITY, con snapshots replicados a MUN1. El multihoming BGP en ambos sitios significaba que un evento a nivel de datacenter podía activar el failover de tráfico, como preveían el diseño y el contrato. El equipo de operaciones de seguridad de la empresa se integró con el servicio de monitorización SOC de SecOps de DIVERSITY, lo que les proporcionó visibilidad continua sobre la capa de infraestructura y una cadena de respuesta a incidentes documentada que podía presentarse directamente a los auditores.

La soberanía como requisito de ingeniería, no como casilla que marcar

Una de las partes más exigentes del proyecto fue producir el rastro documental que necesitarían los auditores. El cumplimiento de NIS2 en el sector energético no se satisface con la autoatestación de un proveedor: la organización debe demostrar que su cadena de suministro es auditable, que sus acuerdos de tratamiento de datos se rigen por la legislación de la UE y que no existe ningún mecanismo contractual o legal por el que una autoridad extranjera pueda acceder a datos operacionales sin el conocimiento y consentimiento de las autoridades competentes del estado miembro de la UE correspondiente.

La soberanía en infraestructuras críticas no es una afirmación de marketing que puedas comprar en la página de cumplimiento de un hiperescalador. Es una propiedad legal y arquitectónica que tiene que ingeniarse en el stack desde los cimientos.

La condición de DIVERSITY como empresa con sede en Europa y sin empresa matriz estadounidense, combinada con un SLA contractual de disponibilidad del 99,9%, proporcionó al equipo legal de la empresa las bases que necesitaba. Los acuerdos de tratamiento de datos se redactaron bajo legislación de la UE, y la infraestructura física en HEL1 y MUN1 estaba documentada. El equipo de DIVERSITY trabajó directamente con los responsables de cumplimiento de la empresa para preparar el paquete de evidencias, mapeando cada obligación de NIS2 a un control arquitectónico o contractual específico.

Resultado: una auditoría sin hallazgos y una estructura de costes más eficiente

La auditoría formal de NIS2 tuvo lugar aproximadamente seis meses después del inicio del proyecto de migración. La empresa la superó sin un solo hallazgo de remediación relacionado con su infraestructura cloud. Los auditores señalaron la claridad jurisdiccional de la nueva arquitectura, la cadena de respuesta a incidentes documentada y el diseño de resiliencia en dos datacenters de la UE geográficamente separados como indicadores positivos de madurez.

El resultado financiero fue un beneficio inesperado más que un objetivo principal, pero fue significativo. Al eliminar los cargos de egreso entre regiones de su proveedor anterior y consolidar en capacidad bare metal con precios mensuales predecibles, la empresa redujo su gasto anual en cloud en aproximadamente un 30 por ciento. Los ahorros no fueron el resultado de recortar capacidades: la nueva arquitectura gestionó mayor throughput con menor latencia que la configuración anterior. Fueron el resultado de pasar de un modelo de consumo diseñado en torno a las estructuras de margen de los hiperescaladores a infraestructura dedicada con precios pensados para cargas de trabajo sostenidas y predecibles.

El equipo de operaciones de la empresa también reportó una mejora medible en la consistencia de la latencia del pipeline. El bare metal eliminó el jitter de planificación que ocasionalmente había empujado los tiempos de procesamiento por encima del umbral de dos segundos. En un contexto de operaciones de red, esa consistencia no es una métrica de confort: afecta directamente a la calidad de los modelos de detección de anomalías que informan las decisiones de conmutación en tiempo real.

Lo que demuestra este proyecto

NIS2 está creando una presión ineludible en toda la infraestructura crítica europea que los equipos de compras y los arquitectos cloud no pueden seguir aplazando. Para los operadores de energía en particular, la combinación de los requisitos de soberanía de datos en pipelines OT, las obligaciones de riesgo en la cadena de suministro y la ya elevada densidad regulatoria del sector significa que la exposición jurisdiccional en la arquitectura cloud es ahora un riesgo de auditoría, no simplemente una preferencia de política. El camino para gestionar ese riesgo no pasa por la complejidad: pasa por elegir infraestructura que sea inequívocamente europea en propiedad, legislación y ubicación física, y por construir la documentación que lo demuestre.

  • El event streaming en bare metal en HEL1 sustituyó a un servicio gestionado de Kafka y, al tratarse del propio Apache Kafka, preservó el código existente de productores y consumidores
  • La replicación de doble sitio exclusiva en la UE entre HEL1 y MUN1 proporcionó recuperación ante desastres sin que los datos abandonaran la jurisdicción europea
  • La integración con el SOC de SecOps proporcionó la cadena de respuesta a incidentes documentada que requerían los auditores
  • El gasto anual en cloud cayó aproximadamente un 30 por ciento gracias a la eliminación de los cargos de egreso y la consolidación en precios predecibles de bare metal
  • La consistencia de la latencia del pipeline mejoró, eliminando las superaciones ocasionales del umbral operacional de dos segundos