Los errores de configuración cloud más comunes: buckets públicos, IAM excesivo y claves en repositorios

Por Kike Gandia · Co-Fundador y CEO, OSCP

La mayoría de los incidentes graves en la nube no empiezan con una vulnerabilidad desconocida, sino con una configuración: un bucket que alguien hizo público, un rol con permisos de administrador «temporales», una clave de acceso subida a un repositorio o una instancia que entrega sus credenciales a quien sepa pedírselas. Son errores conocidos, se repiten en AWS, Azure y Google Cloud, y casi todos tienen una corrección sencilla. En esta guía repasamos los más frecuentes, por qué son peligrosos, qué han cambiado los proveedores en sus valores por defecto, un caso real que los encadena y cómo detectarlos antes que un atacante.

Por qué la configuración es el riesgo principal en cloud

En un centro de datos propio, exponer una base de datos a internet requiere tocar el cortafuegos, el enrutamiento y el servidor. En la nube basta con una casilla o una línea de una plantilla de infraestructura. Esa facilidad es la ventaja del cloud y también su principal riesgo: cualquier persona con permisos puede cambiar en segundos la exposición de un recurso, y el cambio queda activo hasta que alguien lo detecta.

Por eso las guías de los organismos de referencia ponen el foco en la configuración y no en las vulnerabilidades de software. En marzo de 2024 la NSA, con la participación de CISA en seis de ellas, publicó sus «Top Ten Cloud Security Mitigation Strategies»: diez hojas de recomendaciones que empiezan por respetar el modelo de responsabilidad compartida y siguen con la gestión de identidades y accesos, la gestión de claves, la segmentación de red y el cifrado, la protección de los datos, la seguridad de los entornos de CI/CD, la infraestructura como código, los entornos híbridos y multicloud, los proveedores de servicios gestionados y los registros para la detección.

Tres características hacen que estos errores sean tan peligrosos:

Son visibles desde fuera. Hay herramientas que recorren internet buscando buckets abiertos, claves publicadas o servicios expuestos de forma continua.
No requieren explotar nada. Un bucket público se descarga; una clave válida se usa. No hay exploit que detectar.
Se encadenan. Un error menor da acceso a una credencial, y la credencial da acceso a todo lo demás.

Resumen: los errores más comunes y su impacto

Error	Ejemplo	Qué consigue un atacante	Qué lo frena
Almacenamiento público	Bucket de S3, contenedor de Azure Blob o bucket de Cloud Storage abierto a cualquiera	Descargar copias de seguridad, documentos o datos de clientes	Bloqueo de acceso público a nivel de cuenta u organización
IAM excesivo	Usuarios y roles con permisos de administrador o comodines	Que una credencial robada controle toda la cuenta	Mínimo privilegio, límites de permisos, revisión de permisos no usados
Claves en repositorios	Claves de acceso en Git, imágenes de contenedor, apps móviles o logs del pipeline	Acceso directo a la cuenta con la identidad de la clave	Eliminar claves de larga duración, escaneo de secretos, rotación
Metadatos sin proteger	Instancias que aceptan IMDSv1 detrás de una aplicación con SSRF	Robar las credenciales temporales del rol de la máquina	IMDSv2 obligatorio, límite de saltos, roles con mínimo privilegio
Red abierta	SSH, RDP o bases de datos accesibles desde 0.0.0.0/0	Fuerza bruta, explotación de servicios, acceso directo a datos	Grupos de seguridad restrictivos, acceso por bastión o servicios de sesión
Snapshots e imágenes compartidos	Snapshots de discos o bases de datos, o imágenes de máquina, compartidos públicamente	Montar una copia completa del disco con todos sus datos y secretos	Bloqueo de compartición pública, revisión periódica
Registro desactivado	Sin registro de actividad persistente o sin eventos de acceso a datos	Actuar sin dejar rastro útil y sin que nadie lo detecte	Registro centralizado, protegido y con alertas revisadas
Confianzas mal definidas	Roles asumibles desde otras cuentas o desde CI/CD sin condiciones	Que un tercero, o cualquier repositorio, obtenga credenciales de tu cuenta	Condiciones estrictas en las políticas de confianza

Los siguientes apartados explican cada bloque con más detalle.

Almacenamiento público: buckets, blobs y snapshots

Es el error más conocido y el que más titulares ha generado: un contenedor de almacenamiento accesible para cualquiera que conozca, o adivine, su nombre.

Los proveedores han endurecido sus valores por defecto. Desde abril de 2023, los buckets de S3 nuevos se crean con el bloqueo de acceso público activado y las ACL desactivadas, se creen como se creen. En Azure, la configuración por defecto de las cuentas de almacenamiento prohíbe el acceso anónimo a los blobs. Pero esos cambios tienen límites importantes:

Solo afectan a lo nuevo. Los buckets y cuentas creados antes conservan su configuración.
Se pueden desactivar. Basta con que alguien quite el bloqueo para publicar una web estática y, con el tiempo, el mismo bucket acabe guardando otras cosas.
No cubren todas las formas de compartir. Las URLs prefirmadas de S3 o los tokens SAS de Azure con caducidad de años y permisos amplios equivalen a un acceso público para quien tenga el enlace.

Dos confusiones clásicas: en Google Cloud, conceder acceso a allAuthenticatedUsers no limita el acceso a tu organización, sino a cualquier persona con una cuenta de Google; y en S3 las antiguas ACL para «usuarios autenticados» significaban cualquier cuenta de AWS, no las de tu empresa.

Los snapshots merecen mención aparte. Un snapshot de un disco o de una base de datos compartido públicamente contiene una copia completa de los datos, incluidos ficheros de configuración con contraseñas. Las imágenes de máquina compartidas tienen el mismo problema.

La corrección es aplicar el bloqueo a nivel de cuenta u organización, no bucket a bucket —el bloqueo de acceso público de S3 a nivel de cuenta, la política de organización de prevención de acceso público en Google Cloud, Azure Policy para impedir el acceso anónimo—, y revisar periódicamente qué se comparte fuera.

IAM excesivo: el error que convierte cualquier fallo en total

Si hubiera que elegir un solo error, sería este. Los permisos determinan cuánto daño puede hacer quien comprometa una identidad, y en la mayoría de las cuentas son mucho más amplios de lo necesario:

Permisos de administrador por comodidad. Políticas con "Action": "*" y "Resource": "*" asignadas a usuarios, roles de aplicaciones o al pipeline de despliegue, porque así «funciona».
La cuenta raíz o el propietario de la suscripción en uso diario, a veces sin MFA.
Usuarios humanos con claves de acceso de larga duración en lugar de acceso federado con credenciales temporales.
Permisos acumulados. Quien cambió de equipo conserva los de antes; el rol de un proyecto terminado sigue existiendo; las cuentas de servicio de pruebas nunca se borran.
Combinaciones que permiten escalar. Permisos que por separado parecen inofensivos —como poder pasar un rol a un servicio y crear funciones— permiten a una identidad limitada actuar como una más privilegiada.
Relaciones de confianza amplias. Roles que un proveedor externo puede asumir sin un identificador externo, o roles para GitHub Actions u otros sistemas de CI cuya condición no limita qué repositorio o rama puede obtener credenciales.

La forma de reducirlo es conocida: mínimo privilegio, empezando por las identidades expuestas a internet; credenciales temporales para personas y cargas de trabajo; límites de permisos para los roles que crean otros roles; políticas de organización (SCP en AWS, Azure Policy, políticas de organización en Google Cloud) que impidan las acciones más peligrosas; y revisión periódica de los permisos que no se usan, con herramientas nativas como IAM Access Analyzer. Lo que no se ve sin probarlo es si queda alguna ruta de escalada: para eso está el análisis ofensivo de IAM, que explicamos en la guía de pentesting en AWS.

Claves y secretos en repositorios

Las credenciales de larga duración —claves de acceso de AWS, secretos de entidades de servicio de Azure, claves de cuentas de servicio de Google Cloud— acaban en sitios donde no deberían. La dimensión del problema la da el informe State of Secrets Sprawl 2026 de GitGuardian: 28.649.024 secretos nuevos detectados en commits públicos de GitHub durante 2025, un 34 % más que el año anterior. Y eso son solo los repositorios públicos.

Dónde aparecen:

En el historial de Git, aunque se hayan borrado en el último commit.
En ficheros de configuración, plantillas de infraestructura y ficheros .env subidos por error.
En imágenes de contenedor publicadas, en el código de apps móviles y en el JavaScript que se envía al navegador.
En los logs del pipeline de CI/CD y en variables de entorno de funciones.

Los proveedores reaccionan cada vez más rápido. GitHub activó en febrero de 2024 por defecto la protección que bloquea los pushes con secretos a repositorios públicos, y las claves de AWS forman parte de los patrones que GitHub comunica directamente a AWS cuando las detecta. AWS, por su parte, puede aplicar a la clave expuesta una política de cuarentena (AWSCompromisedKeyQuarantineV3) que deniega acciones como lanzar instancias o crear usuarios, y lo comunica mediante un caso de soporte. Pero esa cuarentena es una red de seguridad, no una solución: no revoca la clave ni cubre a otros proveedores, y los atacantes también vigilan los repositorios.

Si una clave se ha publicado, borrar el commit no sirve. Hay que desactivarla y rotarla de inmediato, revisar en el registro de actividad qué se ha hecho con ella y buscar recursos creados por el atacante: instancias para minar criptomonedas, usuarios nuevos o claves adicionales. La prevención pasa por eliminar las claves de larga duración siempre que se pueda —roles, federación de identidades para el CI/CD, acceso temporal para las personas—, guardar los secretos en un gestor y escanear el código antes de cada push.

El servicio de metadatos y el SSRF: el caso Capital One

Cada máquina virtual en la nube puede consultar un servicio de metadatos interno que, entre otras cosas, entrega las credenciales temporales del rol asignado a la máquina. Si una aplicación de esa máquina es vulnerable a SSRF —es decir, se le puede pedir que haga peticiones a direcciones arbitrarias—, un atacante puede pedirle que consulte ese servicio y le devuelva las credenciales.

El caso más conocido es el de Capital One en 2019. Según la denuncia del Departamento de Justicia de Estados Unidos, una configuración errónea de un cortafuegos de aplicaciones web permitió enviar comandos a un servidor de la entidad; con uno de ellos la atacante obtuvo las credenciales de una cuenta denominada «…-WAF-Role», con otro listó más de 700 carpetas o buckets de almacenamiento y con un tercero copió los datos. La denuncia no usa términos como SSRF o servicio de metadatos, pero el patrón que describe —un servidor que ejecuta una petición del atacante y acaba entregando credenciales de un rol— es justo el que AWS quiso cortar cuando, en noviembre de 2019, presentó IMDSv2 como defensa adicional frente a cortafuegos abiertos, proxies inversos y vulnerabilidades SSRF. Capital One cifró los afectados en unos 100 millones de personas en Estados Unidos y unos 6 millones en Canadá, y en agosto de 2020 la OCC, el supervisor bancario estadounidense, le impuso una multa de 80 millones de dólares por no haber establecido procesos eficaces de evaluación de riesgos antes de migrar a la nube pública.

La cadena tiene tres eslabones, y romper cualquiera la corta:

Eslabón	Qué falló	Qué lo corta
La aplicación	Permite peticiones a destinos internos	Validar destinos, bloquear rangos internos y de metadatos
El servicio de metadatos	Entrega credenciales a una petición simple	IMDSv2, que exige un token de sesión obtenido con una petición PUT; límite de saltos para que no se alcance desde contenedores
El rol	Tiene permisos para listar y leer muchos buckets	Mínimo privilegio: el rol de un servidor web no necesita leer todos los datos

Desde marzo de 2024, AWS permite fijarlo como valor por defecto para las instancias nuevas de cada región de la cuenta. Las instancias antiguas, las imágenes heredadas y las plantillas de infraestructura copiadas de hace años siguen aceptando IMDSv1 si nadie lo cambia. En Azure y Google Cloud, el servicio de metadatos exige una cabecera específica en cada petición, lo que frena los SSRF más simples pero no sustituye a la validación de destinos en la aplicación.

Red abierta: puertos de administración y servicios expuestos

Los grupos de seguridad y las reglas de cortafuegos de la nube son fáciles de abrir y fáciles de olvidar. Los patrones que más se repiten:

SSH (22) o RDP (3389) abiertos a 0.0.0.0/0, a menudo «solo durante la migración».
Bases de datos, cachés y motores de búsqueda accesibles desde internet: bases de datos relacionales con acceso público, instancias de Redis, Elasticsearch o MongoDB sin autenticación.
Paneles de administración y APIs internas publicados detrás de un balanceador sin autenticación adicional.
Salida a internet sin restricciones desde todas las subredes, lo que facilita la exfiltración y la descarga de herramientas tras un compromiso.
Conectividad entre entornos más amplia de lo necesario: el entorno de desarrollo puede llegar a producción por un peering que nadie revisó.

La alternativa moderna a abrir puertos de administración es no abrirlos: servicios de acceso por sesión del propio proveedor, bastiones con acceso temporal o redes privadas con acceso por identidad. Y para los servicios que sí deben estar expuestos, un inventario de qué está publicado y por qué, contrastado periódicamente con lo que se ve desde fuera.

Registro y detección desactivados

Este error no abre la puerta a nadie, pero hace que todos los demás sean más graves: sin registros, no se detecta el ataque y, después, no se puede reconstruir qué pasó ni qué datos se vieron afectados, lo que complica también las obligaciones de notificación.

Proveedor	Qué hay por defecto	Qué suele faltar
AWS	CloudTrail ofrece un historial de 90 días de eventos de gestión por región	Un trail o almacén de eventos que guarde los registros a largo plazo, en todas las regiones y protegido frente a borrado; los eventos de acceso a datos de S3; GuardDuty activado
Google Cloud	Los registros de auditoría de actividad administrativa se escriben siempre	Los registros de acceso a datos, desactivados por defecto salvo en BigQuery
Azure	Registro de actividad de la suscripción	Enviarlo a un destino con retención suficiente y activar los registros de diagnóstico de cada recurso

Tener los registros tampoco basta. Hay que centralizarlos en una cuenta o proyecto al que los equipos de desarrollo no puedan escribir, generar alertas sobre los eventos que importan —creación de claves, cambios de políticas, desactivación del registro, accesos desde ubicaciones inusuales— y que alguien las revise. Una de las comprobaciones más reveladoras de un pentest cloud es ver si alguien reacciona mientras se enumeran permisos o se descargan datos.

Cómo detectarlos y evitar que vuelvan

Estos errores se encuentran con tres herramientas complementarias:

Una herramienta de postura (CSPM), nativa del proveedor o de código abierto como Prowler, que revisa de forma continua la configuración de todas las cuentas contra reglas como los CIS Benchmarks y avisa cuando algo cambia.
Guardarraíles preventivos: políticas de organización que impiden directamente las configuraciones peligrosas —acceso público, regiones no usadas, desactivar el registro— y escaneo de las plantillas de infraestructura como código antes del despliegue. Es mejor que un error no pueda llegar a producción que detectarlo después.
Un pentest cloud, que responde a la pregunta que las anteriores no responden: cuáles de estos errores, combinados entre sí y con la aplicación que corre encima, permiten a un atacante llegar a los datos o al control de la cuenta.

El orden importa. Corregir primero lo que detecta una herramienta de postura hace que el pentest se dedique a las cadenas y a la identidad, que es donde aporta más. Las diferencias entre ambos enfoques están en la comparativa entre CSPM y pentesting cloud.

FAQ

¿Cuál es el error de configuración cloud más peligroso?

Los permisos excesivos, porque determinan el alcance de todos los demás. Un bucket público expone lo que contiene; una identidad con permisos de administrador comprometida a través de una clave filtrada o de una aplicación vulnerable expone toda la cuenta. En la práctica, los incidentes graves suelen combinar varios errores.

Si AWS ya bloquea el acceso público por defecto, ¿por qué sigue habiendo buckets públicos?

Porque el cambio, aplicado desde abril de 2023, solo afecta a los buckets nuevos, se puede desactivar y no cubre otras formas de compartir, como las URLs prefirmadas de larga duración o los snapshots públicos. Lo recomendable es aplicar el bloqueo a nivel de cuenta u organización y revisar periódicamente las excepciones.

He subido una clave de AWS a GitHub: ¿qué hago?

Desactivarla y rotarla inmediatamente: borrar el commit no sirve, porque sigue en el historial y puede haber sido copiada en segundos. Después, revisar en CloudTrail qué se ha hecho con ella, buscar recursos o usuarios creados por terceros y comprobar si AWS ha aplicado su política de cuarentena y abierto un caso de soporte. Y sustituir esa clave de larga duración por credenciales temporales.

¿IMDSv2 evita los ataques SSRF?

No evita el SSRF, que es un fallo de la aplicación, pero frena el uso más dañino en AWS: robar las credenciales del rol a través del servicio de metadatos con una petición simple. Debe combinarse con la validación de destinos en la aplicación y con roles de mínimo privilegio, para que unas credenciales robadas den el menor acceso posible.

¿Estos errores son exclusivos de AWS?

No. Todos tienen su equivalente en Azure y Google Cloud: contenedores de almacenamiento con acceso anónimo, roles de propietario asignados de más, secretos de entidades de servicio o claves de cuentas de servicio en repositorios, servicios de metadatos accesibles desde aplicaciones vulnerables y registros de acceso a datos sin activar.

¿Cómo sé cuáles de estos errores tengo en mi cuenta?

Un primer barrido con la herramienta de postura nativa del proveedor o con Prowler muestra la mayoría en pocas horas. Para saber cuáles son realmente explotables y cómo se encadenan con tus aplicaciones e identidades, hace falta un pentest cloud con supuestos realistas de partida.