Migración de KRITIS a la nube: qué garantiza la seguridad
Los operadores de KRITIS trasladan sistemas críticos a la nube. La migración determina si se cumple con la normativa, disponibilidad y certificación C5.
Desde el 17 de marzo de 2026 entra en vigor el KRITIS-Dachgesetz (ley marco alemana sobre infraestructuras críticas). Quienes trasladen ahora sistemas sensibles a la nube deben integrar desde el primer momento la disponibilidad, la soberanía de los datos y la obligación de acreditación. De esa decisión dependerá que la auditoría posterior sea un simple trámite o se convierta en un auténtico problema.
Lo más importante en resumen
- El círculo se amplía: Más de 30.000 empresas quedan desde la ley alemana de transposición de NIS2 bajo nuevas obligaciones de seguridad ampliadas; muchas de ellas se clasifican por primera vez como entidad importante o especialmente importante.
- C5 se endurece: El nuevo catálogo de criterios C5:2026 incluye 168 criterios en lugar de los 121 anteriores y regula por primera vez de forma explícita los contenedores, la cadena de suministro y la computación confidencial. Será vinculante a partir del 1 de junio de 2027.
- El orden importa más que la velocidad: Quien define el nivel de protección antes de elegir proveedor evita costosas rectificaciones posteriores. La arquitectura y el plan de salida determinan si la migración sigue siendo una carga de cumplimiento o se convierte en una ganancia de resiliencia.
Relacionado:El chip de cloud barato con el costoso camino de vuelta / Ingress-NGINX está obsoleto: el camino hacia la Gateway API
Primero la necesidad de protección, luego el proveedor
¿Qué es KRITIS? Como Infraestructura Crítica se consideran aquellas instalaciones cuyo fallo pone en peligro el suministro a la población, por ejemplo en los sectores de energía, agua, salud, finanzas o transporte. Sus operadores están sujetos a obligaciones especiales de seguridad y notificación. Desde la ley de transposición de NIS2 (NIS2-Umsetzungsgesetz) y la ley marco KRITIS (KRITIS-Dachgesetz), esta normativa afecta a muchas más empresas que antes.
El orden más habitual resulta también el más costoso: primero se elige al hyperscaler y después se pregunta qué es lo que realmente hay que proteger. Para los operadores de KRITIS la lógica se invierte. Al principio se clasifica cada workload según su necesidad de protección, su criticidad para el servicio de suministro y su tiempo de recuperación. Un sistema de facturación con datos personales exige un nivel de protección distinto al de una wiki interna. Esa distinción es la que determina después el modelo de despliegue.
En la práctica significa dividir datos y servicios en tres categorías: qué puede ir a una región pública, qué solo a un entorno soberano y qué permanece, por ahora, en el propio centro de datos. Quien dibuja este mapa antes de abrir el primer ticket de migración negocia con el proveedor sobre requisitos concretos y no sobre presentaciones de marketing.
Residencia de datos: Dónde se encuentran realmente las cargas de trabajo
Una región de la UE en el menú de selección no constituye prueba de soberanía de datos. Lo decisivo es quién tiene acceso técnico y jurídico a los datos, en qué país tiene su sede el operador y si el soporte o el mantenimiento proceden de terceros países. Para las cargas de trabajo sensibles de infraestructuras críticas (KRITIS), las preguntas clave son: ¿se encuentra la clave en el proveedor o en el cliente? ¿Puede excluirse técnicamente el acceso del proveedor, por ejemplo mediante Confidential Computing o claves gestionadas por el cliente?
El C5:2026 aborda estos aspectos con mayor rigor que su predecesor. Con 168 criterios en lugar de 121, el catálogo trata por primera vez la gestión de contenedores, las cadenas de suministro y el Confidential Computing como bloques de requisitos independientes. Para la migración, esto significa que la residencia de datos es un asunto de arquitectura que integra cifrado, gestión de claves y modelo operativo. Una casilla en el formulario de compra no basta para reflejarlo.
Un certificado C5 abre la puerta, nada más
Un certificado C5 del proveedor es a menudo la tarjeta de entrada para las adquisiciones cercanas a KRITIS (infraestructuras críticas). Acredita que el proveedor cumple con el catálogo, pero no dice nada sobre si la propia configuración también aprovecha esta seguridad. La seguridad en la nube es una responsabilidad compartida: el proveedor suministra la plataforma certificada, el operador configura identidades, segmentación de red y logging. Un certificado perfecto no protege contra un bucket de almacenamiento abierto.
Al seleccionar proveedores, vale la pena una comparación sobria de los modelos operativos. Cada uno tiene su lugar, dependiendo de la clase de necesidad de protección del paso uno.
| Modelo operativo | Idoneidad para KRITIS | Compensación |
|---|---|---|
| Nube pública, región UE | Media a alta, según la soberanía de las claves | Escalabilidad frente al acceso del proveedor y riesgos de terceros países |
| Nube soberana | Alta, operación y personal locales | Soberanía de datos frente a un catálogo de servicios más reducido y mayores costes |
| Híbrida con núcleo propio | Alta para las cargas de trabajo más críticas | Control total frente a mayor esfuerzo operativo y carga de integración |
El plan de salida decide sobre la disponibilidad
La disponibilidad cumple el mandato de suministro en KRITIS. Si el servicio falla, falla el suministro. Una migración a la nube solo mejora la resiliencia cuando el plan para el fallo precede al plan para el funcionamiento normal. Todo empieza en el lock-in: ¿con qué rapidez se puede trasladar un servicio a un segundo proveedor o de vuelta al propio centro de datos si el proveedor falla, los precios se disparan o una autoridad lo exige?
Quien apoya los servicios críticos en componentes portátiles, como contenedores e interfaces estandarizadas en lugar de servicios gestionados propietarios, mantiene abierta la vía de retorno. La multi-nube solo compensa allí donde el fallo de un proveedor afecta al mandato de suministro. En servicios no críticos sigue siendo un esfuerzo costoso.
La auditoría comienza antes de la migración
La obligación de aportar pruebas es el punto donde una buena arquitectura se hace visible o, por el contrario, se echa en falta. Las entidades afectadas deben registrarse en el BSI (Oficina Federal para la Seguridad de la Información de Alemania). A través de la Ley Marco KRITIS (KRITIS-Dachgesetz), se añade un segundo registro ante el BBK (Oficina Federal para la Protección de la Población y la Ayuda en Catástrofes) para la resiliencia física, con plazo hasta el 17 de julio de 2026. Quien posponga el registro de logs, el inventario de activos y los procesos de incidentes hasta después de la migración, documenta lagunas en lugar de demostrar control.
Por eso, la aportación de pruebas debe integrarse ya en la planificación de la migración: registro centralizado, un directorio actualizado de los servicios externalizados y vías claras de notificación desde el primer día. De este modo, la auditoría final se limita a extraer un informe del funcionamiento habitual.
Preguntas frecuentes
¿Pueden los operadores de infraestructuras críticas (KRITIS) trasladar datos sensibles a la nube pública?
No existe una prohibición general. Lo decisivo es el nivel de protección requerido, la soberanía sobre las claves y un modelo operativo que limite el acceso del proveedor. Las cargas de trabajo altamente críticas suelen alojarse en entornos soberanos o híbridos, mientras que los servicios menos sensibles pueden ejecutarse en una región de la UE con claves controladas por el cliente.
¿Basta con el certificado C5 del proveedor para cumplir la normativa?
Es un requisito en muchas licitaciones, pero no sustituye una auditoría propia. El certificado refleja el estado de certificación del proveedor. Quien lo utilice debe revisar su alcance: qué servicios, qué regiones y qué fecha de corte están cubiertos. Ningún proveedor audita la configuración propia del cliente.
¿Qué cambia en el C5:2026 respecto a la versión anterior?
El catálogo pasa de 121 a 168 criterios e incluye por primera vez de forma explícita la gestión de contenedores, la seguridad de la cadena de suministro, la criptografía postcuántica y la computación confidencial. El monitoreo y la gestión de incidentes se endurecen. El C5:2026 será obligatorio a partir del 1 de junio de 2027; se recomienda una implementación anticipada.
¿Hasta cuándo deben registrarse las entidades afectadas?
El registro ante el BSI debe realizarse como máximo tres meses después de que una empresa cumpla por primera vez los criterios. Para la resiliencia física según la ley marco KRITIS, también es necesario el registro ante el BBK, con plazo hasta el 17 de julio de 2026.
¿Por qué es tan importante el plan de salida en una migración KRITIS?
En el entorno KRITIS, depender de un único proveedor constituye ya un riesgo. Sin una vía de retorno probada, un fallo del proveedor o la terminación del contrato prolonga directamente el tiempo de indisponibilidad. El plan de salida debe probarse: una ejecución periódica de prueba permite verificar si la recuperación se realiza dentro del tiempo de reinicio establecido.
Recomendaciones de lectura de la redacción
La ley marco KRITIS se cruza con NIS2 y la actualización C5
Costes de cumplimiento: la arquitectura decide
FinOps: reducir un 30 % los costes en la nube de forma realista
Más del MBF Media Netzwerk
Fuente de la imagen: generada por IA (junio 2026)
