Auditoría de seguridad cloud: AWS, Azure y Google Cloud bajo control
1. Introducción
La Auditoría de seguridad cloud se ha convertido en una necesidad para cualquier empresa que opere en AWS, Azure o Google Cloud: la nube es segura, pero la configuración rara vez lo es. Un bucket S3 abierto, una política IAM demasiado permisiva o una red mal segmentada pueden exponer datos de clientes sin que nadie lo note. En este artículo explicamos en qué consiste una auditoría de seguridad cloud, qué se revisa y qué entregables debe recibir tu empresa.
Los incidentes de 2025-2026 lo confirman: la mayoría de brechas cloud no se deben a vulnerabilidades de la plataforma, sino a malas configuraciones. La auditoría de seguridad cloud permite detectar estos fallos antes de que lo hagan los atacantes, y es además un requisito para certificaciones como ISO 27001 o el ENS cuando la infraestructura vive en la nube.
En este artículo revisamos la metodología de auditoría por capas — IAM, datos, red, logging y cumplimiento — con ejemplos de comandos reales en los tres proveedores, la periodicidad recomendada y los entregables esperados. Al final, sabrás exactamente qué pedir a tu proveedor de servicios de ciberseguridad.
Para aprovechar la lectura, ten a mano tres respuestas: qué proveedor o proveedores usáis, quién gestiona las credenciales y si existe un inventario actualizado de recursos. Esas tres respuestas ya dicen bastante sobre la madurez de vuestra configuración.
2. ¿Qué es una auditoría de seguridad cloud y por qué fallan las configuraciones?
Una auditoría de seguridad cloud es un proceso sistemático que evalúa la configuración, los permisos y el uso de la infraestructura de un proveedor cloud (AWS, Azure o Google Cloud) frente a buenas prácticas y requisitos normativos, identificando riesgos concretos y proponiendo remediaciones priorizadas.
El modelo de responsabilidad compartida lo explica todo: el proveedor protege la nube, pero el cliente es responsable de lo que hay dentro — identidades, datos, redes y configuraciones. Los fallos más comunes detectados en auditorías reales incluyen buckets con acceso público, claves de acceso embebidas en código, roles con permisos excesivos, logging desactivado y VPC sin segmentar.
En la práctica, la frontera de la responsabilidad compartida depende del modelo de servicio: en IaaS (instancias EC2, VMs) el cliente responde de casi todo lo que corre sobre el hypervisor; en PaaS, la plataforma reduce la superficie atacable, pero identidades, datos y configuración de la aplicación siguen siendo responsabilidad del cliente; en SaaS, el cliente conserva la responsabilidad sobre los usuarios, los permisos y la integración con su identidad corporativa. Una auditoría de seguridad cloud incluye siempre una fase de mapeo de responsabilidades: saber quién responde de cada control evita que los fallos caigan en tierra de nadie.
| Capa | Riesgo típico | Impacto |
|---|---|---|
| IAM / identidades | Permisos excesivos, claves sin rotar | Compromiso de credenciales |
| Datos / almacenamiento | Buckets públicos, cifrado desactivado | Filtración masiva de datos |
| Red | Puertos abiertos, sin segmentación | Acceso no autorizado |
| Logging | CloudTrail/Audit off | Sin visibilidad forense |
Fig. 1 – Capas típicas de una auditoría de seguridad cloud y sus riesgos principales.
3. Auditoría de IAM: el plano de la seguridad cloud
La gestión de identidades y accesos es la capa más crítica. Se revisa el principio de mínimo privilegio, roles en lugar de claves de larga duración, rotación de credenciales y MFA obligatorio:
# AWS: identificar usuarios, roles y permisos
aws iam list-users --output table
aws iam list-access-keys --user-name ana --output table
aws iam get-account-authorization-details --output json | jq '.UserDetailList[].AttachedManagedPolicies'
# Azure: revisar roles y administradores globales
az ad signed-in-user show
az role assignment list --all --output table
# Google Cloud: IAM del proyecto
gcloud projects get-iam-policy mi-proyecto --flatten="bindings[].members" --format="table(bindings.role,bindings.members)"
Fig. 2 – Comandos de auditoría IAM en los tres principales proveedores cloud.
Un hallazgo clásico: usuarios con acceso «AdministratorAccess» o «Owner» cuando solo necesitan permisos limitados a un servicio. La auditoría de seguridad cloud cuantifica este riesgo y propone el rediseño de políticas con ejemplos concretos.
Las comprobaciones concretas de esta capa incluyen:
- MFA obligatorio para todos los usuarios, especialmente los privilegiados.
- Rotación de claves de acceso y uso de roles con credenciales temporales.
- Detección de cuentas inactivas o con permisos de administrador innecesarios.
- Revisión de integraciones de terceros y de cuentas de servicio.
- Acceso condicional en Azure y políticas de sesión en AWS y Google Cloud.
En la práctica, la mayoría de los compromisos cloud comienzan con una credencial robada; cada control de esta lista encarece el ataque para el atacante.
4. Auditoría de datos: buckets, bases de datos y cifrado
El almacenamiento es donde ocurren las filtraciones más sonadas. Se revisan las políticas públicas, el cifrado en reposo y en tránsito, y las reglas de ciclo de vida:
# AWS: detectar buckets con acceso público
aws s3api get-bucket-acl --bucket mi-bucket
aws s3api get-bucket-policy-status --bucket mi-bucket
# Azure: revisar acceso anónimo en blobs
az storage account list --query "[].{name:name,allowBlobPublicAccess:allowBlobPublicAccess}" -o table
# Google Cloud: políticas públicas en buckets
gsutil iam get gs://mi-bucket
Fig. 3 – Comandos para detectar almacenamiento expuesto en la nube.
La auditoría de seguridad cloud incluye también la revisión del cifrado (SSE-S3/KMS, SSE con claves gestionadas), versionado de objetos y bloqueo de eliminación — controles esenciales frente a ransomware y borrado accidental.
Se revisan también los permisos de escritura: un bucket con solo lectura pública expone datos, pero uno con escritura pública permite inyectar contenido malicioso o modificar software de descarga. Las políticas de ciclo de vida (archivado, expiración) evitan que datos sensibles se acumulen más tiempo del necesario.
5. Auditoría de red, logging y cumplimiento
En la capa de red se revisan los grupos de seguridad, las reglas de firewall (incluyendo 0.0.0.0/0), los peerings y la segmentación por entorno. En la capa de logging, que los registros de actividad estén activados y centralizados:
# AWS: grupos de seguridad con acceso desde cualquier IP
aws ec2 describe-security-groups --query 'SecurityGroups[].IpPermissions[]' --output json
# Azure: activar el diagnóstico de red
az monitor diagnostic-settings list --resource mi-vm
# Google Cloud: habilitar audit logging
gcloud services enable cloudaudit.googleapis.com
Fig. 4 – Verificación de reglas de red y logging en los proveedores cloud.
La parte de cumplimiento compara la configuración con el marco aplicable: CIS Benchmarks, ISO 27001, ENS (si aplica) y el RGPD para datos personales. Herramientas de código abierto como ScoutSuite, Prowler (AWS) o CloudSploit permiten automatizar gran parte del barrido inicial, que el auditor complementa con revisión manual.
En la capa de cumplimiento se revisa además el mapa de datos personales: dónde residen, en qué región, qué transferencias internacionales existen y si el cifrado y la retención cumplen el RGPD y, cuando aplica, el ENS. La alineación con los CIS Benchmarks de cada proveedor ofrece un criterio objetivo y comparable entre AWS, Azure y Google Cloud.
6. Metodología, entregables y periodicidad
Una auditoría de seguridad cloud profesional sigue un proceso claro: inventario de recursos, recopilación de configuración (con los permisos mínimos necesarios para el auditor), análisis automatizado + manual, validación de hallazgos (descartando falsos positivos) e informe final.
El informe debe incluir: resumen ejecutivo para dirección, inventario de activos, matriz de hallazgos por severidad (crítica/alta/media/baja), evidencia de cada uno, riesgo de negocio y plan de remediación priorizado con esfuerzo estimado. La periodicidad recomendada es al menos anual, y tras cambios significativos de arquitectura; muchas empresas optan por auditorías trimestrales automatizadas con escaneo continuo.
El coste de una auditoría de seguridad cloud en España en 2026 se sitúa entre 3.000 y 12.000 € para una infraestructura típica de PYME con decenas de recursos, y supera los 20.000 € en entornos grandes o con múltiples cuentas y regulaciones adicionales. Frente a eso, el coste de un único bucket expuesto — multas del RGPD, notificación de brecha, reputación — es de varios órdenes de magnitud superior.
Artículos relacionados: Seguridad en AWS: IAM y buckets S3 bajo control y Análisis de riesgos en la empresa.
7. Herramientas y automatización de la auditoría
La automatización es el aliado del auditor: las herramientas de código abierto y las plataformas CSPM (Cloud Security Posture Management) permiten evaluar cientos de controles en minutos y detectar desviaciones de forma continua. La tabla resume las más habituales:
| Herramienta | Tipo | Proveedores | Uso principal |
|---|---|---|---|
| Prowler | Código abierto | AWS, Azure, GCP | Controles CIS y cumplimiento |
| ScoutSuite | Código abierto | AWS, Azure, GCP | Inventario y evaluación amplia |
| CloudSploit | Open source / SaaS | AWS, Azure, GCP | Monitoreo continuo de configuración |
| CSPM nativo (Security Hub, Defender, SCC) | SaaS | Multi-nube | Postura continua y remediación |
En un barrido típico de la capa IAM:
# Prowler (AWS, Azure, GCP): cientos de controles automatizados
prowler aws -M html -o /tmp/auditoria -c iam,s3
# ScoutSuite: inventario multi-nube en un solo informe
scout aws --profile auditor
Estas herramientas generan un primer borrador de hallazgos que el auditor valida manualmente, descartando falsos positivos y contextualizando el riesgo en el negocio. En equipos maduros, el CSPM se integra con el SIEM y el pipeline de remediación, de modo que una política insegura se corrige o se reporta automáticamente antes de llegar a producción.
8. Señales de que tu empresa necesita una auditoría
Hay momentos en los que la auditoría de seguridad cloud deja de ser recomendable y pasa a ser urgente:
- La infraestructura creció sin documentación y nadie sabe qué hay publicado.
- Las credenciales se comparten entre equipos o aparecen embebidas en código.
- Se prepara una certificación (ISO 27001, ENS) o la exige un cliente, una aseguradora o el delegado de protección de datos.
- Hubo un incidente reciente o un informe anterior con hallazgos sin corregir.
- Se planea migrar más servicios a la nube o integrar la infraestructura de una empresa adquirida.
La auditoría de seguridad cloud no es solo un gasto de cumplimiento: es la forma más barata de descubrir los fallos que los escáneres de los atacantes encuentran cada día en internet.
9. Conclusión
La auditoría de seguridad cloud convierte el «confiamos en la nube» en «hemos verificado que nuestra configuración es segura». En 2026, con los ataques automatizados que escanean internet buscando buckets abiertos y puertas traseras, esta revisión no es opcional para ninguna empresa con infraestructura en AWS, Azure o Google Cloud.
En Jaymon Security realizamos auditorías de seguridad cloud completas para empresas de todos los tamaños, con informe ejecutivo y plan de remediación. Más información en jaymonsecurity.es o en las guías oficiales de AWS Well-Architected y Microsoft Azure Well-Architected.
¿Necesitas ayuda con Auditoría de seguridad cloud?
En Jaymon Security ayudamos a las organizaciones a proteger sus sistemas. Desde auditorías de seguridad hasta implementación de SIEM/SOC, nuestro equipo de expertos diseña soluciones a medida.
Contacta con nosotros para una evaluación gratuita de tu infraestructura.
