25. Pentesting cloud: IAM, almacenamiento, redes, secretos y configuraciones débiles
Los entornos cloud combinan identidad, permisos, servicios administrados, redes virtuales, datos, automatización y exposición pública. En este tema aprenderás a revisar configuraciones cloud dentro de un alcance autorizado, priorizando impacto real, evidencia controlada y recomendaciones aplicables.
Objetivo
Comprender cómo evaluar riesgos cloud en IAM, almacenamiento, redes, secretos, registros y servicios expuestos.
Enfoque
Trabajar con alcance explícito, cuentas de prueba, mínimos privilegios y validaciones que no afecten operación.
Resultado
Identificar configuraciones débiles y traducirlas en controles concretos de arquitectura, gobierno y monitoreo.
25.1 Introducción
El pentesting cloud no consiste en atacar al proveedor de nube. Consiste en evaluar cómo una organización configuró sus recursos, permisos, redes, identidades, integraciones y datos dentro de una plataforma cloud. El foco está en los errores de configuración, los permisos excesivos, la exposición pública accidental, el manejo inseguro de secretos y la falta de monitoreo.
AWS, Azure, Google Cloud y otros proveedores tienen diferencias importantes, pero comparten principios: todo recurso debe tener propietario, permisos mínimos, exposición justificada, cifrado adecuado, registro de eventos y controles de cambio. Una debilidad pequeña, como una clave filtrada o un permiso demasiado amplio, puede escalar rápidamente por la integración entre servicios.
25.2 Modelo de responsabilidad compartida
En cloud, el proveedor protege la infraestructura base, pero el cliente sigue siendo responsable de muchas decisiones: identidades, permisos, datos, configuraciones, redes, aplicaciones, secretos, monitoreo y cumplimiento. El detalle exacto depende del servicio usado: no es lo mismo una máquina virtual que una base de datos administrada o una función serverless.
Para el pentester, este modelo evita conclusiones incorrectas. Un hallazgo debe distinguir si el riesgo nace de la configuración del cliente, de una mala arquitectura, de una aplicación desplegada sobre cloud o de un uso inseguro de un servicio administrado.
25.3 Alcance, autorización y reglas del proveedor
Antes de probar, se debe confirmar qué cuentas, suscripciones, proyectos, regiones, servicios, dominios, direcciones, roles y entornos están autorizados. También deben revisarse las políticas del proveedor cloud sobre pruebas de seguridad, porque algunas acciones pueden requerir coordinación previa o estar limitadas.
El alcance debe aclarar si se permite revisar IAM, inventario, almacenamiento, redes, logs, imágenes, funciones, contenedores, servicios administrados, repositorios, pipelines y secretos. Sin esa claridad, es fácil tocar recursos compartidos, datos productivos o integraciones críticas.
25.4 Inventario cloud
Un inventario cloud debe responder qué existe, dónde está, quién lo administra, qué datos procesa, si está expuesto públicamente y qué identidades pueden usarlo. Las plataformas cloud cambian rápido, por lo que el inventario debe compararse con la realidad actual y no solo con documentación estática.
| Categoría | Qué identificar | Riesgo frecuente |
|---|---|---|
| Identidades | Usuarios, roles, grupos, cuentas de servicio y aplicaciones | Permisos excesivos o credenciales antiguas |
| Datos | Buckets, discos, bases, snapshots y copias | Exposición pública o cifrado débil |
| Redes | VPC, subredes, reglas, balanceadores y gateways | Acceso abierto a administración o servicios internos |
| Automatización | Funciones, pipelines, plantillas e imágenes | Secretos embebidos o permisos heredados |
25.5 IAM como superficie crítica
IAM define quién puede hacer qué sobre qué recurso y bajo qué condiciones. En cloud, la identidad suele ser el perímetro principal. Una red privada pierde valor si una identidad comprometida puede leer secretos, crear llaves, modificar políticas, ejecutar funciones o acceder a almacenamiento sensible.
La revisión debe buscar permisos amplios, roles sin uso, confianza mal definida, cuentas de servicio con privilegios altos, grupos acumulativos, políticas heredadas, llaves sin rotación y ausencia de autenticación multifactor para accesos humanos privilegiados.
25.6 Principio de mínimo privilegio
El mínimo privilegio exige que cada identidad tenga solo los permisos necesarios para su función, durante el tiempo necesario y sobre los recursos necesarios. En la práctica, muchas organizaciones comienzan con permisos amplios para acelerar despliegues y nunca los reducen.
En un pentest, no se debe asumir que un permiso amplio es explotable automáticamente. Se debe explicar qué permite, qué datos o servicios afecta, qué condiciones lo limitan y qué camino real podría habilitar. Esa diferencia entre permiso teórico e impacto práctico mejora mucho la calidad del reporte.
25.7 Roles, confianza y escalamiento de privilegios
Los roles cloud suelen depender de relaciones de confianza. Una identidad puede asumir un rol, una aplicación puede actuar como cuenta de servicio, una función puede acceder a secretos o un pipeline puede desplegar infraestructura. Si esas relaciones son demasiado amplias, se crean caminos de escalamiento.
La revisión debe mapear quién puede asumir roles, modificar políticas, crear credenciales, adjuntar permisos, ejecutar código con identidad privilegiada o cambiar configuraciones de seguridad. La evidencia debe ser controlada y, cuando el riesgo sea alto, puede bastar con demostrar la condición sin ejecutar acciones destructivas.
25.8 Cuentas de servicio y cargas de trabajo
Las aplicaciones, funciones, contenedores, máquinas virtuales y pipelines suelen usar identidades no humanas. Estas cuentas de servicio pueden acumular permisos altos porque facilitan operaciones automáticas. El problema aparece cuando una carga de trabajo vulnerable hereda permisos que exceden su necesidad real.
La evaluación debe verificar permisos por carga, separación entre entornos, rotación de credenciales, acceso a secretos, registros de uso y dependencia entre servicios. Una cuenta de servicio de desarrollo no debería poder modificar producción ni leer datos sensibles fuera de su dominio.
25.9 Almacenamiento cloud
Los servicios de almacenamiento son una fuente habitual de hallazgos: buckets públicos, snapshots compartidos, discos sin cifrado, backups olvidados, archivos con secretos, políticas permisivas o enlaces firmados con duración excesiva. El riesgo depende del contenido, la exposición y la facilidad de acceso.
Un pentest responsable debe evitar descargar grandes volúmenes de datos. Es suficiente documentar metadatos, nombres de archivos, permisos, una muestra mínima autorizada y el impacto potencial. Si aparecen datos personales o información sensible no prevista, se debe escalar por el canal acordado.
25.10 Exposición pública accidental
La exposición pública no siempre es un error. Un sitio estático, una API pública o un balanceador externo pueden ser necesarios. El problema aparece cuando la exposición no está justificada, no tiene autenticación, revela datos internos o permite administrar recursos.
Deben revisarse buckets, bases administradas, paneles, servicios de administración, colas, registros, endpoints de salud, dashboards y recursos con reglas de red abiertas. La recomendación debe diferenciar entre cerrar la exposición, restringirla por red, exigir autenticación o rediseñar el flujo.
25.11 Cifrado y administración de claves
El cifrado en cloud incluye datos en tránsito, datos en reposo, claves administradas por el proveedor, claves gestionadas por el cliente, rotación y controles de acceso a servicios de llaves. Un recurso cifrado no está necesariamente protegido si demasiadas identidades pueden leer la clave o descifrar datos.
La revisión debe verificar qué recursos están cifrados, qué algoritmo o servicio se usa, quién puede administrar llaves, quién puede usarlas, si hay rotación, si las copias también se protegen y si los logs registran uso de operaciones sensibles sobre claves.
25.12 Secretos, credenciales y llaves
Los secretos pueden aparecer en variables de entorno, archivos de configuración, imágenes, repositorios, scripts, logs, plantillas de infraestructura, gestores de secretos, documentación interna y sistemas de CI/CD. Una clave válida puede permitir acceso directo sin explotar vulnerabilidades adicionales.
El manejo adecuado incluye gestores de secretos, rotación, permisos mínimos, separación por entorno, auditoría de lectura, eliminación de secretos embebidos y procedimientos de revocación. En una prueba autorizada, si se encuentra un secreto real, se debe reportar con cuidado y evitar usarlo fuera del alcance acordado.
25.13 Redes virtuales y segmentación
Las redes cloud permiten crear segmentos, rutas, firewalls, grupos de seguridad, balanceadores, gateways, peering, VPN y conexiones privadas. La complejidad puede producir reglas demasiado amplias, rutas inesperadas o servicios internos accesibles desde zonas no previstas.
La revisión debe identificar qué recursos tienen IP pública, qué puertos están permitidos, qué subredes se comunican, qué reglas usan rangos amplios, qué rutas conectan entornos y qué controles existen para acceso administrativo. El objetivo es confirmar que la segmentación refleje el riesgo de los sistemas.
25.14 Servicios administrados y bases de datos
Las bases de datos, colas, caches, servicios de búsqueda, analítica y mensajería administrada reducen carga operativa, pero siguen requiriendo configuración segura. Deben revisarse autenticación, exposición de red, cifrado, backups, snapshots, logging, roles internos y políticas de acceso.
Un hallazgo frecuente es que un servicio administrado esté protegido por contraseña, pero expuesto a redes amplias o accesible desde identidades con permisos innecesarios. La defensa debe combinar red, identidad, cifrado, monitoreo y administración de secretos.
25.15 Metadatos de instancias y credenciales temporales
Muchas máquinas virtuales y cargas cloud acceden a metadatos de instancia para obtener información de entorno o credenciales temporales asociadas a un rol. Este mecanismo es útil, pero puede ser riesgoso si una aplicación vulnerable permite consultar recursos internos o si el rol asignado tiene demasiados permisos.
La evaluación debe revisar la versión y protección del servicio de metadatos, los permisos del rol asociado, las rutas de acceso desde aplicaciones y la segmentación interna. La remediación suele combinar endurecimiento del servicio, corrección de vulnerabilidades de aplicación y reducción de permisos.
25.16 Serverless y funciones cloud
Las funciones serverless ejecutan código en respuesta a eventos, colas, rutas HTTP, cambios en almacenamiento o cronogramas. Su superficie incluye permisos de ejecución, variables de entorno, disparadores, dependencias, logs, límites de tiempo, acceso a redes y secretos.
Se debe validar que cada función tenga permisos mínimos, que los eventos estén autenticados cuando corresponda, que las entradas se validen, que los errores no filtren secretos y que los logs no almacenen información sensible. Una función pequeña puede tener impacto alto si opera con un rol privilegiado.
25.17 Logging, monitoreo y detección
Un entorno cloud seguro necesita visibilidad. Deben registrarse cambios de IAM, uso de claves, creación de recursos, modificaciones de red, acceso a datos sensibles, errores de autenticación y acciones administrativas. Sin logs, los incidentes se detectan tarde o no se pueden reconstruir.
En el pentest conviene revisar si los logs están habilitados, protegidos contra modificación, centralizados, retenidos por el tiempo requerido y conectados a alertas útiles. También debe verificarse que las pruebas acordadas generen eventos visibles para el equipo defensivo.
25.18 Infraestructura como código
Terraform, CloudFormation, Bicep, ARM, Pulumi y otras herramientas permiten definir infraestructura de forma repetible. Esto facilita auditoría, pero también puede propagar configuraciones inseguras a muchos entornos si las plantillas contienen permisos amplios, secretos o valores por defecto débiles.
La revisión debe comparar lo desplegado con lo definido, buscar desviaciones manuales, validar controles en revisión de código, detectar secretos y proponer políticas automatizadas que impidan crear recursos inseguros antes de que lleguen a producción.
25.19 Riesgos típicos por área
| Área | Debilidad común | Control recomendado |
|---|---|---|
| IAM | Políticas demasiado amplias | Mínimo privilegio, condiciones y revisión periódica |
| Almacenamiento | Lectura pública no justificada | Bloqueo público, políticas específicas y monitoreo |
| Red | Puertos administrativos abiertos | Acceso por VPN, bastion, identidad y reglas restrictivas |
| Secretos | Claves en código o logs | Gestor de secretos, rotación y escaneo continuo |
| Logs | Eventos críticos sin registro | Auditoría centralizada, retención y alertas accionables |
25.20 Evidencia en pentesting cloud
La evidencia cloud debe mostrar recurso, cuenta o proyecto, región, servicio, configuración observada, permiso implicado, impacto y recomendación. Cuando el hallazgo involucra datos, se debe minimizar la exposición: no se descargan datasets completos para probar un punto si una muestra autorizada o metadatos bastan.
También conviene incluir contexto de explotación realista. Por ejemplo, un bucket público con archivos de marketing no tiene la misma severidad que un bucket público con backups de base de datos. La severidad debe basarse en impacto, probabilidad, exposición y facilidad de abuso.
25.21 Remediación y endurecimiento
La remediación cloud debe combinar correcciones puntuales con controles preventivos. Cerrar una regla abierta soluciona un caso, pero las organizaciones necesitan políticas, revisiones, plantillas seguras, alertas y procesos para que el problema no reaparezca.
- Aplicar mínimo privilegio y revisar permisos de forma periódica.
- Separar entornos, cuentas, proyectos y suscripciones por criticidad.
- Bloquear exposición pública no justificada en almacenamiento y servicios.
- Usar gestores de secretos y rotación automática cuando sea posible.
- Centralizar logs, protegerlos y activar alertas sobre acciones críticas.
- Validar infraestructura como código antes del despliegue.
- Definir propietarios, etiquetas, clasificación de datos y ciclos de vida.
25.22 Flujo práctico de revisión
Un flujo profesional comienza por alcance y permisos de lectura, continúa con inventario, IAM, exposición, almacenamiento, secretos, redes, servicios administrados, logs e infraestructura como código. Luego se agrupan hallazgos por caminos de impacto, no solo por recurso individual.
- Confirmar alcance, cuentas, regiones, servicios y acciones permitidas.
- Construir inventario de identidades, recursos, datos y exposición.
- Revisar IAM, relaciones de confianza, roles y cuentas de servicio.
- Evaluar almacenamiento, snapshots, backups y políticas públicas.
- Analizar redes, puertos, rutas, gateways y accesos administrativos.
- Buscar secretos en ubicaciones autorizadas y validar rotación.
- Comprobar logging, monitoreo, retención y respuesta defensiva.
- Documentar impacto, evidencia mínima y remediación priorizada.
25.23 Errores frecuentes
Un error habitual es tratar cloud como si fuera solo una red con servidores. En realidad, identidad, APIs de administración, servicios administrados y automatización son tan importantes como las direcciones IP. Otro error es reportar listas extensas de permisos sin explicar qué impacto real permiten.
También es frecuente ignorar entornos de prueba, cuentas antiguas, regiones no utilizadas, snapshots, integraciones y pipelines. En cloud, los recursos olvidados suelen ser más peligrosos que los recursos principales porque reciben menos revisión.
25.24 Qué debes recordar
En cloud, la identidad es una frontera crítica. Un permiso amplio, una relación de confianza mal diseñada o una clave filtrada pueden abrir más puertas que un puerto expuesto. La seguridad debe evaluarse como una combinación de IAM, datos, red, secretos, automatización y monitoreo.
El valor del pentest cloud está en conectar configuraciones con impacto: qué recurso queda expuesto, qué datos están en riesgo, qué identidad puede abusarlo, qué registros lo detectarían y qué control reduce el riesgo de forma sostenible.
25.25 Conclusión
El pentesting cloud exige entender servicios, permisos y arquitectura. No se trata solo de encontrar recursos públicos, sino de evaluar cómo una organización gobierna identidades, secretos, redes, datos y cambios. Con un alcance claro y evidencia responsable, los hallazgos cloud pueden convertirse en mejoras profundas de seguridad.
En el próximo tema abordaremos contenedores, Kubernetes y seguridad en pipelines de despliegue, donde la nube se conecta con imágenes, clusters, manifiestos, registros y automatización de entrega.