Seguridad en la nube: el modelo de responsabilidad compartida

Uno de los malentendidos más peligrosos en la adopción cloud es asumir que mover los sistemas a la nube traslada también la responsabilidad de su seguridad al proveedor. Esta confusión ha sido el origen de incidentes de seguridad significativos en organizaciones de todos los tamaños: bases de datos expuestas en buckets S3 sin control de acceso, instancias sin parches porque el equipo asumía que el proveedor los aplicaba, o secretos embebidos en código subido a repositorios públicos. El modelo de responsabilidad compartida define con claridad qué protege el proveedor y qué debe proteger el cliente.

Entender este modelo no es un ejercicio académico: tiene consecuencias directas en cómo se diseñan los sistemas, cómo se configuran los controles de seguridad y cómo se distribuyen las responsabilidades dentro del equipo de IT. Un error en la interpretación del modelo puede dejar el sistema expuesto, incluso aunque el proveedor cloud tenga las certificaciones de seguridad más rigurosas del mercado.

Este artículo explora en profundidad el modelo de responsabilidad compartida, sus variaciones según el tipo de servicio cloud (IaaS, PaaS, SaaS), sus implicaciones prácticas y el marco de controles que toda organización debería implementar para cumplir con su parte de la responsabilidad.

El modelo de responsabilidad compartida explicado

AWS, que popularizó el término, describe el modelo de responsabilidad compartida como: el proveedor es responsable de la seguridad 'de' la nube (la infraestructura física, el hardware, el software de virtualización, las instalaciones); el cliente es responsable de la seguridad 'en' la nube (el sistema operativo, las aplicaciones, los datos, la configuración de los servicios, la gestión de identidades y accesos).

Esta distinción parece clara en el papel, pero se complica cuando se consideran los diferentes modelos de servicio. En Infrastructure as a Service (IaaS), el cliente gestiona el sistema operativo, el middleware y las aplicaciones: la responsabilidad del cliente es mayor. En Platform as a Service (PaaS), el proveedor gestiona también el sistema operativo y el middleware; el cliente es responsable de la aplicación y los datos. En Software as a Service (SaaS), el proveedor gestiona casi todo; el cliente es principalmente responsable de la configuración del servicio y la gestión de sus usuarios.

Zonas grises y malentendidos frecuentes

La zona gris más común es la del sistema operativo en IaaS. El proveedor cloud gestiona el hipervisor y aísla las instancias entre clientes, pero el sistema operativo que corre dentro de la instancia es responsabilidad del cliente: sus actualizaciones de seguridad, su configuración, su hardening. Muchas organizaciones que migran de un datacenter físico donde el equipo de sistemas gestionaba los servidores asumen erróneamente que ese rol lo asume el proveedor cloud en el modelo IaaS.

Otro malentendido frecuente es sobre la disponibilidad de los datos. El proveedor cloud garantiza la disponibilidad de la infraestructura de almacenamiento, pero no protege contra el borrado accidental o malicioso de los datos por parte del cliente. Si un administrador borra una base de datos, el proveedor no tiene una copia de seguridad automática (salvo que el cliente haya activado y configurado el servicio de backup correspondiente). La protección del dato es siempre responsabilidad del cliente.

Responsabilidad compartida por tipo de servicio

• IaaS (EC2, Azure VM, GCE): el cliente gestiona SO, patches, configuración de red, aplicaciones, datos y control de acceso a la instancia.
• PaaS gestionado (RDS, Azure App Service, GKE): el proveedor gestiona el SO y la plataforma; el cliente gestiona la aplicación, los datos y la configuración de seguridad del servicio.
• Almacenamiento objeto (S3, Azure Blob, GCS): el proveedor gestiona la infraestructura; el cliente configura los controles de acceso, el cifrado y las políticas de retención.
• SaaS (Microsoft 365, Salesforce, Workday): el proveedor gestiona casi todo; el cliente gestiona los usuarios, sus permisos y el cumplimiento normativo de los datos que introduce.
• Serverless FaaS (Lambda, Azure Functions): el proveedor gestiona el runtime; el cliente es responsable del código, las dependencias y los permisos IAM de la función.

Los controles de seguridad que son siempre responsabilidad del cliente

Independientemente del tipo de servicio cloud utilizado, hay un conjunto de controles de seguridad que son siempre responsabilidad del cliente. Estos controles representan la base mínima de seguridad cloud que toda organización debe implementar.

Gestión de identidades y accesos (IAM)

El control de quién puede hacer qué en el entorno cloud es siempre responsabilidad del cliente. Esto incluye la creación y gestión de usuarios, roles y políticas de acceso; la aplicación del principio de mínimo privilegio; la gestión de credenciales (rotación de claves, eliminación de credenciales inactivas); y la configuración de la autenticación multifactor (MFA) para accesos privilegiados.

El incidente de seguridad cloud más común no es un fallo en la infraestructura del proveedor: es una credencial comprometida o una política de IAM mal configurada que permite a un actor no autorizado acceder a los recursos del cliente. La gestión rigurosa de identidades es el control de seguridad de mayor impacto en entornos cloud.

Configuración de servicios

Los servicios cloud vienen configurados con valores predeterminados que priorizan la funcionalidad sobre la seguridad. Un bucket S3 recién creado puede configurarse accidentalmente como público. Un grupo de seguridad puede abrirse con reglas demasiado permisivas durante una prueba y nunca cerrarse. Una base de datos RDS puede desplegarse sin cifrado en reposo si no se especifica explícitamente.

La responsabilidad de configurar cada servicio de forma segura recae en el cliente. Herramientas como AWS Security Hub, Microsoft Defender for Cloud o Google Security Command Center evalúan continuamente la configuración de los servicios contra marcos de referencia como CIS Benchmarks, NIST o el propio AWS Well-Architected Framework, e identifican desviaciones que pueden suponer un riesgo.

Cloud Security Posture Management (CSPM)

El CSPM es la categoría de herramientas diseñadas para proporcionar visibilidad continua sobre la postura de seguridad del entorno cloud: detectar configuraciones incorrectas, comparar contra marcos de referencia, identificar recursos expuestos y priorizar las remediaciones por riesgo. Es, en esencia, la automatización de la auditoría de configuración cloud.

Las soluciones CSPM nativas de cada proveedor (AWS Security Hub con AWS Config Rules, Microsoft Defender for Cloud, Google Security Command Center) son el punto de partida para organizaciones con un único proveedor. Para entornos multi-cloud, soluciones como Wiz, Orca Security, Prisma Cloud de Palo Alto Networks o Lacework ofrecen una visión unificada y capacidades avanzadas de correlación de riesgos.

Wiz en particular ha ganado prominencia en el mercado enterprise por su capacidad de correlacionar vulnerabilidades, configuraciones incorrectas y rutas de ataque en un único grafo de riesgo, permitiendo priorizar las remediaciones con mayor impacto. En lugar de presentar cientos de hallazgos individuales, identifica los caminos más probables que seguiría un atacante para llegar a los activos más críticos.

Cifrado: en reposo y en tránsito

El cifrado de datos es una responsabilidad compartida con matices importantes. Los proveedores cloud cifran habitualmente la infraestructura de almacenamiento subyacente, pero el cifrado a nivel de dato —con claves gestionadas por el cliente— es una decisión y una responsabilidad del cliente. Esta distinción es crítica para el cumplimiento normativo: el RGPD y otras regulaciones requieren que el responsable del tratamiento pueda demostrar control sobre los datos, lo que implica control sobre las claves de cifrado.

El modelo de gestión de claves tiene tres variantes principales: claves gestionadas por el proveedor (SSE-S3 en AWS, la opción más simple pero con menos control), claves gestionadas por el cliente en el servicio de gestión de claves del proveedor (KMS en AWS, Key Vault en Azure, Cloud KMS en GCP), y claves gestionadas por el cliente almacenadas externamente (BYOK, Bring Your Own Key), donde las claves residen en un HSM controlado por el cliente y nunca llegan al proveedor en texto claro.

• Activa el cifrado en reposo para todos los recursos que almacenan datos de negocio o personales, sin excepciones.
• Usa CMKs (Customer Managed Keys) en KMS para tener control sobre la rotación y la revocación de claves.
• Asegúrate de que todo el tráfico usa TLS 1.2 o superior; deshabilita versiones antiguas en los servicios que lo permitan.
• Implementa políticas de KMS que limiten qué roles o servicios pueden usar cada clave.
• Configura la rotación automática de claves KMS (AWS la soporta nativamente con rotación anual automática).
• Considera BYOK para datos regulados que requieren demostrar control total sobre las claves de cifrado.

Gestión de vulnerabilidades en la nube

En IaaS, la responsabilidad de parchear el sistema operativo y los paquetes instalados es del cliente. Esto requiere un proceso de gestión de parches: identificar instancias con vulnerabilidades, priorizar según criticidad, aplicar los parches y verificar el resultado. AWS Systems Manager Patch Manager, Azure Update Management y Google OS Config automatizan gran parte de este proceso, pero el cliente debe activarlos y configurarlos.

Para imágenes de contenedores, la responsabilidad incluye mantener actualizadas las imágenes base y los paquetes de aplicación. Herramientas como Amazon ECR Enhanced Scanning, Microsoft Defender for Container Registries o Trivy (open source) escanean las imágenes en busca de vulnerabilidades conocidas antes de su despliegue. Integrar este escaneo en el pipeline de CI/CD es una práctica fundamental de DevSecOps.

Registro y monitorización: el requisito que más se omite

El registro (logging) de actividad en el entorno cloud es responsabilidad del cliente. Los proveedores ofrecen las herramientas (AWS CloudTrail, AWS CloudWatch Logs, Azure Activity Log, Azure Monitor, GCP Cloud Audit Logs), pero activarlas, configurarlas correctamente y monitorizar los registros en busca de actividad anómala es responsabilidad de la organización.

CloudTrail en AWS registra todas las llamadas a la API del plano de control (quién hizo qué, cuándo y desde dónde), pero no está activo por defecto para todos los tipos de eventos. Es imprescindible activar CloudTrail en todas las regiones, incluyendo los eventos de datos (acceso a S3 y DynamoDB) para los recursos más sensibles, y centralizar los logs en una cuenta separada con acceso restringido para evitar que un actor malicioso cubra sus huellas borrando los registros.

La diferencia entre un incidente que se detecta en horas y uno que se descubre meses después es casi siempre la calidad de los registros y la capacidad de correlacionarlos. No hay SIEM ni analista de seguridad que funcione sin logs completos y bien estructurados.

Gestión de secretos y credenciales en la nube

La exposición accidental de credenciales cloud (access keys de AWS, connection strings de bases de datos, API keys de servicios) es uno de los vectores de compromiso más frecuentes. El patrón típico: un desarrollador sube código a un repositorio Git con una access key de AWS hardcodeada en el archivo de configuración. En minutos, bots automatizados que escanean continuamente los commits públicos de GitHub encuentran la credencial y despliegan instancias para minar criptomonedas.

La práctica correcta es nunca almacenar credenciales en el código o en archivos de configuración versionados. Para aplicaciones que se ejecutan en la nube, el mecanismo preferido son los roles IAM asignados a la instancia o función: el código obtiene credenciales temporales del servicio de metadatos de la instancia sin necesidad de credenciales estáticas. Para credenciales de terceros (APIs externas, bases de datos), los gestores de secretos (AWS Secrets Manager, Azure Key Vault, HashiCorp Vault) son el estándar.

• Activa git-secrets o equivalente en los repositorios para prevenir commits accidentales de credenciales.
• Usa roles IAM de instancia o de función para las aplicaciones que se ejecutan en la nube: nunca credenciales estáticas embebidas.
• Almacena todas las credenciales de terceros en un gestor de secretos con rotación automática.
• Activa AWS GuardDuty o Microsoft Defender for Cloud para detectar uso anómalo de credenciales (acceso desde IPs inusuales, horarios atípicos).
• Revisa periódicamente las access keys activas en IAM y elimina las que no se usan hace más de noventa días.

Seguridad de red en la nube

La configuración de la red cloud es responsabilidad del cliente. Los grupos de seguridad, las Network ACLs, la configuración de las VPCs y las reglas de firewall determinan qué tráfico puede entrar y salir de cada recurso. Una mala configuración de red es el origen de muchos incidentes de exposición de datos: instancias con puertos de administración (SSH, RDP) abiertos a internet, bases de datos accesibles desde fuera de la red privada o servicios internos expuestos accidentalmente.

El principio de defensa en profundidad aplica también en la nube: múltiples capas de control de red reducen la probabilidad de que un error en una capa resulte en una exposición completa. La combinación de VPCs con subredes privadas y públicas bien segmentadas, grupos de seguridad con el principio de mínimo privilegio y WAF (Web Application Firewall) para las aplicaciones web expuestas es la arquitectura de referencia.

Marcos de referencia y cumplimiento normativo

Los proveedores cloud están certificados contra múltiples marcos de seguridad (ISO 27001, SOC 2, PCI DSS, ENS en España para la Administración pública). Estas certificaciones cubren la infraestructura del proveedor, pero no la configuración que el cliente hace de los servicios. Una empresa puede usar AWS, que está certificado ISO 27001, y aun así tener una postura de seguridad deficiente si no implementa correctamente los controles de su parte del modelo compartido.

Para el cumplimiento con el RGPD, el uso de cloud no exime al responsable del tratamiento de sus obligaciones. Debe asegurarse de que el proveedor actúa como encargado del tratamiento con un DPA (Data Processing Agreement) firmado, que los datos no se transfieren a países sin nivel de protección adecuado sin las salvaguardias correspondientes, y que los controles técnicos implementados son apropiados para el riesgo de los datos tratados.

Construir una cultura de seguridad cloud en el equipo

Los controles técnicos son necesarios pero no suficientes. La seguridad cloud depende también de que los equipos de desarrollo y operaciones entiendan el modelo de responsabilidad compartida y apliquen buenas prácticas de forma sistemática. Esto requiere formación continua, procesos claros y herramientas que faciliten hacer las cosas bien por defecto.

El enfoque DevSecOps integra los controles de seguridad en el pipeline de desarrollo desde el principio, en lugar de añadirlos como una capa adicional al final. Esto incluye el escaneo de vulnerabilidades en las imágenes de contenedores, el análisis estático de seguridad en el código, la validación de la configuración de infraestructura como código antes de aplicarla y la inclusión de revisiones de seguridad en el proceso de pull request.

Conclusión: la seguridad cloud es una responsabilidad activa

El modelo de responsabilidad compartida no es una forma de transferir la responsabilidad de la seguridad: es un marco que define con claridad qué debe proteger el proveedor y qué debe proteger el cliente. Los proveedores cloud cumplen su parte de forma rigurosa; la mayoría de los incidentes de seguridad cloud se producen en la parte del cliente, por configuraciones incorrectas, credenciales mal gestionadas o falta de visibilidad sobre el entorno.

Adoptar cloud con madurez de seguridad significa asumir activamente la responsabilidad de los controles que corresponden al cliente: gestión de identidades con mínimo privilegio, configuración segura de todos los servicios, cifrado de datos sensibles, registro y monitorización de la actividad, y gestión rigurosa de secretos y credenciales. Con estos controles en marcha, el cloud no solo es igual de seguro que un datacenter propio: en muchos aspectos es más seguro, por la calidad de las herramientas disponibles y la visibilidad que ofrece sobre el entorno.