El salto hacia la computación en nube ha marcado un antes y un después en la estrategia tecnológica de muchas organizaciones. Empresas de diversos sectores están migrando cargas de trabajo hacia plataformas como Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP), etc. motivadas por ventajas como disponibilidad global de información, capacidad de crecimiento bajo demanda, optimización de gastos y herramientas de protección nativas. Pero la adopción de servicios cloud tiene un lado B: cada servicio cloud añadido representa una nueva puerta que asegurar.
A pesar de años de adopción cloud, un dato bastante interesante como alarmante es que en gran parte de los incidentes, la causa raíz está en configuraciones, identidades o prácticas operativas del cliente, más que en fallas del proveedor. Este dato refleja que “La nube no es insegura por naturaleza, pero tampoco viene segura por defecto”. La protección funciona mediante un modelo de responsabilidad compartida donde los proveedores cloud gestionan la seguridad de la infraestructura física y de red, dejando en manos del cliente la configuración segura de recursos, gestión de roles/permisos, protección de datos y hardening de aplicaciones.
Pruebas de penetración en la nube (Cloud)
Las pruebas de penetración en infraestructuras Cloud se han convertido en un pilar importante en las estrategias de protección en la nube para las organizaciones. A diferencia de las evaluaciones “tradicionales” en infraestructuras on-premise (donde las empresas tienen sus propios servidores físicos, almacenamiento,etc), el pentesting en la nube requiere conocimientos sobre APIs, gestión de identidades, configuraciones de servicios administrados y la compleja interacción entre múltiples capas de control de acceso
En este artículo exploramos los factores más comunes en la nube que generan brechas de seguridad y presentamos una metodología general de pentesting que sirve como punto de partida para cloud. Aunque AWS, Azure, GCP, etc. tienen sus particularidades, esta metodología es aplicable de manera general.
Factores que más provocan brechas de seguridad
Configuraciones inseguras
Las configuraciones inseguras (incorrectas) son de los principales factores que pueden provocar brechas de seguridad según Cloud Security Alliance (CSA). Un gran porcentaje de organizaciones tiene almacenamiento cloud expuesto. Un bucket mal configurado puede exponer millones de registros, una base de datos Firebase sin reglas permite acceso anónimo, y un firewall incorrecto deja servicios internos en Internet. La naturaleza programática de cloud amplifica estos riesgos.
Gestión deficiente de identidades
Muchos incidentes inician con credenciales débiles o ausentes por ejemplo (Google Cloud) service accounts con 20+ roles cuando solo necesitan 5 son comunes en auditorías reales. Permisos excesivos crean doble riesgo: si el tercero es comprometido, el atacante hereda todos esos privilegios innecesarios.
APIs inseguras
Muchas fallas de seguridad son provocadas por APIs mal protegidas o APIs inseguras (versiones con vulnerabilidades o APIs mal configuradas). Las vulnerabilidades incluyen autenticación débil, falta de validación de entrada, y consumo de recursos sin restricciones, etc. (OWASP). Los atacantes aprovechan estas fallas para moverse lateralmente entre servicios cloud, escalar privilegios, y extraer datos sensibles mediante llamadas API que parecen completamente legítimas para los sistemas de monitoreo
Estrategia de seguridad inadecuada
Organizaciones que tratan la nube como “el datacenter de otro” fallan en aprovechar capacidades cloud-native. El extremo opuesto – adoptar sin evaluación de riesgos – resulta en shadow IT y configuraciones no supervisadas.
Cadena de suministro comprometida
Un componente tercero comprometido (librería, imagen de contenedor, servicio externo) puede afectar infraestructuras completas.
Desarrollo de software inseguro
Organizaciones que priorizan velocidad sobre seguridad despliegan vulnerabilidades a producción constantemente. Credenciales hardcodeadas en código y secretos en repositorios son vectores de ataque frecuentes.
Exposición accidental de datos
Un desarrollador habilita acceso público temporal y olvida revocarlo. Un administrador crea un backup sin restricciones. La velocidad con que se despliegan y comparten recursos cloud multiplica las posibilidades de exposición accidental o por desconocimiento de buenas prácticas.
Vulnerabilidades sin parchear
El uso de software sin actualizar sistemas operativos desactualizados, contenedores con versiones antiguas, servicios con vulnerabilidades conocidas deja puertas abiertas a los atacantes. Retrasar parches de seguridad por esperar ventanas de mantenimiento significa mantener exposiciones críticas activas durante bastante tiempo
Visibilidad limitada
Sin registro de eventos robusto y monitoreo centralizado, las brechas pasan inadvertidas durante períodos prolongados. Los atacantes aprovechan esta ceguera para establecer persistencia y realizar movimientos sin detección.
Amenazas persistentes avanzadas (APT)
Grupos sofisticados combinan phishing, explotación de APIs y abuso de servicios cloud legítimos. Han demostrado capacidad para evadir MFA robando tokens de sesión y mantener acceso prolongado mediante backdoors discretas.
El porqué de las pruebas de penetración a entornos Cloud
Los factores de riesgo anteriormente expuestos demuestran la importancia crítica de las pruebas de penetración en entornos cloud. Estas evaluaciones permiten identificar de forma proactiva estos factores de riesgo y otros vectores de ataque antes de que sean descubiertos por actores maliciosos. A diferencia de auditorías de seguridad para cloud, las pruebas de penetración simulan tácticas y técnicas reales de atacantes, validando si las múltiples capas de controles implementadas realmente protegen los activos críticos.
Metodología para pruebas de penetración en la nube
Las pruebas de penetración en entornos cloud siguen un ciclo de vida estructurado que comienza con reconocimiento externo y progresa sistemáticamente hasta demostrar el impacto potencial. A continuación, se presenta una metodología (Pasos a seguir) generalizada aplicable para pruebas de penetración en la nube, proporcionando un marco estructurado para evaluar la postura de seguridad en estos entornos.
PROGRESIÓN:
Reconocimiento
Identificación de la superficie de ataque externa mediante OSINT (Open Source Intelligence). Esta fase incluye descubrimiento de buckets de almacenamiento públicos, enumeración de subdominios asociados a servicios cloud, identificación de APIs expuestas, y búsqueda de credenciales filtradas en repositorios públicos. Herramientas especializadas permiten localizar recursos cloud mal configurados sin necesidad de credenciales.
Compromiso de credenciales
Obtención del acceso inicial mediante claves de acceso expuestas, tokens de autenticación, credenciales comprometidas, o explotación de vulnerabilidades en aplicaciones públicas. Este primer punto de entrada es importante – frecuentemente proviene de credenciales hardcodeadas en código, claves de servicio sin rotación, o phishing dirigido a usuarios privilegiados.
Establecimiento de persistencia
Aseguramiento de acceso continuado mediante creación de service accounts adicionales, generación de nuevas claves de acceso, modificación de roles, o despliegue de funciones maliciosas. El objetivo es mantener acceso incluso si las credenciales iniciales son revocadas.
Escalación de privilegios
Elevación de permisos mediante explotación de configuraciones IAM excesivas, abuso de roles con permisos de escritura peligrosos, aprovechamiento de service accounts con capacidad de impersonación (capacidad de asumir la identidad de otro usuario o servicio), o modificación de políticas de acceso. Esta fase conecta directamente con el factor de riesgo de gestión deficiente de identidades.
Exfiltración de datos
Extracción de información sensible desde buckets de almacenamiento, bases de datos administradas, snapshots de discos, o secretos almacenados en servicios de gestión de claves. Las APIs cloud facilitan la descarga masiva de datos de manera que puede pasar como tráfico legítimo.
Impacto
Demostración del alcance del compromiso mediante modificación de recursos críticos, cifrado de datos (simulación de ransomware), disrupción de servicios, o acceso a sistemas de producción. En pentesting, esta fase se documenta sin ejecutar acciones destructivas reales.
Operación completa (Cierre)
Revocación de credenciales temporales, eliminación de cuentas/llaves o recursos creados para la prueba, desinstalación de herramientas y limpieza de artefactos de evaluación, restauración de configuraciones modificadas (cuando aplique) y documentación exhaustiva de hallazgos, evidencias y recomendaciones para el reporte final. Este cierre busca dejar el entorno en un estado seguro y controlado, preservando la trazabilidad necesaria para remediación.
CICLO INTERNO CLOUD-NATIVE
Enumeración cloud
Descubrimiento sistemático mediante APIs del proveedor: listado de proyectos/cuentas/suscripciones, inventario de recursos (VMs, buckets, bases de datos), análisis de roles y permisos IAM, identificación de service accounts y sus asignaciones.
Acceso a credenciales cloud
Extracción de nuevas identidades mediante robo de service account keys desde metadatos de instancias, captura de tokens OAuth de aplicaciones, recuperación de secretos desde servicios de gestión de credenciales, o explotación de vulnerabilidades SSRF para acceder a APIs de metadatos.
Movimiento cross-project/cross-account
Pivoteo entre entornos aprovechando service accounts con permisos en múltiples proyectos, roles que permiten asumir identidades en otras cuentas, o recursos compartidos entre diferentes áreas de la organización.
Regreso al ciclo
Nueva enumeración con credenciales elevadas, descubriendo recursos previamente inaccesibles y repitiendo el ciclo con mayor alcance y privilegios.
CONSIDERACIONES IMPORTANTES:
Las fases descritas funcionan como modelo conceptual porque se alinean con tácticas comunes observadas en ataques reales (reconocimiento, acceso inicial, persistencia, escalación, exfiltración e impacto). En la práctica, los pasos no siempre ocurren en el mismo orden ni se ejecutan una sola vez. Es común ver escalación antes que persistencia fuerte, o exfiltración parcial antes de buscar impacto, dependiendo de qué tan rápido se detecte al atacante, qué controles existan, o qué tan expuesto esté IAM.
La responsabilidad y el alcance técnico varían por IaaS / PaaS / SaaS: En IaaS se evalúa más “operación” (p. ej., máquinas/OS que sí administras). En PaaS/SaaS muchas capas las gestiona el proveedor, y el foco del pentest suele recaer en IAM, configuración, APIs, datos y lógica de la aplicación.
Conclusión
Los factores de riesgo explorados (configuraciones erróneas, gestión deficiente de identidades, visibilidad limitada) son responsabilidad del cliente bajo el modelo de responsabilidad compartida. Las pruebas de penetración en entornos cloud se han convertido en una necesidad que nos permite identificar y remediar vulnerabilidades antes de que sean descubiertas por atacantes reales. La metodología presentada ofrece un marco general para la realización de las pruebas, pero su efectividad depende de implementación consistente y mejora continua.
No se trata de si existen vulnerabilidades en su entorno cloud, sino de descubrirlas y remediarlas antes que un atacante. Evaluaciones regulares, monitoreo continuo y mejora constante son la diferencia entre protección efectiva y la próxima brecha de seguridad
Referencias
Modelo de responsabilidad compartida – AWS-Responsabilidad Compartida. Recuperado el 26 de enero de 2026.
API security – OWASP API Security Project. Recuperado el 26 de enero de 2026.
Cloud Security – IBM Cloud Security. Recuperado el 26 de enero de 2026.
Modelo de responsabilidad compartida – Microsoft-Responsabilidad Compartida. Recuperado el 26 de enero de 2026.
Solución de accesos y mitigación de riesgos – Google Cloud (GCP). Recuperado el 26 de enero de 2026.
Modelo de responsabilidad compartida – Seguridad de APIs. Recuperado el 26 de enero de 2026.
Cloud Penetration Testing – Cloud Penetration Testing. Recuperado el 26 de enero de 2026.