Conceptos

Modelo de responsabilidad compartida

#cloud#defense#iam#risk

Marco que divide responsabilidades de seguridad entre el proveedor cloud y el cliente según el servicio consumido (IaaS, PaaS, SaaS).

Definición

Marco que divide responsabilidades de seguridad entre el proveedor cloud y el cliente según el servicio consumido (IaaS, PaaS, SaaS).

Idea clave: el proveedor suele responsabilizarse de la seguridad del cloud (infraestructura subyacente), mientras que el cliente se responsabiliza de la seguridad en el cloud (configuración, identidades y datos).

Contexto

  • Evita lagunas de control en la nube al aclarar quién protege qué (hardware, red, sistema operativo, aplicaciones, datos).
  • Cubre identidades, configuraciones, parcheo, respaldo y cumplimiento.
  • Se usa como base para aterrizar controles en Cloud Security Fundamentals.

Desarrollo (MIT-style)

Responsabilidades por modelo (visión práctica)

  • IaaS: el cliente gestiona SO, parches, hardening, red virtual, identidades y datos; el proveedor asegura hardware, red física y hypervisor.
  • PaaS: el proveedor gestiona runtime y parches de plataforma; el cliente gestiona código, identidades, configuración del servicio y datos.
  • SaaS: el proveedor gestiona aplicación, plataforma y SO; el cliente gestiona cuentas, roles, configuración de seguridad (p.ej., MFA) y datos.

Tabla mental (qué capa suele gestionar el cliente)

Capa / control IaaS (cliente) PaaS (cliente) SaaS (cliente)
Identidades (IAM), MFA, SSO Sí Sí Sí
Configuración de seguridad del servicio Sí Sí Sí
Datos (clasificación, acceso, retención) Sí Sí Sí
Aplicación (código) Sí Sí No (salvo configuración)
Runtime / middleware Depende No No
Sistema operativo Sí No No
Virtualización / hypervisor No No No
Infraestructura física No No No

Notas:

  • “Depende” porque hay servicios híbridos/gestionados (p.ej., bases de datos gestionadas en IaaS).
  • El reparto exacto varía por proveedor y por servicio: documentar siempre “por servicio”.

Buenas prácticas

  • Documentar la matriz de responsabilidades por servicio y validar con el proveedor.
  • Configurar identidades, MFA y mínimos privilegios siempre a cargo del cliente.
  • Revisar configuraciones por defecto (público/privado), cifrado y logging.
  • Probar restauraciones de backup y cumplir con requisitos regulatorios sobre datos.

Pitfalls / Errores comunes

  • Asumir que el proveedor cubre la seguridad de datos y cuentas de usuario.
  • Configurar SaaS sin MFA ni roles mínimos, dejando puerta a abuso (account takeover).
  • No parchear imágenes propias en IaaS pensando que el proveedor lo hace.
  • No revisar cambios en términos del proveedor (nuevos servicios, responsabilidades).
  • No activar logs/auditoría del plano de control (p.ej., llamadas API) y perder trazabilidad.

Diagrama

flowchart LR
  A[Proveedor: seguridad del cloud\\n(infraestructura física, red física, hypervisor)] --> B[Cliente: seguridad en el cloud\\n(IAM, configuración, datos, logging)]
  B --> C[IaaS/PaaS/SaaS\\n(se mueve la frontera)]

Referencias

  1. AWS/Azure/GCP Shared Responsibility Model
Título original en mis apuntes: Shared Responsibility Model