Un análisis de 3.000 organizaciones en AWS, Azure y Google Cloud revela que los perfiles de riesgo entre proveedores no comparten casi ningún patrón común.
Intruder publicó en septiembre de 2026 su Cloud Security Index anual, un relevamiento de configuraciones erróneas en infraestructura de nube que abarcó 3.000 organizaciones distribuidas entre Amazon Web Services, Microsoft Azure y Google Cloud Platform. La conclusión central del estudio contradice la premisa de las listas de verificación de seguridad genéricas que circulan en la industria: los perfiles de riesgo entre proveedores de nube no tienen prácticamente nada en común. Cada plataforma falla de manera distinta, con vectores de exposición que no se replican en las otras dos.
Tres arquitecturas, tres conjuntos de vulnerabilidades sin superposición
El análisis de Intruder se concentró en errores de configuración — la categoría de falla que históricamente representa entre el 65% y el 80% de los incidentes de seguridad en nube según datos de proveedores y consultoras especializadas. Lo que el estudio documenta es que las configuraciones problemáticas en AWS no predicen las de Azure, y ninguna de las dos anticipa las de Google Cloud. Los investigadores no encontraron un conjunto significativo de malas prácticas que se repitiera de forma consistente en las tres plataformas.
Esta divergencia no es un detalle técnico menor: implica que una organización que opera en dos o más nubes no puede reutilizar su checklist de seguridad entre proveedores. Un equipo que haya auditado y corregido configuraciones en AWS no está preparado para auditar Azure con el mismo marco de referencia. Las herramientas de escaneo que funcionan bien en una plataforma no necesariamente detectan los problemas críticos en otra, porque los controles nativos, los modelos de permisos y las configuraciones por defecto son arquitectónicamente distintos.
Por qué esto afecta especialmente a organizaciones en América Latina
El impacto de esta fragmentación es particularmente agudo en América Latina, donde la adopción de multicloud creció de forma acelerada en los últimos tres años sin que los equipos de seguridad escalaran al mismo ritmo. Empresas medianas en Brasil, México y Argentina adoptaron estrategias multicloud por razones de continuidad de negocio o para cumplir requisitos de residencia de datos locales, pero muchas lo hicieron sin presupuesto para especialistas en cada plataforma. El resultado es que un mismo equipo de tres o cuatro personas intenta cubrir AWS, Azure y a veces Google Cloud con un conocimiento generalista que el estudio de Intruder demuestra insuficiente.
En sectores regulados como banca y salud — donde la migración a nube en la región todavía está en curso — esta brecha de conocimiento específico por proveedor se traduce en exposiciones no detectadas durante meses. Un banco regional que opera cargas de trabajo críticas en AWS y Azure no puede asumir que las políticas de IAM (gestión de identidad y acceso) que funcionan en una plataforma protegen de la misma manera en la otra. Los modelos de permisos son distintos, los servicios equivalentes tienen configuraciones por defecto diferentes, y las herramientas de auditoría nativas no son intercambiables.
El problema de las herramientas de seguridad que prometen cobertura universal
El hallazgo de Intruder también cuestiona la promesa de las plataformas CSPM (Cloud Security Posture Management) que se comercializan como soluciones unificadas para multicloud. Si los perfiles de riesgo no tienen superposición entre proveedores, una herramienta que intente aplicar el mismo conjunto de reglas a las tres nubes necesariamente va a dejar puntos ciegos. Las CSPM más efectivas son las que mantienen motores de detección separados por proveedor, con reglas específicas para cada arquitectura — pero esas son también las más costosas y complejas de operar, lo que las pone fuera del alcance de muchas organizaciones medianas en la región.
La alternativa que muchas empresas eligen — usar las herramientas nativas de cada proveedor (AWS Security Hub, Azure Security Center, Google Security Command Center) — resuelve el problema de la especificidad pero introduce otro: la falta de visibilidad consolidada. Un equipo de seguridad que tiene que revisar tres consolas distintas, con alertas en formatos diferentes y sin correlación entre eventos, pierde capacidad de respuesta. Los incidentes que cruzan proveedores (un atacante que pivotea de AWS a Azure después de comprometer credenciales) quedan fuera del radar hasta que el daño ya está hecho.
Nuestro análisis
El Cloud Security Index de Intruder documenta un problema estructural que la industria de seguridad en nube ha evitado reconocer públicamente: no existe una estrategia de seguridad multicloud que funcione con un solo conjunto de controles. Cada proveedor construyó su plataforma con decisiones de arquitectura distintas, y esas diferencias se propagan hasta el nivel de configuración donde ocurren la mayoría de las fallas. Las organizaciones que operan en más de una nube necesitan equipos con conocimiento profundo de cada plataforma, herramientas específicas para cada una, y procesos de auditoría que no asuman transferibilidad de controles entre proveedores.
Lo que el estudio no responde — y lo que ninguna herramienta puede resolver por sí sola — es cómo escalan las organizaciones medianas en América Latina para cubrir esta complejidad sin triplicar sus equipos de seguridad. La brecha entre la velocidad de adopción de multicloud y la capacidad de gestionarla de forma segura sigue creciendo. ¿Cuántos incidentes más van a hacer falta para que la industria reconozca que el problema no es la falta de herramientas, sino la falta de un modelo operativo realista para equipos con recursos limitados?