Auditoría de seguridad en la nube (AWS, Azure y Google Cloud): qué revisar

Una auditoría de seguridad en la nube revisa la parte que te toca a ti, no la del proveedor. AWS, Microsoft y Google protegen sus centros de datos, sus servidores y su red; tus datos, tus usuarios y cómo configuras cada servicio son cosa tuya. En la práctica se revisan cinco bloques: identidades y MFA, almacenamiento abierto a internet, claves y secretos, registros de auditoría y puertos abiertos. Como lista pública de referencia sirven los CIS Benchmarks de cada proveedor.

¿Qué parte de la seguridad le toca al proveedor y cuál a ti?

Los tres grandes proveedores lo llaman modelo de responsabilidad compartida. AWS lo resume así: ella se ocupa de la seguridad de la nube (el hardware, el software, la red y las instalaciones que hacen funcionar sus servicios) y tú, de la seguridad en la nube, es decir, de lo que montas encima.

Cuánto te toca depende del tipo de servicio. Con una máquina virtual (EC2, en AWS) gestionas tú el sistema operativo, sus actualizaciones y parches de seguridad, el software que instalas y el cortafuegos del grupo de seguridad. Con servicios más abstractos, como el almacenamiento S3 o la base de datos DynamoDB, AWS opera la infraestructura, el sistema operativo y la plataforma, y tú gestionas tus datos, las opciones de cifrado y los permisos.

Microsoft lo detalla en una matriz. De un vistazo:

Área	Infraestructura (IaaS)	Plataforma (PaaS)	Software (SaaS)
Datos del cliente	Tú	Tú	Tú
Configuración y ajustes	Tú	Tú	Tú
Identidades y usuarios	Tú	Tú	Tú
Dispositivos de los usuarios	Tú	Tú	Compartida
Aplicaciones	Tú	Compartida	Compartida
Controles de red	Tú	Compartida	Microsoft
Sistema operativo	Tú	Microsoft	Microsoft
Servidores, red física y centro de datos	Microsoft	Microsoft	Microsoft

En los ejemplos de Microsoft, IaaS son las máquinas virtuales de Azure; PaaS, App Service, Azure Functions o Azure SQL Database, y SaaS, Microsoft 365.

Las tres primeras filas son la clave: tus datos, tu configuración y tus usuarios son responsabilidad tuya en cualquier modelo. Google dice lo mismo con otras palabras: el proveedor responde siempre de la red y la infraestructura de base, y el cliente, siempre de sus políticas de acceso y de sus datos. Google añade lo que llama "destino compartido" (shared fate): se compromete a dar configuraciones seguras de partida, plantillas y guías. Eso te ayuda, pero no cambia quién responde de tu configuración.

Por eso una auditoría cloud no revisa los centros de datos de Amazon. Revisa lo que tu empresa, tu proveedor informático o un antiguo empleado han configurado en tu cuenta.

¿Qué se revisa en una auditoría de seguridad cloud?

Cinco bloques, por orden de prioridad, que salen de las buenas prácticas que publican los propios proveedores:

1. Identidades y accesos. Quién puede entrar, con qué permisos y si usa MFA.
2. Almacenamiento. Si algún bucket o contenedor se puede leer desde internet sin credenciales.
3. Claves y secretos. Claves de acceso permanentes: cuántas hay, dónde están y quién las tiene.
4. Registros de auditoría. Si queda constancia de quién hizo qué, y durante cuánto tiempo.
5. Red. Qué puertos están abiertos a todo internet, sobre todo los de administración remota.

La misma comprobación tiene un nombre distinto en cada nube:

Qué revisar	AWS	Microsoft Azure	Google Cloud
Identidades	IAM e IAM Identity Center; usuario raíz	Microsoft Entra ID	Cloud Identity o cuentas de Google; IAM
MFA que impone el proveedor	En el usuario raíz	Portal, CLI, PowerShell y API de gestión	Consola, por fases según el tipo de cuenta
Almacenamiento público	Bloqueo de acceso público de S3	Acceso anónimo de la cuenta de almacenamiento	Prevención de acceso público de Cloud Storage
Registro de actividad gratuito	Historial de CloudTrail, 90 días	Registro de actividad, 90 días	Actividad de administración, 400 días
Revisión automática	Security Hub CSPM	Defender for Cloud (plan básico gratuito)	Security Command Center
Guía CIS (octubre de 2026)	AWS Foundations 7.1.0	Azure Foundations 6.0.0	GCP Foundation 5.0.0

¿Quién puede entrar y con qué permisos?

Va primero porque casi todo lo demás depende de ello: quien entra como administrador puede cambiar cualquier otra configuración, incluidas las que revisas después.

En AWS, la cuenta nace con un usuario raíz que tiene acceso completo a todo. AWS recomienda encarecidamente no usarlo salvo para las pocas tareas que lo exigen, crear un usuario administrador para el día a día y no crear nunca claves de acceso para el raíz, porque tiene acceso total a todos los servicios, facturación incluida. Todas las cuentas tienen que configurar MFA en el usuario raíz: si no la tiene, hay que registrarla en los 35 días siguientes al primer intento de entrar en la consola. Para el resto, las buenas prácticas de IAM piden credenciales temporales (federación con un proveedor de identidad o roles) en lugar de usuarios con claves permanentes, MFA resistente al phishing (llaves de seguridad y passkeys) donde se pueda, permisos mínimos y revisar con regularidad los usuarios, roles y permisos que ya no se usan, con la información de último acceso que da IAM.

En Azure, Microsoft ha impuesto la MFA obligatoria a quien gestiona recursos, en dos fases. Desde octubre de 2024 la pide al entrar en el portal de Azure y en los centros de administración de Microsoft Entra e Intune. Desde el 1 de octubre de 2025, también en la CLI de Azure, Azure PowerShell, la app móvil, las herramientas de infraestructura como código y la API de gestión, para crear, cambiar o borrar recursos (no para leer). Las empresas con entornos complejos podían aplazar la segunda fase como mucho hasta el 1 de julio de 2026, así que ese margen ya ha pasado. No se puede renunciar, no hay excepción para los entornos de pruebas y afecta también a las cuentas de emergencia. Las identidades de carga de trabajo (identidades administradas y entidades de servicio) no están afectadas; si un script entra con la cuenta de una persona, Microsoft recomienda pasarlo a una identidad de carga de trabajo.

En Google Cloud, la verificación en dos pasos es obligatoria por fases según el tipo de cuenta:

Tipo de cuenta	Obligatoria a partir de
Cuentas de revendedor	28 de abril de 2025
Cuentas personales de Google usadas en Google Cloud	12 de mayo de 2025
Cuentas de empresa de Cloud Identity sin SSO, en organizaciones creadas antes del 3 de agosto de 2026	20 de octubre de 2026
Las mismas, en organizaciones creadas desde el 3 de agosto de 2026	30 días después de crear la organización
Cuentas de empresa con SSO o federación	Pendiente de anunciar

Afecta a la consola de Google Cloud y a la de Firebase, no a las aplicaciones que tienes alojadas. Si tu empresa entra con usuarios de Cloud Identity sin inicio de sesión único, el cambio te llega ahora.

Qué mirar, sea cual sea tu nube:

• La lista completa de personas y cuentas con permisos de administrador. ¿Siguen todas en la empresa?
• MFA en todas, a ser posible con llave de seguridad o passkey.
• Cuentas de antiguos empleados o de proveedores que ya no trabajan contigo.
• Scripts y automatizaciones que entran con el usuario de una persona.
• Permisos amplios "por si acaso" que nadie ha vuelto a reducir.

¿Hay algún almacenamiento abierto a internet?

Un bucket o contenedor legible por cualquiera es la forma más rápida de que una copia de seguridad o una carpeta de facturas acabe publicada. AWS y Microsoft bloquean hoy por defecto el acceso público en los recursos nuevos, pero eso no protege lo que se creó antes ni lo que alguien abrió después. En Google Cloud, ese bloqueo hay que activarlo.

• AWS S3. Los buckets, puntos de acceso y objetos nuevos no permiten el acceso público por defecto, pero un usuario puede cambiar las políticas para permitirlo. El bloqueo de acceso público (Block Public Access) tiene cuatro ajustes, y AWS recomienda activar los cuatro en toda la cuenta. Ojo a un detalle: estos ajustes no modifican las políticas existentes, así que si alguien los quita, lo que tenía una política pública vuelve a ser público. IAM Access Analyzer para S3 avisa de los buckets abiertos a cualquiera en internet o a otras cuentas.
• Azure Storage. El acceso anónimo está prohibido por defecto. Se controla con el ajuste "Allow Blob anonymous access" (propiedad AllowBlobPublicAccess) de cada cuenta de almacenamiento. Si al consultarlo sale vacío, el script de Microsoft para corregirlo en bloque trata esa cuenta como una que no prohíbe el acceso anónimo. Excepción: el contenedor $web de un sitio web estático siempre es público.
• Google Cloud Storage. La prevención de acceso público se activa en cada bucket o con la política de organización storage.publicAccessPrevention. Si no está configurada en el bucket ni en ningún nivel por encima, no se aplica.

En cada caso, la pregunta es si ese bucket tiene que ser público. Una web estática lo necesita; una carpeta de nóminas, no. Ninguna herramienta automática lo sabe por ti.

¿Dónde están las claves y los secretos?

Una clave de acceso permanente deja entrar a quien la tenga, sin necesidad de contraseña. Google lo dice sin rodeos: para un atacante, una clave de cuenta de servicio puede valer incluso más que una contraseña filtrada.

• AWS: credenciales temporales siempre que se pueda. Las aplicaciones que corren en EC2 o Lambda reciben las credenciales temporales de un rol y no necesitan claves. Si una clave es imprescindible (AWS cita casos como algunos plugins de WordPress o herramientas de terceros), hay que cambiarla cuando haga falta, por ejemplo cuando un empleado se va, y retirar las que no se usan con la información de último uso.
• Google Cloud: evitar las claves de cuentas de servicio y tratarlas como una excepción; no subirlas nunca a un repositorio de código (borrarlas después no basta, porque quedan en el historial); rotarlas, y bloquear su creación con una política de organización. En las organizaciones creadas desde el 3 de mayo de 2024 ese bloqueo viene activado por defecto, junto con otras políticas como el acceso uniforme a nivel de bucket.
• Azure: las claves de una cuenta de almacenamiento dan acceso a todos sus datos, y los roles de Propietario y Colaborador incluyen el permiso para obtenerlas. Revisa quién tiene esos roles sobre las cuentas que guardan datos.

Qué mirar: claves con meses o años de antigüedad, claves pegadas en repositorios de código o en correos, y claves de personas que ya no están.

¿Queda registro de quién hizo qué?

Si alguien borra una base de datos o abre un bucket, el registro de actividad es lo único que dice quién fue, cuándo y desde dónde. Los tres proveedores guardan algo sin coste, pero poco tiempo o no todo:

	Qué guarda sin configurar nada	Durante cuánto	Qué no guarda por defecto
AWS CloudTrail	Eventos de gestión: crear, cambiar o borrar recursos	90 días, sin coste por consultarlos	Eventos de datos, como leer un fichero de S3 (con coste adicional)
Azure, registro de actividad	Operaciones de gestión	90 días, sin coste	Registros de recursos, como leer un secreto o consultar una base de datos
Google Cloud, registros de auditoría	Actividad de administración y eventos del sistema, que no se pueden desactivar	400 días, no configurable	Registros de acceso a datos, salvo en BigQuery

Para guardar más hay que configurarlo: en AWS, un registro (trail) o un almacén de eventos de CloudTrail Lake; en Azure, una configuración de diagnóstico que envíe el registro a un área de trabajo de Log Analytics o a una cuenta de almacenamiento; en Google Cloud, ampliar la retención del bucket _Default del proyecto (30 días por defecto, configurable hasta 3.650) o enrutar los registros a otro bucket. Microsoft da un motivo muy práctico: el registro de actividad es el único sitio donde consta quién creó cada recurso, y a los 90 días se borra.

Tiene que ver con el RGPD. Si hay una brecha con datos personales, tienes que notificarla a la autoridad de control sin dilación indebida y, si es posible, en 72 horas desde que la conoces (art. 33.1). Sin registros es muy difícil saber qué datos se vieron.

¿Qué puertos están abiertos a todo internet?

Los puertos de administración remota, SSH (22) y escritorio remoto RDP (3389), abiertos a cualquier dirección (0.0.0.0/0) son una invitación. Microsoft explica que hay atacantes buscando activamente máquinas con esos puertos abiertos y que una máquina comprometida sirve de entrada para atacar el resto del entorno.

• Google Cloud: la red llamada "default" trae ya creadas reglas de cortafuegos que permiten SSH, RDP y ping desde 0.0.0.0/0. Se pueden borrar o cambiar, y conviene hacerlo si no las usas.
• AWS: Security Hub CSPM tiene dos controles para esto: que ningún grupo de seguridad permita la entrada desde 0.0.0.0/0 o ::/0 al puerto 22 (EC2.13) ni al 3389 (EC2.14).
• Azure: Defender for Cloud ofrece el acceso a máquinas virtuales "justo a tiempo" (just-in-time), que bloquea esos puertos y los abre solo cuando alguien con permiso lo pide, desde su dirección y durante un tiempo limitado. Está en el plan 2 de Defender for Servers.

Qué mirar: cada regla de entrada abierta a 0.0.0.0/0 y, para cada una, si de verdad tiene que estar abierta a todo el mundo. Tu web pública, sí; el acceso de administración a un servidor, casi nunca.

¿Qué son los CIS Benchmarks y qué herramientas gratuitas hay?

Los CIS Benchmarks son guías de configuración segura del Center for Internet Security, elaboradas por consenso entre expertos de ciberseguridad. Hay una por proveedor y se descargan gratis en PDF para uso no comercial. A fecha de octubre de 2026, las versiones publicadas son la 7.1.0 de Amazon Web Services Foundations, la 6.0.0 de Microsoft Azure Foundations y la 5.0.0 de Google Cloud Platform Foundation. Se actualizan a menudo: el resumen de abril de 2026 del CIS daba la 7.0.0 de AWS como recién actualizada, y hoy ya va por la 7.1.0. Si un informe cita una versión antigua, pregunta por qué.

Además, cada proveedor tiene una herramienta que compara tu configuración con buenas prácticas:

• AWS Security Hub CSPM revisa tu cuenta de forma continua frente al estándar de buenas prácticas de AWS (FSBP) y frente al CIS, entre otros. La primera vez que lo activas tienes 30 días de prueba gratuita, aunque durante la prueba pagas el uso de otros servicios como AWS Config, que necesita para la mayoría de controles. Solo detecta lo que ocurre desde que lo activas, y para cumplir del todo con el CIS hay que activarlo en todas las regiones.
• Microsoft Defender for Cloud tiene un plan básico de gestión de la postura de seguridad (Foundational CSPM) gratuito, con recomendaciones según el Microsoft Cloud Security Benchmark y una puntuación de seguridad (secure score). Sirve también para cuentas de AWS y proyectos de Google Cloud. El plan Defender CSPM, de pago, añade análisis de rutas de ataque y priorización de riesgos.
• Google Security Command Center tiene un nivel Standard sin coste adicional, pero la detección de configuraciones inseguras (Security Health Analytics) no está disponible en las activaciones nuevas de ese nivel. Compruébalo antes de contar con ella.

Estas herramientas no sustituyen la revisión: no saben qué bucket tiene que ser público, qué proveedor sigue trabajando contigo ni qué datos personales hay en cada sitio.

¿Es obligatoria una auditoría de seguridad en la nube?

Ninguna norma general obliga a una pyme privada a hacer una "auditoría cloud" con ese nombre. Pero si en la nube hay datos personales de clientes o empleados, el RGPD sí exige tres cosas que una auditoría ayuda a demostrar:

1. Medidas de seguridad adecuadas al riesgo (art. 32.1), entre ellas "un proceso de verificación, evaluación y valoración regulares de la eficacia de las medidas técnicas y organizativas para garantizar la seguridad del tratamiento" (letra d). No dice cada cuánto ni cómo.
2. Un proveedor con garantías suficientes. El proveedor de nube que guarda datos personales por tu cuenta suele actuar como encargado del tratamiento, y el art. 28.1 te obliga a elegir "únicamente un encargado que ofrezca garantías suficientes".
3. Saber dónde están los datos. Llevar datos personales a un tercer país, fuera del Espacio Económico Europeo, es una transferencia internacional, y solo se permite si se cumplen las condiciones del capítulo V del RGPD (art. 44 y siguientes). En la auditoría, revisa en qué región está cada recurso y cada copia.

Si la auditoría incluye un pentest (prueba de intrusión), lee antes las reglas del proveedor. La política de AWS, por ejemplo, permite probar sin aprobación previa una lista de servicios (EC2, RDS, CloudFront, Lambda, Lightsail y otros), pero prohíbe la denegación de servicio, inundar puertos, protocolos o peticiones y tomar buckets de S3 o subdominios.

¿Cómo se hace la auditoría, paso a paso?

1. Inventario. Todas las cuentas de AWS, suscripciones de Azure y proyectos de Google Cloud, también las de pruebas y las que abrió alguien que ya no está. Lo que no está en la lista no se revisa.
2. Acceso de solo lectura para quien audita. Para revisar no hace falta poder cambiar nada.
3. Revisión automática con la herramienta del proveedor, comparando con el CIS Benchmark de tu nube.
4. Revisión manual de lo que una herramienta no sabe: qué debe ser público, quién debe tener acceso y qué datos personales hay y dónde.
5. Informe con prioridades. Primero lo que expone datos o da el control de la cuenta (administradores sin MFA, buckets públicos, claves filtradas); después, lo demás.
6. Corrección y nueva revisión, para confirmar que lo corregido sigue corregido.

En Quantum Nova hacemos estas revisiones nosotros, sin subcontratar y con precio cerrado tras un diagnóstico gratuito de 2 a 5 días. Lo tienes en auditoría de seguridad.

Preguntas frecuentes

¿Quién responde si roban datos de un bucket mal configurado?

Según el modelo de responsabilidad compartida de AWS, Microsoft y Google, la configuración, los datos y los accesos son siempre responsabilidad del cliente; el proveedor responde de su infraestructura. Si había datos personales, además tendrás que valorar si notificas la brecha a la autoridad de control, en 72 horas si es posible (art. 33.1 del RGPD).

¿Qué es un CIS Benchmark?

Una guía de configuración segura que publica el Center for Internet Security, elaborada por consenso entre expertos. Hay versiones para AWS, Azure y Google Cloud, gratuitas en PDF para uso no comercial. A fecha de octubre de 2026 van por la 7.1.0, la 6.0.0 y la 5.0.0, respectivamente.

¿Es obligatoria la MFA en Azure y en Google Cloud?

En Azure, sí para gestionar recursos: desde octubre de 2024 en el portal y desde el 1 de octubre de 2025 en la CLI, PowerShell y la API de gestión, sin opción de renunciar. En Google Cloud va por fases: para las cuentas de empresa de Cloud Identity sin SSO de organizaciones creadas antes del 3 de agosto de 2026, a partir del 20 de octubre de 2026.

¿Cuánto tiempo guarda AWS el registro de actividad?

El historial de eventos de CloudTrail guarda sin coste los últimos 90 días de eventos de gestión. Para guardar más tiempo hay que crear un registro (trail) o un almacén de eventos. Los eventos de datos, como la lectura de ficheros de S3, no se registran por defecto: hay que activarlos aparte y tienen coste adicional.

¿Cada cuánto conviene revisar la configuración?

El RGPD pide una verificación "regular" sin fijar plazos. Las herramientas de los proveedores revisan de forma continua; la revisión manual conviene repetirla cuando cambian las personas con acceso, los proveedores o la forma de montar tus sistemas.

Fuentes

• AWS, modelo de responsabilidad compartida
• Microsoft Learn, Shared responsibility in the cloud
• Google Cloud, Shared responsibilities and shared fate on Google Cloud
• AWS, Root user best practices for your AWS account
• AWS, Security best practices in IAM
• Microsoft Learn, Plan for mandatory Microsoft Entra multifactor authentication
• Google Cloud, Multi-factor authentication requirement for Google Cloud
• AWS, Blocking public access to your Amazon S3 storage
• Microsoft Learn, Remediate anonymous read access to blob data
• Google Cloud, Public access prevention
• Google Cloud, Best practices for managing service account keys
• Google Cloud, Secure by default organizations
• AWS, Working with CloudTrail event history
• AWS, Logging data events with CloudTrail
• Microsoft Learn, Activity log in Azure Monitor
• Google Cloud, Cloud Audit Logs overview
• Google Cloud, Cloud Logging quotas and limits (retención)
• Google Cloud, VPC firewall rules
• AWS, Security Hub CSPM controls for Amazon EC2
• Microsoft Learn, Understand just-in-time virtual machine access
• CIS Benchmarks
• CIS, benchmarks de Amazon Web Services
• CIS, benchmarks de Microsoft Azure
• CIS, benchmarks de Google Cloud
• CIS, CIS Benchmarks April 2026 Update
• AWS, Introduction to AWS Security Hub CSPM
• Microsoft Learn, Cloud Security Posture Management in Defender for Cloud
• Google Cloud, Security Command Center service tiers
• Reglamento (UE) 2016/679, RGPD, en el BOE: arts. 28, 32, 33 y 44
• AWS, Penetration Testing policy