El caso
La nube era segura. La hoja de clientes quedó pública.
Isaac guardó la hoja de clientes de la tienda en un almacenamiento en la nube y, para que un socio bajara el archivo más rápido, dio acceso a cualquiera que tuviera el enlace. Semanas después, los datos de los clientes aparecieron en un foro.
El centro de datos del proveedor nunca fue vulnerado. La puerta que quedó abierta era de Isaac.
Este post parte de Fundamentos de la nube y de Modelos de servicio en la nube.
El problema
La nube segura no significa datos seguros
Los proveedores gastan en seguridad mucho más de lo que una tienda pequeña podría: guardias, cámaras, energía redundante, equipos dedicados, hardware reemplazado antes de fallar. Eso no impide que Isaac exponga sus propios datos con una configuración equivocada.
La mayoría de las filtraciones en la nube vienen de la configuración y del acceso, y no de un ataque a la infraestructura del proveedor.
La solución
Responsabilidad compartida
Todo proveedor trabaja con el mismo principio, el modelo de responsabilidad compartida (shared responsibility model). Divide la seguridad en dos partes:
- Seguridad de la nube (security of the cloud): es del proveedor. Incluye el edificio, el hardware, la red global y la virtualización.
- Seguridad en la nube (security in the cloud): es tuya. Incluye los datos que pones allí, quién puede acceder a ellos y cómo configuras los servicios.
La línea entre las dos partes es la misma que en la pila de Modelos de servicio en la nube: cuanto más administrado es el servicio, más capas asume el proveedor. Solo que dos capas nunca salen de tus manos: los datos y las cuentas de acceso.
Cada proveedor dibuja su propio cuadro, con más o menos líneas. La lógica es la misma: lo que queda bajo tu control queda bajo tu responsabilidad.
Accesos
Quién puede hacer qué
Como los accesos son tuyos, la nube ofrece un servicio solo para eso: el IAM (Identity and Access Management, gestión de identidades y accesos). Responde a dos preguntas: quién eres y qué puedes hacer.
- Identidad (identity): un usuario, un grupo o una aplicación que necesita acceder a algo.
- Política (policy): la regla que dice qué acciones puede hacer esa identidad, y sobre qué recursos.
- Rol (role): un conjunto de permisos que se asigna a una identidad, en lugar de dar permisos uno por uno.
| AWS | Azure | Google Cloud | Oracle Cloud | |
|---|---|---|---|---|
| Servicio de accesos | IAM | Microsoft Entra ID y Azure RBAC | IAM | OCI IAM |
Mínimo privilegio (least privilege)
Da a cada persona y a cada aplicación solo los permisos que necesitan, y solo por el tiempo necesario.
En la tienda: el socio que baja la hoja solo puede leer ese archivo.
Autenticación multifactor (multi-factor authentication, MFA)
Además de la contraseña, un segundo factor: un código en el celular, una llave física. Una contraseña filtrada deja de bastar.
En la tienda: el panel de la nube pide contraseña y código.
Cuenta raíz resguardada (root account)
La cuenta que creó todo tiene poder total. Protégela con MFA y usa cuentas comunes en el día a día.
En la tienda: solo Isaac sabe la contraseña de la cuenta raíz, y casi nunca la usa.
Credenciales temporales (temporary credentials)
Las llaves de acceso que no vencen se filtran y se olvidan. Prefiere credenciales que valgan por poco tiempo.
En la tienda: el sistema de pedidos recibe un rol, en lugar de una llave pegada en el código.
No los confundas
Autenticación × autorización
Dos términos que los exámenes adoran intercambiar. Los dos ocurren en secuencia, y cada uno responde a una pregunta diferente.
Autenticación (authentication)
“¿Eres quien dices ser?”
- Ejemplo
- Entrar al panel con contraseña y un código del celular.
- Foco
- Probar la identidad.
Autorización (authorization)
“¿Qué puedes hacer?”
- Ejemplo
- Poder leer los archivos, pero no borrarlos.
- Foco
- Definir los permisos una vez identificado.
En la práctica
Qué hacer en cada situación
| Situación | Qué hacer |
|---|---|
| Un socio necesita bajar un archivo | Dar permiso de lectura solo a ese archivo, y por tiempo limitado |
| Un servicio necesita llamar a otro | Asignar un rol al servicio, sin llave fija en el código |
| La cuenta raíz se usó en el día a día | Crear cuentas comunes, activar MFA en la raíz y resguardarla |
| Una persona cambió de función | Revisar sus permisos, en lugar de sumar los nuevos a los antiguos |
Términos clave
Seis términos para recordar
Toca la tarjeta para ver la definición.
Prueba rápida
Tres preguntas, estilo examen
01
Una empresa usa un software SaaS. ¿Quién es responsable de los datos que guarda en él?
02
Un desarrollador solo necesita leer archivos de un almacenamiento. ¿Qué permiso aplica el mínimo privilegio?
03
¿Cuál de estas responsabilidades es del proveedor en cualquier modelo de servicio?
La pregunta de examen sobre seguridad suele ser la misma: ¿de quién es la responsabilidad? La respuesta sigue la pila. El proveedor asume las capas más bajas, y tú nunca te libras de los datos ni de los accesos. Con el IAM, el mínimo privilegio y el MFA bien configurados, muchas filtraciones como la de Isaac dejan de ocurrir. El próximo paso de la ruta es Almacenamiento en la nube.