Matriz de Responsabilidad en la Nube

Seguridad compartida, límites claros y control consciente

1. Explicación en profundidad

Como Arquitecta de Seguridad, sé que migrar a la nube no significa externalizar la seguridad, sino compartirla. Esta es la base del modelo de responsabilidad compartida: un marco que define qué parte de la seguridad gestiona el proveedor cloud (CSP) y cuál me corresponde a mí como cliente.

El nivel de responsabilidad varía según el modelo de servicio (SaaS, PaaS, IaaS o FaaS):

— En Software como servicio – Software as a Service (SaaS), el proveedor gestiona todo excepto el control de usuarios, datos y acceso. 👉 Usas directamente aplicaciones completas en la nube sin gestionar nada técnico.

— En Plataforma como servicio – Platform as a Service (PaaS), yo gestiono las aplicaciones y la configuración de acceso, pero no la infraestructura. 👉 El proveedor te da un entorno para desarrollar y desplegar tus propias apps.

— En Infraestructura como servicio – Infrastructure as a Service (IaaS), tengo control sobre sistemas operativos, redes y almacenamiento virtual, pero el proveedor asegura la infraestructura física. 👉 Alquilas servidores, redes y almacenamiento, tú gestionas todo desde el SO hacia arriba.

— En Función como servicio – Function as a Service (FaaS), desarrollo y subo funciones que se ejecutan automáticamente. El proveedor gestiona desde el sistema operativo hasta el escalado y disponibilidad. 👉Subes pequeñas funciones que se ejecutan bajo demanda. Modelo serverless (sin servidor gestionado por ti).

Este modelo no solo es técnico. También es estratégico y legal, porque define el punto de frontera donde mi responsabilidad termina y comienza la del proveedor.

Alegoría realista: La tienda en el centro comercial

Imagina que alquilo un local en un centro comercial:

• En SaaS, alquilo un puesto en una tienda ya montada (yo traigo mis productos y gestiono el mostrador, pero todo lo demás lo hace el centro).

• En PaaS, alquilo un local vacío con instalaciones listas, y yo monto mi tienda como quiero.

• En IaaS, solo tengo el espacio físico, y yo traigo luces, muebles, productos y seguridad.

• En FaaS, simplemente dejo pedidos en el mostrador y el centro comercial los entrega directamente al cliente cuando sea necesario.

Como Arquitecta, debo saber exactamente dónde termina la seguridad del proveedor y empieza la mía. Este límite cambia con cada modelo.

2. Ejemplos prácticos

— SaaS (Microsoft 365):
Gestiono las cuentas de usuario, las políticas de acceso, el doble factor y los permisos para cada servicio.
El proveedor gestiona todo lo demás: servidores, red, parches, backup, actualizaciones.

— PaaS (Google App Engine):
Subo código desarrollado por mi equipo y configuro roles, permisos y secretos.
El proveedor mantiene la base de datos, el entorno de ejecución y la red virtual.

— IaaS (AWS EC2):
Configuro las máquinas virtuales, actualizo el sistema operativo, defino la red interna y aplico las políticas de firewall.
Amazon gestiona los racks físicos, la energía, la seguridad del datacenter, el hipervisor y los routers de core.

— FaaS (AWS Lambda):
Escribo funciones pequeñas que se ejecutan cuando se recibe una solicitud.
Solo configuro el código, el trigger y los permisos. Todo lo demás lo administra el proveedor.

3. Herramientas y soluciones reales

Como Arquitecta de Seguridad, aplico distintas herramientas según el modelo de servicio para cubrir mi área de responsabilidad:

— Control de identidad y acceso
· IAM (AWS, Azure, GCP)
· MFA obligatorio para todos los roles críticos
· Políticas de acceso granular (least privilege)

— Seguridad de aplicaciones y datos
· Cifrado en tránsito y en reposo (TLS, KMS)
· Gestión de claves (HSM, KMS, Vault)
· Validación de entradas y sanitización (OWASP Top 10)

— Sistemas operativos y entornos (IaaS/PaaS)
· Hardening con CIS Benchmarks
· Escaneo de vulnerabilidades con Nessus, Qualys
· Control de parches y actualizaciones

— Supervisión y respuesta
· SIEM centralizado (Elastic, Sentinel, Splunk)
· Monitoreo de funciones (CloudWatch, Stackdriver)
· Alertas por actividad anómala en logs, roles y configuraciones

4. Visión estratégica – Qué hace cada equipo

Red Team (ataque):
— Busca puntos de configuración débil entre el límite de cliente y CSP.
— Explota IAM mal definido, buckets públicos o claves mal protegidas.
— Lanza ataques de escalada entre capas en entornos híbridos mal diseñados.
— Identifica errores de asunción ("el proveedor ya lo protege").

Blue Team (defensa):
— Documenta la matriz de responsabilidades según el modelo contratado.
— Configura alarmas para cambios críticos, accesos no autorizados y anomalías.
— Evalúa periódicamente la postura de seguridad en cada capa: red, VM, app, datos.
— Supervisa backups, redundancia y cumplimiento normativo.

Purple Team (optimización):
— Simula escenarios donde el cliente asume erróneamente que el proveedor protege algo que no está cubierto.
— Automatiza controles para validar continuamente la separación de responsabilidades.
— Verifica que las políticas de cifrado y acceso están aplicadas de forma uniforme.
— Refuerza las auditorías y validaciones entre capas con herramientas de escaneo y análisis contextual.

5. Resumen práctico – Como Arquitecta de Seguridad

La seguridad en la nube no se delega, se reparte.
El modelo de responsabilidad compartida me obliga a tener claridad total sobre qué me corresponde proteger, configurar y monitorear según el servicio utilizado.

— En SaaS, gestiono accesos, usuarios y datos.
— En PaaS, también soy responsable del código y la lógica de negocio.
— En IaaS, controlo el sistema operativo, la red, los parches y el almacenamiento virtual.
— En FaaS, configuro funciones y permisos, asegurando la lógica del evento.

Además:

— Reviso continuamente los SLA, los contratos y las garantías del proveedor.
— Aplico cifrado y segmentación incluso en entornos gestionados.
— Creo documentación clara con la matriz de responsabilidades por servicio.
— No doy nada por hecho: valido, superviso y audito todo lo que me toca.

Como Arquitecta de Seguridad Purple Team, mi trabajo es mantener el control consciente del entorno cloud, entendiendo que la línea entre mi responsabilidad y la del proveedor puede cambiar, pero nunca desaparecer.

🟣 Purple Team – Ejercicios Nivel Experto por Modelo de Servicio

1. SaaS – Software como servicio – Software as a Service (SaaS)

🛡️ Ejercicio: Ataque y detección de abuso de OAuth mal configurado (Red + Blue)

Objetivo: Detectar si es posible comprometer el acceso a una aplicación SaaS (como Microsoft 365 o Google Workspace) abusando de una integración OAuth insegura (por ejemplo, una app maliciosa de terceros).

🔧 Paso a paso:

• Desde el Red Team:

  1. Crea una app OAuth de prueba que solicite permisos amplios (correo, archivos, perfil).

  2. Intenta hacer que un usuario la autorice (phishing simulado o sesión abierta).

  3. Accede a los datos y revisa los tokens.

• Desde el Blue Team:

  1. Revisa los logs del proveedor (audit logs en M365 / Google Admin).

  2. Correlaciona eventos de consentimiento con acceso anómalo a datos.

  3. Configura alertas específicas para nuevas aplicaciones OAuth conectadas.

  4. Usa un CASB para detectar y bloquear apps no aprobadas.

🧠 Resultado esperado:
Detecto que los usuarios pueden autorizar apps peligrosas sin validación. Refuerzo políticas de OAuth (consentimiento previo, whitelisting) y configuro monitorización continua de tokens y eventos sospechosos.

2. PaaS – Plataforma como servicio – Platform as a Service (PaaS)

🛡️ Ejercicio: Simulación de compromiso de entorno CI/CD y despliegue malicioso

Objetivo: Detectar si el pipeline de integración continua permite que código malicioso se inyecte en producción sin detección.

🔧 Paso a paso:

• Desde el Red Team:

  1. Inyecta una dependencia maliciosa en package.json o requirements.txt.

  2. Si se usa un contenedor, añade un reverse shell en Dockerfile.

  3. Sube el código a la rama principal (bypass de revisión, token comprometido).

• Desde el Blue Team:

  1. Configura un sistema de detección en tiempo real para cambios en dependencias.

  2. Asegura el entorno con herramientas como OWASP Dependency-Check, Snyk o SonarQube.

  3. Configura firmas digitales en imágenes y códigos, y revisa logs de builds.

🧠 Resultado esperado:
Fortalezco mi pipeline CI/CD con escaneos automáticos, validación de integridad y alertas por cambios inesperados en código o dependencias antes del despliegue.

3. IaaS – Infraestructura como servicio – Infrastructure as a Service (IaaS)

🛡️ Ejercicio: Simulación de ataque lateral tras compromiso inicial (East-West)

Objetivo: Simular un ataque lateral (lateral movement) dentro de una red virtual mal segmentada para evaluar la efectividad del monitoreo y la segmentación.

🔧 Paso a paso:

• Desde el Red Team:

  1. Compromete una VM expuesta (mediante RCE, credenciales o escaneo de puertos).

  2. Escanea internamente otras VMs dentro de la misma VPC/Subred.

  3. Intenta moverte lateralmente con Pass-the-Hash, SSH o credenciales reutilizadas.

• Desde el Blue Team:

  1. Verifica si hay logs de conexión entre hosts que no deberían comunicarse.

  2. Activa detección de tráfico inusual (east-west) en el firewall interno.

  3. Aplica políticas de microsegmentación con Security Groups, NACLs o Azure NSG.

🧠 Resultado esperado:
Detecto que las VMs están sobrepermisadas y permiten movimiento lateral. Aplico Zero Trust Interno, cierro rutas innecesarias y aplico segmentación lógica y alertas de tráfico entre zonas no autorizadas.

4. FaaS – Función como servicio – Function as a Service (FaaS)

🛡️ Ejercicio: Explotación de función vulnerable expuesta con trigger público (exfiltración silenciosa)

Objetivo: Demostrar cómo una función serverless vulnerable puede ser explotada para exfiltrar datos o escalar privilegios si está expuesta sin protección adecuada.

🔧 Paso a paso:

• Desde el Red Team:

  1. Descubre una función con trigger HTTP abierto (sin autenticación).

  2. Lanza payloads con SQLi, SSRF o extracción de variables de entorno (process.env).

  3. Usa la función para extraer secretos o actuar como proxy a otros recursos.

• Desde el Blue Team:

  1. Analiza logs de invocación para detectar comportamiento anómalo.

  2. Configura WAF o API Gateway con autenticación JWT o firma de requests.

  3. Revisa el código para validar input, usar principio de mínimo privilegio y no exponer variables sensibles.

🧠 Resultado esperado:
Revele que funciones sin autenticación son puertas de entrada silenciosas. Refuerzo la seguridad con triggers autenticados, límites de ejecución, roles separados y monitorización granular por invocación.