1. Introducción
La seguridad en la nube es uno de los aspectos más importantes de cualquier proyecto cloud. No basta con desplegar una aplicación o crear una base de datos: también hay que proteger identidades, credenciales, datos, comunicaciones y operaciones.
Un error habitual es pensar que, por usar AWS, Azure o Google Cloud, la seguridad ya está “resuelta”. Los proveedores protegen una parte enorme de la infraestructura, sí, pero eso no elimina la responsabilidad del cliente.
La nube no elimina los riesgos. Los transforma.
Antes la seguridad se centraba en el perímetro. En cloud, el perímetro se difumina: recursos distribuidos, usuarios desde múltiples ubicaciones y decisiones de seguridad definidas por roles, políticas, cifrado y automatización.
Por eso, en seguridad cloud hay que hacerse preguntas operativas:
- ¿Quién puede acceder?
- ¿Desde dónde?
- ¿Con qué permisos?
- ¿Qué datos puede leer/modificar?
- ¿Hay MFA?
- ¿Los datos están cifrados?
- ¿Se registran accesos y cambios?
- ¿Cumplimos normativa?
Muchos incidentes cloud no ocurren por fallo del proveedor, sino por configuraciones inseguras del cliente: permisos excesivos, buckets públicos, claves en repositorios o cuentas antiguas activas.
2. Concepto clave
El concepto central es el modelo de responsabilidad compartida:
- El proveedor protege la nube.
- El cliente protege lo que hace en la nube.
Esquema básico del modelo de responsabilidad compartida
┌─────────────────────────────────────────────┐ │ PROVEEDOR CLOUD │ │ │ │ Seguridad física del centro de datos │ │ Red global │ │ Hardware │ │ Refrigeración y energía │ │ Hipervisor │ │ Servicios gestionados base │ └─────────────────────────────────────────────┘
┌─────────────────────────────────────────────┐ │ CLIENTE │ │ │ │ Usuarios y contraseñas │ │ MFA │ │ Roles y permisos │ │ Configuración de recursos │ │ Datos │ │ Cifrado │ │ Código de aplicación │ │ Logs y auditoría │ └─────────────────────────────────────────────┘
La frontera cambia según IaaS/PaaS/SaaS.
Seguridad “de la nube” y seguridad “en la nube”
| Tipo de seguridad | Responsable principal | Ejemplos |
|---|---|---|
| Seguridad de la nube | Proveedor | CPD, hardware, red física, hipervisor |
| Seguridad en la nube | Cliente | Identidades, permisos, cifrado, configuración, datos |
Responsabilidad según modelo cloud
Capa IaaS PaaS SaaS ────────────────────────────────────────────────────────────── Centro de datos Proveedor Proveedor Proveedor Hardware Proveedor Proveedor Proveedor Red física Proveedor Proveedor Proveedor Virtualización Proveedor Proveedor Proveedor Sistema operativo Cliente Proveedor Proveedor Runtime / plataforma Cliente Proveedor Proveedor Aplicación Cliente Cliente Proveedor Usuarios y permisos Cliente Cliente Cliente Datos Cliente Cliente Cliente Configuración de seguridad Cliente Cliente Cliente
Los tres pilares de la seguridad
La tríada CIA:
- Confidencialidad: accede quien debe acceder.
- Integridad: los datos no se alteran sin autorización.
- Disponibilidad: el servicio funciona cuando se necesita.
SEGURIDAD │ ┌───────────────┼───────────────┐ ▼ ▼ ▼ Confidencialidad Integridad Disponibilidad │ │ │ Quién accede Datos correctos Servicio activo │ │ │ MFA, cifrado, Logs, hashes, Redundancia, permisos auditoría backups, HA
Zero Trust y seguridad como código
En cloud moderno:
- Zero Trust: no confiar por defecto; verificar siempre.
- Seguridad como código: políticas y controles versionados, revisables y automatizables.
3. Ejemplo mínimo
Una VM pública para prácticas puede ser insegura si:
- SSH abierto a Internet
- contraseña débil
- sin MFA
- sin actualizaciones
- sin logs
- sin backups
Situación insegura Internet │ ▼ Máquina virtual pública │ ├── SSH abierto a todo Internet ├── Usuario admin + contraseña débil ├── Sin MFA ├── Sin actualizaciones ├── Sin backups └── Sin logs
Configuración más segura:
- firewall/grupo de seguridad
- SSH limitado por IP
- MFA en cuenta cloud
- usuario no privilegiado por defecto
- logs activos
- backups automáticos
- mínimo privilegio
4. Ejemplo completo
Para una plataforma educativa AulaSegura Cloud, la seguridad debe diseñarse por capas.
Esquema general de seguridad
Usuarios │ ├── Alumnos ├── Profesores └── Administradores │ ▼ Autenticación (MFA/SSO) │ ▼ Autorización (IAM/roles/políticas) │ ▼ Aplicación (HTTPS, validación, parches) │ ▼ Datos (cifrado, backups, versionado, auditoría) │ ▼ Monitorización y cumplimiento (RGPD/ENS)
Autenticación, autorización y federación
| Concepto | Pregunta | Ejemplo |
|---|---|---|
| Autenticación | ¿Quién eres? | Usuario + contraseña + MFA |
| Autorización | ¿Qué puedes hacer? | Leer bucket, no borrar |
| Federación | ¿Identidad externa válida? | Login con cuenta institucional |
IAM: usuarios, grupos, roles, políticas
| Elemento | Descripción | Ejemplo |
|---|---|---|
| Usuario | Identidad individual | ivan.profesor |
| Grupo | Conjunto con permisos comunes | Profesores, Alumnos |
| Rol | Permisos temporales | AdminTemporal |
| Política | Reglas de acceso | solo lectura en bucket |
Ejemplo correcto (principio mínimo privilegio):
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:ListBucket", "s3:GetObject"],
"Resource": ["arn:aws:s3:::bucket-aula/*"]
}
]
}Mal ejemplo (peligroso):
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}Gestión de secretos y credenciales
Nunca guardar secretos en:
- código fuente
- repos públicos
- documentos sin control
Usar:
| Proveedor | Servicio |
|---|---|
| AWS | Secrets Manager |
| Azure | Key Vault |
| Google Cloud | Secret Manager |
Seguridad de datos
Proteger todo el ciclo de vida del dato: creación, almacenamiento, uso, compartición, archivado, borrado.
Cifrado
| Tipo | Protege | Ejemplo |
|---|---|---|
| En reposo | datos almacenados | BBDD cifrada |
| En tránsito | datos en red | HTTPS/TLS |
Gestión de claves:
| Proveedor | KMS |
|---|---|
| AWS | KMS |
| Azure | Key Vault |
| Google Cloud | Cloud KMS |
Buckets privados por defecto
Buenas prácticas:
- bloquear acceso público por defecto
- acceso por roles
- URLs firmadas temporales
- alertas por cambios de permisos
Backups y recuperación
Regla 3-2-1:
- 3 copias
- 2 ubicaciones/medios
- 1 copia fuera del entorno principal
RPO / RTO:
| Concepto | Pregunta |
|---|---|
| RPO | ¿Cuántos datos puedo perder? |
| RTO | ¿Cuánto tiempo puedo estar caído? |
Monitorización, auditoría y respuesta
Registrar y alertar eventos como:
- login sin MFA
- creación de access key
- cambios IAM
- bucket público
- desactivación de logs
- descargas masivas
- incremento inusual de costes
Usuarios y servicios │ ▼ Acciones en cloud │ ▼ Logs de actividad │ ▼ Monitorización ├── Paneles ├── Alertas ├── Informes └── Respuesta
Cumplimiento normativo
| Norma | Ámbito | Objetivo |
|---|---|---|
| RGPD | UE | protección de datos personales |
| ENS | España | seguridad en sector público |
| ISO 27001 | Internacional | SGSI |
| SOC 1/2/3 | Auditoría | controles y evidencias |
La residencia de datos (región elegida) afecta cumplimiento legal. Hay que documentar decisiones y conservar evidencias (políticas, logs, MFA, cifrado, pruebas de restauración).
5. Errores frecuentes
- Pensar que el proveedor se encarga de todo.
- No activar MFA.
- Usar cuentas compartidas.
- Dar admin global por comodidad.
- Dejar recursos públicos accidentalmente.
- Guardar secretos en código/repos.
- No revisar logs.
- No probar backups.
- No clasificar datos.
- Elegir región sin considerar normativa.
6. Buenas prácticas
- Aplicar responsabilidad compartida explícitamente.
- MFA desde el primer día.
- Mínimo privilegio en todo acceso.
- Separar desarrollo/pruebas/producción.
- Proteger y rotar credenciales.
- Cifrado en reposo y tránsito.
- Buckets privados por defecto.
- Monitorización + alertas + auditoría.
- Automatizar controles de seguridad.
- Documentar decisiones y evidencias.
- Formar a usuarios.
7. Ejercicio propuesto
Caso: CloudAula Segura. Diseñar la seguridad de una plataforma educativa cloud.
Tareas:
- Explicar responsabilidad compartida (proveedor vs cliente).
- Diferenciar seguridad de la nube vs en la nube.
- Completar tabla de responsabilidades.
- Definir roles (Alumno, Profesor, Admin) y permisos.
- Indicar MFA obligatorio.
- Diseñar política de mínimo privilegio para almacenamiento.
- Proteger credenciales y secretos.
- Definir cifrado en reposo y tránsito.
- Diseñar backups con RPO/RTO.
- Definir logs y 5 alertas clave.
- Justificar región considerando RGPD.
- Definir evidencias de cumplimiento.
Esquema orientativo
CloudAula Segura │ ├── Identidad (SSO, MFA, revisión de accesos) ├── Autorización (roles + mínimo privilegio) ├── Datos (cifrado, backups, versionado) ├── Aplicación (HTTPS, validación, secretos fuera de código) ├── Monitorización (logs, alertas, revisiones) └── Cumplimiento (RGPD, evidencias, documentación)
Conclusión
La seguridad cloud no es un botón. Es una forma de trabajar:
- diseñar correctamente,
- configurar con criterio,
- monitorizar continuamente,
- auditar,
- y gobernar con disciplina.
La nube puede ser muy segura, pero no por arte de magia: lo es cuando se aplica responsabilidad compartida, MFA, IAM, cifrado, backups, observabilidad y cumplimiento de forma sistemática.