Si alguna vez has pensado que por subir tu base de datos a la nube ya puedes dormir tranquilo como si un equipo de fuerzas especiales custodiara tus bits, tengo una mala noticia: te has creído el cuento de hadas.
La nube, en esencia, es solo «el ordenador de otro». Un ordenador muy grande, muy redundante y gestionado por genios, sí, pero que sigue estando sujeto a las leyes de la física y, sobre todo, a las leyes de la responsabilidad compartida (shared responsibility). Si dejas la puerta de tu instancia abierta de par en par, no puedes culpar a Amazon de lo que pueda ocurrir.
En este artículo vamos a diseccionar ese contrato invisible que firmas cuando haces clic en «Aceptar términos y condiciones» (ese texto que nadie lee hasta que llega la notificación de la brecha de datos). Veremos dónde termina el trabajo del proveedor y dónde empieza tu labor para que tu infraestructura tenga unos mínimos de seguridad aceptables.
Índice de contenidos
¿Qué es el Modelo de Responsabilidad Compartida (Shared Responsibility Model)?
El modelo de responsabilidad compartida es el marco de trabajo que define qué tareas de seguridad corresponden al proveedor de servicios en la nube (CSP – Cloud Service Provider) y cuáles recaen sobre ti, el cliente.
La peligrosa ilusión de la «Nube Mágica»
Muchos directivos ven la nube como un agujero negro de problemas: tú lanzas allí tus aplicaciones y los problemas desaparecen. Error. El CSP se encarga de la seguridad «de» la nube (Security OF the Cloud): la infraestructura física, los centros de datos, los cables, los generadores eléctricos y el software que hace que la virtualización funcione.
Tú, por el contrario, eres el dueño absoluto de la seguridad «en» la nube (Security IN the Cloud). Esto incluye tus datos, la configuración de tus cortafuegos (firewalls), la gestión de identidades y accesos (identity and access management – IAM) y el parcheo de tus sistemas operativos.
Básicamente, si AWS fuera un hotel, ellos se aseguran de que el edificio no se caiga y que nadie entre por la puerta principal sin permiso, pero si tú le das una copia de la llave de tu habitación al primer desconocido que pasa por el pasillo, el problema es tuyo.
Para entender el estándar de la industria sobre estas divisiones, la Cloud Security Alliance (CSA)
ofrece recursos excelentes y guías agnósticas que todo arquitecto cloud debería tener en su mesita de noche.
IaaS, PaaS y SaaS: Quién limpia qué en esta casa
Dependiendo del modelo de servicio que elijas, tu carga de trabajo será mayor o menor. No es lo mismo alquilar un terreno vacío que una suite con servicio de habitaciones.
Infraestructura como Servicio (IaaS): Eres el rey de tu castillo (y de sus goteras)
En el modelo IaaS (Infrastructure as a Service), el proveedor te da el hierro (servidores, almacenamiento y red). A partir de ahí, la pelota está en tu tejado.
- Tu responsabilidad: Instalar el sistema operativo, actualizarlo (patching), configurar el firewall de la instancia, gestionar las bases de datos y, por supuesto, proteger los datos.
- Analogía: Es como alquilar un piso vacío. Si no cierras la ventana y entra un ladrón, el casero no tiene la culpa.
Plataforma como Servicio (PaaS): El pacto de no agresión
En PaaS (Platform as a Service), como Azure App Service o Google App Engine, tú solo te preocupas de tu código y de tus datos. El proveedor gestiona el sistema operativo, el middleware y el entorno de ejecución (runtime).
- Tu responsabilidad: La seguridad de tu código (¡cuidado con las inyecciones SQL!), la configuración de la aplicación y el acceso de los usuarios.
- Analogía: Alquilar un piso amueblado. No te preocupas de pintar las paredes, pero sí de quién tiene las llaves y de no dejar la cocina encendida.
Software como Servicio (SaaS): Solo te queda cuidar las llaves y los muebles
En SaaS (Software as a Service), como Microsoft 365 o Salesforce, casi todo es responsabilidad del proveedor. Ellos mantienen la aplicación, la infraestructura y la plataforma.
- Tu responsabilidad: Tus datos, tus usuarios y sus permisos. Si un empleado usa una contraseña tipo «123456» y le roban la cuenta, no llames a Microsoft llorando. La gestión de identidad (identity management) sigue siendo tu cruz.
- Analogía: Quedarse en un hotel. Tú solo te encargas de tus maletas y de no dejar la caja fuerte abierta.
Los Tres Mosqueteros del Cloud: AWS, Azure y Google Cloud
Aunque el concepto base es el mismo, cada gigante tiene su propia forma de explicarlo (y sus propias matrices para que sepas a quién insultar si algo falla).
Amazon Web Services (AWS): Seguridad «de» vs. seguridad «en»
AWS es el padre de este concepto. Su modelo es binario y muy claro: ellos protegen la infraestructura global (regiones, zonas de disponibilidad y ubicaciones de borde – edge locations) y tú proteges lo que pongas encima. Si no configuras bien tus grupos de seguridad (security groups), estás básicamente gritando «hacker, ven y llévatelo».
Referencia oficial: AWS Shared Responsibility Model
Microsoft Azure: El enfoque corporativo y granular
Azure pone mucho énfasis en que, independientemente del modelo (IaaS, PaaS o SaaS), el cliente siempre es responsable de sus datos, sus identidades y sus dispositivos finales (endpoints). No importa lo que contrates, la protección de la información (information protection) no es negociable para ellos.
Referencia oficial: Azure Shared Responsibility
Google Cloud: Del riesgo compartido al «Destino Compartido» (Shared Fate)
Google ha intentado ir un paso más allá con su concepto de Shared Fate (Destino Compartido). Básicamente, dicen: «Si tú fallas, nosotros también quedamos mal». Por eso ofrecen más herramientas de seguridad por defecto y plantillas configuradas (blueprints) para que no metas la pata tan fácilmente. Pero no te equivoques: si borras tu base de datos por error, Google no va a aparecer con una varita mágica.
Referencia oficial: Google Cloud Trust Center
Casos del Mundo Real: Cuando la confianza mata al gato
Para entender esto, nada mejor que ver cómo la gente se ha arruinado la vida por no entender dónde acababa su responsabilidad.
El drama de los Buckets S3 abiertos: «Cariño, nos han robado los Gigas»
Este es el clásico. AWS te da un servicio de almacenamiento (S3). Por defecto, son privados, pero el usuario —en un alarde de «necesito que esto funcione rápido»— los pone en modo público.
- Resultado: Millones de registros de clientes expuestos en Internet.
- Lección: AWS cumplió su parte (el servicio funcionaba), pero tú fallaste en la configuración de la lista de control de acceso (access control list – ACL). Es como tener una caja fuerte de 2 toneladas y dejarla abierta en medio de la Gran Vía.
Credenciales en GitHub: El equivalente a dejar las llaves puestas
Un desarrollador sube código a un repositorio público y, por «comodidad», deja las claves de acceso (access keys) de la cuenta de administrador integradas en el código. Los bots de los atacantes tardan segundos en encontrarlas.
- Fragmento de código que NO debes usar ( Hardcoding):
Los bots automatizados rastrean GitHub 24/7 buscando estas cadenas. En menos de cinco minutos, alguien estará levantando instancias gigantes en tu cuenta de AWS para minar Bitcoin, y la factura a fin de mes te hará llorar. La solución pasa por usar bóvedas de secretos (Secrets Management) o variables de entorno gestionadas.
# ERROR FATAL: Esto es un regalo envuelto para los atacantes
import boto3
aws_access_key_id = "AKIAIOSFODNN7EXAMPLE"
aws_secret_access_key = "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
s3 = boto3.client('s3', aws_access_key_id=aws_access_key_id, aws_secret_access_key=aws_secret_access_key)- Uso correcto: Utilizar variables de entorno o servicios de gestión de secretos (secret management) como AWS KMS (Key Management System) o Azure Key Vault.
Checklist: Cómo no arruinar tu despliegue en la nube
Si no quieres ser el protagonista del próximo boletín de noticias de ciberseguridad, sigue esta lista:
- MFA (Multi-Factor Authentication) en TODO: Si alguien tiene acceso a tu consola de administración solo con usuario y contraseña, ya estás tardando en activar el segundo factor.
- Principio de Mínimo Privilegio (Least Privilege): No le des permisos de administrador a todo el mundo. El becario no necesita borrar bases de datos en producción.
- Cifrado (Encryption) en reposo y en tránsito: Si los datos son tuyos, asegúrate de que sean ilegibles para cualquier otro.
- Monitorización y Logs: Si alguien entra, al menos querrás saber cómo lo hizo. Activa servicios como CloudTrail (AWS) o Azure Monitor.
- Parcheo automático: En IaaS, configura actualizaciones automáticas. Un servidor sin parches es un imán para el malware.
- Automatiza la seguridad (DevSecOps): No confíes en configuraciones manuales. Usa infraestructura como código (Terraform, CloudFormation) y escanea en busca de vulnerabilidades antes de desplegar.
Conclusión: La nube es el ordenador de otro, pero la multa de la AEPD es tuya
Migrar a la nube no es delegar la seguridad; es transformar cómo la gestionas. El modelo de responsabilidad compartida es, en el fondo, la letra pequeña que te recuerda que los datos son tuyos.
Si se filtran los datos personales de tus clientes por un servidor mal configurado, la Agencia Española de Protección de Datos (AEPD) no va a multar a Jeff Bezos ni a Satya Nadella. La multa llevará tu nombre.
Aprende a diferenciar el cemento que te da el proveedor de las cerraduras que debes poner tú. Mantén la paranoia en niveles saludables, aplica el mínimo privilegio y asume siempre que la configuración por defecto de cualquier servicio está diseñada para la facilidad de uso, no para la seguridad extrema.
