La lección anterior terminó señalando el puente: la infraestructura inmutable y los contenedores son la mejor forma de aplicar una línea base, y sin embargo el hardening clásico no los cubre. Un contenedor no es una máquina virtual, no se parchea sino que se reconstruye, y la cuenta cloud que lo ejecuta tiene una superficie propia que ningún lynis mira. Esta lección cierra el plan técnico del curso donde hoy se produce la mayoría de las brechas: no en un exploit sofisticado, sino en una casilla mal marcada. Vamos a configurar de una vez por todas la cuenta A-05, el bucket de adjuntos A-02 y las copias A-03, y a construir imágenes que no regalen la partida.

1. Por qué la nube cambia el modelo de amenaza
2. Responsabilidad compartida, en lo técnico
3. La identidad es el nuevo perímetro
4. El bucket A-02, bien configurado de una vez
5. Red y datos: subredes privadas, cifrado y copias aisladas
6. Registro y auditoría de la nube
7. Postura automatizada: CSPM e infraestructura como código
8. Contenedores: qué aísla y qué no
9. Ejecución segura y firma de imágenes
10. Orquestación y detección en tiempo de ejecución
11. Qué debe hacer Nimbus primero, con su presupuesto

En un centro de datos propio, atacar significaba encontrar un servicio vulnerable y explotarlo. En la nube, la causa dominante de brechas no es un exploit: es un error de configuración. Los grandes incidentes públicos de la última década en entornos cloud comparten un patrón que no requiere ninguna habilidad ofensiva: un bucket marcado como público, una clave de acceso publicada en un repositorio, un rol con permisos de administrador que solo necesitaba leer un fichero, una base de datos gestionada expuesta sin autenticación.

Tres cambios de fondo explican el desplazamiento:

• Todo es una API. Crear una máquina, abrir un puerto o dar acceso a todos los datos son llamadas a una API, y una credencial con permisos amplios permite hacerlas todas. El plano de control importa más que el plano de datos: quien controla la cuenta no necesita entrar en ningún servidor.
• La velocidad es la ventaja y el riesgo. Un terraform apply levanta una infraestructura completa en minutos, y también publica un bucket en segundos. La misma agilidad que hace competitiva a Nimbus multiplica la probabilidad del error.
• Todo es público por defecto en cuanto a alcance de red. No hay una puerta física ni una red corporativa alrededor: lo que se despliega es alcanzable desde Internet salvo que se configure lo contrario.

La consecuencia práctica invierte la prioridad de trabajo: en la nube, revisar la configuración rinde más que buscar vulnerabilidades, y por eso el CSPM del apartado 7 es, para una PYME, más rentable que un escáner de vulnerabilidades adicional.

En 04-04 vimos el modelo como asunto contractual. Aquí es una lista de tareas concretas, y la pregunta que la ordena es: si esto falla, ¿a quién llamas? Si la respuesta eres tú, es tuyo.

Dos conclusiones que conviene tener presentes. La primera: cuanto más gestionado es el servicio, menos tareas tienes, pero las que quedan son las más críticas —la configuración de acceso y los datos—. La segunda: el proveedor no te avisa cuando lo haces mal. Publicar un bucket no genera ninguna alerta desde su lado: la casilla existe, y usarla es una decisión legítima del cliente. Esa asimetría es exactamente el hueco donde vive el error de configuración.

Sin red que defender, el control de acceso a la API del proveedor es el perímetro real. Cinco reglas ordenadas por impacto:

1. MFA obligatorio en la cuenta raíz, con la credencial custodiada y sin uso diario. La raíz solo se usa para lo que ninguna otra identidad puede hacer.
2. Nada de claves de acceso de larga duración. Una clave estática vive en un fichero, viaja por chats, se copia a un portátil y aparece en un repositorio: es el riesgo R-06. En su lugar, roles asumibles con credenciales efímeras (minutos u horas) para las personas, e identidad de la propia instancia o del contenedor para los servicios, sin ningún secreto que gestionar.
3. Federación con el proveedor de identidad. Nadie tiene usuario propio en la nube: se entra con la identidad corporativa, y la baja de un empleado revoca su acceso a todo de una vez. Es la corrección de un problema clásico: la cuenta cloud que sobrevive a quien la usaba.
4. Mínimo privilegio real, que se consigue observando lo que cada rol usa de verdad y recortando lo demás.
5. Revisión periódica de permisos excesivos, con el analizador de accesos del proveedor y con la recertificación semestral del control C-18.

Tres decisiones merecen justificarse. No se concede s3:DeleteObject: la API de Nimbus nunca necesita borrar adjuntos, y no tenerlo convierte un compromiso de la API en una fuga —grave— en lugar de en una destrucción —irreversible—. El Resource acota la ruta, no solo el bucket, así que un fallo de la aplicación no alcanza otros prefijos. Y la denegación explícita por punto de enlace de la VPC es la más potente: aunque otra política conceda acceso por error, si la petición no viene por la red privada de Nimbus, se deniega. Una credencial robada y usada desde fuera no sirve.

Este es el activo que 02-06 vació durante siete días. Se cierra con siete controles que se aplican juntos.

Los dos controles restantes van sobre el bucket de copias A-03, y son los que 02-06 demostró imprescindibles:

El modo COMPLIANCE es la diferencia entre una copia y una esperanza. En modo governance, un administrador puede levantar la retención; en modo compliance, nadie puede, ni el propietario de la cuenta, hasta que expire. Es el cuarto dígito de la regla 3-2-1-1-0 de 04-06 y es, literalmente, lo que habría impedido el borrado del día 20 a las 02:10.

Y el séptimo control, ya conocido: las descargas se sirven con URL firmadas de 120 segundos (03-07), generadas tras comprobar la autorización en la aplicación (05-05). Nunca hay un enlace permanente ni un objeto legible sin credencial.

Retomando el diseño de 05-04 con la mirada puesta en los servicios gestionados:

• La base de datos vive en una subred privada sin ruta a Internet, ni de entrada ni de salida. No es «un puerto cerrado»: es que no existe camino.
• Puntos de enlace privados (VPC endpoints) para hablar con el almacenamiento de objetos y con el gestor de secretos. El tráfico no sale a Internet, y —lo más valioso— permite la condición aws:SourceVpce del apartado 3, que anula el valor de una credencial robada.
• Cifrado en reposo y en tránsito por defecto en todos los servicios, con claves gestionadas por Nimbus y rotación con kid (03-06). El cifrado del proveedor protege frente al robo físico del disco; el cifrado con clave propia protege además frente a errores de acceso lógico.
• Bloqueo del servicio de metadatos o exigencia de su versión con sesión (IMDSv2), que es la mitigación estructural del SSRF de 05-05: sin ella, un SSRF en la API entrega las credenciales del rol de la instancia.
• Las copias viven en otra cuenta, con credenciales distintas. Es la lección más cara de 02-06: las copias de Nimbus estaban en la misma cuenta que producción, y quien comprometió la cuenta las borró junto con todo lo demás. Copias en otra cuenta significa que el atacante necesita comprometer dos cuentas independientes, con dos conjuntos de credenciales y dos proveedores de identidad. El coste añadido es de unos pocos euros al mes.

El registro de actividad del proveedor (CloudTrail o equivalente) responde a quién llamó a qué API, cuándo, desde dónde y con qué resultado. Es la fuente más importante de un entorno cloud y hay que configurarla bien:

• Activo en todas las regiones, no solo en la que se usa. Una técnica habitual consiste en operar en una región que nadie mira.
• Enviado a un bucket de otra cuenta, con las mismas propiedades del apartado 4: inmutable y solo escritura. Los logs se protegen igual que las copias.
• Validación de integridad activada, para poder demostrar que no se manipularon.
• Complementado con los registros de acceso al bucket, los del balanceador y los de flujo de la VPC (05-04).

Las alertas mínimas, que conectan directamente con el catálogo de 05-02:

Las cinco primeras son S1 porque ninguna tiene explicación benigna frecuente. Son, además, baratísimas de montar: son consultas sobre un registro que ya existe.

CSPM (Cloud Security Posture Management) es evaluar de forma continua la configuración de la cuenta contra un conjunto de buenas prácticas. prowler y ScoutSuite son libres y suficientes.

Lectura comentada, con el criterio de priorización de 05-01. iam_root_mfa_enabled es el primero, pese a no ser el que más ruido hace: sin MFA en la raíz, todos los demás controles son opcionales para quien consiga esa credencial, y activarlo son cinco minutos. El bucket público va inmediatamente después, y la primera pregunta no es cómo cerrarlo sino qué contiene y desde cuándo está así: si tiene datos personales, esto ya no es un hallazgo de configuración, es una posible brecha (04-05, 06-03). La clave de acceso sin usar 402 días es el hallazgo más silencioso y uno de los más peligrosos: una credencial permanente, olvidada, que nadie echaría de menos si alguien la usara; se elimina, no se rota. Y las copias desactivadas en preproducción vuelven a señalar a A-22.

Desplazar el control a la izquierda. El CSPM detecta el error después de que llegue a producción. checkov y tfsec lo detectan en el pull request, sobre el código de infraestructura, antes de que exista:

La combinación correcta es checkov bloqueante en el CI y prowler semanal sobre la cuenta, porque no todo se despliega por código: siempre hay algo hecho a mano en la consola web, y eso solo lo ve el CSPM.

La frase que hay que interiorizar: un contenedor es aislamiento de procesos, no una frontera de seguridad como la de una máquina virtual. Si necesitas separar cargas de confianza muy distinta, la frontera correcta es la máquina virtual o la cuenta separada.

El último comentario merece énfasis porque es el error más común y el menos evidente: borrar un fichero en una capa posterior no lo elimina de la imagen. Sigue estando en la capa anterior y se recupera con un comando. Por eso trivy --scanners secret (05-01) forma parte del pipeline.

Construir bien la imagen es la mitad; la otra mitad es cómo se ejecuta.

read_only más cap_drop: ALL más no-new-privileges es la combinación que más eleva el coste de un ataque, y no cuesta nada: la mayoría de las aplicaciones web funcionan tal cual, y las que no, solo necesitan declarar sus rutas de escritura como volúmenes.

Firma de artefactos con cosign (retomando 03-07), que responde a la pregunta «¿esta imagen es la que construimos nosotros?»:

Sin verificación en el despliegue, la firma es decorativa. La cadena completa queda así, y es la integridad de la cadena de suministro de 04-04 llevada a la práctica:

Nimbus todavía no usa Kubernetes, y conviene decir con claridad que Kubernetes es un ámbito de seguridad propio, no un detalle de despliegue. Si llega, estas son las seis piezas mínimas: espacios de nombres por entorno y por criticidad, con cuotas; RBAC con cuentas de servicio propias por aplicación y sin usar la cuenta por defecto; políticas de red, porque por defecto todos los pods hablan con todos —es el error más frecuente y el equivalente a la red plana de 05-04—; estándares de seguridad de pods en nivel restricted, que impone lo del apartado 9; gestión de secretos con un proveedor externo, porque los secretos nativos van codificados en base64 y no cifrados; y kube-bench, que evalúa el clúster contra el benchmark CIS igual que lynis evalúa un servidor.

Detección en tiempo de ejecución con Falco. El escaneo de imágenes mira lo que hay; Falco mira lo que ocurre, observando las llamadas al sistema:

Qué merece la pena detectar en tiempo de ejecución, sin generar ruido: shell dentro de un contenedor, escritura en rutas del sistema (/etc, /usr/bin) cuando el sistema de ficheros debería ser de solo lectura, conexión saliente a un destino inesperado, lectura de ficheros sensibles como /etc/shadow o las credenciales de la instancia, y montaje del socket de Docker. Todas van al mismo canal de 05-02 y comparten sus reglas de calidad de alerta.

El total suma unos 540 €/año y unas 70 horas. Es menos del 3 % del presupuesto de 18.000 €/año y el 16 % de las 440 horas de Lucía, y cubre los tres riesgos peor puntuados del registro de 04-01. Es, con diferencia, la mejor relación coste/impacto de todo el módulo 5, y la razón es la misma con la que empezó la lección: en la nube, casi todo lo que falla es una casilla, y las casillas son gratis.

• Creer que el proveedor te protege de tus propias configuraciones. No te avisa cuando publicas un bucket: es una acción legítima del cliente.
• Usar claves de acceso de larga duración. Acaban en un repositorio, en un chat o en un portátil. Roles efímeros e identidad de instancia.
• Conceder Action: "*" «temporalmente». No hay nada más permanente que un permiso temporal que funciona.
• Dejar las copias en la misma cuenta que producción. Es lo que convirtió el incidente de 02-06 en una catástrofe.
• Confiar en que un contenedor aísla como una máquina virtual. Comparte kernel; con capacidades de más o el socket de Docker montado, es el host entero.
• Etiquetas en lugar de digests. :latest no es reproducible: escaneas una imagen y despliegas otra.
• Secretos en ENV del Dockerfile. Quedan en la capa aunque los borres después.
• Consejo: empieza por las dos primeras filas de la tabla del §11. Cuatro horas, coste cero, y cubren el peor escenario posible.
• Consejo: verifica, no configures. Un curl que devuelva 403 vale más que una captura de la consola web, y es la evidencia que pide 04-03.
• Consejo: checkov en el CI antes que prowler en la cuenta. Es más barato impedir el error que descubrirlo, aunque necesitarás los dos.

Sobre la salida de prowler del §7, y sabiendo que nimbus-web-assets sirve las imágenes públicas de la web de marketing:

1. Ordena los seis hallazgos por prioridad real, justificando cada posición.
2. ¿Cambia tu evaluación del bucket público al saber para qué se usa? ¿Qué comprobarías antes de decidir?
3. Escribe la corrección concreta de los tres primeros e indica cómo verificarías cada una.

Iván propone este servicio para producción. Identifica todos los problemas y reescríbelo.

Marta pregunta, tras leer el post mortem de 02-06: «¿cómo garantizamos que esto no puede volver a pasar?». Diseña el esquema de copias de Nimbus de modo que un atacante con control total de la cuenta de producción no pueda destruirlas, e indica cómo lo demostrarías.

Ejercicio 1

(1) Orden por prioridad real:

(2) Sí cambia, pero menos de lo que parece. Que un bucket de imágenes de marketing sea legible públicamente puede ser exactamente lo que se pretende, y en ese caso el hallazgo es un falso positivo que se documenta como excepción (04-02). Antes de decidir hay que comprobar cuatro cosas: qué objetos contiene realmente —los buckets de «recursos web» acumulan con enorme frecuencia exportaciones, copias de seguridad puntuales y PDF de clientes que alguien dejó ahí—; si además de lectura pública tiene escritura pública, que sería crítico porque permitiría a cualquiera alterar el contenido servido bajo el dominio de Nimbus; desde cuándo está así y qué dicen los registros de acceso; y si hay un modo mejor de conseguir lo mismo, que lo hay: CDN delante con el bucket privado, lo que da control, caché y registro sin exposición directa. La regla general: un bucket público es aceptable solo si es un bucket dedicado, cuyo contenido está íntegramente destinado a ser público y así consta por escrito.

(3) Correcciones y verificación:

• Raíz sin MFA: activar MFA con una llave física, guardar la credencial y el segundo factor de respaldo en custodia física con acceso de dos personas, y crear una alerta S1 ante cualquier uso de la raíz (§6). Verificación: prowler vuelve a ejecutar iam_root_mfa_enabled con resultado PASS, y una prueba de acceso pide el segundo factor.
• Bucket público: si el contenido debe ser público, moverlo a un bucket dedicado detrás de CDN y dejar el original privado; si no, aplicar el bloqueo de acceso público del §4. En ambos casos, inventariar el contenido antes. Verificación: curl sobre un objeto conocido devolviendo 403 y put-public-access-block confirmado.
• Clave sin usar: eliminarla, no desactivarla —una clave desactivada se reactiva—; comprobar antes en el registro de actividad que ningún proceso la usó en 402 días, y buscar si aparece en el historial del repositorio con gitleaks (05-01), porque una clave olvidada suele estarlo por haber sido incrustada en algún sitio. Verificación: la clave no aparece en el listado y no hay errores de autenticación nuevos en 48 horas.

Ejercicio 2

Problemas, de mayor a menor gravedad:

Ejercicio 3

El requisito reformulado: que la destrucción de las copias exija credenciales que la cuenta de producción no posee y una acción que ninguna credencial puede realizar. Cuatro capas, cada una resolviendo un fallo distinto:

1. Cuenta separada, con su propio proveedor de identidad y su propio MFA. Comprometer producción no da ningún acceso a la cuenta de copias. Es la capa que faltaba en 02-06, donde todo vivía junto.
2. Flujo de escritura en un solo sentido y de mínimo privilegio. El rol nimbus-backup de producción tiene únicamente PutObject sobre el bucket de copias: no puede listar, no puede leer y no puede borrar. Que no pueda leer es importante y suele olvidarse: impide que un atacante en producción se lleve también el histórico completo.
3. Bloqueo de objetos en modo COMPLIANCE con 35 días de retención. Aquí está el núcleo de la respuesta a Marta: ni siquiera un administrador de la cuenta de copias con MFA puede acortar la retención ni borrar un objeto antes de que expire. No es una cuestión de permisos, que siempre se pueden cambiar; es una propiedad del almacenamiento.
4. Replicación a una segunda región y, para el conjunto crítico, una copia adicional en almacenamiento frío con credenciales distintas de todo lo anterior.

Se complementa con detección: la alerta D-10 de 05-02 ante cualquier intento de borrado o de cambio de retención, y la alerta de silencio —si el proceso de copia deja de escribir durante 24 horas, alguien debe enterarse—, porque la forma sigilosa de destruir copias no es borrarlas, sino impedir que se creen y esperar a que el histórico caduque.

Cómo se demuestra, que es lo que Marta debe exigir y no una explicación: (a) intento real de borrado desde la cuenta de copias con credenciales de administrador, que debe fallar con AccessDenied, con la salida guardada como evidencia; (b) prueba de restauración cronometrada de 04-06, ejecutada desde la cuenta de copias, que verifica hash, compara filas y mide el RTO real; (c) simulacro de compromiso: revocar todas las credenciales de producción y comprobar que las copias siguen siendo accesibles y restaurables; y (d) revisión trimestral de que el bloqueo de objetos sigue activo, incluida en el --check --diff de la infraestructura como código (05-06). La respuesta correcta a la pregunta de Marta no es «hemos configurado esto»: es «lo hemos intentado destruir y no hemos podido, y aquí está la salida de consola con fecha».

Has cerrado el plan técnico del curso donde hoy se rompen la mayoría de las empresas. Sabes por qué la nube cambia el modelo de amenaza —el error de configuración sustituye al exploit como causa dominante— y las tres razones de fondo: todo es una API, la velocidad multiplica el error y el alcance es público por defecto. De ahí la inversión de prioridades: revisar la configuración rinde más que buscar vulnerabilidades. Aplicas el modelo de responsabilidad compartida servicio a servicio con la pregunta que lo ordena —«si esto falla, ¿a quién llamas?»— y con las dos conclusiones que importan: cuanto más gestionado el servicio, menos tareas y más críticas; y el proveedor nunca te avisa cuando lo haces mal.

Dominas la identidad como nuevo perímetro: MFA en la raíz, fin de las claves de larga duración, roles asumibles con credenciales efímeras, federación con el proveedor de identidad y revisión de permisos excesivos; con la política mínima que no concede Delete, acota el prefijo y añade una denegación explícita por punto de enlace de la VPC que anula el valor de una credencial robada. Has configurado el bucket A-02 de una vez: bloqueo de acceso público, cifrado con clave propia, versionado, registro de accesos y verificación con un curl que debe devolver 403; y las copias A-03 en cuenta separada con bloqueo de objetos en modo COMPLIANCE, que es lo que convierte «inmutable» en algo real y lo que habría impedido el borrado del día 20. Sabes montar subredes privadas, puntos de enlace privados, cifrado por defecto, bloqueo del servicio de metadatos como mitigación estructural del SSRF, y copias que exigen comprometer dos cuentas independientes.

Sabes configurar el registro de actividad multirregión, inmutable, en otra cuenta y con validación de integridad, y las siete alertas mínimas de las que cinco son S1 porque ninguna tiene explicación benigna. Manejas CSPM con prowler —leyendo su informe con el criterio de 05-01, empezando por el MFA de la raíz y preguntando qué contiene el bucket público antes de cerrarlo— y checkov bloqueante en el CI para que el error no llegue a producción, con la conclusión de que hacen falta los dos. Entiendes qué aísla y qué no un contenedor, y tienes el Dockerfile antes y después: multi-stage, distroless, fijado por digest, --require-hashes, sin secretos en capas y sin root; con la advertencia de que borrar un fichero en una capa posterior no lo elimina de la imagen. Ejecutas con read_only, cap_drop: ALL, no-new-privileges y límites, firmas con cosign y verificas antes de desplegar, porque sin verificación la firma es decorativa. Y conoces el encuadre de Kubernetes como ámbito propio y Falco para detectar lo que ocurre en ejecución. Todo ello priorizado en una tabla que suma unos 540 € y 70 horas y cubre los tres riesgos peor puntuados del registro: en la nube, casi todo lo que falla es una casilla, y las casillas son gratis.

Con esto, el Módulo 5 está completo. Nimbus ya sabe encontrar lo que tiene expuesto y priorizarlo (05-01), ver al atacante moverse con doce detecciones que habrían cortado el incidente de 02-06 en el día 0 (05-02), probarse con un pentest autorizado y aprovechar su informe (05-03), segmentar su red y verificar que la segmentación funciona de verdad (05-04), defender su propio código con autorización centralizada y un CI que dice que no (05-05), endurecer sus sistemas con una línea base automatizada y verificada semanalmente (05-06) y cerrar su nube y sus contenedores (05-07). Han caído, uno a uno, todos los hallazgos que arrastrábamos desde 01-04: el PostgreSQL expuesto, el Redis sin autenticación, el SSH abierto, el python -m http.server y el acceso permanente de la consultora.

Y aquí aparece el límite de todo lo anterior. Nada de esto se mantiene solo. Las herramientas encuentran y corrigen, pero el escaneo mensual deja de ejecutarse cuando Lucía tiene una semana mala; la línea base se degrada si nadie mira el --check --diff; la CSP se rellena de excepciones; el security.txt caduca; y el próximo empleado que entre no sabrá nada de todo esto salvo que alguien se lo enseñe. Además, haber hecho el trabajo no basta: hay que poder demostrarlo —ante un cliente que exige garantías, ante una auditoría, ante la Agencia Española de Protección de Datos si un día hay que notificar una brecha—. En el Módulo 6: Buenas Prácticas y Normativas pasamos de la ejecución a lo que la sostiene en el tiempo: buenas prácticas que convierten decisiones puntuales en hábitos (06-01), normativas y estándares como ISO 27001, NIS2 y ENS (06-02), la protección de datos y el RGPD aplicados de verdad a un SaaS que trata datos de salud (06-03), cumplimiento y auditoría con la evidencia que este módulo ha ido generando (06-04), formación y concienciación, porque las personas siguen siendo el vector principal (06-05), y la ética y la divulgación responsable que 05-03 dejó pendientes (06-06). Dejamos de preguntar si está protegido y empezamos a preguntar si puede demostrarse y si durará.