6 min de lectura<\/p>\n
Desde el 17 de marzo de 2026 entra en vigor el KRITIS-Dachgesetz (ley marco alemana sobre infraestructuras cr\u00edticas). Quienes trasladen ahora sistemas sensibles a la nube deben integrar desde el primer momento la disponibilidad, la soberan\u00eda de los datos y la obligaci\u00f3n de acreditaci\u00f3n. De esa decisi\u00f3n depender\u00e1 que la auditor\u00eda posterior sea un simple tr\u00e1mite o se convierta en un aut\u00e9ntico problema.<\/strong><\/p>\n Relacionado:<\/span>El chip de cloud barato con el costoso camino de vuelta<\/a> \/<\/span> Ingress-NGINX est\u00e1 obsoleto: el camino hacia la Gateway API<\/a><\/p>\n \u00bfQu\u00e9 es KRITIS?<\/strong> Como Infraestructura Cr\u00edtica se consideran aquellas instalaciones cuyo fallo pone en peligro el suministro a la poblaci\u00f3n, por ejemplo en los sectores de energ\u00eda, agua, salud, finanzas o transporte. Sus operadores est\u00e1n sujetos a obligaciones especiales de seguridad y notificaci\u00f3n. Desde la ley de transposici\u00f3n de NIS2 (NIS2-Umsetzungsgesetz) y la ley marco KRITIS (KRITIS-Dachgesetz), esta normativa afecta a muchas m\u00e1s empresas que antes.<\/p>\n El orden m\u00e1s habitual resulta tambi\u00e9n el m\u00e1s costoso: primero se elige al hyperscaler y despu\u00e9s se pregunta qu\u00e9 es lo que realmente hay que proteger. Para los operadores de KRITIS la l\u00f3gica se invierte. Al principio se clasifica cada workload seg\u00fan su necesidad de protecci\u00f3n, su criticidad para el servicio de suministro y su tiempo de recuperaci\u00f3n. Un sistema de facturaci\u00f3n con datos personales exige un nivel de protecci\u00f3n distinto al de una wiki interna. Esa distinci\u00f3n es la que determina despu\u00e9s el modelo de despliegue.<\/p>\n En la pr\u00e1ctica significa dividir datos y servicios en tres categor\u00edas: qu\u00e9 puede ir a una regi\u00f3n p\u00fablica, qu\u00e9 solo a un entorno soberano y qu\u00e9 permanece, por ahora, en el propio centro de datos. Quien dibuja este mapa antes de abrir el primer ticket de migraci\u00f3n negocia con el proveedor sobre requisitos concretos y no sobre presentaciones de marketing.<\/p>\n Una regi\u00f3n de la UE en el men\u00fa de selecci\u00f3n no constituye prueba de soberan\u00eda de datos. Lo decisivo es qui\u00e9n tiene acceso t\u00e9cnico y jur\u00eddico a los datos, en qu\u00e9 pa\u00eds tiene su sede el operador y si el soporte o el mantenimiento proceden de terceros pa\u00edses. Para las cargas de trabajo sensibles de infraestructuras cr\u00edticas (KRITIS), las preguntas clave son: \u00bfse encuentra la clave en el proveedor o en el cliente? \u00bfPuede excluirse t\u00e9cnicamente el acceso del proveedor, por ejemplo mediante Confidential Computing o claves gestionadas por el cliente?<\/p>\n El C5:2026 aborda estos aspectos con mayor rigor que su predecesor. Con 168 criterios en lugar de 121, el cat\u00e1logo trata por primera vez la gesti\u00f3n de contenedores, las cadenas de suministro y el Confidential Computing como bloques de requisitos independientes. Para la migraci\u00f3n, esto significa que la residencia de datos es un asunto de arquitectura que integra cifrado, gesti\u00f3n de claves y modelo operativo. Una casilla en el formulario de compra no basta para reflejarlo.<\/p>\n Un certificado C5 del proveedor es a menudo la tarjeta de entrada para las adquisiciones cercanas a KRITIS (infraestructuras cr\u00edticas). Acredita que el proveedor cumple con el cat\u00e1logo, pero no dice nada sobre si la propia configuraci\u00f3n tambi\u00e9n aprovecha esta seguridad. La seguridad en la nube es una responsabilidad compartida: el proveedor suministra la plataforma certificada, el operador configura identidades, segmentaci\u00f3n de red y logging. Un certificado perfecto no protege contra un bucket de almacenamiento abierto.<\/p>\n Al seleccionar proveedores, vale la pena una comparaci\u00f3n sobria de los modelos operativos. Cada uno tiene su lugar, dependiendo de la clase de necesidad de protecci\u00f3n del paso uno.<\/p>\n La disponibilidad cumple el mandato de suministro en KRITIS. Si el servicio falla, falla el suministro. Una migraci\u00f3n 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: \u00bfcon qu\u00e9 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?<\/p>\n Quien apoya los servicios cr\u00edticos en componentes port\u00e1tiles, como contenedores e interfaces estandarizadas en lugar de servicios gestionados propietarios, mantiene abierta la v\u00eda de retorno. La multi-nube solo compensa all\u00ed donde el fallo de un proveedor afecta al mandato de suministro. En servicios no cr\u00edticos sigue siendo un esfuerzo costoso.<\/p>\n \n”<\/span><\/p>\n Una migraci\u00f3n que no contempla el camino de vuelta solo ha desplazado la dependencia, no la ha reducido.<\/p>\n<\/blockquote>\n<\/figure>\n La obligaci\u00f3n 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\u00f3n de Alemania). A trav\u00e9s de la Ley Marco KRITIS (KRITIS-Dachgesetz), se a\u00f1ade un segundo registro ante el BBK (Oficina Federal para la Protecci\u00f3n de la Poblaci\u00f3n y la Ayuda en Cat\u00e1strofes) para la resiliencia f\u00edsica, 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\u00e9s de la migraci\u00f3n, documenta lagunas en lugar de demostrar control.<\/p>\n Por eso, la aportaci\u00f3n de pruebas debe integrarse ya en la planificaci\u00f3n de la migraci\u00f3n: registro centralizado, un directorio actualizado de los servicios externalizados y v\u00edas claras de notificaci\u00f3n desde el primer d\u00eda. De este modo, la auditor\u00eda final se limita a extraer un informe del funcionamiento habitual.<\/p>\n No existe una prohibici\u00f3n general. Lo decisivo es el nivel de protecci\u00f3n requerido, la soberan\u00eda sobre las claves y un modelo operativo que limite el acceso del proveedor. Las cargas de trabajo altamente cr\u00edticas suelen alojarse en entornos soberanos o h\u00edbridos, mientras que los servicios menos sensibles pueden ejecutarse en una regi\u00f3n de la UE con claves controladas por el cliente.<\/p>\n<\/details>\n Es un requisito en muchas licitaciones, pero no sustituye una auditor\u00eda propia. El certificado refleja el estado de certificaci\u00f3n del proveedor. Quien lo utilice debe revisar su alcance: qu\u00e9 servicios, qu\u00e9 regiones y qu\u00e9 fecha de corte est\u00e1n cubiertos. Ning\u00fan proveedor audita la configuraci\u00f3n propia del cliente.<\/p>\n<\/details>\n El cat\u00e1logo pasa de 121 a 168 criterios e incluye por primera vez de forma expl\u00edcita la gesti\u00f3n de contenedores, la seguridad de la cadena de suministro, la criptograf\u00eda postcu\u00e1ntica y la computaci\u00f3n confidencial. El monitoreo y la gesti\u00f3n de incidentes se endurecen. El C5:2026 ser\u00e1 obligatorio a partir del 1 de junio de 2027; se recomienda una implementaci\u00f3n anticipada.<\/p>\n<\/details>\n El registro ante el BSI debe realizarse como m\u00e1ximo tres meses despu\u00e9s de que una empresa cumpla por primera vez los criterios. Para la resiliencia f\u00edsica seg\u00fan la ley marco KRITIS, tambi\u00e9n es necesario el registro ante el BBK, con plazo hasta el 17 de julio de 2026.<\/p>\n<\/details>\n En el entorno KRITIS, depender de un \u00fanico proveedor constituye ya un riesgo. Sin una v\u00eda de retorno probada, un fallo del proveedor o la terminaci\u00f3n del contrato prolonga directamente el tiempo de indisponibilidad. El plan de salida debe probarse: una ejecuci\u00f3n peri\u00f3dica de prueba permite verificar si la recuperaci\u00f3n se realiza dentro del tiempo de reinicio establecido.<\/p>\n<\/details>\n La ley marco KRITIS se cruza con NIS2 y la actualizaci\u00f3n C5<\/a><\/p>\n Costes de cumplimiento: la arquitectura decide<\/a><\/p>\nLo m\u00e1s importante en resumen<\/h2>\n
\n
Primero la necesidad de protecci\u00f3n, luego el proveedor<\/h2>\n
Residencia de datos: D\u00f3nde se encuentran realmente las cargas de trabajo<\/h2>\n
Un certificado C5 abre la puerta, nada m\u00e1s<\/h2>\n
\n\n
\n \nModelo operativo<\/th>\n Idoneidad para KRITIS<\/th>\n Compensaci\u00f3n<\/th>\n<\/tr>\n<\/thead>\n \n Nube p\u00fablica, regi\u00f3n UE<\/strong><\/td>\n Media a alta, seg\u00fan la soberan\u00eda de las claves<\/td>\n Escalabilidad frente al acceso del proveedor y riesgos de terceros pa\u00edses<\/td>\n<\/tr>\n \n Nube soberana<\/strong><\/td>\n Alta, operaci\u00f3n y personal locales<\/td>\n Soberan\u00eda de datos frente a un cat\u00e1logo de servicios m\u00e1s reducido y mayores costes<\/td>\n<\/tr>\n \n H\u00edbrida con n\u00facleo propio<\/strong><\/td>\n Alta para las cargas de trabajo m\u00e1s cr\u00edticas<\/td>\n Control total frente a mayor esfuerzo operativo y carga de integraci\u00f3n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n El plan de salida decide sobre la disponibilidad<\/h2>\n
La auditor\u00eda comienza antes de la migraci\u00f3n<\/h2>\n
Preguntas frecuentes<\/h2>\n
\u00bfPueden los operadores de infraestructuras cr\u00edticas (KRITIS) trasladar datos sensibles a la nube p\u00fablica?<\/strong><\/summary>\n
\u00bfBasta con el certificado C5 del proveedor para cumplir la normativa?<\/strong><\/summary>\n
\u00bfQu\u00e9 cambia en el C5:2026 respecto a la versi\u00f3n anterior?<\/strong><\/summary>\n
\u00bfHasta cu\u00e1ndo deben registrarse las entidades afectadas?<\/strong><\/summary>\n
\u00bfPor qu\u00e9 es tan importante el plan de salida en una migraci\u00f3n KRITIS?<\/strong><\/summary>\n
Recomendaciones de lectura de la redacci\u00f3n<\/h2>\n