⬅️ Volver al programa · 📚 Índice completo · ⏭️ Parte siguiente
15 clases · rango 221–235 · AWS, Azure, GCP, IAM, Docker, Kubernetes e IaC
Fuentes de referencia de esta parte:
La seguridad cloud no consiste en trasladar controles del centro de datos a una consola. Los recursos se crean mediante API, las identidades pueden operar entre cuentas y servicios, y gran parte de la infraestructura es efímera o administrada por un proveedor. El alumno debe aprender a preguntar quién controla cada capa, qué identidad autoriza una acción, qué configuración expresa la intención y qué registro permite reconstruirla.
El modelo de responsabilidad compartida no es una frontera única ni una exención contractual automática: cambia por servicio, configuración y tarea. IAM tampoco reemplaza red, cifrado, aplicaciones o operación. Esta parte conecta esos controles y enseña a razonar sobre su composición en AWS, Azure y Google Cloud, antes de pasar a contenedores, Kubernetes, IaC, postura, serverless, secretos, detección y respuesta.
Sirve a arquitectos de seguridad cloud, ingenieros DevSecOps, pentesters que auditan infraestructura moderna y equipos SRE que deben endurecer plataformas Kubernetes en producción. Toda la práctica usa herramientas reales y de código abierto: Prowler, ScoutSuite, kube-bench, Trivy, Terraform, tfsec/Checkov y las CLIs oficiales de cada nube.
Al terminar la parte, el alumno podrá:
| Bloque | Clases | Foco |
|---|---|---|
| Fundamentos e identidad | 221–222 | Responsabilidad compartida, IAM |
| Seguridad por proveedor | 223–225 | AWS, Azure, GCP |
| Ofensiva cloud | 226 | Pentest en entornos cloud |
| Contenedores | 227 | Docker: aislamiento, imágenes, runtime |
| Kubernetes | 228–229 | Arquitectura, hardening y ataques |
| Automatización y postura | 230–231 | IaC/Terraform, CSPM |
| Cargas modernas | 232–233 | Serverless, gestión de secretos |
| Operación y defensa | 234–235 | Logging/detección, respuesta a incidentes |
Clase 221 — Fundamentos y responsabilidad compartida. Construye el vocabulario de servicio, región, zona, plano de control y plano de datos. Enseña a asignar cada tarea de seguridad al proveedor, cliente o responsabilidad compartida sin usar porcentajes publicitarios. La evidencia es una matriz razonada para una arquitectura IaaS, PaaS y SaaS.
Clase 222 — IAM en la nube. Convierte identidad en una decisión evaluable: principal, credencial, política, recurso, condición, sesión y límites superiores. Aparece antes de los proveedores porque toda consola y API necesita autorización. La evidencia es una política mínima acompañada por pruebas positivas y negativas.
Clase 223 — Seguridad en AWS. Aplica los fundamentos a cuentas, VPC, S3, KMS, CloudTrail, Config, GuardDuty y Security Hub. No presenta servicios como botones mágicos: explica qué fuente usan y qué cobertura depende de configuración. La evidencia es una revisión de arquitectura con controles preventivos, detectivos y trazabilidad.
Clase 224 — Seguridad en Azure. Relaciona tenant, management groups, suscripciones, Entra ID, Azure RBAC, Policy, NSG, Key Vault, Defender for Cloud y Sentinel. La secuencia obliga a distinguir identidad del directorio y autorización sobre recursos. La evidencia es una asignación por ámbito y una política con efecto probado.
Clase 225 — Seguridad en Google Cloud. Explica organización, carpetas, proyectos, IAM, cuentas de servicio, Organization Policy, VPC Service Controls y Security Command Center. La evidencia es un diseño donde herencia, perímetro de datos y excepciones quedan documentados.
Clase 226 — Ataques y pentest cloud. Usa un laboratorio autorizado para mostrar cómo una credencial limitada, metadatos, relaciones de confianza o permisos indirectos pueden producir rutas de ataque. Enseña reglas de compromiso y política del proveedor antes que herramientas. La evidencia es una cadena reproducible con impacto controlado y mitigación.
Clase 227 — Seguridad de contenedores Docker. Pasa de los servicios administrados al aislamiento de procesos: namespaces, cgroups, capabilities, daemon, imágenes, capas, secretos y perfiles de runtime. La evidencia es una imagen reconstruida y una ejecución con privilegios medidos.
Clase 228 — Arquitectura de seguridad Kubernetes. Presenta API server, etcd, kubelet, autenticación, autorización, admisión, ServiceAccounts, namespaces y red como una cadena de decisiones. La evidencia es el seguimiento de una petición desde identidad hasta persistencia y ejecución.
Clase 229 — Hardening y ataques Kubernetes. Aplica Pod Security Admission, securityContext, RBAC, NetworkPolicy y benchmarks sin confundir cumplimiento con seguridad completa. La evidencia es un workload que falla bajo una política insegura y funciona con la excepción mínima explicada.
Clase 230 — Seguridad de Terraform e IaC. Conecta código, plan, state, proveedores, módulos, drift, escaneo y policy-as-code. La evidencia es un cambio revisado desde HCL hasta plan y estado, con secretos y dependencias tratados explícitamente.
Clase 231 — CSPM. Enseña a convertir miles de checks en decisiones basadas en exposición, privilegio, datos, explotabilidad y dueño. Se coloca después de IaC para corregir tanto el recurso como su fuente declarativa. La evidencia es una cola priorizada y métricas de cierre y recurrencia.
Clase 232 — Seguridad serverless. Analiza funciones, triggers, payloads, identidades, dependencias, concurrencia, costos y observabilidad. La evidencia es un flujo de evento validado con permisos acotados y límites operativos.
Clase 233 — Gestión de secretos. Distingue secreto, clave, token, certificado e identidad de carga, y explica almacenamiento, entrega, rotación, revocación y auditoría. La evidencia es un secreto entregado en runtime sin quedar en código, imagen o logs, más un procedimiento de compromiso.
Clase 234 — Logging y detección cloud. Diseña visibilidad por planos de gestión, datos, identidad, red y carga. Explica cobertura, latencia, costo, retención e integridad antes de crear una alerta. La evidencia es una matriz de fuentes y una detección probada con evento benigno controlado.
Clase 235 — Respuesta a incidentes cloud. Integra la Parte 9 con identidades, API, snapshots, logs, recursos efímeros e IaC. La evidencia final es una bitácora de decisiones, preservación reproducible, contención reversible y recuperación validada.
Cada clase usa el mismo razonamiento profesional: definir activo y frontera de responsabilidad, identificar identidad y plano, expresar estado esperado, comprobar estado efectivo, observar cambios y registrar excepciones. Los laboratorios se ejecutan solo en cuentas, suscripciones, proyectos o clústeres propios y con límites de costo. Una herramienta entrega observaciones; el alumno debe explicar alcance, falsos positivos, permisos usados y qué control corrige la causa.
Clase 221 — Fundamentos de seguridad en la nube y responsabilidad compartida