La lección anterior dejó el código de Nimbus defendiéndose solo. Pero ese código se ejecuta sobre algo: servidores con paquetes, servicios, usuarios y permisos, y unos cuarenta portátiles repartidos entre la oficina de Valencia y las casas de media plantilla. Ahí sigue vivo, desde 01-04, el python -m http.server que nadie apagó; ahí están los equipos sin cifrar del KPI de 04-03 (92,3 % frente al objetivo del 98 %); y ahí están las cuentas con privilegios de administrador que nadie necesita. Esta lección aplica al sistema operativo la reducción de superficie de 01-04 y convierte «tenemos los servidores bien configurados» en una línea base escrita, aplicada por una máquina y verificada cada semana.

1. Qué es el hardening y qué es una línea base
2. Estándares de referencia: CIS Benchmarks y STIG
3. Evaluar antes de tocar: lynis y OpenSCAP
4. Hardening del servidor Linux, paso a paso
5. SSH endurecido, directiva a directiva
6. auditd, fail2ban y actualizaciones automáticas
7. La gestión de parches como proceso
8. El endpoint del empleado
9. Antivirus frente a EDR
10. Gestión de dispositivos, BYOD y osquery
11. Automatizar y verificar la línea base
12. El sistema heredado que no se puede endurecer

Hardening es reducir la superficie de ataque de un sistema: quitar lo que no se usa, cerrar lo que no debe estar abierto, limitar lo que cada cuenta puede hacer y dejar registro de lo que ocurre. Es la aplicación al sistema operativo de los principios de 01-03 —mínimo privilegio, valores por defecto seguros, defensa en profundidad— y de la reducción de superficie de 01-04.

Un sistema recién instalado está optimizado para funcionar en cualquier escenario, no para el tuyo. Trae servicios activos que nunca usarás, permisos generosos y configuraciones cómodas. El hardening es la diferencia entre lo genérico y lo tuyo.

La idea que sostiene todo lo demás es la línea base: un conjunto de configuraciones de seguridad, escrito, versionado y aplicable de forma automática, que define cómo debe estar todo servidor y todo portátil de Nimbus. Sin línea base ocurren tres cosas: cada máquina acaba distinta, nadie sabe cuál es la correcta, y la deriva de configuración es invisible.

No hace falta inventar la línea base: existen catálogos públicos y detallados.

Cómo se usan de verdad, que no es como suele hacerse. Un benchmark de Ubuntu tiene más de 300 controles; aplicarlos todos a ciegas produce, con casi total seguridad, un servidor que no arranca o una aplicación que deja de funcionar. El procedimiento correcto tiene cuatro pasos:

1. Evaluar primero sobre un sistema real y ver la distancia actual (§3).
2. Filtrar por nivel y por rol: Nivel 1 completo; del Nivel 2, solo lo que aporte en tu contexto. Un control sobre servicios de impresión no aplica a un servidor de API.
3. Probar en preproducción, en tandas pequeñas y con reinicio incluido, porque muchos controles solo muestran su efecto al reiniciar.
4. Documentar las excepciones con motivo, responsable y caducidad, en el registro de 04-02. Un control no aplicado y no documentado es una desviación silenciosa; documentado, es una decisión.

El benchmark es un punto de partida, no una meta. Un 100 % de conformidad con datos personales sin cifrar y sin copias verificadas es peor postura que un 80 % con las prioridades bien elegidas.

• lynis --quick no espera confirmación entre secciones: es lo que permite ejecutarlo desde cron. Da una puntuación orientativa y una lista de sugerencias priorizadas.
• oscap evalúa contra un perfil formal (aquí, CIS Nivel 1 para servidor) y produce un XML procesable más un informe legible. Es la herramienta que genera evidencia auditable; lynis es la que se usa a diario.

Cómo leer esta salida sin perder el tiempo. El índice de endurecimiento (58) no es la métrica que importa: sirve para medir progreso, no para presumir. Lo que importa son las tres líneas marcadas con ! en la sección de servicios y SSH, porque describen exposición real: el http.server del puerto 8000 sigue ahí 94 días después, root puede entrar por SSH y se aceptan contraseñas. Esos tres se corrigen hoy; las 23 sugerencias se reparten en semanas.

Minimizar paquetes y servicios. Cada servicio activo es una superficie y un flujo de parches.

La regla de oro: si no sabes por qué está ahí, apágalo en preproducción y observa una semana. Es más rápido y más honesto que investigar el origen de cada servicio.

Usuarios y sudo con mínimo privilegio. Sin cuentas compartidas —una nominal por persona—, sin contraseña para servicios (cuentas de sistema con nologin), y sudo acotado por comando cuando sea posible en lugar de ALL. Todo uso de sudo se registra y ese registro alimenta las detecciones de 05-02.

Permisos y montajes. Las opciones de montaje son un control barato y muy efectivo:

noexec impide ejecutar binarios desde esa partición, nosuid anula el bit de escalada de privilegios y nodev bloquea ficheros de dispositivo. noexec en /tmp corta de raíz el patrón más común tras una intrusión: descargar una herramienta a /tmp y ejecutarla.

Parámetros del kernel. sysctl endurece la pila de red y el comportamiento del núcleo: desactivar el reenvío de paquetes en máquinas que no son routers, ignorar redirecciones ICMP, activar syncookies contra las inundaciones SYN, restringir el acceso a dmesg y a las trazas del kernel, y activar kernel.randomize_va_space=2 para la aleatorización del espacio de direcciones. Se declaran en /etc/sysctl.d/60-nimbus.conf y se aplican con sysctl --system.

AppArmor y SELinux son controles de acceso obligatorios: limitan lo que un proceso puede hacer aunque se ejecute como root. Si el proceso de Nginx solo tiene permitido leer su configuración y escribir sus logs, un compromiso de Nginx no puede leer /etc/shadow. En Ubuntu, AppArmor viene activo y con perfiles para los servicios habituales; la recomendación para Nimbus es no desactivarlo nunca —lo primero que hace mucha gente cuando algo no funciona— y aprender a leer sus denegaciones en el log.

SSH es la puerta de administración y, por tanto, el objetivo preferente.

Se valida con sshd -t antes de recargar el servicio y, muy importante, se prueba una segunda sesión antes de cerrar la primera: un error en este fichero deja el servidor inaccesible.

auditd registra llamadas al sistema y accesos a ficheros. Se configura con pocas reglas y bien elegidas, porque registrar todo genera gigabytes inservibles:

-w vigila una ruta (p wa = escritura y cambios de atributos), -k etiqueta el evento para poder buscarlo, y -e 2 congela las reglas: ni siquiera root puede modificarlas sin reiniciar, lo que impide que un atacante desactive la auditoría en silencio. Estos eventos alimentan directamente las detecciones D-07 y D-08 de 05-02.

fail2ban lee los logs y bloquea temporalmente las IP que fallan repetidamente. Es útil, pero conviene situarlo bien: con SSH accesible solo desde el bastión y sin autenticación por contraseña, fail2ban es la segunda línea, no la primera. Donde sí aporta valor real es delante de la API, complementando el límite de tasa de 05-05, y es una de las respuestas automáticas que 05-02 clasificó como seguras por ser reversibles.

Actualizaciones automáticas de seguridad. En los servidores de Nimbus se activa unattended-upgrades solo para el repositorio de seguridad, con ventana nocturna, reinicio automático desactivado y notificación por correo. El razonamiento: la probabilidad de que un parche de seguridad rompa algo es baja; la probabilidad de que un servidor sin parchear durante seis semanas sea explotado, no lo es. Los paquetes críticos para el servicio (la base de datos) se excluyen y se parchean en ventana planificada.

Parchear no es ejecutar apt upgrade: es un proceso con inventario, plazos y verificación, que se apoya en la política de prioridades P0-P4 de 05-01.

El compromiso real es entre disponibilidad y riesgo, y conviene formularlo con honestidad: parchear puede romper el servicio unos minutos; no parchear puede costar el servicio durante días. La forma de resolverlo no es elegir un bando, sino reducir el coste de parchear: entornos reproducibles, despliegue sin corte, y una prueba de humo automática que confirme que la aplicación sigue viva tras la ventana. Cuando parchear cuesta veinte minutos y no una noche, el dilema desaparece.

Y el caso especial: el reinicio pendiente. Nimbus lo trata como un hallazgo con dueño y plazo, no como una molestia. needrestart indica qué servicios siguen usando bibliotecas antiguas, y esa lista se revisa en cada ventana.

Cuarenta portátiles, la mitad fuera de la oficina. Es el activo A-14 y el principio de la mayoría de las intrusiones reales.

La cuenta sin privilegios de administrador merece un párrafo propio, porque es el control con mejor relación coste/eficacia de toda la lección y el que más resistencia genera. Sin privilegios, la mayoría del malware no puede instalarse, no puede persistir entre reinicios, no puede desactivar el antivirus y no puede leer las credenciales de otras cuentas del equipo. La objeción habitual —«los desarrolladores necesitan instalar cosas»— se resuelve casi siempre con gestores de paquetes de usuario, contenedores y una vía de elevación puntual con registro. La objeción real que queda es cultural, y se gestiona explicándolo, no imponiéndolo.

Por qué el EDR importa, dicho sin marketing: el antivirus responde «¿este fichero es malo?», y el EDR responde «¿qué ha pasado en este equipo?». Cuando el portátil de Sara aparece comprometido, el antivirus dice que puso algo en cuarentena; el EDR muestra que un adjunto abrió PowerShell, que PowerShell descargó un fichero, que ese fichero se copió a la carpeta de inicio y que abrió una conexión a un dominio registrado hace tres días. Lo primero cierra una incidencia; lo segundo permite responder según 04-05 y contestar la única pregunta que importa: ¿hasta dónde llegó?

Recomendación para Nimbus con 18.000 €/año: Microsoft Defender (incluido) como antivirus + agente de Wazuh como capa de visibilidad y respuesta. Cubre el 80 % de lo que da un EDR comercial a coste cero de licencia, a cambio de horas de Lucía. Cuando el presupuesto crezca, el EDR gestionado es la primera compra de esta lección.

MDM (gestión de dispositivos) es lo que hace aplicable todo lo anterior a cuarenta equipos sin visitar cada uno. Aplica la línea base, exige cifrado y bloqueo, distribuye actualizaciones, instala agentes y —lo más importante— permite el borrado remoto de un equipo perdido y comprueba de forma continua que la política sigue aplicada. Para Nimbus, la opción realista es el MDM incluido en su proveedor de identidad/ofimática, más el agente de Wazuh.

BYOD (dispositivos personales) es donde la técnica se cruza con lo legal y lo laboral. Nimbus no puede borrar el móvil personal de Sara ni inspeccionar sus fotos. El planteamiento correcto, alineado con POL-04 (Uso Aceptable), es: acceso al correo y a las herramientas corporativas solo desde el contenedor de trabajo gestionado del dispositivo, con requisitos mínimos verificables (bloqueo con PIN, cifrado, sistema al día, sin root/jailbreak), borrado remoto limitado a los datos corporativos, e información previa y por escrito de qué puede ver y hacer la empresa y qué no. (Nota de validación legal: en España el control de dispositivos del personal exige información previa y proporcionalidad; la política BYOD conviene revisarla jurídicamente antes de aplicarla. Se desarrolla en 06-03.)

osquery convierte el parque en una base de datos SQL a la que se pueden hacer preguntas. Es la herramienta que responde a las métricas de 04-03 con datos y no con estimaciones:

La tercera consulta, ejecutada sobre los servidores, es la que habría encontrado el http.server el primer día. Y todas ellas, programadas y enviadas a Wazuh, convierten «creemos que el 98 % está cifrado» en un número exacto con fecha, que es exactamente lo que 04-03 exige como evidencia.

Por qué no se aplica a mano. Configurar treinta directivas en un servidor lleva dos horas, se hace distinto la segunda vez, no queda registro de qué se cambió y no se puede repetir cuando el servidor se recrea. La línea base se aplica con Ansible (o equivalente) o se hornea en una imagen dorada.

Tres propiedades hacen valioso este fichero. Es idempotente: se puede ejecutar mil veces y el resultado es el mismo, así que sirve tanto para aplicar como para corregir la deriva. Es la documentación, porque describe exactamente cómo está configurada la flota, sin que pueda quedar desactualizada. Y está versionado, de modo que cada cambio de la línea base pasa por revisión como cualquier otro código.

La evolución natural es la infraestructura inmutable: en lugar de modificar servidores, se construye una imagen ya endurecida y los servidores se sustituyen en cada despliegue. Elimina la deriva por definición —ningún servidor vive lo suficiente para desviarse— y, como beneficio de seguridad enorme, destruye cualquier persistencia del atacante en cada despliegue. Para la API en contenedores de Nimbus esto ya es así, y se desarrolla en 05-07.

Verificar. La línea base no se aplica y se olvida: se comprueba.

--check --diff es la joya: ejecuta el playbook sin aplicar nada y muestra qué se desviaría de la línea base. Si el resultado no está vacío, alguien tocó algo a mano y hay que averiguar quién y por qué. Se completa con la vigilancia de integridad de ficheros (FIM de Wazuh) sobre /etc, /usr/bin y las claves SSH, cuyos avisos van al canal de 05-02 como una detección más: un cambio no autorizado en la configuración de un servidor es una señal de compromiso, no una curiosidad.

Siempre hay uno: un servidor con una aplicación que solo funciona con una versión antigua, una máquina de un proveedor que no permite tocar nada, un equipo que controla algo físico. Negarlo no ayuda; la respuesta correcta es aislar y compensar:

• Aislar en su propia zona de red (05-04), con reglas de entrada y salida mínimas: si no puede navegar, no puede recibir órdenes ni exfiltrar.
• Compensar con controles alrededor: proxy inverso delante con WAF, autenticación en la capa anterior, registro exhaustivo de todo lo que entra y sale.
• Monitorizar más, no menos: al ser el sistema más frágil, es el que necesita las detecciones más sensibles.
• Copia y plan de recuperación específicos, porque será el más difícil de reconstruir.
• Documentarlo como riesgo aceptado con caducidad en el registro de 04-01, con fecha de revisión y, si se puede, presupuesto de sustitución.

Nimbus tiene su propio caso: A-22, el entorno de preproducción. No es que no se pueda endurecer; es que nadie lo ha hecho. La decisión correcta es aplicarle la misma línea base que a producción —cuesta lo mismo, porque está automatizada— y resolver de una vez la clasificación «a revisar» del inventario.

• Aplicar un benchmark completo a ciegas. Rompes el servicio, pierdes la confianza del equipo y el proyecto de hardening muere en la primera semana.
• Cambiar el puerto de SSH y creer que es un control. Reduce ruido; no detiene a nadie. El control es que solo sea alcanzable desde el bastión.
• Recargar sshd sin validar y sin una segunda sesión abierta. Es la forma clásica de quedarse fuera de un servidor de producción.
• Desactivar AppArmor o SELinux «porque algo no funciona». Se ajusta el perfil, no se apaga el control.
• Parchear sin reiniciar. Un kernel actualizado y no reiniciado sigue siendo vulnerable, y la métrica de parcheo miente.
• Dejar a todo el mundo con privilegios de administrador local. Es el control que más ataques detiene y el que más se posterga.
• Aplicar la línea base a mano. No es repetible, no deja registro y garantiza que ninguna máquina sea igual a otra.
• Consejo: empieza por medir. Ejecuta lynis en los tres servidores hoy: en veinte minutos tendrás la lista priorizada de lo que hay que hacer, gratis.
• Consejo: --check --diff semanal en el CI. Es la forma más barata de detectar la deriva de configuración y el cambio no autorizado.
• Consejo: la primera consulta de osquery que debes lanzar es la de cifrado de disco. Convierte un KPI estimado en un número exacto, y suele dar una sorpresa.

Lucía ejecuta lynis sobre api-prod-1 y obtiene, además del índice 58, estos hallazgos:

1. Ordena los ocho hallazgos por prioridad, justificando el criterio.
2. Indica cuáles se corrigen hoy y cuáles requieren ventana de mantenimiento, y por qué.
3. ¿Cuál de ellos no se resuelve en este servidor, sino en otra capa?

Marta aprueba presupuesto para poner en regla los 40 portátiles. Define la línea base del puesto:

1. Diez controles con su justificación, ordenados por impacto.
2. Para cada uno, cómo se verifica de forma automática que sigue aplicado.
3. Qué harías con el desarrollador que exige privilegios de administrador permanentes.

El ansible-playbook --check --diff semanal devuelve esto sobre api-prod-2:

Interpreta cada diferencia, indica qué es más grave y qué acciones tomarías.

Ejercicio 1

(1) Orden por prioridad, aplicando el criterio de 05-01 —exposición y explotabilidad primero, no gravedad nominal—:

(2) Hoy frente a ventana. Se corrigen hoy, sin corte: el http.server (matar el proceso y eliminar la unidad), las directivas de SSH (recargar sshd no corta las sesiones existentes, siempre validando antes con sshd -t y con una segunda sesión abierta), auditd, el cortafuegos local —con cuidado de aplicar la regla de permitir SSH antes que la política de denegar por defecto— y el umask. Requieren ventana de mantenimiento: las 2 actualizaciones de kernel, porque exigen reinicio y sin él la vulnerabilidad sigue viva; y la partición separada de /tmp, que implica repartir el disco. Las 12 actualizaciones restantes pueden aplicarse en horario laboral si no afectan a servicios activos, aunque conviene agruparlas en la ventana del martes.

(3) El hallazgo que no se resuelve aquí es, en rigor, el de exposición del puerto 8000: eliminar el proceso es la corrección inmediata, pero la pregunta de fondo —¿por qué un servicio no autorizado era alcanzable desde Internet?— se responde en 05-04, con el grupo de seguridad que solo debería permitir 443 desde el balanceador. La respuesta completa combina dos capas: el hardening quita el servicio, y la red impide que un servicio futuro sea alcanzable. Ese es exactamente el sentido de la defensa en profundidad de 01-03.

Ejercicio 2

(1) y (2) Línea base del puesto:

La verificación es lo que separa esta lista de un documento decorativo: cada control tiene una consulta que produce un número con fecha, y ese número es la evidencia que 04-03 pide y que un cliente o un auditor solicitará en 06-04.

(3) El desarrollador que pide administrador permanente. No se le dice que no sin más, ni se le dice que sí. Primero se averigua el caso de uso concreto —normalmente instalar dependencias, usar contenedores o depurar—, porque casi todos se cubren sin privilegios permanentes: gestores de paquetes en el espacio del usuario, Docker con el grupo adecuado, y herramientas preaprobadas instaladas por el MDM. Para lo que quede, se ofrece elevación puntual con registro: una vía que concede privilegios durante un tiempo limitado, deja rastro de qué se hizo y no sobrevive al reinicio. Es el mismo modelo just-in-time de A-19 aplicado al puesto. Si aun así queda un caso irreductible, se documenta como excepción con responsable y caducidad (04-02), se compensa con monitorización reforzada en ese equipo, y se revisa cada seis meses: casi todas las excepciones de este tipo dejan de ser necesarias antes de la primera revisión.

Ejercicio 3

Primera diferencia — PasswordAuthentication yes en el servidor. Alguien desactivó a mano un control de la línea base en un servidor de producción. Es lo más grave del informe por tres motivos: reabre la autenticación por contraseña, y con ella la fuerza bruta y el credential stuffing; es exactamente lo que haría un atacante para garantizarse la vuelta tras perder su acceso original; y es un cambio no autorizado, es decir, un indicador de compromiso hasta que se demuestre lo contrario. Acciones inmediatas: no revertirlo en silencio. Primero, consultar el registro de auditd (-w /etc/ssh/sshd_config -p wa) para saber quién y cuándo; revisar los accesos SSH con éxito por contraseña desde ese momento; y solo entonces reaplicar la línea base. Si no aparece una explicación legítima con ticket, se trata como incidente S2 según 04-05.

Segunda diferencia — soporte-tmp en AllowUsers. Una cuenta temporal —el nombre lo delata— con acceso SSH a producción, que sobrevivió al motivo que la creó. Es la misma familia de problemas que la excepción sin caducidad de A-19 y que el http.server: lo temporal que se queda. Se comprueba quién la usa, cuándo se creó, si tiene clave asociada y qué hizo; se elimina la cuenta y no solo la línea de AllowUsers; y se revisa si existen cuentas equivalentes en los demás servidores.

Tercera diferencia — reglas de auditd ausentes. El fichero no existe en api-prod-2. Es menos alarmante que las dos anteriores porque puede deberse simplemente a que la máquina se creó antes de que la regla entrara en la línea base, pero tiene una consecuencia grave sobre este mismo ejercicio: sin auditd, la investigación del primer punto puede no tener datos, y por eso conviene comprobar primero si el fichero llegó a existir. Acción: aplicar la línea base completa y verificar que en el resto de servidores sí está.

Conclusión transversal del ejercicio. Los tres hallazgos aparecieron porque existía una línea base automatizada y una comprobación semanal. Sin --check --diff, el PasswordAuthentication yes habría permanecido invisible hasta el siguiente pentest o hasta que alguien lo usara. Ese es el argumento entero de la lección: el hardening no es aplicar configuraciones, es mantener una diferencia igual a cero.

Has aplicado al sistema operativo la reducción de superficie que el módulo 1 planteó en abstracto. Sabes qué es el hardening y, sobre todo, qué es una línea base: un conjunto de configuraciones escrito, versionado y aplicable por una máquina, sin el cual cada servidor acaba distinto, nadie sabe cuál es el correcto y la deriva es invisible. Conoces los CIS Benchmarks y los STIG, y el procedimiento honesto para usarlos —evaluar, filtrar por nivel y rol, probar en preproducción y documentar excepciones— junto con el aviso que evita el fracaso más común: aplicar 300 controles a ciegas rompe el servicio y mata el proyecto en la primera semana. Sabes evaluar antes de tocar con lynis y OpenSCAP, y leer su salida buscando exposición real en lugar de presumir de índice.

Tienes el hardening del servidor Linux completo: minimizar servicios —donde muere definitivamente el python -m http.server de 01-04, eliminando la unidad y no solo matando el proceso—, cuentas nominales y sudo acotado, montajes con noexec, nosuid y nodev que cortan de raíz el patrón de descargar y ejecutar desde /tmp, parámetros del kernel, y AppArmor/SELinux con la regla de ajustarlos y no apagarlos. Dominas el sshd_config directiva a directiva, con PermitRootLogin no, sin contraseñas, solo claves Ed25519, AllowUsers como lista blanca, tiempos de inactividad, LogLevel VERBOSE para registrar la huella de la clave usada, y la advertencia de que cambiar el puerto no es un control: lo es que solo sea alcanzable desde el bastión. Sabes configurar auditd con pocas reglas bien elegidas y -e 2 para congelarlas, situar fail2ban como segunda línea y activar actualizaciones automáticas de seguridad con criterio.

Manejas la gestión de parches como proceso —inventario, recepción, priorización P0-P4, prueba, ventana, reinicio y verificación— con la clave que disuelve el dilema entre disponibilidad y riesgo: reducir el coste de parchear hasta que dure veinte minutos. Tienes la línea base del endpoint con sus ocho controles, encabezada por el que más ataques detiene y más resistencia genera —la cuenta sin privilegios de administrador—, y sabes distinguir antivirus de EDR por la pregunta que responde cada uno: «¿este fichero es malo?» frente a «¿hasta dónde llegó?». Sabes qué aporta el MDM, cómo plantear el BYOD de forma compatible con POL-04 y con la ley, y cómo usar osquery para convertir estimaciones en números con fecha, incluida la consulta que habría encontrado el http.server el primer día. Y te llevas lo que hace sostenible todo lo anterior: automatizar con Ansible de forma idempotente, versionada y autodocumentada, la evolución hacia la infraestructura inmutable que destruye cualquier persistencia en cada despliegue, y la verificación semanal con --check --diff, porque el hardening no es aplicar configuraciones sino mantener una diferencia igual a cero. Con el sistema heredado, la respuesta es aislar, compensar, monitorizar más y documentar el riesgo con caducidad.

Fíjate en la última idea, porque es el puente. La infraestructura inmutable, las imágenes doradas y los contenedores de la API llevan toda la lección apareciendo como 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, se reconstruye; y la cuenta cloud que lo ejecuta tiene una superficie propia que ningún lynis mira. Ahí es donde hoy se producen la mayoría de las brechas, y no por un exploit sino por un error de configuración: un bucket público, una política de permisos demasiado amplia, unas copias que viven en la misma cuenta que producción. En Seguridad en la Nube y en Contenedores (05-07) cerramos el plan técnico del curso: responsabilidad compartida en lo técnico, identidad como nuevo perímetro, el bucket A-02 bien configurado de una vez, red y copias aisladas por cuenta, registro y alertas de la nube, postura automatizada con prowler y checkov, imágenes seguras con su Dockerfile antes y después, firma con cosign, ejecución con capacidades mínimas y detección en tiempo de ejecución con Falco.