Un ataque nube rara vez empieza forzando una puerta: empieza con una credencial mal guardada o un bucket mal configurado. La cloud security en 2026 ya no es un lujo de departamento IT grande, es supervivencia básica para cualquier empresa que use AWS, Azure o Google Cloud. Este año hemos visto un aumento notable en incidentes de hackeo AWS, fallos de seguridad Azure mal parcheados y casos de vulnerabilidad cloud que empiezan con algo tan tonto como una API key olvidada en un repositorio público. MataSpam filtra spam, no configura permisos IAM, pero si algo aprendimos filtrando millones de correos maliciosos es que el atacante siempre busca el camino de menor resistencia. Y en la nube, ese camino suele estar abierto de par en par.
Buckets S3 y storage mal configurado: el clásico que nunca pasa de moda
El error más viejo del mundo cloud sigue siendo el más rentable para los atacantes. Un bucket de Amazon S3 con permisos públicos, un contenedor de Azure Blob Storage sin autenticación, o un bucket de Google Cloud Storage abierto a "cualquiera con el enlace". Empresas de todos los tamaños han filtrado datos de clientes, backups completos de bases de datos y hasta código fuente por este motivo.
La causa casi siempre es humana: alguien crea el bucket para "probar algo rápido", lo deja público para no complicarse con permisos, y se olvida de cerrarlo. Meses después, un escáner automatizado lo encuentra en cuestión de minutos. Herramientas como VirusTotal sirven para analizar archivos sospechosos, pero para buckets expuestos existen escáneres específicos (GrayhatWarfare, S3Scanner) que los bad actors usan a diario, de forma automatizada y a escala global.
Qué hacer:
- Bloquear el acceso público por defecto a nivel de cuenta, no solo por bucket
- Activar el cifrado en reposo (SSE-S3, SSE-KMS o equivalente en Azure/GCP)
- Revisar periódicamente con herramientas de auditoría propias del proveedor (AWS Trusted Advisor, Azure Security Center, Google Security Command Center)
- Nunca subir credenciales, tokens ni claves privadas dentro del propio bucket "por comodidad"
Credenciales robadas y claves API filtradas en GitHub
Si hay un patrón que se repite en casi todos los incidentes graves de hackeo AWS es este: una clave de acceso (Access Key ID + Secret Access Key) acaba publicada en un repositorio de GitHub, un fichero de configuración de Docker, o un script olvidado en un servidor de pruebas. Los bots que escanean GitHub en busca de patrones tipo AKIA... tardan minutos, no días, en encontrarla y empezar a usarla.
Una vez dentro, el atacante no siempre roba datos directamente. Muchas veces lanza instancias de cómputo masivo para minar criptomonedas a costa de la factura de la víctima, algo que ha generado facturas sorpresa de miles de euros en cuentas de startups que ni se habían dado cuenta del problema hasta recibir el aviso de facturación.
El paralelismo con el phishing tradicional es directo: igual que en el phishing de Microsoft 365 contra empresas, aquí el objetivo es una credencial válida que abre la puerta sin necesidad de "romper" nada técnicamente. La diferencia es que en la nube esa puerta suele dar acceso a infraestructura completa, no solo a un buzón de correo.
Medidas básicas:
- Nunca hardcodear credenciales en el código: usar gestores de secretos (AWS Secrets Manager, Azure Key Vault, Google Secret Manager)
- Activar MFA obligatorio para cuentas con permisos de administrador
- Rotar claves de acceso periódicamente y revocar las que no se usan
- Configurar alertas de gasto anómalo (billing alerts) para detectar minería de criptomonedas no autorizada
Configuración de IAM y el problema del exceso de permisos
La gestión de identidad y acceso (IAM) es, según estimaciones del sector de seguridad para 2026, la causa raíz de la mayoría de brechas en entornos cloud, por encima incluso de vulnerabilidades técnicas puras. El motivo es sencillo: es mucho más fácil dar permisos de más "para que funcione" que auditar exactamente qué necesita cada usuario o servicio.
El resultado típico es una cuenta de servicio con permisos de administrador total, usada solo para una tarea puntual, que un atacante que compromete ese servicio puede aprovechar para moverse lateralmente por toda la infraestructura. Este patrón de "movimiento lateral" es el que convierte un incidente pequeño en una brecha catastrófica.
Buenas prácticas de IAM:
| Principio | Qué significa en la práctica |
|---|---|
| Mínimo privilegio | Cada usuario o servicio solo tiene los permisos estrictamente necesarios |
| Revisión periódica | Auditar cada trimestre quién tiene acceso a qué |
| Roles temporales | Usar credenciales con caducidad en lugar de accesos permanentes |
| Separación de entornos | Producción y desarrollo nunca comparten las mismas credenciales |
Ransomware y cifrado de datos en entornos cloud híbridos
El ransomware ya no se limita a servidores locales. Los grupos criminales han adaptado sus técnicas para atacar snapshots de máquinas virtuales, bases de datos gestionadas y backups almacenados en la nube. Si el atacante consigue permisos suficientes, puede cifrar no solo los datos en producción sino también las copias de seguridad, dejando a la empresa sin manera de recuperarse sin pagar el rescate.
Este tipo de vulnerabilidad cloud se combina a menudo con técnicas de exfiltración previa: antes de cifrar, el atacante copia los datos y amenaza con publicarlos si no se paga (doble extorsión). Es una evolución directa de las tácticas que ya vemos en otros vectores, como explica nuestro análisis sobre las diferencias de seguridad entre iOS y Android frente al malware.
Prevención práctica:
- Backups inmutables (write once, read many) que ni un administrador comprometido pueda borrar
- Backups en una cuenta o proyecto cloud separado, con credenciales distintas
- Monitorización de actividad anómala (borrado masivo de snapshots, cifrado inusual de volúmenes)
- Plan de recuperación probado, no solo documentado
Vulnerabilidades específicas: contenedores, Kubernetes y APIs expuestas
Más allá del error humano, existen vulnerabilidades técnicas reales. Los clústeres de Kubernetes mal configurados, con el panel de administración (dashboard) expuesto sin autenticación, han sido el origen de múltiples incidentes documentados por investigadores de seguridad. Lo mismo pasa con APIs REST expuestas sin límites de tasa (rate limiting) ni validación adecuada, que permiten ataques de enumeración o denegación de servicio.
Los tres grandes proveedores publican boletines de seguridad (CVE) de forma regular. Mantenerse al día no es opcional: una vulnerabilidad conocida y sin parchear en una imagen de contenedor es, básicamente, una invitación abierta. Herramientas como Trivy, Clair o el propio escáner de imágenes de cada proveedor ayudan a detectar estas brechas antes de desplegar.
Para equipos que gestionan infraestructura propia además de la cloud, conviene revisar también la seguridad de los equipos Mac que dan acceso a esa infraestructura, porque un endpoint comprometido es a menudo el primer paso hacia la cuenta cloud.
Preguntas frecuentes
¿Cómo sé si mi cuenta de AWS, Azure o Google Cloud ha sido hackeada?
Las señales más claras son un aumento repentino de la factura sin actividad justificada, instancias de cómputo que no reconoces, alertas de inicio de sesión desde ubicaciones inusuales o cambios en la configuración de IAM que nadie del equipo hizo. Revisa los logs de CloudTrail (AWS), Activity Log (Azure) o Cloud Audit Logs (GCP) en cuanto sospeches algo.
¿Es más seguro AWS, Azure o Google Cloud?
Ninguno de los tres es intrínsecamente más seguro: la mayoría de brechas vienen de configuraciones erróneas del cliente, no de fallos del proveedor. El modelo de responsabilidad compartida significa que el proveedor asegura la infraestructura, pero tú eres responsable de cómo la configuras.
¿Qué es el "modelo de responsabilidad compartida" en la nube?
Es el reparto de obligaciones de seguridad entre el proveedor cloud y el cliente. El proveedor protege el hardware, la red física y la capa de virtualización; el cliente es responsable de la configuración de permisos, el cifrado de datos y la gestión de accesos. La mayoría de incidentes ocurren precisamente en esa parte que le toca al cliente.
¿Un ataque a la nube afecta al RGPD?
Sí, si hay datos personales implicados. Una filtración de datos en un bucket mal configurado o por credenciales robadas puede obligar a notificar a la Agencia Española de Protección de Datos en un plazo de 72 horas, según el Reglamento General de Protección de Datos de la UE. Las sanciones por no notificar a tiempo se suman a las del propio incidente.
¿Necesito un experto en ciberseguridad para asegurar mi infraestructura cloud?
Para configuraciones básicas, la documentación oficial de cada proveedor y las herramientas de auditoría integradas (AWS Trusted Advisor, Azure Secure Score, Google Security Command Center) cubren bastante terreno. Para infraestructuras críticas o empresas con datos sensibles, contar con alguien especializado en detectar patrones de ataque y hardening cloud reduce el riesgo de forma notable.
El siguiente paso
Entra ahora mismo en la consola de tu proveedor cloud (AWS, Azure o Google Cloud) y revisa si tienes algún bucket o contenedor de almacenamiento con acceso público activado. Es la comprobación más rápida y la que más incidentes evita.
