Superficie de ataque en la nube

En la nube, el proveedor protege la infraestructura, mientras que el cliente protege la configuración, la identidad y los datos. La mayoría de las brechas se producen en el lado del cliente de esta separación.

• El proveedor aplica parches a los hipervisores y se encarga de la seguridad física.
• El cliente es responsable de las políticas de IAM, los permisos de almacenamiento y las reglas de red.
• El riesgo predominante es la configuración incorrecta, no el compromiso del proveedor.

La nube no tiene un perímetro de red tradicional. El acceso se rige por IAM: usuarios, roles, políticas y claves. Una clave de acceso filtrada puede ser tan dañina como una contraseña de administrador de dominio robada.

• Las políticas de IAM conceden acciones sobre los recursos.
• Los roles permiten que los servicios y los usuarios asuman credenciales temporales.
• Las identidades con permisos excesivos son el principal vector de escalada.

Las credenciales de la nube se filtran constantemente. Entre las fuentes habituales se incluyen:

• Claves de acceso confirmadas en repositorios públicos de Git.
• Claves codificadas directamente en aplicaciones móviles, registros de CI o imágenes de contenedores.
• Server-Side Request Forgery (SSRF) que alcanza el servicio de metadatos.
• Uso compartido excesivamente amplio de claves de larga duración en lugar de roles de corta duración.

Cada instancia en la nube expone un endpoint de metadatos que puede proporcionar credenciales temporales de rol. Un SSRF o RCE en una VM que pueda acceder a él suele permitir obtener el rol de la instancia.

• AWS IMDS está disponible en 169.254.169.254.
• IMDSv1 solo admite solicitudes y se puede aprovechar fácilmente mediante SSRF.
• IMDSv2 requiere un token de sesión (PUT y luego GET), lo que mitiga muchos ataques SSRF.

El almacenamiento de objetos (S3, GCS, Azure Blob) es una fuente recurrente de exposición de datos.

• Los buckets con lectura pública pueden filtrar archivos confidenciales.
• Los buckets con escritura pública permiten realizar modificaciones o alojar malware.
• Las políticas de buckets o las ACL demasiado permisivas conceden acceso a usuarios autenticados.
• Las URL prefirmadas con una caducidad prolongada permiten un acceso persistente.

Los controles de red de la nube (Security Groups, NSG y reglas de firewall) se pueden configurar fácilmente de forma demasiado permisiva.

• Bases de datos o puertos de administración expuestos a 0.0.0.0/0.
• Planos de administración (API de Kubernetes, RDP y SSH) accesibles desde Internet.
• Servicios internos que confían implícitamente en la VPC y no requieren autenticación.

El modelo serverless cambia los riesgos, pero no los elimina. Las funciones, las colas y las bases de datos administradas tienen cada una una identidad de ejecución.

• El rol de ejecución de una Lambda puede tener permisos excesivos.
• Las variables de entorno suelen contener secretos que se pueden leer tras un compromiso.
• Una configuración incorrecta de la fuente de eventos puede permitir que entradas no confiables activen funciones privilegiadas.

Distinga las dos superficies de ataque:

• Plano de control: la API de la nube (crear recursos, modificar IAM y leer configuraciones). Comprometerlo afecta a toda la cuenta.
• Plano de datos: las propias cargas de trabajo (aplicaciones, VM y contenedores).

Obtener credenciales del plano de control desde un punto de apoyo en el plano de datos es la escalada clásica en la nube.

Las organizaciones grandes dividen las cargas de trabajo entre muchas cuentas, suscripciones y proyectos.

• Los roles entre cuentas con políticas de confianza débiles permiten pivotar.
• Un confused deputy en un rol de integración de terceros puede aprovecharse.
• Los roles a nivel de organización (por ejemplo, OrganizationAccountAccessRole) tienen un gran valor.

Los defensores dependen de los registros nativos de la nube. Los atacantes intentan dejarlos ciegos.

• CloudTrail / Activity Log / Audit Logs registran las llamadas al plano de control.
• Los atacantes pueden deshabilitar los trails o detener la entrega de registros.
• GuardDuty / Security Command Center / Defender detectan anomalías.

Deshabilitar el registro es en sí mismo un evento muy indicativo que merece generar una alerta.

Las pruebas de penetración en la nube requieren conocer las políticas del proveedor y contar con autorización. Algunas acciones (como la denegación de servicio o determinados escaneos) infringen las condiciones del proveedor. Confirme siempre la titularidad de la cuenta, acuerde el alcance del impacto y prefiera comenzar con una enumeración de solo lectura.

Utilice una cuenta de pruebas dedicada o recursos claramente etiquetados, y no toque nunca recursos que estén fuera del alcance documentado.

Confirme que comprende la superficie de ataque en la nube.

Ha trazado la superficie de ataque en la nube.

• Las configuraciones incorrectas por parte del cliente son el principal riesgo de la nube.
• La identidad es el perímetro; las claves y los roles filtrados son vectores fundamentales.
• El servicio de metadatos conecta los errores del plano de datos con las credenciales de la nube.
• Las configuraciones incorrectas del almacenamiento, la red y el registro completan la superficie.

A continuación: enumerar los recursos de la nube para encontrar estos problemas.