La seguridad cloud no consiste en confiar ciegamente en que Amazon o Microsoft protegen tus datos — consiste en entender qué parte de la protección te toca a ti. Las empresas que migran a la nube sin una estrategia de seguridad nube empresa clara acaban descubriendo sus errores cuando ya es tarde: una base de datos expuesta, un bucket S3 público o credenciales hardcodeadas en un repositorio de GitHub. El modelo de responsabilidad compartida que aplican AWS, Azure y Google Cloud significa exactamente eso: ellos aseguran la infraestructura física, tú aseguras todo lo que pones encima. Y ahí es donde la mayoría de organizaciones fallan. Esta guía recoge las prácticas reales de cloud security que funcionan, sin humo ni frameworks vacíos, para que puedas proteger datos nube de forma efectiva y dormir algo más tranquilo.
El modelo de responsabilidad compartida: lo que tu proveedor NO hace por ti
AWS lo llama Shared Responsibility Model. Azure usa el mismo concepto. La idea es simple: el proveedor protege la infraestructura (centros de datos, red física, hipervisores) y tú proteges lo que despliegas (configuraciones, datos, accesos, aplicaciones). El problema es que muchas empresas asumen que "estar en la nube" equivale a "estar protegido".
Un ejemplo clásico: el incidente de Capital One en 2019. Un WAF mal configurado en AWS permitió a una atacante acceder a más de 100 millones de registros de clientes. AWS funcionó perfectamente — el fallo fue de configuración, responsabilidad del cliente. Esto no fue un caso aislado. Según el informe de Thales de 2023, aproximadamente el 39% de las empresas encuestadas habían sufrido una brecha de datos en su entorno cloud durante el año anterior.
¿Qué cubre tu proveedor y qué cubres tú? Depende del modelo de servicio:
| Capa | IaaS (EC2, VMs) | PaaS (App Engine, Azure App Service) | SaaS (Office 365, Salesforce) |
|---|---|---|---|
| Infraestructura física | Proveedor | Proveedor | Proveedor |
| Sistema operativo | Tú | Proveedor | Proveedor |
| Configuración de red | Tú | Compartida | Proveedor |
| Gestión de identidades | Tú | Tú | Tú |
| Datos y cifrado | Tú | Tú | Tú |
Fíjate: la gestión de identidades y el cifrado de datos siempre son tu responsabilidad, da igual el modelo. Esto conecta directamente con las amenazas persistentes avanzadas (APT), donde los atacantes buscan precisamente esos puntos débiles de configuración que el proveedor no va a corregir por ti.
Cinco prácticas de seguridad cloud que no puedes ignorar
Aquí van las medidas que marcan la diferencia real entre una empresa que usa la nube de forma segura y una que simplemente reza para que no pase nada.
1. IAM con privilegio mínimo (de verdad)
El principio de least privilege suena obvio, pero la ejecución es otra cosa. En AWS, usa políticas IAM granulares en lugar de adjuntar AdministratorAccess a todo lo que se mueve. En Azure, aprovecha los roles RBAC integrados y Azure AD Conditional Access. Revisa los permisos trimestralmente — las cuentas de servicio tienden a acumular privilegios como un cajón acumula trastos.
Herramientas útiles: AWS IAM Access Analyzer identifica recursos compartidos externamente. Azure AD Privileged Identity Management (PIM) permite activar roles elevados solo cuando se necesitan, con aprobación y registro.
2. Cifrado en tránsito y en reposo — sin excepciones
TLS 1.2 como mínimo para todo el tráfico. Cifrado del lado del servidor (SSE) para almacenamiento. Para datos sensibles, considera el cifrado del lado del cliente con claves que tú controles (AWS KMS, Azure Key Vault, Google Cloud KMS). Si tu proveedor gestiona las claves, al menos tienes una capa. Si las gestionas tú con CMK (Customer Managed Keys), tienes control total.
Punto clave: el cifrado no sirve de nada si las claves están en un fichero .env en un repositorio público. Suena absurdo, pero GitGuardian detectó más de 10 millones de secretos expuestos en repositorios públicos de GitHub solo en 2022.
3. Logging y monitorización centralizada
Activa AWS CloudTrail, Azure Monitor o Google Cloud Audit Logs. Centraliza los logs con un SIEM (Splunk, Elastic Security, Microsoft Sentinel). Configura alertas para eventos críticos: cambios en políticas IAM, accesos desde IPs desconocidas, creación de usuarios con privilegios altos.
Sin visibilidad no hay seguridad. Si un atacante accede a tu entorno y no lo detectas en horas, lo detectarás en meses — el tiempo medio de detección de brechas rondaba los 200 días según datos de IBM en 2023.
4. Segmentación de red y Zero Trust
No pongas todo en la misma VPC con Security Groups abiertos a 0.0.0.0/0. Segmenta por entorno (producción, staging, desarrollo) y por función (frontend, backend, bases de datos). Implementa Zero Trust: verifica cada solicitud independientemente de su origen, incluso dentro de tu propia red.
AWS ofrece VPC endpoints para que el tráfico a servicios como S3 o DynamoDB no salga a internet. Azure tiene Private Link. Úsalos. Cada conexión que no atraviesa internet público es un vector de ataque menos.
5. Backups y plan de recuperación probado
Tener backups en la nube está bien. Tener backups probados, cifrados y en una cuenta o región separada está mejor. El ransomware cloud existe: si un atacante compromete tus credenciales de AWS, puede borrar tus snapshots de EBS y tus backups de S3 si están en la misma cuenta con los mismos permisos.
Usa AWS Backup con vault lock, Azure Immutable Blob Storage o reglas de retención que impidan el borrado incluso con permisos de administrador. Haz simulacros de restauración al menos una vez al trimestre. Un backup que no has probado restaurar es una promesa, no una garantía.
Cumplimiento normativo: RGPD, ENS y lo que viene
Si operas en Europa, el RGPD (Reglamento General de Protección de Datos) exige que sepas exactamente dónde están tus datos y quién accede a ellos. Esto tiene implicaciones directas en seguridad cloud: ¿tu proveedor almacena datos en la UE? ¿Puedes demostrar que aplicas medidas técnicas adecuadas?
AWS, Azure y Google Cloud ofrecen regiones europeas y cláusulas contractuales tipo. Pero la responsabilidad de configurar correctamente la residencia de datos sigue siendo tuya. Un descuido en la configuración de un servicio de replicación puede enviar copias de datos personales a un centro de datos en Virginia sin que te enteres.
Para empresas españolas, el Esquema Nacional de Seguridad (ENS) añade requisitos adicionales si trabajas con el sector público. Y la directiva NIS2 de la UE, en vigor desde octubre de 2024, amplía las obligaciones de ciberseguridad a más sectores y tamaños de empresa. Si gestionas infraestructura cloud para clientes, te conviene revisarla.
Herramientas como AWS Config, Azure Policy y los benchmarks de CIS (Center for Internet Security) te ayudan a auditar tu configuración contra estándares reconocidos. No es solo cumplir: es poder demostrar que cumples cuando alguien pregunte. Si procesas datos con modelos de IA en la nube, asegúrate de que los datos de entrenamiento y las APIs también cumplen estos estándares.
Errores reales que siguen pasando
La teoría está muy bien, pero los incidentes reales enseñan más. Estos son patrones que se repiten año tras año:
- Buckets S3 públicos. Prestige Software expuso datos de reservas hoteleras de millones de clientes por un bucket S3 sin restricciones de acceso. Acquia, múltiples hospitales — la lista de organizaciones que han expuesto datos por un bucket mal configurado es interminable. Activa S3 Block Public Access a nivel de cuenta, no solo de bucket.
- Errores de configuración de servidor. Twitch sufrió una filtración masiva en 2021 cuando un cambio de configuración en un servidor interno dejó expuestos sus repositorios de código fuente y datos internos. No fue un fallo del proveedor cloud — fue un error de configuración propio.
- Credenciales en código fuente. Uber fue hackeada en 2022 cuando un atacante compró credenciales comprometidas y accedió a sus sistemas internos, incluyendo consolas de AWS y Google Cloud. Usa un gestor de secretos (AWS Secrets Manager, HashiCorp Vault) y rota credenciales periódicamente.
- MFA ausente en cuentas root. La cantidad de cuentas de AWS con usuario root sin MFA activado sigue siendo preocupante. Activa MFA con llave física (YubiKey) para las cuentas root y guárdalas en una caja fuerte. No es exageración — es el acceso con más privilegios de tu infraestructura.
- Security Groups demasiado permisivos. Abrir el puerto 22 (SSH) o 3389 (RDP) a
0.0.0.0/0"solo para probar" y dejarlo así durante meses. Esto lo explotan bots automatizados en minutos. Si necesitas acceso remoto, usa AWS Systems Manager Session Manager o una VPN — como las que mencionamos en nuestra guía sobre los hackeos más famosos de la historia, muchos empezaron por accesos remotos mal protegidos.
Herramientas de auditoría cloud que deberías conocer
No hace falta comprar una suite enterprise de medio millón para auditar tu entorno. Estas herramientas cubren lo básico:
- Prowler (open source) — auditoría de seguridad para AWS, Azure y GCP contra benchmarks CIS. Genera informes detallados con recomendaciones.
- ScoutSuite (open source) — escaneo multi-cloud que identifica configuraciones peligrosas. Interfaz web con dashboard visual.
- CloudSploit (Aqua Security) — escaneo continuo de configuraciones cloud con versión gratuita limitada.
- AWS Security Hub / Azure Security Center / Google Security Command Center — las soluciones nativas de cada proveedor. Buenas como primera capa, pero tienden a generar ruido si no afinamos las reglas.
- Trivy (Aqua Security, open source) — escaneo de vulnerabilidades en contenedores, IaC (Terraform, CloudFormation) y configuraciones cloud.
Un buen punto de partida: ejecuta Prowler contra tu cuenta de AWS con el perfil CIS Level 1. Los resultados te darán una lista priorizada de lo que arreglar primero. Muchos hallazgos se solucionan con un par de clics — pero si no los buscas, no los encuentras.
Preguntas frecuentes
¿Es más segura la nube que un servidor propio?
Depende de cómo la configures. La infraestructura física de AWS o Azure supera lo que la mayoría de empresas pueden montar internamente. Pero una mala configuración en la nube te expone igual o más que un servidor local, porque la superficie de ataque es mayor y accesible desde cualquier punto de internet.
¿Qué certificaciones de seguridad cloud debería pedir a mi proveedor?
Como mínimo, ISO 27001, SOC 2 Type II y cumplimiento RGPD. Para sectores regulados, busca ISO 27017 (controles específicos cloud) y ISO 27018 (protección de datos personales en cloud). Los tres grandes proveedores las tienen; pregunta a proveedores más pequeños y exige evidencia.
¿Cómo protejo los datos en la nube del ransomware?
Backups inmutables en cuenta separada, MFA obligatorio en todas las cuentas con privilegios, segmentación de red estricta y monitorización de eventos sospechosos (borrado masivo, cambios de permisos). El ransomware cloud suele entrar por credenciales comprometidas, no por vulnerabilidades del proveedor.
¿Necesito un CASB (Cloud Access Security Broker)?
Si tu empresa usa múltiples servicios SaaS y necesitas visibilidad sobre qué datos suben los empleados a aplicaciones no autorizadas (shadow IT), un CASB aporta valor. Opciones como Microsoft Defender for Cloud Apps, Netskope o Zscaler cubren este hueco. Para empresas pequeñas con pocos servicios cloud, puede ser excesivo.
¿Cada cuánto debo auditar la seguridad de mi entorno cloud?
Escaneos automatizados continuos (Prowler, Security Hub) con revisión humana trimestral de los hallazgos críticos. Auditoría externa completa al menos una vez al año. Revisión de permisos IAM cada trimestre. Simulacro de recuperación de desastres al menos semestral.
El siguiente paso
Ejecuta Prowler o ScoutSuite contra tu entorno cloud esta misma semana. Elige el benchmark CIS Level 1 de tu proveedor, lanza el escaneo y prioriza los hallazgos críticos. La mayoría son configuraciones que se corrigen en minutos — un Security Group abierto, un bucket sin cifrar, una cuenta sin MFA. Cada hallazgo que cierras es un vector de ataque menos. Y si quieres profundizar en cómo los atacantes explotan vulnerabilidades como CSRF en aplicaciones web desplegadas en la nube, ya tienes lectura para el fin de semana.
