Situación del cliente
Una de las mayores administraciones locales de España —con decenas de aplicaciones críticas para los ciudadanos, desde gestión de padrón y tributos hasta servicios de emergencias y transporte urbano— necesitaba definir su estrategia de adopción cloud de forma coherente, sostenible y segura. La presión política para modernizar los servicios digitales chocaba con la obligación de cumplir el ENS y garantizar la continuidad de los servicios esenciales.
La administración carecía de un modelo de gobierno cloud formal: cada departamento tomaba decisiones tecnológicas de forma autónoma, generando proliferación de herramientas SaaS no auditadas, contratos cloud sin cláusulas de salida adecuadas y ausencia de visibilidad sobre qué datos de los ciudadanos residían en qué servicios cloud.
Retos
- Diseñar una estrategia de adopción cloud (pública, privada, híbrida) que estableciera criterios claros y vinculantes para cada tipo de aplicación, basados en la clasificación ENS y la sensibilidad de los datos de ciudadanos gestionados
- Definir criterios objetivos de clasificación de aplicaciones por criticidad ciudadana, sensibilidad de datos (datos de salud, fiscales, judiciales) y complejidad de migración
- Diseñar el modelo de seguridad perimetral conforme al ENS para la arquitectura cloud, incluyendo controles de acceso, cifrado, monitorización y gestión de vulnerabilidades
- Construir un catálogo de servicios gestionados con SLAs públicamente auditables, que satisficiera los requisitos de transparencia propios de la administración pública y los derechos de los ciudadanos
- Implicar a los departamentos en el proceso de definición del modelo de gobierno para conseguir su adopción sin necesidad de imposición normativa interna
Solución implementada
- Estrategia cloud trimodal: definición de los criterios de asignación de aplicaciones a cloud pública (Azure, servicios SaaS certificados ENS), cloud privada (CPD propio para datos sensibles de ciudadanos) o modelo híbrido, con criterios técnicos y regulatorios objetivos y proceso de revisión anual
- Clasificación de aplicaciones: metodología de evaluación de las aplicaciones municipales en 4 dimensiones (criticidad de servicio ciudadano, sensibilidad de datos, complejidad técnica, coste de migración), con mapa de calor que priorizaba el roadmap de adopción cloud
- Modelo de seguridad perimetral ENS: arquitectura de referencia para la nube municipal con controles técnicos alineados con el ENS, incluyendo gestión centralizada de identidades con SSO, cifrado de datos en reposo y en tránsito, y SIEM para detección de incidentes de seguridad
- Catálogo de servicios gestionados: definición de 18 servicios cloud gestionados con fichas técnicas de SLA (disponibilidad, RTO, RPO), procedimientos de operación y métricas de calidad publicables en el portal de transparencia municipal
- Modelo de gobierno participativo: estructura de comité de gobierno cloud con representantes de todos los departamentos, proceso de aprobación de nuevos servicios cloud y mecanismo de gestión de excepciones para casos que no encajaran en los criterios estándar
Ventajas para el cliente
Patrón de arquitectura
Estrategia cloud para administración local que define el modelo óptimo entre nube pública (Azure con 300+ servicios ENS certificados), nube privada (CPD propio o Azure Stack para datos de máxima clasificación) e híbrido (Azure Arc + ExpressRoute). Marco de gobernanza con catálogo de servicios auditado, SLAs públicamente publicables y cumplimiento LOPD/RGPD desde el diseño.
- La decisión público/privado/híbrido es política antes que técnica — en administración local, la decisión de qué datos van a nube pública requiere aprobación del pleno municipal en muchos casos. El arquitecto cloud debe entender el proceso político, no solo el técnico.
- ENS no es un checklist, es un proceso de auditoría continua — obtener la conformidad ENS en el primer año es la parte fácil. Mantenerla con cada nuevo servicio desplegado es el verdadero reto operativo que nadie anticipa en la planificación inicial.
- Identidad ciudadana con Cl@ve y DNIe requiere federación SAML/OIDC cuidadosa — la integración con los sistemas de identidad del MPTFP tiene particularidades técnicas no documentadas que solo aparecen en el entorno de producción. Reservar al menos 3 sprints solo para la integración de identidad.
- Catálogo de servicios gestionados con SLAs públicos como primer entregable — las administraciones locales no pueden contratar servicios cloud sin un catálogo formal con SLAs. Este documento es también el contrato político con los concejales responsables de cada área.
- LOPD/RGPD: evaluación de impacto antes de mover cualquier dato de ciudadanos — el DPD de la administración local debe firmar una EIPD para cada categoría de dato que migra a cloud. Sin esta firma, el despliegue puede ser bloqueado por el delegado de protección de datos meses después de comenzar.
- Transparencia: publicar métricas de disponibilidad de servicios ciudadanos — la ciudadanía tiene derecho a conocer la disponibilidad de los servicios digitales públicos. Diseñar el dashboard de disponibilidad público desde el inicio, no como proyecto de comunicación posterior.