Al final de la lliçó anterior va quedar una escletxa oberta al catàleg de controls: hi ha controls l'eficàcia dels quals no depèn de Nimbus. C-03 exigeix accés just-in-time a una consultora amb els seus propis processos; C-19 replica còpies a la regió d'un proveïdor les decisions del qual no pren ningú de Nimbus; el CI arrossega centenars de dependències escrites per desconeguts. I el detall que ho resumeix tot: el vector de l'incident de 02-06 no va ser una fallada de Nimbus, sinó una bretxa a la consultora que Nimbus ni tan sols va arribar a conèixer fins al dia 20. Aquesta lliçó tracta d'aquella part del perímetre que no controles i de la qual sí que respons: com es tria un proveïdor, què se li exigeix per contracte, com se supervisa, com se li dona de baixa, i com es gestiona el risc del programari de tercers que forma part del teu producte.

1. El perímetre que no controles: s'externalitza l'execució, mai la responsabilitat
2. El mapa de tercers de Nimbus
3. El retorn de la consultora: anatomia del vector de 02-06
4. El cicle de vida de la gestió de proveïdors
5. Diligència deguda proporcionada al risc
6. Què ha de dir el contracte
7. Responsabilitat compartida al núvol
8. Cadena de subministrament de programari
9. Supervisió contínua i l'incident que no és teu
10. El registre de tercers com a artefacte

Quan una clínica de fisioteràpia contracta Nimbus, no contracta «Nimbus i els seus dotze proveïdors»: contracta Nimbus. Si el proveïdor de correu transaccional filtra els correus de recordatori de cites, la clínica trucarà al Rubén, no al proveïdor. I si les dades que s'exposen revelen quins pacients acudeixen a quin tractament, qui haurà de donar explicacions —i, molt probablement, notificar— serà Nimbus.

D'aquí l'asimetria fonamental d'aquesta lliçó:

Existeix una traducció jurídica d'aquesta idea. Quan un tercer tracta dades personals per compte de Nimbus, la normativa europea distingeix entre responsable del tractament —qui decideix per a què i com es tracten les dades, que aquí és la clínica, i Nimbus és al seu torn responsable davant els seus propis empleats— i encarregat del tractament, que és qui les tracta seguint instruccions. Un proveïdor d'infraestructura o de correu transaccional sol ser encarregat (o subencarregat) de Nimbus. La conseqüència pràctica que importa avui és que triar malament un encarregat i no vigilar-lo és un incompliment propi, no aliè.

Nota de validació. La qualificació de cada tercer com a encarregat, subencarregat o responsable independent, i les obligacions contractuals associades, depenen del cas concret i tenen conseqüències legals directes. Aquí es presenta només la idea; el desenvolupament correspon a 06-03. Abans de signar un contracte d'encàrrec de tractament, revisa'l amb assessoria jurídica o amb el teu responsable de compliment.

Abans de gestionar cal llistar, i la majoria de les pimes descobreix aquí que té el doble de proveïdors dels que es pensava. La columna que més converses provoca és l'última.

Tres lectures del mapa. Primera: la superfície de tercers és més gran que la pròpia. Nimbus té 22 actius i nou categories de tercer, i diverses d'elles toquen dades que revelen salut. Segona: el gestor d'incidències sembla inofensiu fins que recordes que els clients adjunten captures de pantalla amb dades reals de pacients en obrir una incidència; aquest és el proveïdor que tothom classifica malament. Tercera: les dependències de programari lliure són l'únic tercer amb qui no hi ha contracte, ni interlocutor, ni SLA, i tanmateix el seu codi s'executa amb els mateixos privilegis que el de l'Iván.

Promès a 03-07 i aquí el tens. Recorda la cronologia: dia −45, la consultora pateix una bretxa i es filtren credencials d'accés als seus clients; no ho comunica a ningú. Dia 0, 22:14, algú entra a Nimbus amb el compte compartit de la consultora, sense MFA, i ningú no ho nota perquè l'accés nocturn de la consultora és habitual. Vint dies després, 1,2 TB exfiltrats i les còpies destruïdes.

Cinc condicions es van haver de donar alhora, i cap no era tècnica:

I el cost de no haver-les evitat, segons l'anàlisi de 02-06: 40 clíniques aturades, 1,2 TB de dades que revelen salut en mans d'un atacant, còpies destruïdes, notificació de bretxa amb abast indeterminat —perquè els logs havien rotat als 7 dies— i pèrdua de clients. És a dir: cinc mesures de cost essencialment nul separaven Nimbus del pitjor dia de la seva història.

Hi ha un detall encara més incòmode. Les tres primeres condicions són de Nimbus, però la bretxa va passar a la consultora, i Nimbus no se'n va assabentar durant 45 dies. Encara que Nimbus hagués tingut MFA, continuaria sense saber que el seu proveïdor havia estat compromès. La clàusula de notificació no és paperassa: és l'únic mecanisme pel qual la informació arriba des del perímetre que no controles.

El que hauria d'haver existit, en l'ordre en què s'implanta:

1. Comptes nominals per tècnic amb el seu nom i el seu correu, mai un compte «consultora».
2. MFA resistent al phishing obligatori, sense excepció i per escrit al contracte.
3. Accés just-in-time: no existeix fins que se sol·licita, dura 8 hores i es revoca sol (C-03).
4. Registre de sessió conservat 12 mesos, amb alerta davant accés fora de la finestra pactada (C-09).
5. Revisió trimestral de qui de la consultora continua tenint accés i per què (C-22).
6. Clàusula contractual de notificació d'incidents amb termini de 24-48 hores.

Les dues fases que més es descuiden són la 1 i, sobretot, la 5. Quan una empresa deixa de treballar amb un proveïdor, la relació comercial s'acaba el dia que es cancel·la la factura; els accessos tècnics, no. La sortida té la seva pròpia llista de comprovació:

• Revocar tots els comptes del proveïdor, inclosos els de servei i les claus API que vas emetre tu.
• Retirar les seves IP de qualsevol llista de permesos i els seus certificats o claus SSH.
• Recuperar les teves dades en un format usable abans de tancar el compte, no després.
• Exigir certificat d'esborrament de les teves dades als seus sistemes i a les seves còpies, amb la data en què caduquen les seves pròpies còpies de seguretat.
• Desconnectar integracions, webhooks i secrets del CI que apuntin al seu servei.
• Anotar la baixa al registre de tercers amb data, perquè la propera revisió no el busqui.

És una feina de dues hores que gairebé ningú no fa, i produeix exactament el tipus d'accés orfe que apareix als casos d'estudi de 02-06.

El principi rector: no demanis a un proveïdor de 3 persones el mateix que a un de 3.000. Un qüestionari de 200 preguntes enviat a una consultora local produeix dos resultats garantits: no el contesten, o el contesten mentint. Proporciona l'esforç a la criticitat:

És el document que més es demana i menys es llegeix. Quatre claus:

• Tipus I davant Tipus II. El Tipus I diu que els controls estaven dissenyats en una data; el Tipus II diu que van funcionar durant un període (normalment 6-12 mesos). Només el segon demostra eficàcia, que és justament la distinció de 04-03.
• L'abast ho és tot. Un informe pot cobrir només un producte o una regió. Si les teves dades són al servei que queda fora de l'abast, l'informe no diu res sobre tu.
• Ves directament a les excepcions. La secció de resultats de les proves llista les desviacions trobades per l'auditor. Un informe sense cap excepció en 12 mesos mereix una pregunta, no un aplaudiment.
• Mira els controls complementaris de l'usuari. Gairebé tots els informes inclouen una llista de coses que tu has de fer perquè els controls del proveïdor funcionin. És la responsabilitat compartida de l'apartat 7, escrita amb nom i cognoms.

Nota de validació. Totes aquestes clàusules tenen efectes jurídics i econòmics, i diverses interactuen amb la normativa de protecció de dades (contracte d'encàrrec de tractament) i amb la de contractació mercantil. Redacta-les o revisa-les amb assessoria jurídica; el contingut d'aquesta taula és una llista de comprovació de temes, no un text contractual.

Un consell pràctic de negociació per a una empresa de la mida de Nimbus: amb els grans proveïdors al núvol o SaaS no negociaràs res, així que la teva feina no és redactar clàusules sinó llegir les seves i decidir si el risc residual és acceptable (04-01). On sí que tens capacitat real de negociació és amb els proveïdors petits —la consultora, la gestoria—, que són justament els que solen tenir contractes més pobres. Aquí és on has de gastar la teva energia.

El malentès més car del núvol és creure que «el proveïdor s'encarrega de la seguretat». El proveïdor s'encarrega de la seguretat del núvol; tu, de la seguretat al núvol. On cau la línia depèn del model de servei:

Fixa't en les tres darreres files: són sempre de Nimbus, en els tres models. I són exactament les que van fallar als incidents de 02-06: el bucket mal configurat va ser una fallada de configuració del client, no del proveïdor; la troballa de PostgreSQL a 0.0.0.0:5432 és configuració de xarxa del client; i la credencial al .env és gestió d'identitats del client. El proveïdor al núvol no ha fallat en cap dels problemes que té Nimbus.

La darrera fila mereix un avís específic per al SaaS: que els teus documents siguin en una suite ofimàtica al núvol no vol dir que estiguin salvaguardats davant un esborrament teu o davant un ransomware que xifri el que està sincronitzat. El detall tècnic de configuració segura de núvol i contenidors és de 05-07; aquí n'hi ha prou de saber on cau la línia.

Les dependències són el tercer sense contracte. L'API de Nimbus declara unes 40 dependències directes, que n'arrosseguen centenars de transitives, i totes s'executen amb els mateixos privilegis que el codi de l'Iván.

La defensa base és fixar per hash, no per versió ni per etiqueta, perquè una etiqueta es pot reassignar i un hash no.

Un SBOM (Software Bill of Materials) és la llista completa de components que conté un artefacte, amb versions i llicències, en un format estàndard com CycloneDX o SPDX. El seu valor no és filosòfic, és operatiu: el dia que es publica una vulnerabilitat crítica en una biblioteca, la pregunta és «la fem servir?», i sense SBOM la resposta triga dies.

Ús: ./sbom-nimbus.sh genera i emmagatzema; ./sbom-nimbus.sh log4j respon en segons a la pregunta que el 2021 va tenir milers d'empreses cercant durant una setmana.

Signar i verificar els artefactes propis (cosign amb identitat efímera, 03-07) acredita l'origen, no l'absència de malícia: SolarWinds va distribuir una porta del darrere perfectament signada. Per això la signatura es combina amb revisió i amb una política d'actualització explícita:

L'última fila és la més barata i la més oblidada: el millor moment per rebutjar una dependència és abans d'afegir-la. Una biblioteca amb un sol mantenidor, sense publicacions en dos anys i amb 300 descàrregues setmanals és un risc de cadena de subministrament que s'evita amb una conversa de dos minuts a la revisió de codi.

La diligència deguda es fa una vegada; el risc dura tot el contracte. La supervisió mínima viable de Nimbus:

• Trimestral: revisió d'accessos actius de tercers (C-22) i d'excepcions vigents.
• Mensual: revisió dels KPI de l'SLA i de les alertes d'accés fora de finestra.
• Continu: subscripció als avisos d'estat i de seguretat dels proveïdors crítics, i vigilància de mencions públiques de bretxes.
• Anual: requestionari dels proveïdors de nivell reforçat i actualització del registre de tercers.

Quan l'incident és del proveïdor, la seqüència importa perquè la temptació d'esperar informació és enorme:

Els dos errors clàssics en aquest flux són esperar que el proveïdor confirmi abans de revocar-li els accessos —el pas 3 no depèn de ningú més i és gratis— i donar per fet que si el proveïdor no notifica, no ha passat res, que és literalment el que va ocórrer durant 45 dies a 02-06.

Nota de validació. Si l'incident d'un proveïdor pot afectar dades personals dels teus clients, hi ha terminis i obligacions de notificació que no depenen de la voluntat del proveïdor. Consulta amb el teu responsable de compliment o amb assessoria jurídica des del primer moment; el detall es tracta a 04-05 i 06-03.

Fixa't en T-09: una baixa no està completa fins que arriba el certificat d'esborrament, i deixar aquest camp visible com a «Pendent» és el que impedeix que la sortida es doni per bona abans d'hora.

• No tenir inventari de tercers. No pots revisar el que no has llistat, i sempre n'hi ha més dels que et penses. Consell: comença per la llista de despeses recurrents de la Sara; allà hi ha tots els SaaS que ningú no va declarar.
• Confiar en el segell i no llegir l'abast. «Tenim ISO 27001» no diu res si l'abast no inclou el servei que tu contractes. Consell: demana sempre el certificat amb la seva declaració d'abast i la data.
• Contractes que només parlen de preu i disponibilitat. És el contracte de la consultora a 02-06. Consell: la clàusula de notificació d'incidents amb termini en hores és la que més valor aporta per línia escrita.
• Diligència deguda només en signar. El proveïdor canvia, tu canvies i els seus subencarregats canvien. Consell: fixa la revisió anual al registre i tracta-la com un control amb propietari.
• Oblidar la sortida. Accessos orfes i dades teves en sistemes d'una empresa amb qui ja no parles. Consell: la baixa no es tanca sense certificat d'esborrament.
• Demanar a un proveïdor petit el mateix que a un de gran. Aconsegueixes una resposta inventada i una falsa sensació de control. Consell: proporciona el qüestionari al risc i gasta la teva energia negociadora on sí que pots negociar.
• Assumir que el núvol inclou còpies de seguretat. Ni el SaaS ofimàtic ni el bucket estan salvaguardats davant el teu propi esborrament. Consell: revisa la taula de responsabilitat compartida servei per servei.
• Fixar dependències per etiqueta. Una etiqueta mòbil equival a executar el que el mantenidor decideixi demà. Consell: fixa per hash i fes servir --require-hashes.

Per a cadascun d'aquests quatre tercers de Nimbus, decideix el nivell de diligència (lleuger, estàndard o reforçat), indica les tres preguntes més importants del qüestionari per a aquell cas concret i la clàusula contractual que no pot faltar:

1. Una eina SaaS de signatura electrònica que la Sara vol fer servir per als contractes laborals.
2. Un servei de traducció automàtica que el Rubén vol integrar al suport, enviant-li el text dels tiquets.
3. L'empresa de neteja de l'oficina de València.
4. Un nou proveïdor d'observabilitat al qual s'enviarien els registres de l'API en temps real.

Aquest és el registre real d'un tercer de Nimbus. Identifica tots els problemes i ordena les correccions:

Un dilluns al matí, la Marta llegeix en un mitjà especialitzat que el proveïdor de correu transaccional de Nimbus (A-11) ha patit una intrusió: els atacants van accedir a les metadades d'enviament d'una part dels seus clients durant tres setmanes. El proveïdor encara no ha comunicat res a Nimbus.

1. Quines dades de Nimbus podrien estar afectades, i per què són sensibles encara que «només» siguin metadades?
2. Enumera les accions de les primeres quatre hores, en ordre, indicant quines no depenen del proveïdor.
3. Què exigiries per escrit al proveïdor i amb quin termini?
4. Què hauria de canviar al contracte i al registre de tercers després de l'incident?

Exercici 1

El punt de l'exercici és el 4. Enviar els registres de l'API en temps real a un tercer significa que aquest tercer rep una còpia contínua del que passa a producció, i si l'equip no ha depurat el contingut dels seus registres, allà hi poden anar identificadors de pacients, correus, tokens o fragments de dades clíniques. Un proveïdor d'observabilitat és, a la pràctica, un proveïdor amb accés a dades de producció, i cal avaluar-lo com a tal. I el 2 ensenya la trampa contrària: un servei «petit» i barat pot ser el que tregui les dades més sensibles del teu perímetre.

Exercici 2

Problemes, de més a menys greu:

1. El projecte va acabar el novembre de 2025 i l'agència continua amb accés d'administrador al repositori. És la fase 5 del cicle de vida sense executar: un accés orfe i privilegiat amb quatre mesos d'antiguitat. És exactament el patró del vector de 02-06.
2. Compte compartit («agencia») en lloc de comptes nominals: no es pot saber qui va fer què, ni si aquella persona continua treballant allà.
3. Permisos d'administrador al repositori quan la feina requeria, com a molt, escriptura en una branca. Mínim privilegi incomplert.
4. Sense clàusula de notificació d'incidents i sense devolució ni esborrament: si l'agència pateix una bretxa, Nimbus no se n'assabentarà, i el seu codi continua als equips de l'agència.
5. Mai avaluada (ultima_avaluacio: null) tot i estar classificada com a criticitat Alta.
6. Accés a preproducció amb classificació «a revisar»: ningú no sap si l'agència ha estat llegint dades reals de pacients durant 18 mesos, i aquest dubte és en si mateix una troballa notificable si es confirma.

Ordre de correcció: (a) avui mateix, revocar el compte agencia, rotar qualsevol clau o token que se li lliurés i revisar el registre del repositori i de la base de dades de preproducció per determinar si hi va haver activitat després del novembre. (b) Aquesta setmana, determinar si A-22 conté dades reals —tancant per fi la casella «a revisar» de l'inventari d'01-04— i, si en conté, avaluar l'abast amb el responsable de compliment. (c) Aquest mes, completar la sortida formal: sol·licitar per escrit l'esborrament del codi i de les dades amb certificat, i anotar la baixa al registre. (d) Abans del pròxim projecte, incorporar l'avaluació prèvia, els comptes nominals, el permís mínim i les clàusules de notificació i sortida.

Exercici 3

(1) Les metadades d'enviament d'un proveïdor de correu transaccional inclouen destinatari, remitent, assumpte, data i estat de lliurament. En el cas de Nimbus això és: el correu del pacient, la marca temporal, i molt probablement un assumpte del tipus «Recordatori de la seva cita de dijous a Fisioteràpia Levante». Encara que no hi hagi cap dada clínica dins del missatge, la combinació de destinatari i clínica revela que aquella persona és pacient d'un centre sanitari concret, que és precisament el tipus de dada que l'escala d'impacte de 04-01 puntua amb un 5. «Només metadades» és, en aquest context, un eufemisme perillós. A més, pot estar afectada la clau API que Nimbus li va lliurar.

(2) Primeres quatre hores, en ordre. No depenen del proveïdor les quatre primeres: (a) obrir el quadern de bitàcola de l'incident i anotar l'hora i la font de la notícia (04-05); (b) rotar la clau API que Nimbus té en aquell proveïdor, que és una acció pròpia, immediata i sense cost; (c) revisar els registres propis d'ús d'aquella clau per si hi hagués enviaments no originats per Nimbus; (d) determinar exactament quina informació s'envia a aquell proveïdor —quins camps, amb quins assumptes, amb quina retenció— per poder acotar l'exposició sense esperar ningú; (e) contactar amb el proveïdor per escrit exigint confirmació de si Nimbus és entre els afectats; (f) informar la Marta i activar l'equip de resposta; (g) preparar, sense enviar-lo encara, un esborrany de comunicació als clients.

(3) Per escrit i amb termini de 24 hores: si Nimbus figura entre els clients afectats; finestra temporal exacta de l'accés; quines categories de dades es van veure compromeses i si inclouen contingut a més de metadades; si hi ha evidència d'exfiltració o només d'accés; quines mesures ha pres; i si ha notificat l'autoritat de control. I una petició addicional que gairebé ningú no fa: el llistat dels enviaments de Nimbus compresos en aquella finestra, que és el que permetria notificar amb precisió en lloc d'assumir el pitjor escenari, que va ser justament el problema de Nimbus a 02-06.

(4) Al contracte: termini de notificació explícit en hores (si no n'hi havia o era de 72 h, baixar-lo a 24), obligació de facilitar el detall dels enviaments afectats, i declaració actualitzada de subencarregats. Al registre de tercers: pujar la criticitat si estava infravalorada, avançar la propera avaluació, i afegir l'incident a l'historial del proveïdor —dada que pesarà en la propera renovació—. I al registre de riscos de 04-01: aquest incident és un disparador de reavaluació, i hi hauria d'aparèixer un risc específic sobre l'exposició de metadades de cites a través de tercers, amb el seu propi tractament. Una millora tècnica que avalua bé aquí: reduir les dades enviades al proveïdor a un identificador opac i un assumpte genèric, aplicant minimització.

Has après a gestionar la part del perímetre que no controles. Parteixes de l'asimetria fonamental: es pot externalitzar l'execució, el cost i el coneixement tècnic, però mai la responsabilitat, ni davant el client ni davant l'autoritat, ni la reputació d'A-20 —amb la distinció legal entre responsable i encarregat del tractament apuntada aquí i desenvolupada a 06-03—. Tens el mapa de tercers de Nimbus amb les seves nou categories, i les seves tres lectures: la superfície de tercers és més gran que la pròpia, el gestor d'incidències és el proveïdor que tothom classifica malament perquè els clients adjunten captures amb dades de pacients, i les dependències de programari lliure són l'únic tercer sense contracte, sense interlocutor i sense SLA el codi del qual s'executa amb tots els privilegis.

Has tornat a la consultora de l'incident de 02-06 i n'has desmuntat el vector: cinc condicions simultànies —accés permanent, compte compartit, sense MFA, sense registre ni alerta, sense clàusula de notificació—, cap d'elles tècnica i totes de cost essencialment nul. Amb el detall més incòmode: encara que Nimbus hagués tingut MFA, hauria continuat sense saber durant 45 dies que el seu proveïdor estava compromès, perquè la clàusula de notificació és l'únic mecanisme pel qual la informació arriba des del perímetre que no controles.

Coneixes el cicle de vida del proveïdor i en especial la seva fase 5, la sortida, que gairebé ningú no executa: revocar tots els comptes i claus API, retirar IP i certificats, recuperar les dades abans de tancar el compte, exigir certificat d'esborrament i anotar la baixa. Saps fer diligència deguda proporcionada amb tres nivells i un qüestionari complet per al nivell reforçat, i saps llegir un informe SOC 2: Tipus II i no Tipus I, l'abast per damunt del segell, anar directe a les excepcions i no ignorar els controls complementaris de l'usuari. Tens la llista de clàusules contractuals amb la seva nota de validació jurídica i el consell de negociació realista: amb els grans no negocies, així que llegeix i decideix; amb els petits sí, i són els que tenen pitjors contractes.

Domines el model de responsabilitat compartida, amb l'observació decisiva que configuració, identitats i dades són sempre teves en IaaS, PaaS i SaaS —i que, en conseqüència, el proveïdor al núvol no ha fallat en cap dels problemes que té Nimbus—. I manegues la cadena de subministrament de programari: dependències directes i transitives, typosquatting, confusió de dependències, presa de control del mantenidor i compromís del CI; la fixació per hash d'accions i dependències davant les etiquetes mòbils; l'SBOM signat, el valor del qual és respondre en segons a «fem servir aquell component?»; la signatura d'artefactes que acredita l'origen i no l'absència de malícia, amb SolarWinds com a recordatori; i una política d'actualització amb terminis, la línia més barata de la qual és l'última: el millor moment per rebutjar una dependència és abans d'afegir-la. Tanquen la lliçó la supervisió contínua, el flux de resposta quan l'incident és del proveïdor —on revocar accessos i rotar claus no depèn de ningú i és el primer— i el registre de tercers, en què una baixa no es tanca fins que arriba el certificat d'esborrament.

I fixa't en el que ha passat dues vegades en aquesta lliçó. En analitzar la bretxa de la consultora i en respondre a la del proveïdor de correu, has necessitat una cosa que encara no tens: un quadern de bitàcola, un equip amb rols, una decisió sobre a qui es comunica i en quin termini, i una seqüència acordada per endavant. A 02-06, a les 09:00 del dia 20, la Marta va convocar l'equip i ningú no sabia què fer primer. Aquest buit no l'omple ni el millor registre de riscos ni el millor catàleg de controls.

A la lliçó següent, Pla de Resposta a Incidents (04-05), escriuràs el pla abans de l'incident, perquè a les tres de la matinada ningú no improvisa bé: les fases del NIST SP 800-61, l'equip de resposta de Nimbus amb suplents i contactes fora de banda, la matriu de severitat, la preservació d'evidències abans de tocar res, les disjuntives reals de la contenció, les plantilles de comunicació als clients, el quadern de bitàcola, un runbook desenvolupat sencer i el post mortem sense culpables aplicat a l'incident de 02-06.