La lliçó anterior va deixar el codi de Nimbus defensant-se sol. Però aquest codi s'executa sobre alguna cosa: servidors amb paquets, serveis, usuaris i permisos, i una quarantena de portàtils repartits entre l'oficina de València i les cases de mitja plantilla. Allà segueix viu, des d'01-04, el python -m http.server que ningú no va apagar; allà hi ha els equips sense xifrar del KPI de 04-03 (92,3 % davant de l'objectiu del 98 %); i allà hi ha els comptes amb privilegis d'administrador que ningú no necessita. Aquesta lliçó aplica al sistema operatiu la reducció de superfície d'01-04 i converteix «tenim els servidors ben configurats» en una línia base escrita, aplicada per una màquina i verificada cada setmana.

1. Què és l'enfortiment i què és una línia base
2. Estàndards de referència: CIS Benchmarks i STIG
3. Avaluar abans de tocar: lynis i OpenSCAP
4. Enfortiment del servidor Linux, pas a pas
5. SSH endurit, directiva a directiva
6. auditd, fail2ban i actualitzacions automàtiques
7. La gestió de pedaços com a procés
8. L'endpoint de l'empleat
9. Antivirus davant d'EDR
10. Gestió de dispositius, BYOD i osquery
11. Automatitzar i verificar la línia base
12. El sistema heretat que no es pot endurir

Enfortiment (hardening) és reduir la superfície d'atac d'un sistema: treure el que no es fa servir, tancar el que no ha d'estar obert, limitar el que cada compte pot fer i deixar registre del que passa. És l'aplicació al sistema operatiu dels principis d'01-03 —mínim privilegi, valors per omissió segurs, defensa en profunditat— i de la reducció de superfície d'01-04.

Un sistema acabat d'instal·lar està optimitzat per funcionar en qualsevol escenari, no per al teu. Porta serveis actius que no faràs servir mai, permisos generosos i configuracions còmodes. L'enfortiment és la diferència entre el que és genèric i el que és teu.

La idea que sosté tota la resta és la línia base: un conjunt de configuracions de seguretat, escrit, versionat i aplicable de forma automàtica, que defineix com ha d'estar tot servidor i tot portàtil de Nimbus. Sense línia base passen tres coses: cada màquina acaba diferent, ningú no sap quina és la correcta, i la deriva de configuració és invisible.

No cal inventar la línia base: existeixen catàlegs públics i detallats.

Com es fan servir de debò, que no és com se sol fer. Un benchmark d'Ubuntu té més de 300 controls; aplicar-los tots a cegues produeix, amb gairebé tota seguretat, un servidor que no arrenca o una aplicació que deixa de funcionar. El procediment correcte té quatre passos:

1. Avaluar primer sobre un sistema real i veure la distància actual (§3).
2. Filtrar per nivell i per rol: Nivell 1 complet; del Nivell 2, només el que aporti en el teu context. Un control sobre serveis d'impressió no aplica a un servidor d'API.
3. Provar en preproducció, en tandes petites i amb reinici inclòs, perquè molts controls només mostren el seu efecte en reiniciar.
4. Documentar les excepcions amb motiu, responsable i caducitat, al registre de 04-02. Un control no aplicat i no documentat és una desviació silenciosa; documentat, és una decisió.

El benchmark és un punt de partida, no una meta. Un 100 % de conformitat amb dades personals sense xifrar i sense còpies verificades és pitjor postura que un 80 % amb les prioritats ben triades.

• lynis --quick no espera confirmació entre seccions: és el que permet executar-lo des de cron. Dona una puntuació orientativa i una llista de suggeriments prioritzats.
• oscap avalua contra un perfil formal (aquí, CIS Nivell 1 per a servidor) i produeix un XML processable més un informe llegible. És l'eina que genera evidència auditable; lynis és la que es fa servir cada dia.

Com llegir aquesta sortida sense perdre el temps. L'índex d'enduriment (58) no és la mètrica que importa: serveix per mesurar progrés, no per presumir. El que importa són les tres línies marcades amb ! a la secció de serveis i SSH, perquè descriuen exposició real: el http.server del port 8000 continua allà 94 dies després, root pot entrar per SSH i s'accepten contrasenyes. Aquests tres es corregeixen avui; els 23 suggeriments es reparteixen en setmanes.

Minimitzar paquets i serveis. Cada servei actiu és una superfície i un flux de pedaços.

La regla d'or: si no saps per què és allà, apaga'l en preproducció i observa una setmana. És més ràpid i més honest que investigar l'origen de cada servei.

Usuaris i sudo amb mínim privilegi. Sense comptes compartits —un de nominal per persona—, sense contrasenya per a serveis (comptes de sistema amb nologin), i sudo acotat per ordre quan sigui possible en lloc d'ALL. Tot ús de sudo es registra i aquest registre alimenta les deteccions de 05-02.

Permisos i muntatges. Les opcions de muntatge són un control barat i molt efectiu:

noexec impedeix executar binaris des d'aquella partició, nosuid anul·la el bit d'escalada de privilegis i nodev bloqueja fitxers de dispositiu. noexec a /tmp talla d'arrel el patró més comú després d'una intrusió: descarregar una eina a /tmp i executar-la.

Paràmetres del kernel. sysctl endureix la pila de xarxa i el comportament del nucli: desactivar el reenviament de paquets en màquines que no són routers, ignorar redireccions ICMP, activar syncookies contra les inundacions SYN, restringir l'accés a dmesg i a les traces del kernel, i activar kernel.randomize_va_space=2 per a l'aleatorització de l'espai d'adreces. Es declaren a /etc/sysctl.d/60-nimbus.conf i s'apliquen amb sysctl --system.

AppArmor i SELinux són controls d'accés obligatoris: limiten el que un procés pot fer encara que s'executi com a root. Si el procés d'Nginx només té permès llegir la seva configuració i escriure els seus logs, un compromís d'Nginx no pot llegir /etc/shadow. A Ubuntu, AppArmor ve actiu i amb perfils per als serveis habituals; la recomanació per a Nimbus és no desactivar-lo mai —el primer que fa molta gent quan alguna cosa no funciona— i aprendre a llegir les seves denegacions al log.

SSH és la porta d'administració i, per tant, l'objectiu preferent.

Es valida amb sshd -t abans de recarregar el servei i, molt important, es prova una segona sessió abans de tancar la primera: un error en aquest fitxer deixa el servidor inaccessible.

auditd registra crides al sistema i accessos a fitxers. Es configura amb poques regles i ben triades, perquè registrar-ho tot genera gigabytes inservibles:

-w vigila una ruta (p wa = escriptura i canvis d'atributs), -k etiqueta l'esdeveniment per poder cercar-lo, i -e 2 congela les regles: ni tan sols root pot modificar-les sense reiniciar, cosa que impedeix que un atacant desactivi l'auditoria en silenci. Aquests esdeveniments alimenten directament les deteccions D-07 i D-08 de 05-02.

fail2ban llegeix els logs i bloqueja temporalment les IP que fallen repetidament. És útil, però convé situar-lo bé: amb SSH accessible només des del bastió i sense autenticació per contrasenya, fail2ban és la segona línia, no la primera. On sí que aporta valor real és davant de l'API, complementant el límit de taxa de 05-05, i és una de les respostes automàtiques que 05-02 va classificar com a segures per ser reversibles.

Actualitzacions automàtiques de seguretat. Als servidors de Nimbus s'activa unattended-upgrades només per al repositori de seguretat, amb finestra nocturna, reinici automàtic desactivat i notificació per correu. El raonament: la probabilitat que un pedaç de seguretat trenqui alguna cosa és baixa; la probabilitat que un servidor sense pedaços durant sis setmanes sigui explotat, no ho és. Els paquets crítics per al servei (la base de dades) s'exclouen i se'ls apliquen pedaços en finestra planificada.

Aplicar pedaços no és executar apt upgrade: és un procés amb inventari, terminis i verificació, que es recolza en la política de prioritats P0-P4 de 05-01.

El compromís real és entre disponibilitat i risc, i convé formular-lo amb honestedat: aplicar un pedaç pot trencar el servei uns minuts; no aplicar-lo pot costar el servei durant dies. La forma de resoldre-ho no és triar un bàndol, sinó reduir el cost d'aplicar pedaços: entorns reproduïbles, desplegament sense tall, i una prova de fum automàtica que confirmi que l'aplicació segueix viva després de la finestra. Quan aplicar un pedaç costa vint minuts i no una nit, el dilema desapareix.

I el cas especial: el reinici pendent. Nimbus el tracta com una troballa amb propietari i termini, no com una molèstia. needrestart indica quins serveis continuen fent servir biblioteques antigues, i aquesta llista es revisa a cada finestra.

Quaranta portàtils, la meitat fora de l'oficina. És l'actiu A-14 i el principi de la majoria de les intrusions reals.

El compte sense privilegis d'administrador mereix un paràgraf propi, perquè és el control amb millor relació cost/eficàcia de tota la lliçó i el que més resistència genera. Sense privilegis, la majoria del programari maliciós no es pot instal·lar, no pot persistir entre reinicis, no pot desactivar l'antivirus i no pot llegir les credencials d'altres comptes de l'equip. L'objecció habitual —«els desenvolupadors necessiten instal·lar coses»— es resol gairebé sempre amb gestors de paquets d'usuari, contenidors i una via d'elevació puntual amb registre. L'objecció real que queda és cultural, i es gestiona explicant-ho, no imposant-ho.

Per què l'EDR importa, dit sense màrqueting: l'antivirus respon «aquest fitxer és dolent?», i l'EDR respon «què ha passat en aquest equip?». Quan el portàtil de la Sara apareix compromès, l'antivirus diu que va posar alguna cosa en quarantena; l'EDR mostra que un adjunt va obrir PowerShell, que PowerShell va descarregar un fitxer, que aquell fitxer es va copiar a la carpeta d'inici i que va obrir una connexió a un domini registrat fa tres dies. El primer tanca una incidència; el segon permet respondre segons 04-05 i contestar l'única pregunta que importa: fins on va arribar?

Recomanació per a Nimbus amb 18.000 €/any: Microsoft Defender (inclòs) com a antivirus + agent de Wazuh com a capa de visibilitat i resposta. Cobreix el 80 % del que dona un EDR comercial a cost zero de llicència, a canvi d'hores de la Lucía. Quan el pressupost creixi, l'EDR gestionat és la primera compra d'aquesta lliçó.

MDM (gestió de dispositius) és el que fa aplicable tot l'anterior a quaranta equips sense visitar-ne cap. Aplica la línia base, exigeix xifratge i bloqueig, distribueix actualitzacions, instal·la agents i —el més important— permet l'esborrament remot d'un equip perdut i comprova de forma contínua que la política segueix aplicada. Per a Nimbus, l'opció realista és el MDM inclòs al seu proveïdor d'identitat/ofimàtica, més l'agent de Wazuh.

BYOD (dispositius personals) és on la tècnica es creua amb el legal i el laboral. Nimbus no pot esborrar el mòbil personal de la Sara ni inspeccionar les seves fotos. El plantejament correcte, alineat amb POL-04 (Ús Acceptable), és: accés al correu i a les eines corporatives només des del contenidor de treball gestionat del dispositiu, amb requisits mínims verificables (bloqueig amb PIN, xifratge, sistema al dia, sense root/jailbreak), esborrament remot limitat a les dades corporatives, i informació prèvia i per escrit de què pot veure i fer l'empresa i què no. (Nota de validació legal: a Espanya el control de dispositius del personal exigeix informació prèvia i proporcionalitat; la política BYOD convé revisar-la jurídicament abans d'aplicar-la. Es desenvolupa a 06-03.)

osquery converteix el parc en una base de dades SQL a la qual es poden fer preguntes. És l'eina que respon a les mètriques de 04-03 amb dades i no amb estimacions:

La tercera consulta, executada sobre els servidors, és la que hauria trobat el http.server el primer dia. I totes elles, programades i enviades a Wazuh, converteixen «creiem que el 98 % està xifrat» en un número exacte amb data, que és exactament el que 04-03 exigeix com a evidència.

Per què no s'aplica a mà. Configurar trenta directives en un servidor porta dues hores, es fa diferent la segona vegada, no queda registre de què es va canviar i no es pot repetir quan el servidor es recrea. La línia base s'aplica amb Ansible (o equivalent) o s'enforna en una imatge daurada.

Tres propietats fan valuós aquest fitxer. És idempotent: es pot executar mil vegades i el resultat és el mateix, així que serveix tant per aplicar com per corregir la deriva. És la documentació, perquè descriu exactament com està configurada la flota, sense que pugui quedar desactualitzada. I està versionat, de manera que cada canvi de la línia base passa per revisió com qualsevol altre codi.

L'evolució natural és la infraestructura immutable: en lloc de modificar servidors, es construeix una imatge ja endurida i els servidors se substitueixen a cada desplegament. Elimina la deriva per definició —cap servidor no viu prou per desviar-se— i, com a benefici de seguretat enorme, destrueix qualsevol persistència de l'atacant a cada desplegament. Per a l'API en contenidors de Nimbus això ja és així, i es desenvolupa a 05-07.

Verificar. La línia base no s'aplica i s'oblida: es comprova.

--check --diff és la joia: executa el playbook sense aplicar res i mostra què es desviaria de la línia base. Si el resultat no està buit, algú va tocar alguna cosa a mà i cal esbrinar qui i per què. Es completa amb la vigilància d'integritat de fitxers (FIM de Wazuh) sobre /etc, /usr/bin i les claus SSH, els avisos de la qual van al canal de 05-02 com una detecció més: un canvi no autoritzat a la configuració d'un servidor és un senyal de compromís, no una curiositat.

Sempre n'hi ha un: un servidor amb una aplicació que només funciona amb una versió antiga, una màquina d'un proveïdor que no permet tocar res, un equip que controla alguna cosa física. Negar-ho no ajuda; la resposta correcta és aïllar i compensar:

• Aïllar a la seva pròpia zona de xarxa (05-04), amb regles d'entrada i sortida mínimes: si no pot navegar, no pot rebre ordres ni exfiltrar.
• Compensar amb controls al voltant: proxy invers al davant amb WAF, autenticació a la capa anterior, registre exhaustiu de tot el que entra i surt.
• Monitorar més, no menys: en ser el sistema més fràgil, és el que necessita les deteccions més sensibles.
• Còpia i pla de recuperació específics, perquè serà el més difícil de reconstruir.
• Documentar-lo com a risc acceptat amb caducitat al registre de 04-01, amb data de revisió i, si es pot, pressupost de substitució.

Nimbus té el seu propi cas: A-22, l'entorn de preproducció. No és que no es pugui endurir; és que ningú no ho ha fet. La decisió correcta és aplicar-li la mateixa línia base que a producció —costa el mateix, perquè està automatitzada— i resoldre d'una vegada la classificació «a revisar» de l'inventari.

• Aplicar un benchmark complet a cegues. Trenques el servei, perds la confiança de l'equip i el projecte d'enfortiment mor la primera setmana.
• Canviar el port d'SSH i creure que és un control. Redueix soroll; no atura ningú. El control és que només sigui assolible des del bastió.
• Recarregar sshd sense validar i sense una segona sessió oberta. És la forma clàssica de quedar-se fora d'un servidor de producció.
• Desactivar AppArmor o SELinux «perquè alguna cosa no funciona». S'ajusta el perfil, no s'apaga el control.
• Aplicar pedaços sense reiniciar. Un kernel actualitzat i no reiniciat continua sent vulnerable, i la mètrica d'aplicació de pedaços menteix.
• Deixar tothom amb privilegis d'administrador local. És el control que més atacs atura i el que més es posposa.
• Aplicar la línia base a mà. No és repetible, no deixa registre i garanteix que cap màquina no sigui igual que una altra.
• Consell: comença per mesurar. Executa lynis als tres servidors avui: en vint minuts tindràs la llista prioritzada del que cal fer, gratis.
• Consell: --check --diff setmanal al CI. És la forma més barata de detectar la deriva de configuració i el canvi no autoritzat.
• Consell: la primera consulta d'osquery que has de llançar és la de xifratge de disc. Converteix un KPI estimat en un número exacte, i sol donar una sorpresa.

La Lucía executa lynis sobre api-prod-1 i obté, a més de l'índex 58, aquestes troballes:

1. Ordena les vuit troballes per prioritat, justificant el criteri.
2. Indica quines es corregeixen avui i quines requereixen finestra de manteniment, i per què.
3. Quina d'elles no es resol en aquest servidor, sinó en una altra capa?

La Marta aprova pressupost per posar en regla els 40 portàtils. Defineix la línia base del lloc de treball:

1. Deu controls amb la seva justificació, ordenats per impacte.
2. Per a cadascun, com es verifica de forma automàtica que segueix aplicat.
3. Què faries amb el desenvolupador que exigeix privilegis d'administrador permanents.

L'ansible-playbook --check --diff setmanal retorna això sobre api-prod-2:

Interpreta cada diferència, indica què és més greu i quines accions prendries.

Exercici 1

(1) Ordre per prioritat, aplicant el criteri de 05-01 —exposició i explotabilitat primer, no gravetat nominal—:

(2) Avui davant de finestra. Es corregeixen avui, sense tall: el http.server (matar el procés i eliminar la unitat), les directives d'SSH (recarregar sshd no talla les sessions existents, sempre validant abans amb sshd -t i amb una segona sessió oberta), auditd, el tallafoc local —amb compte d'aplicar la regla de permetre SSH abans que la política de denegar per omissió— i l'umask. Requereixen finestra de manteniment: les 2 actualitzacions de kernel, perquè exigeixen reinici i sense ell la vulnerabilitat segueix viva; i la partició separada de /tmp, que implica repartir el disc. Les 12 actualitzacions restants es poden aplicar en horari laboral si no afecten serveis actius, encara que convé agrupar-les a la finestra del dimarts.

(3) La troballa que no es resol aquí és, en rigor, la d'exposició del port 8000: eliminar el procés és la correcció immediata, però la pregunta de fons —per què un servei no autoritzat era assolible des d'Internet?— es respon a 05-04, amb el grup de seguretat que només hauria de permetre 443 des del balancejador. La resposta completa combina dues capes: l'enfortiment treu el servei, i la xarxa impedeix que un servei futur sigui assolible. Aquest és exactament el sentit de la defensa en profunditat d'01-03.

Exercici 2

(1) i (2) Línia base del lloc de treball:

La verificació és el que separa aquesta llista d'un document decoratiu: cada control té una consulta que produeix un número amb data, i aquest número és l'evidència que 04-03 demana i que un client o un auditor sol·licitarà a 06-04.

(3) El desenvolupador que demana administrador permanent. No se li diu que no sense més, ni se li diu que sí. Primer s'esbrina el cas d'ús concret —normalment instal·lar dependències, fer servir contenidors o depurar—, perquè gairebé tots es cobreixen sense privilegis permanents: gestors de paquets a l'espai de l'usuari, Docker amb el grup adequat, i eines preaprovades instal·lades pel MDM. Per al que quedi, s'ofereix elevació puntual amb registre: una via que concedeix privilegis durant un temps limitat, deixa rastre de què es va fer i no sobreviu al reinici. És el mateix model just-in-time d'A-19 aplicat al lloc de treball. Si així i tot queda un cas irreductible, es documenta com a excepció amb responsable i caducitat (04-02), es compensa amb monitoratge reforçat en aquell equip, i es revisa cada sis mesos: gairebé totes les excepcions d'aquest tipus deixen de ser necessàries abans de la primera revisió.

Exercici 3

Primera diferència — PasswordAuthentication yes al servidor. Algú va desactivar a mà un control de la línia base en un servidor de producció. És el més greu de l'informe per tres motius: reobre l'autenticació per contrasenya, i amb ella la força bruta i el credential stuffing; és exactament el que faria un atacant per garantir-se el retorn després de perdre el seu accés original; i és un canvi no autoritzat, és a dir, un indicador de compromís fins que es demostri el contrari. Accions immediates: no revertir-ho en silenci. Primer, consultar el registre d'auditd (-w /etc/ssh/sshd_config -p wa) per saber qui i quan; revisar els accessos SSH amb èxit per contrasenya des d'aquell moment; i només llavors reaplicar la línia base. Si no apareix una explicació legítima amb tiquet, es tracta com a incident S2 segons 04-05.

Segona diferència — suport-tmp a AllowUsers. Un compte temporal —el nom el delata— amb accés SSH a producció, que va sobreviure al motiu que el va crear. És la mateixa família de problemes que l'excepció sense caducitat d'A-19 i que el http.server: el que és temporal i s'hi queda. Es comprova qui el fa servir, quan es va crear, si té clau associada i què va fer; s'elimina el compte i no només la línia d'AllowUsers; i es revisa si existeixen comptes equivalents als altres servidors.

Tercera diferència — regles d'auditd absents. El fitxer no existeix a api-prod-2. És menys alarmant que les dues anteriors perquè pot deure's simplement al fet que la màquina es va crear abans que la regla entrés a la línia base, però té una conseqüència greu sobre aquest mateix exercici: sense auditd, la investigació del primer punt pot no tenir dades, i per això convé comprovar primer si el fitxer va arribar a existir. Acció: aplicar la línia base completa i verificar que a la resta de servidors sí que hi és.

Conclusió transversal de l'exercici. Les tres troballes van aparèixer perquè existia una línia base automatitzada i una comprovació setmanal. Sense --check --diff, el PasswordAuthentication yes hauria romàs invisible fins al pentest següent o fins que algú l'hagués fet servir. Aquest és l'argument sencer de la lliçó: l'enfortiment no és aplicar configuracions, és mantenir una diferència igual a zero.

Has aplicat al sistema operatiu la reducció de superfície que el mòdul 1 va plantejar en abstracte. Saps què és l'enfortiment i, sobretot, què és una línia base: un conjunt de configuracions escrit, versionat i aplicable per una màquina, sense el qual cada servidor acaba diferent, ningú no sap quin és el correcte i la deriva és invisible. Coneixes els CIS Benchmarks i els STIG, i el procediment honest per fer-los servir —avaluar, filtrar per nivell i rol, provar en preproducció i documentar excepcions— juntament amb l'avís que evita el fracàs més comú: aplicar 300 controls a cegues trenca el servei i mata el projecte la primera setmana. Saps avaluar abans de tocar amb lynis i OpenSCAP, i llegir la seva sortida cercant exposició real en lloc de presumir d'índex.

Tens l'enfortiment del servidor Linux complet: minimitzar serveis —on mor definitivament el python -m http.server d'01-04, eliminant la unitat i no només matant el procés—, comptes nominals i sudo acotat, muntatges amb noexec, nosuid i nodev que tallen d'arrel el patró de descarregar i executar des de /tmp, paràmetres del kernel, i AppArmor/SELinux amb la regla d'ajustar-los i no apagar-los. Domines el sshd_config directiva a directiva, amb PermitRootLogin no, sense contrasenyes, només claus Ed25519, AllowUsers com a llista blanca, temps d'inactivitat, LogLevel VERBOSE per registrar l'empremta de la clau usada, i l'advertiment que canviar el port no és un control: ho és que només sigui assolible des del bastió. Saps configurar auditd amb poques regles ben triades i -e 2 per congelar-les, situar fail2ban com a segona línia i activar actualitzacions automàtiques de seguretat amb criteri.

Manegues la gestió de pedaços com a procés —inventari, recepció, priorització P0-P4, prova, finestra, reinici i verificació— amb la clau que dissol el dilema entre disponibilitat i risc: reduir el cost d'aplicar pedaços fins que duri vint minuts. Tens la línia base de l'endpoint amb els seus vuit controls, encapçalada pel que més atacs atura i més resistència genera —el compte sense privilegis d'administrador—, i saps distingir antivirus d'EDR per la pregunta que respon cadascun: «aquest fitxer és dolent?» davant de «fins on va arribar?». Saps què aporta el MDM, com plantejar el BYOD de forma compatible amb POL-04 i amb la llei, i com fer servir osquery per convertir estimacions en números amb data, inclosa la consulta que hauria trobat el http.server el primer dia. I t'endus el que fa sostenible tot l'anterior: automatitzar amb Ansible de forma idempotent, versionada i autodocumentada, l'evolució cap a la infraestructura immutable que destrueix qualsevol persistència a cada desplegament, i la verificació setmanal amb --check --diff, perquè l'enfortiment no és aplicar configuracions sinó mantenir una diferència igual a zero. Amb el sistema heretat, la resposta és aïllar, compensar, monitorar més i documentar el risc amb caducitat.

Fixa't en l'última idea, perquè és el pont. La infraestructura immutable, les imatges daurades i els contenidors de l'API fa tota la lliçó que apareixen com la millor forma d'aplicar una línia base, i tanmateix l'enfortiment clàssic no els cobreix: un contenidor no és una màquina virtual, no s'hi apliquen pedaços, es reconstrueix; i el compte cloud que l'executa té una superfície pròpia que cap lynis no mira. Aquí és on avui es produeixen la majoria de les bretxes, i no per un exploit sinó per un error de configuració: un bucket públic, una política de permisos massa àmplia, unes còpies que viuen al mateix compte que producció. A Seguretat al Núvol i en Contenidors (05-07) tanquem el pla tècnic del curs: responsabilitat compartida en el tècnic, identitat com a nou perímetre, el bucket A-02 ben configurat d'una vegada, xarxa i còpies aïllades per compte, registre i alertes del núvol, postura automatitzada amb prowler i checkov, imatges segures amb el seu Dockerfile abans i després, signatura amb cosign, execució amb capacitats mínimes i detecció en temps d'execució amb Falco.