Situación del cliente
Gran grupo bancario con presencia en varios mercados europeos operaba con una infraestructura cloud profundamente fragmentada: múltiples suscripciones Azure sin jerarquía coherente, políticas de seguridad inconsistentes entre filiales y un modelo de costes completamente opaco.
Cada país gestionaba su cloud de forma autónoma, generando duplicidades técnicas, brechas de cumplimiento regulatorio y un crecimiento del gasto sin control que superaba el 20% interanual. La falta de visibilidad consolidada impedía atribuir el gasto a unidades de negocio concretas, dificultando la toma de decisiones de inversión a nivel corporativo.
Retos
- Diseñar un modelo de gobierno cloud válido para múltiples jurisdicciones regulatorias (GDPR, DORA, regulación bancaria local)
- Unificar la gestión de identidades y accesos en miles de usuarios sin afectar la operativa diaria
- Implantar políticas de seguridad y cumplimiento de forma automática y no disruptiva sobre suscripciones ya en producción
- Crear un modelo de costes transparente (showback/chargeback) aceptable por los directores financieros de cada país
- Migrar las suscripciones existentes a la nueva jerarquía de Management Groups con impacto mínimo en los equipos técnicos locales
Solución implementada
- Jerarquía de Management Groups: estructura Tenant Root → Corporativo → Países → Departamentos, con herencia de políticas en cascada
- Azure Policy centralizado: iniciativas por país para cumplimiento regulatorio automático (cifrado, ubicación de datos, configuración de seguridad)
- RBAC granular con delegación controlada: cada filial gestiona sus recursos sin romper el gobierno global corporativo
- Modelo FinOps con Azure Cost Management: tags de chargeback obligatorios vía Policy, dashboards por unidad de negocio y geografía en tiempo real
- Defender for Cloud centralizado: postura de seguridad unificada con exportación al SIEM corporativo y remediación automatizada de hallazgos
Ventajas para el cliente
Patrón de arquitectura
Arquitectura de red Hub-Spoke para entornos enterprise multi-suscripción con Management Groups jerárquicos, Azure Policy centralizado, RBAC granular y conectividad privada. La base sobre la que se construye cualquier adopción cloud seria en el mercado enterprise.
- Planificar el espacio de direcciones ANTES del primer spoke — modificar CIDR en VNets con peerings activos requiere destruir y recrear. En este proyecto lo aprendimos en el entorno de desarrollo antes de que llegara a producción; en producción hubiera sido un incidente mayor.
- Centralizar la inspección de tráfico con Azure Firewall y UDRs en cada spoke. Sin esta configuración, el tráfico lateral entre spokes no se inspeccionará y el modelo de seguridad queda roto desde el diseño.
- Desplegar Azure Firewall en múltiples Availability Zones para SLA elevado. Un firewall en zona única es un SPOF para toda la conectividad de la Landing Zone.
- Activar IDPS en modo Alert & Deny desde el primer día — no activarlo en producción después es casi imposible sin una revisión exhaustiva de todas las reglas existentes.
- ExpressRoute: circuitos redundantes en ubicaciones de peering distintas y proveedores diferentes. En este banco, el primer circuito se cayó durante la migración; la redundancia evitó el corte.
- Todo el despliegue en IaC (Bicep/Terraform) — los cambios manuales en reglas de firewall o NSGs son la principal fuente de deriva de configuración en entornos enterprise multi-filial.