Qué cambia técnicamente
Security Hub añadía hasta ahora visibilidad centralizada de hallazgos de seguridad dentro del perímetro de AWS: GuardDuty, Inspector, Macie y controles de configuración propios, correlacionados en un panel único. La novedad es que ese mismo motor de correlación pasa a ingerir activos de Azure — VMs, imágenes de contenedor en registries, Function Apps e identidades — y a evaluarlos contra el CIS Microsoft Azure Foundations Benchmark, exactamente el mismo estándar de referencia que usa Microsoft Defender for Cloud de forma nativa.
AWS suma además protecciones específicas para cargas de IA, que describe como la superficie de ataque de crecimiento más rápido en la empresa: modelos expuestos sin control de acceso adecuado, pipelines de entrenamiento con dependencias no verificadas, endpoints de inferencia sin monitorización. El hallazgo de Azure se prioriza con el mismo formato, automatización y flujos de respuesta que el de AWS — en la práctica, un intento de convertir Security Hub en el plano de control de seguridad, no solo de AWS, sino de la postura multicloud completa de la organización.
Por qué esto no es solo una funcionalidad más de un CSPM
El movimiento reconoce en voz alta lo que en nuestra guía de decisión de Kubernetes en sectores regulados ya tratábamos como hecho consumado: la pregunta del arquitecto enterprise dejó de ser "qué cloud" para convertirse en "qué capa de cada cloud". Si AWS decide que su plano de seguridad debe cubrir también las cargas que corren en Azure, es porque sus propios clientes ya operan así y necesitan un único lugar donde correlacionar hallazgos — sin que ese lugar tenga por qué ser el hyperscaler donde vive cada carga.
Para equipos que ya operan un SOC con Microsoft Sentinel como plataforma central de correlación, la pregunta inmediata es de gobierno, no de tecnología: si Security Hub también ingiere hallazgos de Azure, ¿qué producto es la fuente de verdad para un incidente en una VM Azure — Defender for Cloud, Sentinel, o Security Hub? Sin una decisión explícita, el resultado no es más seguridad, es doble alerta, doble triage y doble coste de licenciamiento por el mismo hallazgo.
El benchmark compartido es la parte más interesante. Que dos productos de dos hyperscalers distintos evalúen la misma carga contra el mismo CIS Microsoft Azure Foundations Benchmark abre la puerta a comparar resultados y detectar divergencias de configuración — pero solo si alguien en la organización asume la tarea de reconciliarlos activamente. Por defecto, tendrás dos paneles que pueden discrepar sobre el mismo hallazgo.
Las dos preguntas antes de activarlo en producción
Dónde encaja frente a las herramientas nativas de Azure
| Escenario | Herramienta recomendada | Motivo |
|---|---|---|
| Postura de configuración nativa Azure (día a día) | Microsoft Defender for Cloud | Integración directa con Azure Policy, remediación automática y sin salto de nube para credenciales |
| Correlación SIEM/SOC multicloud unificada | Microsoft Sentinel (con conectores AWS) | Plataforma ya consolidada en la mayoría de SOCs de sectores regulados en España; añade contexto de identidad Entra ID |
| Organización con AWS como cloud primario y Azure como secundaria | AWS Security Hub multicloud | Un único panel para equipos cuyo centro de gravedad operativo ya es AWS, evitando doble consola |
| Cargas de IA con endpoints de inferencia expuestos | Ambos, con reconciliación explícita | Las protecciones de IA de Security Hub son nuevas y complementarias, no sustitutivas de Defender for AI Services |
Qué debería exigir un arquitecto antes de habilitarlo
- Matriz de propiedad por tipo de hallazgo, documentada antes de conectar la integración — no descubierta durante el primer incidente real.
- Alcance mínimo de la identidad cross-cloud: solo lectura, solo sobre las suscripciones necesarias, con revisión trimestral de permisos efectivos.
- Prueba de reconciliación del CIS Benchmark: ejecutar la misma carga contra Defender for Cloud y Security Hub, y documentar cualquier divergencia de puntuación antes de confiar en cualquiera de los dos como único origen.
- Coste incremental real: Security Hub factura por hallazgo y cuenta ingerida; sumar activos Azure sin control puede disparar el gasto sin ganancia proporcional de cobertura si ya existe Defender for Cloud activo.
El riesgo de fondo: un plano de control multicloud gestionado por uno de los dos hyperscalers en juego no es neutral por diseño. Es una herramienta legítima y útil para muchas organizaciones, pero la decisión de usarlo como fuente de verdad debe tomarse con los ojos abiertos sobre quién la opera — el mismo principio de gobierno que aplicamos al evaluar cualquier dependencia de proveedor único en una arquitectura crítica.