AWS, Azure y GCP: las vulnerabilidades de la nube que ningún proveedor le cuenta

Cada vez que un proveedor de nube sufre una brecha, el titular dice que "la nube fue hackeada". Casi nunca es verdad. La infraestructura de AWS, Azure y GCP es objetivamente más segura que la mayoría de centros de datos privados: tienen equipos de seguridad de cientos de personas, certificaciones de cumplimiento exhaustivas y sistemas de detección de intrusiones que operan a escala casi imposible de replicar.

El problema es diferente, y el modelo de responsabilidad compartida lo explica claramente: el proveedor asegura la infraestructura. Usted asegura todo lo que construye sobre ella. Y en esa responsabilidad del cliente es donde ocurren prácticamente todas las brechas reales.

En este penúltimo artículo de la serie, analizamos los patrones de vulnerabilidad que se repiten en AWS, Azure y GCP independientemente del proveedor. Son los mismos porque reflejan errores humanos y de proceso, no fallas del proveedor.

IAM: el problema universal de la nube

El Identity and Access Management (IAM) es el sistema nervioso de cualquier plataforma cloud. Define quién puede hacer qué en cuáles recursos. Y es, consistentemente, la fuente número uno de vulnerabilidades cloud según los informes de Gartner, Verizon DBIR y los propios proveedores.

El patrón que se repite sin importar el proveedor:

• Políticas demasiado permisivas: En AWS, roles con "Action": "*", "Resource": "*". En GCP, Service Accounts con el rol Owner a nivel de proyecto. En Azure, service principals con Contributor en toda la suscripción. Son el equivalente cloud de darle a cada empleado llave maestra de todas las instalaciones de la empresa.
• Access keys/credentials estáticas sin rotación: Las credenciales de largo plazo son un objetivo prioritario. Una AWS Access Key publicada accidentalmente en GitHub es detectada por bots automatizados en segundos —herramientas como truffleHog y GitLeaks escanean repositorios públicos en tiempo real buscando exactamente esto.
• Sin MFA para usuarios con acceso a consola: El mismo problema que en M365, pero en la consola de AWS o GCP. Un usuario IAM con contraseña pero sin MFA es una credencial comprometida esperando su momento.

# AWS: identificar políticas de IAM con acceso total
aws iam list-policies --scope Local |   jq '.Policies[].PolicyName' |   xargs -I {} aws iam get-policy-version     --policy-arn "arn:aws:iam::ACCOUNT:policy/{}"     --version-id v1 |   jq 'select(.PolicyVersion.Document.Statement[].Action=="*")'

## GCP: listar Service Accounts con roles primitivos (Owner/Editor)
gcloud projects get-iam-policy PROJECT_ID   --format="table(bindings.role, bindings.members)" |   grep -E "roles/owner|roles/editor"

SSRF: el ataque que explota la confianza interna

Server-Side Request Forgery (SSRF) es una vulnerabilidad de aplicación web que, en el contexto de la nube, tiene consecuencias devastadoras. Cuando una aplicación en la nube permite que un usuario externo dicte a qué URL interna debe conectarse el servidor, un atacante puede forzarla a consultar el metadata endpoint del proveedor cloud.

Todos los proveedores tienen este endpoint en la misma dirección IP:

http://169.254.169.254/latest/meta-data/    # AWS
http://169.254.169.254/metadata/instance    # Azure
http://metadata.google.internal/            # GCP

Este endpoint proporciona credenciales temporales del rol IAM asociado a la instancia. Si la aplicación vulnerable tiene un rol con permisos amplios, el atacante puede usar esas credenciales para acceder a cualquier recurso del proveedor cloud al que tenga acceso ese rol.

La brecha de Capital One en 2019 —que expuso datos de 100 millones de clientes y costó más de 80 millones de dólares en multas— fue esencialmente un ataque SSRF combinado con un rol IAM sobreasignado. La técnica no cambió desde entonces; la frecuencia de ocurrencia tampoco.

Mitigación: AWS IMDSv2 (Metadata Service versión 2) requiere un token de sesión que el payload SSRF básico no puede obtener, bloqueando el ataque. Azure IMDS tiene protecciones similares. Asegúrese de que sus instancias usen la versión más reciente del servicio de metadata y que los roles asociados sigan el principio de mínimo privilegio.

Storage mal configurado: el problema que no aprende

Los buckets de S3 en AWS, los blobs de Azure Storage y los buckets de GCP Cloud Storage son recursos convenientes y escalables para almacenar datos. También son uno de los orígenes más frecuentes de exposición de datos sensibles.

A pesar de años de cobertura mediática, notificaciones de los proveedores y multas regulatorias, los estudios de 2024 muestran que un porcentaje significativo de buckets de S3 con contenido sensible siguen siendo accesibles públicamente. La razón es casi siempre la misma: alguien habilitó acceso público temporalmente para hacer una prueba o facilitar un acceso externo, y nunca lo revirtió.

• AWS: S3 Block Public Access a nivel de cuenta es la configuración más importante que puede hacer. Una sola configuración a nivel de cuenta previene que cualquier bucket en esa cuenta sea accesible públicamente, independientemente de las configuraciones de buckets individuales.
• GCP: Uniform Bucket-Level Access previene que listas de control de acceso (ACL) individuales anulen la política del bucket.
• Azure: Como vimos en el artículo anterior, allowBlobPublicAccess: false a nivel de Storage Account.

Kubernetes: el nuevo perímetro de ataque

Kubernetes se convirtió en el estándar de facto para orquestación de contenedores. Su API server es el componente central que controla todo el cluster: puede crear pods, leer secrets, modificar deployments, ejecutar comandos en cualquier contenedor.

Las misconfiguraciones más peligrosas en Kubernetes cloud (EKS, AKS, GKE):

• API server expuesto sin autenticación: Kubernetes tiene un modo de acceso anónimo que en clusters mal configurados permite a cualquier persona en Internet ejecutar comandos en el cluster. Herramientas como kube-hunter escanean activamente Internet buscando API servers expuestos.
• Pods en modo privilegiado: Como mencionamos en el artículo sobre Linux, un pod privilegiado puede escapar al nodo host.
• Secrets de Kubernetes como variables de entorno: Los Secrets de Kubernetes no están cifrados por defecto en etcd. Si un atacante obtiene acceso de lectura al API server, puede listar todos los secrets del cluster.
• Sin Network Policies: Por defecto, todos los pods en un cluster Kubernetes pueden comunicarse entre sí. Sin Network Policies, si un pod es comprometido, el atacante puede moverse lateralmente hacia cualquier otro pod en el cluster.

Secretos en repositorios de código: el error más costoso

El patrón más común que lleva a compromisos de cuentas cloud no es una técnica sofisticada de hacking: es encontrar credenciales en un repositorio de código. AWS Access Keys, tokens de GCP, connection strings de Azure, API keys de servicios de terceros.

Los desarrolladores comprometidos por tiempo hardcodean credenciales "temporalmente" que permanecen en el historial de git para siempre, incluso si se elimina el archivo en un commit posterior. Los repositorios públicos de GitHub son escaneados automáticamente por herramientas de threat intelligence y por los propios proveedores cloud (GitHub Secret Scanning).

Controles fundamentales:

• Pre-commit hooks con truffleHog o detect-secrets que bloquean commits con secretos antes de que lleguen al repositorio.
• Rotación inmediata de cualquier credencial que haya tocado un repositorio, incluso privado.
• Uso de servicios de gestión de secretos nativos: AWS Secrets Manager, Azure Key Vault, GCP Secret Manager.
• Preferencia por Managed Identities/Instance Profiles sobre credenciales estáticas en todos los entornos cloud.

CSPM: visibilidad continua sobre la postura cloud

Cloud Security Posture Management (CSPM) es la categoría de herramientas diseñada para hacer exactamente lo que acabamos de describir: monitoreo continuo de configuraciones cloud contra benchmarks de seguridad (CIS Benchmarks, NIST, SOC 2).

Cada proveedor ofrece su versión nativa: Microsoft Defender for Cloud, AWS Security Hub con AWS Config, Google Security Command Center. Las organizaciones multi-cloud frecuentemente optan por soluciones independientes como Wiz, Orca Security o Prisma Cloud, que cubren los tres proveedores en una sola plataforma.

Lo fundamental: sin visibilidad continua sobre las configuraciones cloud, los errores que describimos en este artículo pueden existir durante meses sin que nadie lo sepa. Un CSPM los detecta en minutos.

En el artículo final de esta serie integramos todo: cómo crear un programa de gestión de vulnerabilidades que cubra simultáneamente Windows, M365, Azure, Linux, macOS y la nube. Un programa que tenga sentido para una PYME con recursos limitados y que produzca mejoras reales y medibles.

Si su empresa usa servicios cloud y no tiene visibilidad de su postura de seguridad actual, el diagnóstico gratuito de Structa Defense incluye revisión de configuraciones en los principales proveedores cloud con informe de hallazgos priorizados.