Pentest en la nube y auditoría de seguridad de AWS, Azure y Google Cloud: qué se revisa y qué preparar

Una revisión de seguridad de AWS, Azure o Google Cloud busca lo que expone tus datos sin que nadie rompa al proveedor: permisos de IAM de más, almacenamiento público, claves en el código, puertos abiertos, registros desactivados, ajustes débiles de Kubernetes y de los pipelines de CI/CD. Hay dos formatos: una auditoría de configuración con un rol de solo lectura frente a los CIS Benchmarks y un pentest que comprueba si esos puntos débiles se pueden aprovechar de verdad.

Abajo explico de qué responde el proveedor y de qué respondes tú, qué se mira en cada área, en qué se diferencia una auditoría de un pentest, qué reglas de pruebas aplican AWS, Microsoft Azure y Google Cloud a octubre de 2026, qué preparar y qué recibes. La preparación general para cualquier prueba está en cómo prepararse para un pentest.

En resumen

• El proveedor protege la nube en sí, tú proteges lo que configuras en ella. Los datos, las cuentas, los permisos y la configuración siempre son tuyos. ^{[5] [6]}
• Una auditoría de configuración compara los ajustes con los CIS Benchmarks mediante un rol de solo lectura y no cambia nada. Un pentest en la nube comprueba de forma activa hasta dónde llega un atacante desde el acceso público o desde una sola clave robada.
• Los hallazgos más comunes son permisos de más, almacenamiento público, claves de larga duración en el código y en los pipelines, puertos de administración abiertos y registros que nadie guarda más allá de los plazos por defecto.
• Aprobación del proveedor. AWS, Azure y Google Cloud no exigen aprobación previa para probar tus propios recursos, pero los tres prohíben el DoS. AWS exige una solicitud aparte con al menos dos semanas de antelación para simulaciones encubiertas de ataque, servidores de mando y control (C2) y simulaciones de phishing. ^{[1] [2] [4]}
• Lo que aportas tú: un rol de solo lectura, la lista de cuentas, suscripciones o proyectos y un contacto que pueda parar la prueba.

Qué se revisa en la nube: tabla

Responsabilidad compartida: qué es tuyo y qué del proveedor

AWS lo formula así: el proveedor responde de la seguridad de la nube, es decir, hardware, red y centros de datos, y el cliente de la seguridad en la nube. Del lado del cliente están el sistema operativo de las máquinas virtuales, los datos y su cifrado, los permisos de IAM y la configuración del grupo de seguridad (firewall) de cada instancia. ^[5]

La matriz de responsabilidades de Microsoft dice claramente que en cualquier modelo, desde máquinas virtuales hasta servicios listos para usar, el cliente conserva los datos, las cuentas, la gestión de accesos y la configuración. ^[6]

La conclusión práctica es sencilla: la mayoría de los incidentes en la nube no empiezan con un ataque al proveedor, sino con un ajuste del cliente. Un bucket público o una clave de administrador en un repositorio no los va a arreglar el proveedor por ti.

Auditoría de configuración y pentest en la nube: la diferencia

Una auditoría de configuración (configuration review) mira los ajustes desde dentro con un rol de solo lectura. La referencia habitual son los CIS Benchmarks: recomendaciones de configuración segura de la comunidad del Center for Internet Security, gratuitas para uso no comercial. Hay documentos separados para AWS Foundations, Microsoft Azure Foundations, Google Cloud Platform Foundation, Kubernetes, y también para EKS, AKS y GKE. ^[7] La auditoría es rápida, no rompe nada y da la imagen completa de la configuración, pero no responde a la pregunta "qué de todo esto se puede explotar de verdad".

Un pentest en la nube comprueba cadenas. Por ejemplo: una función pública devuelve un error con una clave de acceso, la clave permite leer el almacenamiento, y en el almacenamiento hay una copia de la base de datos. El pentester trabaja desde dos posiciones: desde fuera, como cualquiera en internet, y desde un punto de entrada acordado, por ejemplo con las credenciales de un desarrollador normal o de un servidor comprometido. Así se ve hasta dónde llega un atacante si ya se ha filtrado una clave.

Para una primera revisión suele bastar la auditoría de configuración: encuentra los problemas más comunes al menor coste. El pentest tiene sentido cuando la configuración básica ya está en orden o cuando en la nube vive un producto con datos de clientes. A menudo se combinan: auditoría de todo el entorno y pentest de las aplicaciones críticas. Más sobre revisión automática frente a prueba manual en pentest o escaneo de vulnerabilidades.

1. IAM y permisos de más

IAM (gestión de identidades y accesos) es la principal zona de riesgo en cualquier nube. Se mira:

• quién tiene permisos de administrador: Owner en Azure, Owner o Editor en Google Cloud, AdministratorAccess en AWS;
• roles y políticas que permiten cualquier acción sobre cualquier recurso;
• usuarios, roles y claves de acceso sin uso;
• MFA para las personas y protección de la cuenta root de AWS;
• quién puede subirse los permisos a sí mismo, por ejemplo creando una política nueva o asignándose un rol.

AWS recomienda que las personas entren mediante inicio de sesión único con credenciales temporales y que las cargas de trabajo usen roles en lugar de claves de larga duración. Los roles, permisos y claves sin uso conviene detectarlos con regularidad por los datos de último uso y eliminarlos. ^[8]

2. Almacenamiento público

Un almacenamiento abierto "a todos" sigue siendo una de las formas más fáciles de perder datos. En AWS los buckets S3 nuevos bloquean el acceso público por defecto, pero una política del bucket o una ACL pueden abrirlo. Por eso se comprueba si S3 Block Public Access está activado para toda la cuenta y no solo para algunos buckets. ^[9] En Azure se revisa el acceso anónimo a los contenedores de Blob Storage y los enlaces SAS (enlaces temporales con permisos) con caducidad larga. En Google Cloud se buscan buckets con acceso para allUsers o allAuthenticatedUsers.

También se revisa lo contrario: si tu dominio apunta a un bucket o servicio eliminado. Un registro DNS así permite que otra cuenta ocupe el nombre y sirva contenido en tu nombre. Durante la prueba ese registro solo se documenta: AWS prohíbe apropiarse de verdad del bucket o del subdominio. ^[1]

3. Claves y secretos

Una clave de acceso a la nube en un repositorio, en una imagen Docker, en las variables de entorno de una función o en un log de compilación equivale a una contraseña de administrador. Se revisa:

• el historial de Git, no solo el código actual: una clave borrada sigue en commits antiguos;
• las variables de entorno de funciones y contenedores;
• los secretos en los almacenes de claves (AWS Secrets Manager, Azure Key Vault, Google Secret Manager) y quién puede leerlos;
• la antigüedad de las claves de acceso y si alguien las ha rotado alguna vez.

Una clave encontrada no se usa para entrar en sistemas ajenos. Las reglas de Microsoft prohíben expresamente usar credenciales que no son tuyas, aunque se hayan filtrado públicamente. ^[3]

4. Red y grupos de seguridad

Los grupos de seguridad en AWS, los NSG (grupos de seguridad de red) en Azure y las reglas de firewall de VPC en Google Cloud deciden qué es accesible desde internet. Hallazgos típicos: SSH (puerto 22), RDP (3389) o el puerto de una base de datos abiertos a todo internet, servidores de prueba olvidados con dirección pública, bases de datos con acceso público. Un buen resultado: la administración de servidores pasa por un bastión, una VPN o un servicio del proveedor como AWS Systems Manager, Azure Bastion o IAP en Google Cloud, y desde internet solo están abiertos los puertos web de los servicios que deben ser públicos.

Un escaneo externo de tus direcciones públicas muestra lo mismo desde el lado del atacante. Los tres proveedores lo permiten sobre tus propios recursos. ^{[1] [2] [4]}

5. Registros y monitorización

Sin registros, tras un incidente nadie puede decir quién cambió qué ni qué se llevó. Lo que tienes por defecto:

• AWS CloudTrail. El historial de eventos está activado automáticamente, pero solo guarda 90 días de eventos de administración por región y no muestra eventos de acceso a datos. Para guardar más hace falta un trail o un almacén de eventos. ^[10]
• Azure Activity Log. Se recoge sin configurar nada, pero se guarda 90 días. Más tiempo solo con una configuración de diagnóstico que lo exporte a Log Analytics o a un almacenamiento. Los registros de acciones dentro de los recursos (por ejemplo, leer un secreto de Key Vault) no se recogen por defecto. ^[11]
• Google Cloud Audit Logs. Los registros de actividad administrativa se escriben siempre y no se pueden desactivar. Los de acceso a datos, salvo BigQuery, están desactivados por defecto. ^[12] Los registros administrativos se guardan 400 días, el resto 30 días por defecto. ^[13]

También se comprueba si los registros de todas las cuentas, suscripciones o proyectos se reúnen en un solo sitio, si están protegidos contra borrado y si hay alertas para eventos críticos: entrada con root, cambios de políticas, desactivación del registro.

6. Kubernetes y servicios gestionados

En EKS, AKS y GKE se revisa lo básico: si la API del clúster es accesible desde todo internet, cómo están los permisos dentro del clúster (RBAC), si los pods tienen permisos que llevan a la cuenta de la nube y si la versión del clúster está al día. Para esto también hay CIS Benchmarks propios. ^[7] En bases de datos gestionadas, funciones y colas se revisan el acceso público, el cifrado y los permisos de las cuentas de servicio con las que funcionan.

7. CI/CD y accesos del pipeline

El pipeline de compilación y despliegue suele tener más permisos que cualquier persona del equipo. Si en los secretos de GitHub Actions, GitLab CI o Azure DevOps hay una clave de administrador de larga duración, quien pueda modificar el archivo del pipeline obtiene esa clave. Mejor opción: el acceso mediante OIDC, en el que el proveedor emite un token corto válido para un solo trabajo y en GitHub no se guarda ninguna clave de la nube. Lo admiten AWS, Azure y Google Cloud. ^[14] También se revisa quién puede cambiar el pipeline y si el despliegue a producción está limitado a ramas concretas.

Reglas de AWS, Azure y Google Cloud para el pentest

A octubre de 2026:

• AWS. No hace falta aprobación previa para los servicios de la lista permitida, entre ellos EC2, RDS, Aurora, CloudFront, API Gateway, Lambda, Lightsail, Elastic Beanstalk, ECS y Fargate. Para otros servicios se contacta con el soporte de AWS. Están prohibidos el DoS y el DDoS, también simulados, la inundación de puertos, protocolos y peticiones, el recorrido de zonas DNS en Route 53 y la apropiación de buckets S3 y subdominios. Las simulaciones encubiertas de ataque, los servidores de mando y control (C2), las simulaciones de phishing y las pruebas con malware requieren una solicitud aparte con al menos dos semanas de antelación. ^[1]
• Microsoft Azure. No se exige aprobación previa desde el 15 de junio de 2017, pero se aplican las Microsoft Cloud Unified Penetration Testing Rules of Engagement. Están prohibidos el DoS de cualquier tipo, el acceso a tenants y almacenamientos ajenos, el uso de credenciales que no son tuyas, el fuzzing con tráfico excesivo, el phishing a empleados de Microsoft o a terceros a través de servicios de Microsoft y las acciones posteriores a la explotación contra los propios servicios de Microsoft. La resistencia a DDoS se puede probar con los socios que recomienda Microsoft. ^{[2] [3]}
• Google Cloud. No hace falta avisar a Google. La prueba debe afectar solo a tus proyectos y cumplir la Política de uso aceptable y las Condiciones del servicio de Google Cloud. ^[4]

Las tres normas se refieren a la infraestructura del proveedor. El permiso para probar tus recursos no lo da el proveedor, lo das tú: por escrito, con alcance y contactos. Las reglas cambian, así que antes de empezar abre las páginas actuales enlazadas en las fuentes.

Qué necesitamos de ti

• Alcance. La lista de cuentas de AWS, suscripciones de Azure o proyectos de Google Cloud, regiones y entornos. Aparte, qué queda fuera: servicios SaaS de terceros, cuentas de socios.
• Un rol de solo lectura. En AWS suelen ser las políticas gestionadas SecurityAudit y ViewOnlyAccess, en Azure los roles Reader y Security Reader a nivel de suscripción o de grupo de administración, en Google Cloud los roles Viewer y Security Reviewer a nivel de organización o de proyecto. Se concede durante la revisión y se retira después.
• Para un pentest. La lista de direcciones públicas y dominios, un punto de entrada acordado (por ejemplo, una cuenta con nivel de desarrollador) y lo que está prohibido: cambiar datos, borrar recursos, probar en horario laboral.
• Una descripción de la arquitectura. Aunque sea un esquema sencillo: dónde corre la aplicación, dónde están las bases de datos, cómo se despliega.
• Contactos. Quién recibe los avisos urgentes y quién puede parar la prueba.
• Autorización escrita. La firma alguien con autoridad para dar acceso a las cuentas de nube de la empresa.

La checklist completa de preparación con una tabla de responsables está en cómo prepararse para un pentest.

Qué recibes

• Un resumen breve para la dirección: qué se encontró, qué riesgo supone para el negocio, qué arreglar primero.
• Cada hallazgo por separado: en qué cuenta o proyecto, en qué recurso, prueba, impacto, gravedad y cómo corregirlo, con referencia al punto de los CIS Benchmarks o a la guía del proveedor cuando corresponde.
• En un pentest: las rutas de ataque descritas paso a paso desde el punto de entrada hasta los datos.
• La lista de lo revisado y lo no revisado, para que nadie dé por segura una cuenta que nadie miró.
• Aviso inmediato de lo crítico, por ejemplo un bucket público con datos personales, sin esperar al informe.
• Un retest (segunda comprobación tras las correcciones), si forma parte del alcance acordado.

Qué hacer después con el informe se explica en qué hacer después de un pentest. Una imagen más amplia de la seguridad de la empresa, de los procesos a los accesos, la da una Security Assessment.

Checklist antes de revisar la nube

• Están listadas todas las cuentas, suscripciones y proyectos, también los de prueba.
• Se ha concedido un rol de solo lectura durante la revisión.
• La cuenta root de AWS y todos los administradores tienen MFA.
• S3 Block Public Access está activado a nivel de cuenta, todo almacenamiento público está justificado.
• Se ha comprobado que no hay claves de nube de larga duración en repositorios y pipelines.
• SSH, RDP y las bases de datos no están abiertos a todo internet.
• Los registros de todas las cuentas se guardan más de los 90 días por defecto en un sitio protegido.
• La API de los clústeres de Kubernetes no es accesible desde todo internet sin necesidad.
• Se han revisado las reglas de pruebas actuales de tu proveedor.
• La autorización está firmada y hay un contacto que puede parar la prueba.

Descargar la lista de preparación (PDF)PDF · A4

Preguntas frecuentes

¿Necesito permiso de AWS, Azure o Google Cloud para un pentest?

A octubre de 2026 no hace falta aprobación previa para probar tus propios recursos, pero hay que cumplir las reglas de cada proveedor. AWS exige aparte una solicitud con dos semanas de antelación para simulaciones encubiertas de ataque, C2 y simulaciones de phishing. El DoS está prohibido en los tres.

¿En qué se diferencia una auditoría de configuración de un pentest en la nube?

La auditoría con un rol de solo lectura muestra qué está mal configurado comparándolo con los CIS Benchmarks. El pentest comprueba si esos errores se pueden explotar y hasta dónde llega un atacante. La auditoría es más barata y más segura, el pentest da pruebas de rutas de ataque reales.

¿Puede la revisión romper el sistema en producción?

La auditoría de configuración no: solo lee ajustes. El pentest trabaja dentro de límites acordados, sin DoS y sin borrar datos, y los pasos arriesgados se acuerdan aparte. Aun así hacen falta una copia de seguridad reciente y un contacto que pueda parar la prueba.

¿Bastan las herramientas integradas del proveedor?

AWS Security Hub, Microsoft Defender for Cloud y Security Command Center en Google Cloud son útiles para vigilar la configuración de forma continua. Pero no ven cadenas de ataque, la lógica de tus aplicaciones ni las claves en código fuera de la nube. Actívalas y haz una revisión independiente de forma periódica.

¿Cuánto dura una revisión de la nube?

Depende del número de cuentas, suscripciones o proyectos y de si hace falta pentest. Auditar un entorno pequeño puede llevar unos días, varios entornos con pentest llevan más. El plazo y el precio se fijan antes de empezar, una vez acordado el alcance.

Referencias

1. AWS: Penetration Testing aws.amazon.com
2. Microsoft Learn: Penetration testing (Azure) learn.microsoft.com
3. Microsoft Cloud Unified Penetration Testing Rules of Engagement microsoft.com
4. Google Cloud Security FAQ support.google.com
5. AWS: Shared Responsibility Model aws.amazon.com
6. Microsoft Learn: Shared responsibility in the cloud learn.microsoft.com
7. Center for Internet Security: CIS Benchmarks cisecurity.org
8. AWS: Security best practices in IAM docs.aws.amazon.com
9. AWS: Blocking public access to your Amazon S3 storage docs.aws.amazon.com
10. AWS: Working with CloudTrail event history docs.aws.amazon.com
11. Microsoft Learn: Activity log in Azure Monitor learn.microsoft.com
12. Google Cloud: Cloud Audit Logs overview docs.cloud.google.com
13. Google Cloud: Cloud Logging quotas and limits docs.cloud.google.com
14. GitHub Docs: OpenID Connect docs.github.com