Seguridad e identidad en la nube
Trabajar en la nube cambia el modelo de seguridad: ya no controlas el servidor físico, pero sí controlas quién accede, cómo se guardan los datos y cómo está configurado todo lo que desplegas. Entender esa frontera evita el error más caro: asumir que "la nube es segura por sí sola".
Modelo de responsabilidad compartida
La línea divisoria se mueve según el modelo de servicio. En IaaS tú gestionas hasta el sistema operativo; en SaaS el proveedor gestiona casi todo, pero en ningún modelo delegas tus datos, tus accesos ni tu configuración.
| Capa | Responsabilidad del proveedor | Responsabilidad del cliente |
|---|---|---|
| Datos | Infraestructura que los almacena | Contenido, clasificación y respaldo |
| Acceso e identidad | Mecanismos (IAM, MFA) | Quién tiene qué permisos |
| Configuración | Seguridad de los servicios | Cómo los configuras y expone |
| Cómputo y red | Física, hipervisor, regiones | Grupos de seguridad, reglas, parches (según modelo) |
IAM: quién puede hacer qué
Identity and Access Management (IAM) define identidades y permisos. En vez de dar un acceso enorme a un usuario, se usan roles con políticas que conceden acciones específicas sobre recursos concretos.
- Principio de mínimo privilegio: solo los permisos estrictamente necesarios.
- Grupos y roles en lugar de permisos individuales: se hereda y se audita mejor.
- Separación de funciones: quien despliega no es quien aprueba cambios sensibles.
- Rotación y alcance: políticas revisadas, accesos que expiran.
Credenciales: que no vivan en el código
La causa clásica de brechas es una clave de acceso escrita en el código y subida al repositorio. La alternativa es usar credenciales temporales (STS), perfiles de rol y almacenes de secretos, además de MFA para accesos privilegiados.
Cifrado de datos
Los datos deben ir cifrados en tránsito (TLS entre servicios) y en reposo (almacenados). La gestión de llaves se apoya en un KMS; en modelos BYOK/HYOK el cliente conserva el control de las claves, no solo del texto cifrado.
- En tránsito: TLS para cualquier llamada entre servicios o con usuarios.
- En reposo: cifrado transparente del almacenamiento y de bases de datos.
- Gestión de claves: KMS, rotación y separación entre datos y llaves.
La brecha típica es de configuración
Los informes de incidentes coinciden: la mayoría de exposiciones en la nube no son fallos del proveedor sino errores humanos de configuración.
- Bucket de almacenamiento público con datos sensibles.
- Puerto abierto a Internet (por ejemplo, SSH 22) sin restricción de origen.
- Rol con permisos administrativos asignado a una carga de trabajo que no los necesita.
Gobierno y visibilidad
No se puede proteger lo que no se ve. Etiquetar recursos (tagging), segmentar cuentas por entorno y activar registros de auditoría permiten detectar desviaciones antes de que se vuelvan incidentes.
Errores frecuentes
- Creer que "está en la nube, entonces es seguro".
- Reutilizar credenciales de administración para tareas cotidianas.
- Dejar reglas de red abiertas "temporalmente" durante desarrollo.
Ejemplo resuelto: asegurar un bucket con datos de clientes
- Activar el bloqueo de acceso público a nivel de cuenta.
- Restringir el bucket con una política que solo acepte solicitudes autenticadas.
- Exigir cifrado en reposo con llaves gestionadas por el cliente.
- Otorgar acceso por rol con mínimo privilegio y MFA, no por clave compartida.
- Encender registros de auditoría y una alerta ante cambios de política.
¿Para qué sirve en la realidad?
Diseñar con la frontera de responsabilidad clara permite preguntar no "¿es seguro este servicio?" sino "¿cómo lo configuré yo?", que es donde casi siempre está el riesgo.
En el modelo de responsabilidad compartida, ¿qué es SIEMPRE responsabilidad del cliente?
Al migrar a SaaS, el cliente transfiere al proveedor la responsabilidad sobre quién accede a sus datos.
El principio de IAM que concede solo los permisos estrictamente necesarios se llama de mínimo .
Clasifica cada responsabilidad según a quién corresponde.
Proveedor
Cliente
Une cada concepto con su propósito.
Seguridad en la nube
Responsabilidad, identidad, cifrado y configuración
# Seguridad en la nube ## Responsabilidad ### el proveedor: de la nube ### tu cliente: en la nube ## IAM ### minimo privilegio ### roles y politicas ### MFA y credenciales temporales ## Cifrado ### en transito TLS ### en reposo y KMS ## Configuracion ### bucket publico ### puertos abiertos ### roles sobrepermitidos
Modelo de responsabilidad compartida (AWS)
Descripción oficial de qué capa cuida el proveedor y qué capa el cliente.
Buenas prácticas de IAM (AWS)
Guía de referencia sobre identidades, roles, credenciales y mínimo privilegio.
Un equipo de datos publicó sin querer un bucket con archivos de clientes porque "así funcionaba en desarrollo". ¿Qué controles técnicos y qué política de responsabilidad compartida propondrías para que no vuelva a pasar sin frenar la productividad?