1. Introducción a la seguridad en cloud, contenedores y DevSecOps

1.1 Introducción

Las organizaciones modernas despliegan aplicaciones en plataformas cloud, empaquetan servicios en contenedores, automatizan infraestructura y publican cambios mediante pipelines de integración y entrega continua. Este modelo mejora la velocidad y la escalabilidad, pero también cambia la forma en que aparecen y se gestionan los riesgos.

En un entorno tradicional, muchos controles se aplicaban sobre servidores relativamente estables y perímetros bien definidos. En cloud y contenedores, los recursos pueden crearse y destruirse en minutos, las identidades de servicio tienen permisos críticos, las imágenes se construyen desde múltiples dependencias y los pipelines pueden convertirse en una vía directa hacia producción.

Por eso la seguridad debe integrarse desde el diseño. No alcanza con revisar al final ni con instalar una herramienta aislada. Se necesita arquitectura segura, automatización, revisión continua, trazabilidad y controles que acompañen el ciclo completo: código, build, imagen, despliegue, runtime y operación.

1.2 Qué significa seguridad en cloud, contenedores y DevSecOps

La seguridad en este contexto es el conjunto de prácticas, controles técnicos, procesos y decisiones de arquitectura que protegen plataformas cloud native y el flujo de entrega de software.

Incluye proteger:

• Las cuentas, suscripciones, proyectos, redes y servicios cloud utilizados por la organización.
• Las identidades humanas y de máquina, junto con sus permisos y credenciales.
• Los datos almacenados, procesados y transmitidos por servicios cloud y aplicaciones.
• Las imágenes de contenedores, sus dependencias, registros y firmas.
• Los clusters de Kubernetes, sus políticas, workloads, secretos y componentes de control.
• Los pipelines CI/CD, artefactos, runners, repositorios, aprobaciones y entornos de despliegue.
• La cadena de suministro de software, desde dependencias externas hasta infraestructura como código.

1.3 Por qué este tema es crítico

Cloud, contenedores y DevSecOps concentran decisiones con impacto directo en la exposición de una organización. Una política IAM demasiado amplia, un bucket público, una imagen vulnerable, un secreto filtrado o un pipeline mal protegido pueden provocar incidentes graves sin necesidad de explotar una vulnerabilidad compleja.

El riesgo aumenta porque los entornos son altamente automatizados. Una mala plantilla de infraestructura como código puede replicar una configuración insegura en decenas de cuentas. Un token comprometido puede permitir modificar despliegues. Una dependencia alterada puede ingresar a la cadena de build y llegar a producción si no existen validaciones adecuadas.

1.4 Objetivos de protección

Los objetivos de protección ayudan a ordenar las decisiones de seguridad. En este curso no se estudian herramientas como piezas aisladas, sino como mecanismos para preservar propiedades concretas del sistema.

• Confidencialidad: evitar exposición de datos, secretos, tokens, configuraciones y tráfico sensible.
• Integridad: impedir cambios no autorizados en código, imágenes, infraestructura, políticas y despliegues.
• Disponibilidad: mantener aplicaciones y plataformas operativas frente a errores, ataques o fallas de dependencias.
• Autenticidad: verificar identidades, artefactos, imágenes, dependencias y fuentes de despliegue.
• Trazabilidad: registrar quién hizo qué, cuándo, desde dónde y con qué impacto.
• Contención: limitar el alcance de una credencial comprometida, un contenedor vulnerable o un workload malicioso.
• Reproducibilidad: poder reconstruir infraestructura, builds y despliegues de forma controlada y auditable.

1.5 El modelo de responsabilidad compartida

En cloud, la seguridad se reparte entre el proveedor y el cliente. El proveedor protege la infraestructura base del servicio, pero el cliente sigue siendo responsable de configurar adecuadamente identidades, datos, redes, permisos, aplicaciones y monitoreo.

El alcance exacto depende del tipo de servicio utilizado. No es lo mismo administrar máquinas virtuales que consumir una base de datos administrada o una función serverless. Cuanto más administrado es el servicio, más tareas operativas asume el proveedor, pero las decisiones de configuración, acceso y uso seguro siguen siendo responsabilidad del cliente.

1.6 DevSecOps: seguridad integrada al flujo de entrega

DevSecOps propone incorporar seguridad en el proceso de desarrollo y operación, no agregarla como una revisión tardía. El objetivo es que los equipos puedan detectar problemas temprano, automatizar controles repetibles y reducir la distancia entre quienes desarrollan, operan y protegen el sistema.

Esto implica aplicar controles en varias etapas:

• En el repositorio: revisión de código, protección de ramas y detección de secretos.
• En el build: análisis de dependencias, generación de SBOM y validación de artefactos.
• En la imagen: escaneo de vulnerabilidades, firma y verificación de procedencia.
• En el pipeline: separación de permisos, aprobaciones y protección de runners.
• En el despliegue: políticas como código, admission control y validación de configuración.
• En runtime: monitoreo, detección de comportamiento anómalo y respuesta.

1.7 Superficie de ataque cloud native

La superficie de ataque es el conjunto de puntos por los que un actor puede intentar ingresar, alterar, observar o interrumpir el sistema. En entornos cloud native, esa superficie no se limita a puertos abiertos o servidores expuestos.

También incluye:

• Políticas IAM, roles asumibles, cuentas de servicio y claves de acceso.
• Repositorios de código, pipelines, runners y variables de entorno.
• Registros de contenedores, imágenes base y dependencias externas.
• APIs cloud, consolas administrativas y herramientas de automatización.
• Clusters Kubernetes, API server, etcd, admission controllers y permisos RBAC.
• Plantillas de infraestructura como código y módulos reutilizables.
• Servicios expuestos públicamente, balanceadores, gateways y reglas de red.
• Logs, backups, snapshots y datos exportados a servicios externos.

Reducir esta superficie requiere inventario, mínimos privilegios, configuración segura, revisión continua y eliminación de exposición innecesaria.

1.8 Principios de diseño seguro

Antes de entrar en herramientas específicas, conviene fijar principios que se repetirán durante todo el curso.

• Mínimo privilegio: cada usuario, servicio, pipeline o workload recibe solo los permisos necesarios.
• Defensa en profundidad: se combinan controles de identidad, red, datos, build, despliegue y runtime.
• Seguridad por defecto: las configuraciones iniciales deben favorecer el bloqueo y la exposición mínima.
• Automatización verificable: los controles deben ejecutarse de manera consistente y quedar registrados.
• Inmutabilidad: se prefieren artefactos versionados, firmados y reemplazables antes que cambios manuales en producción.
• Separación de responsabilidades: se evitan permisos concentrados y rutas directas sin aprobación hacia producción.
• Observabilidad: se recolectan señales suficientes para detectar, investigar y responder incidentes.
• Mejora continua: la postura de seguridad se revisa porque la arquitectura, dependencias y amenazas cambian.

1.9 Riesgos frecuentes

Muchos incidentes en cloud native no aparecen por ataques sofisticados sino por combinaciones de permisos excesivos, secretos mal gestionados, automatizaciones poco controladas y baja visibilidad.

• Permisos IAM demasiado amplios o heredados sin revisión.
• Almacenamiento cloud expuesto públicamente por error de configuración.
• Secretos incluidos en repositorios, imágenes o variables de pipelines.
• Imágenes con vulnerabilidades críticas o ejecutadas como root.
• Clusters Kubernetes con RBAC permisivo o sin políticas de red.
• Pipelines con tokens capaces de modificar producción sin controles suficientes.
• Dependencias externas sin validación de origen, versión o integridad.
• Infraestructura como código sin revisión ni análisis automatizado.
• Logs incompletos o sin retención suficiente para investigar incidentes.

1.10 Controles técnicos y organizativos

La seguridad efectiva combina tecnología con procesos claros. Una herramienta de escaneo no compensa una arquitectura mal diseñada, y una política escrita no protege si no se aplica en la operación diaria.

1.11 Ejemplo de flujo seguro

Un flujo DevSecOps maduro aplica controles en varias capas sin obligar a que todo dependa de una revisión final. Un ejemplo simplificado sería:

1. El desarrollador sube cambios a una rama protegida.
2. El repositorio ejecuta análisis de código, dependencias y secretos.
3. El pipeline construye una imagen desde una base aprobada y reproducible.
4. La imagen se escanea, se firma y se publica en un registro controlado.
5. El despliegue valida políticas de Kubernetes antes de aceptar el workload.
6. El entorno aplica permisos mínimos, límites de recursos y segmentación.
7. La operación monitorea eventos, logs, métricas y comportamiento en runtime.
8. Si aparece un incidente, se puede rastrear artefacto, cambio, actor y entorno afectado.

El valor está en la continuidad del control: cada etapa reduce riesgo y produce evidencia útil.

1.12 Roles involucrados

La seguridad cloud native es transversal. No pertenece a un único equipo, porque las decisiones relevantes aparecen en arquitectura, desarrollo, infraestructura, seguridad, compliance y operación.

• Desarrollo: escribe código seguro, gestiona dependencias y evita exposición de secretos.
• DevOps o plataforma: diseña pipelines, automatiza infraestructura y opera entornos de despliegue.
• Seguridad: define controles, revisa riesgos, monitorea amenazas y lidera respuesta a incidentes.
• Arquitectura cloud: diseña landing zones, redes, identidades, cifrado y patrones reutilizables.
• Operaciones: asegura disponibilidad, monitoreo, backups, restauración y continuidad.
• Gobierno y compliance: establece requisitos, auditoría, gestión de excepciones y evidencia.

Cuando estos roles trabajan aislados, suelen aparecer permisos inconsistentes, controles duplicados, excepciones permanentes y baja trazabilidad.

1.13 Errores frecuentes en la adopción

• Tratar cloud como si fuera solamente un datacenter externo.
• Confiar en que el proveedor cloud protege automáticamente toda la configuración.
• Usar permisos administrativos para automatizaciones que solo necesitan acciones puntuales.
• Escanear imágenes pero no bloquear despliegues inseguros ni corregir causas de fondo.
• Guardar secretos en repositorios, archivos de configuración o variables sin control.
• Permitir que cualquier pipeline despliegue en producción sin separación de funciones.
• No registrar eventos suficientes para investigar cambios, accesos y despliegues.
• Crear políticas demasiado estrictas sin proceso de excepción, lo que lleva a bypasses informales.

1.14 Qué aprenderemos en el resto del curso

Este primer tema define el marco general. En los próximos temas profundizaremos en los bloques necesarios para construir una estrategia completa.

• Modelo de responsabilidad compartida, arquitectura cloud y landing zones.
• Gestión de identidades, permisos, redes cloud, cifrado y secretos.
• Postura cloud, inventario, configuración segura y detección de drift.
• Fundamentos de contenedores, hardening de imágenes, registros y firmas.
• Seguridad en Kubernetes, RBAC, namespaces, network policies y runtime security.
• DevSecOps, pipelines CI/CD, artefactos, aprobaciones y entornos.
• Supply chain, SCA, SBOM, SLSA, SAST, DAST, IaC scanning y policy as code.
• Observabilidad, respuesta a incidentes, cumplimiento, gobierno y mejora continua.

1.15 Qué debes recordar de este tema

• Cloud native cambia la superficie de ataque porque combina infraestructura dinámica, automatización e identidades programáticas.
• La seguridad debe cubrir código, dependencias, imágenes, pipelines, cloud, Kubernetes y runtime.
• El modelo de responsabilidad compartida no elimina las obligaciones del cliente.
• DevSecOps integra controles de seguridad en el flujo de entrega para detectar y corregir antes.
• Los principios clave son mínimo privilegio, defensa en profundidad, automatización verificable, trazabilidad y mejora continua.

1.16 Conclusión

La seguridad en cloud, contenedores y DevSecOps exige una visión integrada. No se trata solo de proteger máquinas, clusters o pipelines por separado, sino de entender cómo cada componente participa en una cadena de entrega y operación que debe ser confiable de extremo a extremo.

En el próximo tema estudiaremos el modelo de responsabilidad compartida con más detalle y analizaremos los riesgos específicos que aparecen al operar infraestructura y servicios en plataformas cloud.