Parte: 10 — Seguridad en la nube y contenedores · Fuente: AWS Well-Architected Framework: Security Pillar (documentación oficial de AWS) ⏱️ Duración estimada: 90 min · Nivel: Fundamentos
Comprender qué cambia cuando la infraestructura se mueve a la nube y dónde queda exactamente la frontera de responsabilidad entre el proveedor y el cliente. Al terminar, el alumno sabrá clasificar cualquier servicio (IaaS, PaaS, SaaS) según quién asegura qué, e identificar los errores de configuración del cliente que pueden exponer datos, identidades y servicios.
Al finalizar, el alumno podrá:
| # | Tema | Por qué importa |
|---|---|---|
| 1 | Modelo de responsabilidad compartida | Asigna tareas técnicas y operativas según servicio y contrato |
| 2 | IaaS vs PaaS vs SaaS | La frontera de responsabilidad se mueve con cada modelo |
| 3 | "DE la nube" vs "EN la nube" | Separa fallos del proveedor de errores del cliente |
| 4 | Configuración insegura y estado efectivo | Distinguir intención, valor por defecto y cambio desplegado |
| 5 | Identidad, red y datos como controles compuestos | Ninguna capa reemplaza por sí sola a las demás |
| 6 | Regiones, zonas y soberanía de datos | Cumplimiento, latencia y aislamiento de fallos |
| 7 | Modelo de amenazas cloud | Superficie de API, plano de gestión y datos |
La nube combina recursos virtualizados, servicios administrados y automatización por API. NIST SP 800-145 define características y modelos de servicio, pero esa taxonomía no decide quién configura una clave, revisa un log o corrige una aplicación. Para cada servicio se construye una matriz de tarea, parte responsable, evidencia de cumplimiento y dependencia compartida.
El diagrama no presenta una línea fija: obliga a clasificar tareas. En IaaS el proveedor opera instalaciones y virtualización, mientras el cliente suele administrar sistema invitado, aplicaciones, identidades y reglas. En un servicio administrado, el parche del motor puede pasar al proveedor, pero esquema, acceso, cifrado elegido y datos siguen requiriendo decisiones del cliente. En SaaS permanecen cuentas, configuración, dispositivos, compartición y gobierno de datos.
La distinción popular ayuda a empezar, pero puede ocultar dependencias. El proveedor protege la infraestructura del servicio y publica capacidades; el cliente debe activarlas y operar sus controles. Algunas tareas son compartidas: el proveedor ofrece cifrado y resiliencia regional, mientras el cliente selecciona claves, región, replicación y pruebas de recuperación. La responsabilidad también tiene una dimensión contractual: SLA y certificaciones no demuestran que una arquitectura concreta cumpla el requisito del cliente.
El plano de control crea, cambia o elimina recursos; el plano de datos procesa contenido; el plano de identidad emite y evalúa sesiones. Una acción administrativa puede venir desde Internet sin cruzar la VPC de la carga. Por eso IAM es crítico, pero no «sustituye» firewall, segmentación, validación de aplicación o cifrado. Un rol mínimo puede invocar una API vulnerable; una red privada puede contener una identidad excesiva; un dato cifrado puede quedar públicamente legible para una identidad autorizada de forma incorrecta.
Región describe una ubicación geográfica ofrecida por el proveedor; zonas dentro de ella aportan dominios de fallo separados según el servicio. Desplegar en dos zonas mejora tolerancia a ciertos fallos, pero no protege automáticamente contra borrado lógico, credencial comprometida o dependencia regional compartida. Residencia, transferencia, jurisdicción y backup deben analizarse por tipo de dato y servicio, no solo por el nombre de la región.
Una organización puede instalar PostgreSQL en una VM o contratar una base administrada. En la VM controla parche, sistema, proceso, backup, red, credenciales y datos. En PaaS el proveedor asume sistema y motor dentro del servicio, pero el cliente todavía define acceso público o privado, usuarios, parámetros disponibles, retención, claves y restauración. «El proveedor parchea» no significa «la base está segura».
La matriz de evidencia cambia: en IaaS se conserva inventario y estado de parche del host; en PaaS se usa versión administrada, configuración, logs del servicio y pruebas de restauración. En ambos casos se verifica IAM, red, clasificación de datos y monitoreo. Esa comparación muestra por qué el modelo se aplica por tarea, no mediante un porcentaje genérico.
Dominas la clase cuando puedes tomar un servicio concreto, asignar al menos diez tareas entre proveedor, cliente y compartidas, indicar una evidencia verificable para cada tarea y explicar cómo identidad, red, aplicación, datos, región y operación reducen riesgos distintos.
aws, az, gcloud.# Verificar instalación de CLIs
aws --version
az version
gcloud version
Este es un tema conceptual: el laboratorio es un análisis de arquitectura y una matriz de responsabilidad.
Elabora una matriz de responsabilidad compartida en formato tabla para una arquitectura de tres capas (balanceador gestionado + contenedores + base de datos gestionada) en el proveedor que elijas.
Criterio de aceptación: cada componente lista al menos seis capas, cada capa tiene asignado responsable (Proveedor/Cliente/Compartida) coherente con la documentación oficial, y se incluye al menos un control concreto del cliente por componente.
| Síntoma / mensaje | Causa y cómo arreglar |
|---|---|
| "El proveedor ya me protege, no necesito hacer nada" | Confunde operación del servicio con configuración y gobierno del cliente. Construye la matriz por tarea y contrato. |
| Bucket o blob accesible públicamente sin querer | ACL/política heredada o pública por defecto en versiones antiguas; activa block public access. |
| Uso diario de la cuenta raíz | Rompe el privilegio mínimo; crea usuarios/roles y guarda la raíz solo para tareas críticas con MFA. |
| Datos en región equivocada | Se ignoró soberanía/latencia; define región por diseño y bloquea otras con SCP/policies. |
| "No sé qué recursos tengo" | Falta de inventario; habilita Config/Asset Inventory desde el día uno. |
❓ ¿La responsabilidad compartida es un contrato legal o solo técnico? Ambas cosas. Está reflejada en el acuerdo del proveedor y define técnicamente qué controles quedan de tu lado; en una brecha por misconfiguration la responsabilidad legal suele ser del cliente.
❓ ¿En SaaS ya no tengo nada que asegurar? Sí lo tienes: identidades, permisos, configuración de la app y los datos que subes. La mayoría de incidentes SaaS son por cuentas mal protegidas o permisos excesivos.
❓ ¿Por qué se dice que "la identidad es el nuevo perímetro"? Porque no hay un firewall físico entre tú y el mundo: cualquiera con credenciales válidas puede llamar a la API. Controlar quién puede hacer qué (IAM) es el control central.
Clase 220 — Caso completo de respuesta a incidentes end-to-end