NIS2 y DORA separados limpiamente: Clústeres de cumplimiento en Kubernetes
NIS2 y DORA exigen diferentes obligaciones. Cómo los arquitectos de la nube implementan ambas como clústeres de cumplimiento separados en Kubernetes y…
Dos conjuntos de reglas, un clúster, mucha confusión. Quien combina NIS2 y DORA en el mismo entorno de Kubernetes se crea un problema de auditoría que solo se detecta durante la inspección. La separación limpia en clústeres de cumplimiento separados ahorra, en caso de emergencia, las semanas que un equipo perdería buscando pruebas.
Lo más importante en resumen
- NIS2 y DORA abordan mundos diferentes: DORA se aplica desde el 17 de enero de 2025 para el sector financiero y sus proveedores de servicios de TI, mientras que NIS2 afecta a un círculo mucho más amplio de instalaciones críticas e importantes. Para bancos y aseguradoras, DORA como regla especial tiene prioridad.
- El clúster de cumplimiento implica separación con fuerza probatoria: Los espacios de nombres propios, las políticas aplicadas y la evidencia recopilada automáticamente superan cualquier documentación posterior. El inspector quiere ver el estado deseado técnicamente impuesto, no descrito en un PDF.
- La soberanía de los datos pertenece a la configuración del clúster, no al contrato: El anclaje regional, el cifrado y los caminos de acceso rastreables deciden si la arquitectura supera una prueba o cae el primer día.
Relacionado:Kubernetes como sistema operativo predeterminado de IA: clúster como cuestión de cumplimiento / La soberanía de la IA comienza en la infraestructura
1. Separar NIS2 y DORA antes de que esté la arquitectura
El error más común ocurre antes de la primera línea de YAML. Los equipos tratan NIS2 y DORA como un solo paquete de cumplimiento, porque ambos provienen de Bruselas y ambos suenan a resiliencia. En la práctica, abordan diferentes destinatarios con diferente profundidad.
DORA, la Ley de Resiliencia Operativa Digital, está en vigor desde principios de 2025. Se aplica directamente a las empresas financieras y captura a los proveedores críticos de TI a través de un régimen de supervisión y contrato propio. NIS2, la directiva subyacente de la UE, traza un círculo mucho más amplio: energía, salud, transporte, infraestructura digital y muchos proveedores entran dentro. En Alemania, la ley de implementación de NIS2 ya ha sido aprobada y está en vigor desde diciembre de 2025. La obligación de implementación se vuelve así concreta.
Importante para la arquitectura es el orden de prioridad. Para una empresa financiera regulada, DORA como regla especial tiene prioridad sobre los requisitos generales de NIS2, donde ambos regulan el mismo asunto. Un arquitecto de nube en la mediana empresa que construye para un banco, planea principalmente contra DORA. Quien construye para un proveedor de energía o un fabricante de máquinas, planea contra NIS2. Quien atiende a ambos clientes, necesita ambos mundos separados, no mezclados.
2. Cortar los clústeres de forma limpia en lugar de mezclar cargas de trabajo
¿Qué es un Compliance-Cluster? Un Compliance-Cluster es un entorno Kubernetes delimitado, en el que las workloads de un determinado marco normativo se ejecutan aisladas, con sus propias Policies, su propio control de acceso y su propia evidencia. El límite se impone técnicamente y se mantiene en operación.
Detrás del término hay una decisión de segmentación. La regla básica: las workloads que caen bajo diferentes marcos normativos no comparten una zona de confianza. En Kubernetes esto se puede implementar en dos niveles.
La separación estricta se realiza mediante clústeres dedicados con su propio Control Plane y su propio modelo de acceso. Los Node-Pools solo separan la capacidad de cálculo y comparten la capa de control; para workloads financieros fuertemente regulados, esto a menudo no basta. La separación más suave dentro de un clúster utiliza Namespaces como límite de cumplimiento, asegurados con Network Policies que impiden el tráfico cruzado entre zonas. Un Namespace solo se convierte en un verdadero límite mediante una Network Policy aplicada; antes de eso, sigue siendo una mera etiqueta.
La diferencia la marca la aplicación. Los Policy-Engines como Kyverno o Open Policy Agent revisan cada recurso contra reglas antes de que llegue al clúster. No hay Pod sin límites de recursos definidos, no hay contenedor como root, no hay imagen de un registro no autorizado. Estas reglas son la verdadera evidencia de cumplimiento, porque imponen el estado deseado y lo demuestran en todo momento.
| Dimensión | NIS2 | DORA |
|---|---|---|
| Destinatarios | Instalaciones críticas y importantes en numerosos sectores | Empresas financieras y sus proveedores de TI críticos |
| Ámbito | Directiva de la UE, se requiere implementación nacional | Reglamento de la UE, aplicable directamente desde el 17 de enero de 2025 |
| Enfoque | Gestión de riesgos, obligaciones de notificación, cadena de suministro | Resiliencia de TI, riesgo de terceros, pruebas de resiliencia |
| Relación | Marco general | Regla especial, prevalece en el sector financiero |
3. Recopilar evidencia automáticamente, no buscarla el día de la auditoría
La mayor parte del trabajo de cumplimiento se consume en la evidencia, no en la implementación. Quien el día de la auditoría busca entre los logs, ha construido el sistema de forma incorrecta. Un Compliance-Cluster genera su propia evidencia en operación.
Tres capas deben activarse por defecto. El Kubernetes-Audit-Log registra cada acción de la API, quién, cuándo y qué recurso se modificó. Un vigilante de tiempo de ejecución como Falco informa de comportamientos sospechosos en contenedores, por ejemplo una shell que aparece en un Pod de producción. Y la Policy-Engine registra cada recurso rechazado como una entrada verificable de que la regla se aplica. En conjunto, estas tres capas forman una cadena de evidencia que un auditor puede seguir sin necesidad de mirar la pantalla del equipo.
El beneficio va más allá de la auditoría. NIS2 exige a las entidades afectadas que notifiquen incidentes de seguridad significativos en plazos cortos. Quien ha instrumentado su telemetría de forma limpia, responde a la pregunta de qué y cuándo ocurrió un incidente a partir de sus propios datos, en lugar de reconstruirlos.
4. Anclar la soberanía de datos en la configuración del clúster
La soberanía se decide en la configuración, no en el contrato con el proveedor de servicios en la nube. Ambas regulaciones exigen control sobre dónde se encuentran los datos y quién accede a ellos. En Kubernetes, esto se puede implementar técnicamente.
El anclaje de región a través de afinidades de nodo y restricciones de topología garantiza que las cargas de trabajo reguladas no abandonen la región prometida. El cifrado debe aplicarse en ambos caminos, en tránsito y en reposo, con claves cuya administración controle la empresa misma. Y el acceso se realiza a través de derechos basados en roles, que se asignan según el principio de privilegios mínimos. Un clúster en el que la mitad del equipo sea administrador de clúster no resiste una auditoría seria.
Qué rompe una auditoría
- Espacios de nombres sin políticas de red aplicadas
- Cumplimiento solo en documentos, no impuesto en el clúster
- Amplios derechos de administración sin justificación
- Evidencia que solo se busca el día de la auditoría
Qué contribuye
- El motor de políticas implementa técnicamente el estado deseado
- Registro de auditoría, monitoreo en tiempo de ejecución y registros de políticas como cadena de evidencia
- Anclaje de región y administración de claves propia
- Derechos asignados según privilegios mínimos
5. Por dónde deben empezar los arquitectos
El orden decide sobre el esfuerzo. Quien comienza con la decisión de interfaz, qué cargas de trabajo pertenecen a qué zona, ahorra reconstrucciones costosas más adelante. Quien comienza con la herramienta, construye políticas para una separación que aún no se ha pensado.
Tres pasos en esta secuencia brindan la mayor palanca. Primero, el mapa regulatorio: ¿Qué carga de trabajo cae bajo qué regulación, y hay cargas de trabajo financieras que activan la prioridad DORA? Luego, la separación: clústeres dedicados para los casos difíciles, espacios de nombres con políticas de red para el resto. Finalmente, la automatización de la evidencia, para que la prueba se genere en la operación. Las multas son reales, la directiva NIS2 prevé sanciones de al menos 10 millones de euros o el 2% del volumen de negocios mundial del año anterior para las entidades esenciales, dependiendo de cuál sea mayor. Sin embargo, el daño real suele ocurrir antes, en semanas que un equipo pierde en la documentación posterior, porque la arquitectura nunca generó la prueba por sí misma.
Preguntas frecuentes
¿Se aplican NIS2 y DORA simultáneamente a mi empresa?
Depende del sector. Las empresas financieras caen principalmente bajo DORA, que como regla especial precede a los requisitos generales de NIS2, donde ambos regulan el mismo asunto. Las empresas fuera del sector financiero que se consideran instalaciones críticas o importantes planifican contra NIS2. Quien atiende a ambos mundos, los separa técnicamente.
¿Es suficiente un solo clúster de Kubernetes para ambos conjuntos de reglas?
Técnicamente es posible mediante espacios de nombres con políticas de red aplicadas. En casos difíciles, como cargas de trabajo financieras críticas bajo DORA, la separación física en clústeres dedicados o grupos de nodos es la opción más limpia. La decisión depende del riesgo, no de la comodidad.
¿Qué se considera una prueba de cumplimiento fiable en una auditoría?
Un estado objetivo forzado más una cadena de evidencia rastreable. Un motor de políticas que verifica cada recurso frente a las reglas, un registro de auditoría de Kubernetes y el monitoreo en tiempo de ejecución juntos proporcionan la prueba de que las especificaciones técnicas son efectivas. Un PDF que describe el estado es significativamente más débil.
¿Desde cuándo es válida DORA y si NIS2 es ley en Alemania?
DORA es válida como reglamento de la UE desde el 17 de enero de 2025. NIS2 es una directiva que requiere implementación nacional. En Alemania, la ley de implementación de NIS2 está en vigor desde diciembre de 2025. Las instalaciones afectadas deben verificar activamente sus obligaciones de registro y notificación.
¿Dónde empiezan mejor los equipos de nube de tamaño mediano?
Con el mapa regulatorio, no con la herramienta. Primero, aclaren qué carga de trabajo cae bajo qué conjunto de reglas, luego corten la separación y luego automaticen la evidencia. Este orden evita reconstrucciones costosas y asegura que la evidencia ya esté disponible durante la operación en curso.
Más del network de MBF Media
Fuente de la imagen: generada por IA (Juli 2026)
