Cómo diseñar una Enterprise Landing Zone para banca en España: guía práctica

Una Enterprise Landing Zone no es solo un conjunto de suscripciones de Azure bien organizadas. En el contexto de banca española, es la infraestructura de gobierno que determina si tu organización puede mover aplicaciones críticas a la nube sin que el regulador — Banco de España, BCE o el equipo de auditoría interna — devuelva el proyecto por incumplimiento.

Después de implantar Landing Zones para grupos bancarios multi-país en los últimos tres años, estas son las decisiones de diseño que más impactan en el resultado real. No las que aparecen en los diagramas de Microsoft Learn, sino las que descubres cuando tienes un auditor del BCE delante preguntando por el modelo de recuperación de datos en menos de cuatro horas.

El punto de partida: el contexto regulatorio antes que el diagrama

Antes de dibujar un solo Management Group, un arquitecto cloud en banca española necesita tener claras tres variables regulatorias que condicionan cada decisión técnica:

DORA (Digital Operational Resilience Act) entró en vigor en enero de 2025 y exige que cualquier proveedor cloud considerado concentración crítica esté bajo un régimen de supervisión reforzado. Esto no impide usar Azure — Microsoft cumple los requisitos — pero sí obliga a documentar la estrategia de salida, implementar controles de continuidad medibles y mantener registros de auditoría durante cinco años. Una Landing Zone genérica no incluye nada de esto por defecto.

El ENS (Esquema Nacional de Seguridad) en categoría alta es el estándar para entidades que trabajan con Administración Pública o que manejan datos clasificados. Con los 300 servicios de Azure certificados en ENS alto, la cobertura para cargas de trabajo modernas es prácticamente total. El impacto en la Landing Zone es concreto: todos los servicios que manejen datos del sector público deben estar en suscripciones con políticas de cumplimiento ENS activas y auditables.

Las Directrices EBA sobre Externalización (EBA/GL/2019/02) definen qué procesos pueden externalizarse a cloud y con qué controles. Para un grupo bancario, esto se traduce en requisitos específicos de trazabilidad, segregación de funciones y planes de recuperación que la Landing Zone debe incorporar desde el primer día, no como un proyecto posterior de remediación.

Jerarquía de Management Groups: el error que se repite

El error más común que veo en Landing Zones para banca es estructurar los Management Groups por entorno — Producción / Desarrollo / Pruebas — en lugar de por perfil de riesgo regulatorio. El resultado es una arquitectura que facilita la gestión del ciclo de vida de aplicaciones pero complica enormemente aplicar controles diferenciados según el tipo de dato que procesa cada carga.

La estructura recomendada para un grupo bancario con presencia multi-país:

Root Management Group
├── Platform  (conectividad, identidad, gestión centralizada)
│   ├── Connectivity
│   ├── Identity
│   └── Management
├── Landing Zones
│   ├── Corp  (cargas no reguladas, office, colaboración)
│   ├── Banking  (core bancario, sujeto a EBA/DORA/ENS)
│   │   ├── Producción
│   │   └── No-Prod
│   └── Sandbox
└── Decommissioned

La clave está en aislar las suscripciones sujetas a regulación bancaria dentro de Banking. Esto permite aplicar Azure Policies más restrictivas — sin acceso a internet público salvo excepciones explícitas, cifrado en reposo obligatorio, logs de auditoría a un SIEM centralizado con retención de cinco años — solo donde es necesario. Los equipos de desarrollo que trabajan en Corp o Sandbox no tropiezan con restricciones que no les aplican, y el compliance no se convierte en una barrera para la productividad.

Network Topology: Hub-Spoke o Azure Virtual WAN

Para grupos con presencia en múltiples países — algo habitual en banca española con filiales en LATAM o Europa del Este — la elección entre Hub-Spoke clásico y Azure Virtual WAN tiene implicaciones de coste y operaciones que merece analizar con datos reales, no con preferencias de arquitectura.

Hub-Spoke es más predecible en coste y da más control sobre el routing. Es la opción correcta si tienes un equipo de red con experiencia en Cisco o Juniper que quiere mantener visibilidad total sobre el tráfico, o si el número de regiones activas es inferior a cinco.

Azure Virtual WAN simplifica la gestión cuando tienes más de cinco o seis regiones activas o cuando la complejidad de branching — conexiones SD-WAN a sucursales y oficinas locales — justifica delegar el routing a la plataforma. El coste es más alto en euros por GB transferido, pero el ahorro en horas de operación y reducción de incidentes de routing puede compensarlo a partir de cierta escala.

Para la mayoría de grupos bancarios españoles medianos, la recomendación es Hub-Spoke con un hub por región geográfica principal — West Europe más Spain Central si tienes requerimientos de soberanía de datos bajo ENS o DORA — y peering centralizado con reglas de UDR gestionadas por Azure Firewall Premium.

Security Baseline mínimo para banca: ocho controles no negociables

Estos controles deben estar configurados como Azure Policy en modo DeployIfNotExists o Deny desde el día uno. Aplicarlos como remediación posterior multiplica el coste y la resistencia interna:

• Microsoft Defender for Cloud habilitado en todos los planes relevantes — Servers P2, Databases, Key Vault, Storage, DNS — en cada suscripción del MG Banking.
• Diagnostic Settings centralizados en un Log Analytics Workspace dedicado a seguridad, con retención mínima de doce meses en caliente y archivo a Storage de cinco años para cumplir DORA.
• Private Endpoints para todos los servicios PaaS que manejen datos de clientes: Storage, Azure SQL, Key Vault, Service Bus. Sin Private Endpoint, sin despliegue.
• JIT VM Access activado por política, eliminando RDP y SSH permanentes expuestos. Nadie accede a una VM de producción bancaria sin aprobación con ventana temporal.
• Customer-Managed Keys en Key Vault para cifrado de datos en reposo en los sistemas que procesan información financiera clasificada.
• Azure Policy for Guest Configuration para validar el baseline de seguridad dentro de las VMs — parches aplicados, agente de Defender activo, configuración de auditoría de Windows.
• Defender for DevOps integrado en los pipelines de CI/CD para detectar secretos en el código, vulnerabilidades en contenedores y misconfiguraciones de IaC antes del despliegue.
• Log Analytics alerts para cambios en asignaciones de roles privilegiados (Owner, User Access Administrator) con notificación inmediata al equipo de seguridad.

Cuando un CISO me pregunta por la identidad, la respuesta es que Microsoft Entra ID con Privileged Identity Management (PIM) y Conditional Access con MFA fuerte no es opcional. Es el perímetro real en una arquitectura donde no existe firewall perimetral clásico.

Modelo FinOps: del coste invisible al showback útil

Una Landing Zone sin modelo de costes integrado genera un problema político en seis o ocho meses: nadie sabe qué consume cada unidad de negocio y el equipo cloud acaba siendo el responsable de facturas que no controla. He visto proyectos cloud técnicamente impecables fracasar por este motivo.

La solución es implementar un modelo de etiquetado obligatorio desde el Management Group raíz, con herencia forzada:

• cost-center: centro de coste del área de negocio responsable
• environment: prod / pre / dev / sandbox
• application: nombre del sistema o aplicación propietaria
• owner: alias del responsable técnico o equipo
• data-classification: public / internal / confidential / restricted

Con ese etiquetado, Azure Cost Management más Power BI genera dashboards de showback semanales que cada área de negocio puede consumir directamente. El paso a chargeback real — con facturación interna en SAP — requiere integración adicional y suele tardar tres o cuatro meses más, pero cambia radicalmente la cultura de consumo cloud en la organización. Los equipos dejan de pedir recursos sin límite cuando ven reflejado el coste en su presupuesto.

Lo que cambia cuando lo haces bien

En el proyecto de Landing Zone multi-entidad que describimos en el caso de estudio 001, el resultado más tangible no fue el ahorro del 28% en gasto cloud — aunque fue lo que más impresionó al CFO en la presentación de resultados. Fue que el equipo de auditoría interna pasó de tardar semanas en generar evidencias de cumplimiento para el BCE a tenerlas disponibles en tiempo real en un dashboard de Defender for Cloud.

Una Enterprise Landing Zone bien diseñada para banca no es un proyecto de infraestructura. Es una decisión de gobierno que determina la velocidad a la que tu organización puede innovar dentro de los límites regulatorios. Y en banca española, esos límites no son un obstáculo: son el diferencial competitivo si sabes convertirlos en arquitectura auditable, reproducible y que tu equipo de seguridad pueda defender ante cualquier inspector sin improvisaciones.