Situación del cliente
Una de las mayores empresas de seguridad privada del mundo —con operaciones en más de 30 países, desde vigilancia física y gestión de efectivo hasta ciberseguridad y tecnología de control de accesos— operaba sobre un entorno cloud profundamente fragmentado. Azure dominaba Europa, AWS era el estándar en Norteamérica y mercados emergentes, y algunas filiales adquiridas operaban con servicios cloud locales sin integración corporativa.
La dirección tecnológica global lanzó un RFI para seleccionar un partner capaz de diseñar y operar un modelo MHC (Managed Hybrid Cloud) que unificara la gestión de Azure y AWS bajo un servicio único, con capacidades SOAR para responder automáticamente a los incidentes de seguridad que los propios clientes de la empresa reportaban, y con un modelo de gobernanza que respetara las fronteras de datos regulatorias de cada mercado.
Retos
- Diseñar el modelo MHC que proporcionara una capa de gestión unificada sobre Azure y AWS con panel de control único, procesos de operación estandarizados y SLAs coherentes independientemente del proveedor cloud subyacente
- Integrar el modelo de gestión cloud con el ITSM corporativo existente (ServiceNow), manteniendo los procesos de gestión de incidentes y cambios ya establecidos sin reemplazar las herramientas que los equipos de país ya dominaban
- Diseñar las capacidades SOAR para la respuesta automática a incidentes de seguridad, considerando que la empresa operaba en entornos con distintos marcos regulatorios de seguridad (GDPR, CCPA, NIS2, marcos locales de países emergentes)
- Establecer el modelo de gobernanza multi-tenant con fronteras de datos por región regulatoria, garantizando que los datos de clientes de seguridad (algunos con carácter altamente sensible) no cruzaran fronteras jurisdiccionales inadecuadas
- Definir el modelo de precios del servicio MHC que fuera equitativo para entidades con proporciones muy distintas de Azure vs. AWS, y que incentivara la optimización de costes cloud en lugar de simplemente facturar sobre el gasto existente
Solución implementada
- Modelo MHC (Managed Hybrid Cloud): arquitectura de servicio con capa de abstracción de gestión sobre Azure y AWS usando Azure Arc para extender las políticas y el monitoreo de Azure sobre los recursos AWS, proporcionando un panel de control único para operaciones, seguridad y costes
- Integración ITSM con ServiceNow: conectores bidireccionales entre Azure Monitor/AWS CloudWatch y ServiceNow, con mapeo de alertas a tickets de incidente conforme a los procesos ITIL del cliente, manteniendo el workflow de aprobación y escalado ya establecido
- Plataforma SOAR multi-cloud: Microsoft Sentinel como SIEM/SOAR primario con conectores a AWS Security Hub, playbooks de respuesta automática para los 15 incidentes de seguridad más frecuentes (lockout de cuentas, movimiento lateral, exfiltración de datos) con capacidad de ejecución de contramedidas en Azure y AWS desde un único punto de control
- Gobernanza multi-tenant con fronteras regulatorias: definición de regiones de datos (EU, US, APAC, LATAM) con segregación lógica de tenants en Azure y AWS, políticas de replicación y backup que respetaban las restricciones de localización de datos de cada región, y audit log unificado para evidencias regulatorias
- Modelo de precios orientado a valor: estructura de facturación del servicio MHC basada en unidades de servicio (compute, storage, network) en lugar del gasto cloud bruto, con incentivo de reducción de tarifa cuando el partner conseguía reducciones de coste cloud para el cliente mediante optimización
Ventajas para el cliente
Patrón de arquitectura
Centro de operaciones de seguridad multicloud bajo modelo MHC (Managed Hybrid Cloud) para empresa de seguridad global en 30+ países: Sentinel como SIEM unificado correlacionando señales de Azure (Defender XDR) y AWS (GuardDuty, Security Hub), SOAR con Logic Apps para respuesta automática 24×7 y playbooks de aislamiento, y equipo SOC L1-L2-L3 con cobertura global e integración con SOAR para tickets automáticos en ServiceNow.
- Sentinel como SIEM central para Azure y AWS — los conectores nativos de Sentinel para AWS (GuardDuty, CloudTrail, Security Hub) son la forma más eficiente de correlacionar señales cross-cloud. No desplegar dos SIEMs separados: la correlación entre nubes es donde se detectan los ataques avanzados.
- SOAR con modo "human approval" antes de "full auto" — en una empresa de seguridad global con clientes en 30+ países, un playbook que aísla automáticamente endpoints puede causar más daño que el incidente que intenta contener. Validar cada playbook con 30 días en modo notificación antes de activar la acción automática.
- Threat Intelligence feeds específicos del sector seguridad — las empresas de seguridad física y electrónica son objetivo de actores de amenaza que buscan sus bases de datos de clientes (bancos, ministerios, infraestructuras críticas). Los feeds genéricos no capturan estos TTPs específicos.
- Normalización de logs AWS→Sentinel con esquema ASIM — los logs de CloudTrail y GuardDuty no tienen el mismo esquema que los logs de Azure. Usar el esquema ASIM (Advanced SIEM Information Model) de Sentinel para normalizar permite usar las mismas reglas KQL en ambas nubes.
- Definir runbooks de respuesta a incidentes antes de desplegar el SOAR — los playbooks automáticos ejecutan runbooks. Sin runbooks documentados y validados por el equipo de operaciones, los playbooks implementan lógica que nadie ha revisado y que puede fallar en el peor momento.
- Jurisdicción y privacidad de logs en 30+ países — los logs de eventos de seguridad de clientes en algunos países (Francia, Alemania, países del Golfo) tienen restricciones de exportación de datos. El workspace de Sentinel debe respetar la residencia de datos por región y no centralizar logs que no pueden salir del país de origen.