Actualidad · 11 de septiembre de 2026 · 7 min de lectura
La seguridad en la nube no se resuelve con un checklist: cada entorno tiene riesgos diferentes
Migrar infraestructura y servicios a la nube puede simplificar operaciones, acelerar proyectos y entregar mayor flexibilidad a las organizaciones. Pero también cambia la forma en que debe gestionarse la seguridad.
La seguridad cloud no falla solamente por falta de controles
Migrar infraestructura y servicios a la nube puede simplificar operaciones, acelerar proyectos y entregar mayor flexibilidad a las organizaciones. Pero también cambia la forma en que debe gestionarse la seguridad.
Cuando una empresa trabaja con un único proveedor, es posible establecer controles y procedimientos relativamente homogéneos. El escenario cambia cuando comienzan a convivir AWS, Microsoft Azure, Google Cloud, servicios SaaS y componentes propios.
En ese punto aparece una dificultad que muchas estrategias de seguridad subestiman: los riesgos no se distribuyen de la misma manera en cada plataforma.
Un análisis publicado por Intruder en su 2026 Cloud Security Index, basado en datos de 3.000 organizaciones, comparó configuraciones de seguridad en AWS, Azure y Google Cloud. El resultado muestra que no existe un único patrón de riesgo que pueda aplicarse de manera uniforme a todos los entornos.
La conclusión es relevante para cualquier organización que esté construyendo o ampliando una estrategia multicloud: tener una lista de controles no significa necesariamente tener visibilidad sobre el riesgo real.
Un mismo entorno cloud puede tener problemas muy diferentes
El estudio agrupó las configuraciones incorrectas en seis grandes categorías: gestión de identidades y accesos (IAM), registro y monitoreo, servicios mal configurados, firewalls permisivos, servicios expuestos y cifrado débil.
Hay dos categorías que aparecen prácticamente en todas las plataformas: IAM débil y ausencia de registros o alertas adecuados.
Dependiendo del proveedor, entre un 80% y un 98% de las cuentas analizadas presentaban problemas relacionados con estas áreas.
Pero cuando se observan otros controles, las diferencias aumentan considerablemente.
Los servicios expuestos afectaron al 76% de las cuentas AWS, frente al 64% en Azure y solo el 8% en Google Cloud. En el caso de los firewalls permisivos, las cifras fueron de 83%, 45% y 34%, respectivamente. Para el cifrado débil, AWS alcanzó el 49%, Azure el 35% y Google Cloud el 8%.
Los servicios mal configurados presentan otro comportamiento: Azure registra un 80%, frente al 68% de AWS y 37% de Google Cloud.
Esto demuestra algo importante: el riesgo cloud no depende únicamente del proveedor, sino también de cómo se utilizan y configuran sus servicios.
AWS: el desafío de la exposición y los permisos
En AWS, algunas de las configuraciones incorrectas más frecuentes están relacionadas con almacenamiento, redes y privilegios.
Entre las principales aparecen buckets S3 que no fuerzan HTTPS, accesos permisivos a puertos sensibles, ACL de red demasiado abiertas y políticas IAM capaces de permitir escalada de privilegios.
El problema de IAM merece especial atención.
Una política puede parecer adecuada a primera vista y, sin embargo, entregar permisos superiores a los necesarios. En ambientes donde existen múltiples usuarios, roles, aplicaciones y servicios automatizados, esa acumulación de privilegios puede convertirse en una vía para ampliar el impacto de una intrusión.
De hecho, el informe recoge un incidente reciente en el que un atacante pasó desde credenciales expuestas hasta privilegios administrativos en AWS en menos de diez minutos, comprometiendo 19 principales de AWS.
La lección no está únicamente en proteger las credenciales. También está en controlar qué puede hacer una identidad una vez que esas credenciales son comprometidas.
Azure: almacenamiento e identidad concentran buena parte del riesgo
En Azure, el patrón cambia.
Las principales configuraciones incorrectas identificadas están relacionadas con Azure Storage: falta de rotación de claves, claves de acceso habilitadas y acceso público a la red.
Estas tres situaciones afectan entre el 61% y el 67% de las cuentas analizadas.
Esto resulta especialmente relevante porque las cuentas de almacenamiento pueden contener información sensible, incluyendo datos personales y otros activos críticos para la operación.
Pero hay otro dato que destaca: el 55% de las cuentas presentaba usuarios de Entra ID sin MFA.
El problema trasciende al entorno cloud.
Microsoft Entra ID puede controlar el acceso a Microsoft 365, aplicaciones SaaS de terceros y sistemas locales. Por eso, una debilidad en la identidad puede convertirse en un problema que atraviesa diferentes capas de la infraestructura empresarial.
En otras palabras, proteger la nube también implica proteger la identidad que permite entrar a ella.
Google Cloud: la identidad vuelve a aparecer como punto crítico
En Google Cloud, los principales problemas identificados se concentran nuevamente alrededor de IAM.
El 77% de las cuentas analizadas no tenía habilitada la MFA para OS Login y el 76% no tenía habilitado OS Login. Además, el 75% presentaba cuentas de servicio sin utilizar y un 53% contaba con cuentas de servicio excesivamente permisivas.
Estos datos muestran un patrón que se repite independientemente del proveedor: la identidad continúa siendo uno de los elementos más difíciles de controlar dentro de las infraestructuras cloud.
No basta con saber quién tiene acceso.
También es necesario conocer qué permisos posee, qué servicios puede utilizar, qué cuentas siguen activas, cuáles dejaron de ser necesarias y qué aplicaciones dependen de esas identidades.
El tamaño de la empresa tampoco elimina el problema
Podría pensarse que las organizaciones más grandes, debido a sus mayores recursos y equipos especializados, deberían presentar una postura considerablemente más madura.
En varias categorías ocurre precisamente eso.
Las grandes empresas presentan menores niveles de servicios expuestos, firewalls permisivos y cifrado débil. Sin embargo, IAM constituye una excepción significativa.
Según el estudio, los controles IAM débiles afectan al:
- 87% de las organizaciones pequeñas.
- 95% de las organizaciones medianas.
- 98% de las grandes empresas.
El dato resulta especialmente interesante porque muestra que aumentar el tamaño de una organización también aumenta la complejidad de administrar identidades, roles y permisos.
Más usuarios, más aplicaciones, más proveedores y más servicios significan también más relaciones de confianza que controlar.
Por eso, una infraestructura más grande no necesariamente significa una superficie de identidad más sencilla.
La empresa mediana enfrenta otro desafío: remediar a tiempo
El estudio también encontró diferencias importantes en la velocidad de corrección.
Las organizaciones medianas fueron las que más tardaron en solucionar las configuraciones incorrectas, alcanzando un promedio de 35 días, mientras que las organizaciones pequeñas se situaron entre 7 y 16 días y las grandes empresas alrededor de 10 días.
Este comportamiento plantea una situación particularmente compleja.
Las empresas medianas pueden estar gestionando una infraestructura suficientemente grande como para tener la complejidad de una organización empresarial, pero sin disponer necesariamente de los mismos recursos especializados para administrarla.
El resultado puede ser una acumulación de configuraciones pendientes, permisos que deberían revisarse y activos cuya postura de seguridad deja de estar completamente controlada.
El verdadero problema no es tener más controles, sino saber dónde están los riesgos
Una lista de verificación sigue siendo útil.
El problema aparece cuando se transforma en el principal mecanismo para entender la seguridad de un entorno cloud.
En un escenario multicloud, revisar si existe MFA, cifrado, firewall o logging no es suficiente. También hay que entender cómo está implementado cada control, sobre qué activos aplica y qué riesgos específicos genera su configuración.
AWS, Azure y Google Cloud pueden compartir principios de seguridad, pero sus arquitecturas, servicios, permisos y configuraciones son diferentes.
Por eso, una estrategia efectiva necesita combinar dos niveles de análisis.
Por un lado, una metodología común, que permita establecer criterios corporativos de seguridad y comparar la postura general de la organización.
Por otro, una evaluación específica por plataforma, capaz de identificar las configuraciones que realmente generan exposición en cada entorno.
Esta combinación permite pasar de una seguridad basada en cumplimiento de casillas a una seguridad basada en visibilidad, contexto y priorización.
La nube necesita una visión integral de seguridad
La adopción cloud seguirá creciendo y, con ella, también la diversidad de plataformas y servicios que forman parte de la infraestructura empresarial.
El desafío ya no consiste simplemente en proteger servidores que están en la nube.
Implica controlar identidades, permisos, configuraciones, exposición de servicios, almacenamiento, redes, registros y relaciones entre múltiples plataformas.
El 2026 Cloud Security Index deja una señal clara: no existe un único mapa de riesgo para la nube. Los problemas cambian según el proveedor, el tamaño de la organización y la forma en que cada entorno ha sido implementado.
Para los equipos de seguridad, esto significa que la prioridad no debería ser acumular más controles, sino conseguir una visión suficientemente amplia para identificar qué está expuesto, por qué está expuesto y qué debería corregirse primero.
Porque en una infraestructura multicloud, la seguridad no se fortalece simplemente revisando más casillas. Se fortalece entendiendo mejor el entorno que esas casillas intentan proteger.
Fuente
Este artículo toma como referencia el 2026 Cloud Security Index de Intruder, elaborado a partir de datos de configuraciones cloud de 3.000 organizaciones, y el análisis publicado posteriormente por The Hacker News.