El mito que abre la puerta
"Está en AWS/Azure/GCP, así que está seguro." Esta frase, repetida en comités de decisión y en equipos técnicos, es la raíz de buena parte de los incidentes de seguridad en la nube. No porque los proveedores fallen en su parte, sino porque la mayoría de las empresas nunca definió cuál es su parte.
El modelo de responsabilidad compartida no es letra chica del contrato: es la arquitectura de seguridad real de todo lo que corre en la nube. Ignorarlo no elimina el riesgo, solo lo traslada a un punto ciego.
Qué cubre el proveedor (y qué no)
Los hyperscalers (AWS, Azure, GCP) son responsables de la seguridad de la nube:
- Infraestructura física: datacenters, hardware, redes troncales.
- Virtualización y aislamiento entre tenants.
- Disponibilidad de los servicios core (cómputo, almacenamiento, red).
- Parcheo del hipervisor y capas por debajo del sistema operativo del cliente.
Lo que el proveedor no hace por vos es la seguridad en la nube, y ahí es donde vive la mayoría de las brechas reales:
- Configuración de buckets, bases de datos y storage (permisos públicos por defecto o mal seteados).
- Gestión de identidades y accesos (IAM): roles sobre-permisionados, credenciales hardcodeadas, falta de rotación de claves.
- Cifrado de datos en tránsito y en reposo cuando no viene activado por default.
- Parcheo del sistema operativo, runtime y dependencias de tu aplicación.
- Segmentación de red interna, reglas de firewall, exposición innecesaria de puertos.
- Logging, monitoreo y respuesta a incidentes sobre tu propia carga de trabajo.
El desglose cambia según el modelo
La línea divisoria no es fija: se mueve según qué tipo de servicio consumís.
| Capa | IaaS | PaaS | SaaS |
|---|---|---|---|
| Datos y accesos | Cliente | Cliente | Cliente |
| Aplicación | Cliente | Cliente | Proveedor |
| Runtime / middleware | Cliente | Proveedor | Proveedor |
| Sistema operativo | Cliente | Proveedor | Proveedor |
| Infraestructura física | Proveedor | Proveedor | Proveedor |
Cuanto más gestionado es el servicio, más responsabilidad asume el proveedor, pero nunca cero para vos. Incluso en SaaS, la gestión de usuarios, permisos y configuración de la aplicación sigue siendo tuya.
Dónde aparecen los agujeros en la práctica
En una auditoría de infraestructura cloud, los hallazgos más frecuentes no son fallas del proveedor, sino decisiones (o falta de ellas) del lado del cliente:
- Buckets de storage sin política de acceso explícita.
- Claves de API o secrets versionados en el repositorio de código.
- Roles de IAM con permisos de administrador asignados "para que funcione y ya".
- Ausencia de logging centralizado, lo que hace imposible reconstruir un incidente.
- Backups sin cifrar o sin pruebas de restauración.
Ejemplo hipotético: una empresa migra su base de datos a un servicio gestionado y asume que, al estar en la nube, ya está protegida. Nadie revisó que el bucket de backups automáticos quedó con acceso público por configuración default. El proveedor cumplió su parte —la infraestructura funcionó sin fallas— pero la exposición de datos fue 100% responsabilidad del cliente.
Qué hacer con esto
El punto de partida no es "contratar más seguridad", sino mapear exactamente dónde termina la responsabilidad del proveedor y empieza la tuya, servicio por servicio. Eso implica:
- Auditar configuración de IAM, storage y redes contra el modelo de responsabilidad específico de cada servicio contratado.
- Automatizar el chequeo de configuraciones críticas (policy as code) en vez de depender de revisiones manuales.
- Definir gobernanza clara: quién es dueño de qué control, con qué frecuencia se revisa, y qué pasa cuando algo cambia.
- Documentar el reparto de responsabilidades como parte del proceso de despliegue, no como un anexo legal que nadie lee.
La nube no es insegura ni segura por definición: es tan segura como la claridad que tengas sobre qué parte del sistema depende de vos. En Tinto & Bots trabajamos justamente ese cruce —auditoría de procesos, despliegue cloud y gobernanza— para que esa línea divisoria deje de ser un supuesto y se convierta en un control verificable.