La lliçó anterior va acabar assenyalant el pont: la infraestructura immutable i els contenidors són 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 sinó que es reconstrueix, i el compte cloud que l'executa té una superfície pròpia que cap lynis no mira. Aquesta lliçó tanca el pla tècnic del curs allà on avui es produeix la majoria de les bretxes: no en un exploit sofisticat, sinó en una casella mal marcada. Configurarem d'una vegada per totes el compte A-05, el bucket d'adjunts A-02 i les còpies A-03, i construirem imatges que no regalin la partida.

1. Per què el núvol canvia el model d'amenaça
2. Responsabilitat compartida, en el tècnic
3. La identitat és el nou perímetre
4. El bucket A-02, ben configurat d'una vegada
5. Xarxa i dades: subxarxes privades, xifratge i còpies aïllades
6. Registre i auditoria del núvol
7. Postura automatitzada: CSPM i infraestructura com a codi
8. Contenidors: què aïlla i què no
9. Execució segura i signatura d'imatges
10. Orquestració i detecció en temps d'execució
11. Què ha de fer Nimbus primer, amb el seu pressupost

En un centre de dades propi, atacar significava trobar un servei vulnerable i explotar-lo. Al núvol, la causa dominant de bretxes no és un exploit: és un error de configuració. Els grans incidents públics de l'última dècada en entorns cloud comparteixen un patró que no requereix cap habilitat ofensiva: un bucket marcat com a públic, una clau d'accés publicada en un repositori, un rol amb permisos d'administrador que només necessitava llegir un fitxer, una base de dades gestionada exposada sense autenticació.

Tres canvis de fons expliquen el desplaçament:

• Tot és una API. Crear una màquina, obrir un port o donar accés a totes les dades són crides a una API, i una credencial amb permisos amplis permet fer-les totes. El pla de control importa més que el pla de dades: qui controla el compte no necessita entrar a cap servidor.
• La velocitat és l'avantatge i el risc. Un terraform apply aixeca una infraestructura completa en minuts, i també publica un bucket en segons. La mateixa agilitat que fa competitiva Nimbus multiplica la probabilitat de l'error.
• Tot és públic per omissió pel que fa a abast de xarxa. No hi ha una porta física ni una xarxa corporativa al voltant: el que es desplega és assolible des d'Internet llevat que es configuri el contrari.

La conseqüència pràctica inverteix la prioritat de treball: al núvol, revisar la configuració reteix més que buscar vulnerabilitats, i per això el CSPM de l'apartat 7 és, per a una pime, més rendible que un escàner de vulnerabilitats addicional.

A 04-04 vam veure el model com a assumpte contractual. Aquí és una llista de tasques concretes, i la pregunta que l'ordena és: si això falla, a qui truques? Si la resposta ets tu, és teu.

Dues conclusions que convé tenir presents. La primera: com més gestionat és el servei, menys tasques tens, però les que queden són les més crítiques —la configuració d'accés i les dades—. La segona: el proveïdor no t'avisa quan ho fas malament. Publicar un bucket no genera cap alerta des del seu costat: la casella existeix, i fer-la servir és una decisió legítima del client. Aquesta asimetria és exactament el buit on viu l'error de configuració.

Sense xarxa per defensar, el control d'accés a l'API del proveïdor és el perímetre real. Cinc regles ordenades per impacte:

1. MFA obligatori al compte arrel, amb la credencial custodiada i sense ús diari. L'arrel només es fa servir per al que cap altra identitat no pot fer.
2. Res de claus d'accés de llarga durada. Una clau estàtica viu en un fitxer, viatja per xats, es copia a un portàtil i apareix en un repositori: és el risc R-06. Al seu lloc, rols assumibles amb credencials efímeres (minuts o hores) per a les persones, i identitat de la mateixa instància o del contenidor per als serveis, sense cap secret per gestionar.
3. Federació amb el proveïdor d'identitat. Ningú no té usuari propi al núvol: s'entra amb la identitat corporativa, i la baixa d'un empleat revoca el seu accés a tot d'una vegada. És la correcció d'un problema clàssic: el compte cloud que sobreviu a qui el feia servir.
4. Mínim privilegi real, que s'aconsegueix observant el que cada rol fa servir de debò i retallant la resta.
5. Revisió periòdica de permisos excessius, amb l'analitzador d'accessos del proveïdor i amb la recertificació semestral del control C-18.

Tres decisions mereixen justificar-se. No es concedeix s3:DeleteObject: l'API de Nimbus no necessita mai esborrar adjunts, i no tenir-ho converteix un compromís de l'API en una fuita —greu— en lloc d'en una destrucció —irreversible—. El Resource acota la ruta, no només el bucket, així que una fallada de l'aplicació no arriba a altres prefixos. I la denegació explícita per punt d'enllaç de la VPC és la més potent: encara que una altra política concedeixi accés per error, si la petició no ve per la xarxa privada de Nimbus, es denega. Una credencial robada i usada des de fora no serveix.

Aquest és l'actiu que 02-06 va buidar durant set dies. Es tanca amb set controls que s'apliquen junts.

Els dos controls restants van sobre el bucket de còpies A-03, i són els que 02-06 va demostrar imprescindibles:

El mode COMPLIANCE és la diferència entre una còpia i una esperança. En mode governance, un administrador pot aixecar la retenció; en mode compliance, ningú no pot, ni el propietari del compte, fins que expiri. És el quart dígit de la regla 3-2-1-1-0 de 04-06 i és, literalment, el que hauria impedit l'esborrament del dia 20 a les 02:10.

I el setè control, ja conegut: les descàrregues se serveixen amb URL signades de 120 segons (03-07), generades després de comprovar l'autorització a l'aplicació (05-05). Mai no hi ha un enllaç permanent ni un objecte llegible sense credencial.

Reprenent el disseny de 05-04 amb la mirada posada als serveis gestionats:

• La base de dades viu en una subxarxa privada sense ruta a Internet, ni d'entrada ni de sortida. No és «un port tancat»: és que no existeix camí.
• Punts d'enllaç privats (VPC endpoints) per parlar amb l'emmagatzematge d'objectes i amb el gestor de secrets. El trànsit no surt a Internet, i —el més valuós— permet la condició aws:SourceVpce de l'apartat 3, que anul·la el valor d'una credencial robada.
• Xifratge en repòs i en trànsit per omissió a tots els serveis, amb claus gestionades per Nimbus i rotació amb kid (03-06). El xifratge del proveïdor protegeix davant del robatori físic del disc; el xifratge amb clau pròpia protegeix a més davant d'errors d'accés lògic.
• Bloqueig del servei de metadades o exigència de la seva versió amb sessió (IMDSv2), que és la mitigació estructural del SSRF de 05-05: sense ella, un SSRF a l'API lliura les credencials del rol de la instància.
• Les còpies viuen en un altre compte, amb credencials diferents. És la lliçó més cara de 02-06: les còpies de Nimbus eren al mateix compte que producció, i qui va comprometre el compte les va esborrar juntament amb tota la resta. Còpies en un altre compte significa que l'atacant necessita comprometre dos comptes independents, amb dos conjunts de credencials i dos proveïdors d'identitat. El cost afegit és d'uns pocs euros al mes.

El registre d'activitat del proveïdor (CloudTrail o equivalent) respon a qui va cridar quina API, quan, des d'on i amb quin resultat. És la font més important d'un entorn cloud i cal configurar-la bé:

• Actiu a totes les regions, no només a la que es fa servir. Una tècnica habitual consisteix a operar en una regió que ningú no mira.
• Enviat a un bucket d'un altre compte, amb les mateixes propietats de l'apartat 4: immutable i només escriptura. Els logs es protegeixen igual que les còpies.
• Validació d'integritat activada, per poder demostrar que no es van manipular.
• Complementat amb els registres d'accés al bucket, els del balancejador i els de flux de la VPC (05-04).

Les alertes mínimes, que connecten directament amb el catàleg de 05-02:

Les cinc primeres són S1 perquè cap no té explicació benigna freqüent. Són, a més, baratíssimes de muntar: són consultes sobre un registre que ja existeix.

CSPM (Cloud Security Posture Management) és avaluar de forma contínua la configuració del compte contra un conjunt de bones pràctiques. prowler i ScoutSuite són lliures i suficients.

Lectura comentada, amb el criteri de priorització de 05-01. iam_root_mfa_enabled és el primer, malgrat no ser el que més soroll fa: sense MFA a l'arrel, tots els altres controls són opcionals per a qui aconsegueixi aquella credencial, i activar-lo són cinc minuts. El bucket públic va immediatament després, i la primera pregunta no és com tancar-lo sinó què conté i des de quan està així: si té dades personals, això ja no és una troballa de configuració, és una possible bretxa (04-05, 06-03). La clau d'accés sense usar 402 dies és la troballa més silenciosa i una de les més perilloses: una credencial permanent, oblidada, que ningú no trobaria a faltar si algú la fes servir; s'elimina, no es rota. I les còpies desactivades a preproducció tornen a assenyalar A-22.

Desplaçar el control a l'esquerra. El CSPM detecta l'error després que arribi a producció. checkov i tfsec el detecten al pull request, sobre el codi d'infraestructura, abans que existeixi:

La combinació correcta és checkov bloquejant al CI i prowler setmanal sobre el compte, perquè no tot es desplega per codi: sempre hi ha alguna cosa feta a mà a la consola web, i això només ho veu el CSPM.

La frase que cal interioritzar: un contenidor és aïllament de processos, no una frontera de seguretat com la d'una màquina virtual. Si necessites separar càrregues de confiança molt diferent, la frontera correcta és la màquina virtual o el compte separat.

L'últim comentari mereix èmfasi perquè és l'error més comú i el menys evident: esborrar un fitxer en una capa posterior no l'elimina de la imatge. Continua sent a la capa anterior i es recupera amb una ordre. Per això trivy --scanners secret (05-01) forma part del pipeline.

Construir bé la imatge és la meitat; l'altra meitat és com s'executa.

read_only més cap_drop: ALL més no-new-privileges és la combinació que més eleva el cost d'un atac, i no costa res: la majoria de les aplicacions web funcionen tal qual, i les que no, només necessiten declarar les seves rutes d'escriptura com a volums.

Signatura d'artefactes amb cosign (reprenent 03-07), que respon a la pregunta «aquesta imatge és la que vam construir nosaltres?»:

Sense verificació al desplegament, la signatura és decorativa. La cadena completa queda així, i és la integritat de la cadena de subministrament de 04-04 portada a la pràctica:

Nimbus encara no fa servir Kubernetes, i convé dir amb claredat que Kubernetes és un àmbit de seguretat propi, no un detall de desplegament. Si arriba, aquestes són les sis peces mínimes: espais de noms per entorn i per criticitat, amb quotes; RBAC amb comptes de servei propis per aplicació i sense fer servir el compte per omissió; polítiques de xarxa, perquè per omissió tots els pods parlen amb tots —és l'error més freqüent i l'equivalent a la xarxa plana de 05-04—; estàndards de seguretat de pods en nivell restricted, que imposa el de l'apartat 9; gestió de secrets amb un proveïdor extern, perquè els secrets natius van codificats en base64 i no xifrats; i kube-bench, que avalua el clúster contra el benchmark CIS igual que lynis avalua un servidor.

Detecció en temps d'execució amb Falco. L'escaneig d'imatges mira el que hi ha; Falco mira el que passa, observant les crides al sistema:

Què val la pena detectar en temps d'execució, sense generar soroll: shell dins d'un contenidor, escriptura en rutes del sistema (/etc, /usr/bin) quan el sistema de fitxers hauria de ser de només lectura, connexió sortint a una destinació inesperada, lectura de fitxers sensibles com /etc/shadow o les credencials de la instància, i muntatge del socket de Docker. Totes van al mateix canal de 05-02 i comparteixen les seves regles de qualitat d'alerta.

El total suma uns 540 €/any i unes 70 hores. És menys del 3 % del pressupost de 18.000 €/any i el 16 % de les 440 hores de la Lucía, i cobreix els tres riscos pitjor puntuats del registre de 04-01. És, amb diferència, la millor relació cost/impacte de tot el mòdul 5, i la raó és la mateixa amb què va començar la lliçó: al núvol, gairebé tot el que falla és una casella, i les caselles són gratis.

• Creure que el proveïdor et protegeix de les teves pròpies configuracions. No t'avisa quan publiques un bucket: és una acció legítima del client.
• Fer servir claus d'accés de llarga durada. Acaben en un repositori, en un xat o en un portàtil. Rols efímers i identitat d'instància.
• Concedir Action: "*" «temporalment». No hi ha res més permanent que un permís temporal que funciona.
• Deixar les còpies al mateix compte que producció. És el que va convertir l'incident de 02-06 en una catàstrofe.
• Confiar que un contenidor aïlla com una màquina virtual. Comparteix kernel; amb capacitats de més o el socket de Docker muntat, és l'amfitrió sencer.
• Etiquetes en lloc de digests. :latest no és reproduïble: escaneges una imatge i en desplegues una altra.
• Secrets a ENV del Dockerfile. Queden a la capa encara que els esborris després.
• Consell: comença per les dues primeres files de la taula del §11. Quatre hores, cost zero, i cobreixen el pitjor escenari possible.
• Consell: verifica, no configuris. Un curl que retorni 403 val més que una captura de la consola web, i és l'evidència que demana 04-03.
• Consell: checkov al CI abans que prowler al compte. És més barat impedir l'error que descobrir-lo, encara que necessitaràs tots dos.

Sobre la sortida de prowler del §7, i sabent que nimbus-web-assets serveix les imatges públiques del web de màrqueting:

1. Ordena les sis troballes per prioritat real, justificant cada posició.
2. Canvia la teva avaluació del bucket públic en saber per a què es fa servir? Què comprovaries abans de decidir?
3. Escriu la correcció concreta de les tres primeres i indica com verificaries cadascuna.

L'Iván proposa aquest servei per a producció. Identifica tots els problemes i reescriu-lo.

La Marta pregunta, després de llegir el post mortem de 02-06: «com garantim que això no pot tornar a passar?». Dissenya l'esquema de còpies de Nimbus de manera que un atacant amb control total del compte de producció no les pugui destruir, i indica com ho demostraries.

Exercici 1

(1) Ordre per prioritat real:

(2) Sí que canvia, però menys del que sembla. Que un bucket d'imatges de màrqueting sigui llegible públicament pot ser exactament el que es pretén, i en aquest cas la troballa és un fals positiu que es documenta com a excepció (04-02). Abans de decidir cal comprovar quatre coses: quins objectes conté realment —els buckets de «recursos web» acumulen amb enorme freqüència exportacions, còpies de seguretat puntuals i PDF de clients que algú hi va deixar—; si a més de lectura pública té escriptura pública, que seria crític perquè permetria a qualsevol alterar el contingut servit sota el domini de Nimbus; des de quan està així i què diuen els registres d'accés; i si hi ha una manera millor d'aconseguir el mateix, que sí que n'hi ha: CDN al davant amb el bucket privat, cosa que dona control, memòria cau i registre sense exposició directa. La regla general: un bucket públic és acceptable només si és un bucket dedicat, el contingut del qual està íntegrament destinat a ser públic i així consta per escrit.

(3) Correccions i verificació:

• Arrel sense MFA: activar MFA amb una clau física, guardar la credencial i el segon factor de reserva en custòdia física amb accés de dues persones, i crear una alerta S1 davant de qualsevol ús de l'arrel (§6). Verificació: prowler torna a executar iam_root_mfa_enabled amb resultat PASS, i una prova d'accés demana el segon factor.
• Bucket públic: si el contingut ha de ser públic, moure'l a un bucket dedicat darrere d'una CDN i deixar l'original privat; si no, aplicar el bloqueig d'accés públic del §4. En tots dos casos, inventariar el contingut abans. Verificació: curl sobre un objecte conegut retornant 403 i put-public-access-block confirmat.
• Clau sense usar: eliminar-la, no desactivar-la —una clau desactivada es reactiva—; comprovar abans al registre d'activitat que cap procés no la va fer servir en 402 dies, i cercar si apareix a l'historial del repositori amb gitleaks (05-01), perquè una clau oblidada sol estar-ho per haver estat incrustada en algun lloc. Verificació: la clau no apareix al llistat i no hi ha errors d'autenticació nous en 48 hores.

Exercici 2

Problemes, de major a menor gravetat:

Exercici 3

El requisit reformulat: que la destrucció de les còpies exigeixi credencials que el compte de producció no posseeix i una acció que cap credencial no pot realitzar. Quatre capes, cadascuna resolent una fallada diferent:

1. Compte separat, amb el seu propi proveïdor d'identitat i el seu propi MFA. Comprometre producció no dona cap accés al compte de còpies. És la capa que faltava a 02-06, on tot vivia junt.
2. Flux d'escriptura en un sol sentit i de mínim privilegi. El rol nimbus-backup de producció té únicament PutObject sobre el bucket de còpies: no pot llistar, no pot llegir i no pot esborrar. Que no pugui llegir és important i se sol oblidar: impedeix que un atacant a producció s'endugui també l'històric complet.
3. Bloqueig d'objectes en mode COMPLIANCE amb 35 dies de retenció. Aquí hi ha el nucli de la resposta a la Marta: ni tan sols un administrador del compte de còpies amb MFA pot escurçar la retenció ni esborrar un objecte abans que expiri. No és una qüestió de permisos, que sempre es poden canviar; és una propietat de l'emmagatzematge.
4. Replicació a una segona regió i, per al conjunt crític, una còpia addicional en emmagatzematge fred amb credencials diferents de tot l'anterior.

Es complementa amb detecció: l'alerta D-10 de 05-02 davant de qualsevol intent d'esborrament o de canvi de retenció, i l'alerta de silenci —si el procés de còpia deixa d'escriure durant 24 hores, algú se n'ha d'assabentar—, perquè la forma sigil·losa de destruir còpies no és esborrar-les, sinó impedir que es creïn i esperar que l'històric caduqui.

Com es demostra, que és el que la Marta ha d'exigir i no una explicació: (a) intent real d'esborrament des del compte de còpies amb credencials d'administrador, que ha de fallar amb AccessDenied, amb la sortida guardada com a evidència; (b) prova de restauració cronometrada de 04-06, executada des del compte de còpies, que verifica hash, compara files i mesura l'RTO real; (c) simulacre de compromís: revocar totes les credencials de producció i comprovar que les còpies segueixen sent accessibles i restaurables; i (d) revisió trimestral que el bloqueig d'objectes segueix actiu, inclosa al --check --diff de la infraestructura com a codi (05-06). La resposta correcta a la pregunta de la Marta no és «hem configurat això»: és «ho hem intentat destruir i no hem pogut, i aquí hi ha la sortida de consola amb data».

Has tancat el pla tècnic del curs allà on avui es trenquen la majoria de les empreses. Saps per què el núvol canvia el model d'amenaça —l'error de configuració substitueix l'exploit com a causa dominant— i les tres raons de fons: tot és una API, la velocitat multiplica l'error i l'abast és públic per omissió. D'aquí la inversió de prioritats: revisar la configuració reteix més que buscar vulnerabilitats. Apliques el model de responsabilitat compartida servei a servei amb la pregunta que l'ordena —«si això falla, a qui truques?»— i amb les dues conclusions que importen: com més gestionat el servei, menys tasques i més crítiques; i el proveïdor no t'avisa mai quan ho fas malament.

Domines la identitat com a nou perímetre: MFA a l'arrel, fi de les claus de llarga durada, rols assumibles amb credencials efímeres, federació amb el proveïdor d'identitat i revisió de permisos excessius; amb la política mínima que no concedeix Delete, acota el prefix i afegeix una denegació explícita per punt d'enllaç de la VPC que anul·la el valor d'una credencial robada. Has configurat el bucket A-02 d'una vegada: bloqueig d'accés públic, xifratge amb clau pròpia, versionat, registre d'accessos i verificació amb un curl que ha de retornar 403; i les còpies A-03 en compte separat amb bloqueig d'objectes en mode COMPLIANCE, que és el que converteix «immutable» en alguna cosa real i el que hauria impedit l'esborrament del dia 20. Saps muntar subxarxes privades, punts d'enllaç privats, xifratge per omissió, bloqueig del servei de metadades com a mitigació estructural del SSRF, i còpies que exigeixen comprometre dos comptes independents.

Saps configurar el registre d'activitat multiregió, immutable, en un altre compte i amb validació d'integritat, i les set alertes mínimes de les quals cinc són S1 perquè cap no té explicació benigna. Manegues CSPM amb prowler —llegint el seu informe amb el criteri de 05-01, començant pel MFA de l'arrel i preguntant què conté el bucket públic abans de tancar-lo— i checkov bloquejant al CI perquè l'error no arribi a producció, amb la conclusió que calen tots dos. Entens què aïlla i què no un contenidor, i tens el Dockerfile abans i després: multi-stage, distroless, fixat per digest, --require-hashes, sense secrets en capes i sense root; amb l'advertiment que esborrar un fitxer en una capa posterior no l'elimina de la imatge. Executes amb read_only, cap_drop: ALL, no-new-privileges i límits, signes amb cosign i verifiques abans de desplegar, perquè sense verificació la signatura és decorativa. I coneixes l'enquadrament de Kubernetes com a àmbit propi i Falco per detectar el que passa en execució. Tot això prioritzat en una taula que suma uns 540 € i 70 hores i cobreix els tres riscos pitjor puntuats del registre: al núvol, gairebé tot el que falla és una casella, i les caselles són gratis.

Amb això, el Mòdul 5 està complet. Nimbus ja sap trobar el que té exposat i prioritzar-ho (05-01), veure l'atacant moure's amb dotze deteccions que haurien tallat l'incident de 02-06 el dia 0 (05-02), posar-se a prova amb un pentest autoritzat i aprofitar-ne l'informe (05-03), segmentar la seva xarxa i verificar que la segmentació funciona de debò (05-04), defensar el seu propi codi amb autorització centralitzada i un CI que diu que no (05-05), endurir els seus sistemes amb una línia base automatitzada i verificada setmanalment (05-06) i tancar el seu núvol i els seus contenidors (05-07). Han caigut, un a un, tots els problemes que arrossegàvem des d'01-04: el PostgreSQL exposat, el Redis sense autenticació, l'SSH obert, el python -m http.server i l'accés permanent de la consultora.

I aquí apareix el límit de tot l'anterior. Res d'això no es manté sol. Les eines troben i corregeixen, però l'escaneig mensual deixa d'executar-se quan la Lucía té una mala setmana; la línia base es degrada si ningú no mira el --check --diff; la CSP s'omple d'excepcions; el security.txt caduca; i el pròxim empleat que entri no en sabrà res de tot això llevat que algú l'hi ensenyi. A més, haver fet la feina no basta: cal poder demostrar-ho —davant d'un client que exigeix garanties, davant d'una auditoria, davant de l'Agència Espanyola de Protecció de Dades si un dia cal notificar una bretxa—. Al Mòdul 6: Bones Pràctiques i Normatives passem de l'execució al que la sosté en el temps: bones pràctiques que converteixen decisions puntuals en hàbits (06-01), normatives i estàndards com ISO 27001, NIS2 i ENS (06-02), la protecció de dades i el RGPD aplicats de debò a un SaaS que tracta dades de salut (06-03), compliment i auditoria amb l'evidència que aquest mòdul ha anat generant (06-04), formació i sensibilització, perquè les persones continuen sent el vector principal (06-05), i l'ètica i la divulgació responsable que 05-03 va deixar pendents (06-06). Deixem de preguntar si està protegit i comencem a preguntar si es pot demostrar i si durarà.