Els tres apartats anteriors t'han donat el vocabulari, el catàleg d'amenaces i els principis de disseny. Tot això és inaplicable mentre no responguis a una pregunta prosaica: què té exactament Nimbus Reservas? No pots protegir el que no saps que existeix, no pots reduir una superfície que no has mesurat i no pots prioritzar sense saber qui podria atacar-te i amb quins mitjans. Aquesta lliçó tanca el mòdul construint aquestes tres peces —inventari d'actius, superfície d'atac i actors d'amenaça— i les uneix amb una primera eina d'anàlisi: STRIDE aplicat a un diagrama de flux de dades de la mateixa arquitectura de Nimbus. En acabar tindràs la foto completa del terreny sobre el qual treballarem durant els sis mòduls restants.

1. Què és un actiu i per què l'inventari és el control número u
2. Tipus d'actius i l'inventari de Nimbus Reservas
3. Classificació de la informació: públic, intern, confidencial, restringit
4. Descobrir el que ja tens: inventari tècnic amb eines del sistema
5. La superfície d'atac i les seves cinc dimensions
6. Tècniques de reducció de superfície
7. Actors d'amenaça: qui, per què i amb quina capacitat
8. Introducció pràctica al modelatge d'amenaces amb STRIDE
9. Tancament del mòdul

Un actiu és qualsevol element que té valor per a l'organització i que, per tant, mereix protecció.

La paraula clau és valor, i el valor no és només econòmic. Un fitxer de registres no val diners, però sense ell Nimbus no pot investigar un incident ni demostrar què va passar: el seu valor és probatori. La reputació no apareix en cap balanç, però és el que fa que una clínica renovi el contracte.

Per què l'inventari apareix el primer a totes les llistes de controls serioses:

• No pots protegir el que no saps que existeix. El servidor de proves que l'Iván va aixecar fa vuit mesos «per a una demo», amb una còpia de dades reals i sense pedaços des d'aleshores, no és a cap llista. És exactament el que troba un escaneig automatitzat.
• No pots prioritzar sense criticitat. Si tots els sistemes semblen igual d'importants, es protegeixen tots igual de malament.
• No pots respondre a un incident sense saber què hi ha. La primera pregunta en una bretxa és «a quines dades ha pogut accedir?». Sense inventari, la resposta honesta és «no ho sabem», que davant d'un client o d'un regulador és la pitjor de les respostes.
• No pots aplicar cap pedaç amb seguretat. Quan surti la CVE de la lliçó 01-02, la pregunta «ens afecta?» només es respon ràpid amb inventari.

Una dada incòmoda del sector: en la majoria de bretxes rellevants en pimes, el punt d'entrada va ser un actiu que l'organització havia oblidat que tenia. Un subdomini antic, un entorn de proves, un compte d'un exempleat, una integració desconnectada però amb credencial viva.

Els quatre camps que converteixen una llista en un inventari útil:

Els actius no són només servidors. Una classificació pràctica distingeix sis tipus:

Els dos últims s'obliden sistemàticament i són decisius. La Lucía és un actiu: és l'única persona que sap restaurar la infraestructura completa. Si la Lucía se'n va o està il·localitzable durant un incident, Nimbus té un problema de disponibilitat tan real com si caigués un servidor. I la reputació és un actiu: la major part del dany econòmic d'una bretxa en un SaaS no ve de la multa, ve dels clients que no renoven.

Tres observacions sobre aquesta taula que valen més que la taula mateixa:

1. A-05 (el compte del proveïdor de núvol) és l'actiu del qual depenen gairebé tots els altres. Comprometre aquest compte anul·la la majoria dels controls simultàniament. En el llenguatge de la lliçó 01-03: és el punt que tomba diverses capes de defensa alhora, i per això mereix protecció desproporcionada.
2. A-19 (l'accés de la consultoria) té criticitat crítica i propietària la Marta, no la Lucía. És deliberat: el risc d'aquest actiu és contractual i de govern, no tècnic. Es desenvolupa a 04-04.
3. A-22 apareix amb classificació «a revisar». És honest i és el que sol passar: ningú no està segur de si preproducció té dades reals. Un inventari que reflecteix els dubtes és més útil que un que els amaga; aquesta cel·la és, de fet, la primera tasca de seguretat de la setmana.

Com es manté viu un inventari. L'inventari no és un document, és un procés. Tres regles pràctiques: (a) que la infraestructura es defineixi com a codi, de manera que el repositori sigui l'inventari; (b) que l'alta de qualsevol actiu nou requereixi propietari i classificació des del primer dia; (c) una revisió trimestral curta buscant específicament el que sobra —comptes, entorns, integracions i subdominis que ja no es fan servir.

Classificar significa decidir quanta protecció mereix cada dada. Sense classificació, o es protegeix tot al màxim (car, insostenible i contraproduent) o res de manera consistent.

Quatre nivells basten per a una empresa com Nimbus. Més nivells no aporten precisió: aporten confusió.

Regla 1: la classificació s'hereta cap amunt. Un fitxer que conté una sola dada restringida és restringit. Un informe agregat que barreja dades internes i confidencials és confidencial. Els conjunts prenen la classificació del seu element més sensible.

Regla 2: l'agregació pot pujar el nivell. L'historial d'una cita aïllada és una dada restringida. La taula completa de 400.000 cites de clíniques de fisioteràpia és qualitativament pitjor: no només suma, es converteix en un mapa de persones amb dolències. Aquest canvi de naturalesa és el que fa que les exportacions massives mereixin controls propis (ho vas dissenyar a l'exercici 3 de la lliçó anterior).

Regla 3: el context defineix la sensibilitat. «Anna Ruiz, 15/03, 17:00» sembla innocu. A l'agenda d'una clínica de rehabilitació revela indirectament informació de salut. Nimbus no pot dir «jo només gestiono agendes»: gestiona agendes el contingut de les quals, per context, és sensible.

Nota sobre implicacions legals: la categoria de «dades que revelen informació de salut» i les obligacions associades (bases de legitimació, mesures reforçades, avaluacions d'impacte) tenen un tractament normatiu específic que s'aborda a la lliçó 06-03. La qualificació concreta de les dades de la teva organització s'ha de validar amb el responsable de compliment o amb un professional de l'àmbit jurídic.

Un actiu d'informació que ja no es necessita deixa de ser un actiu i passa a ser només passiu de risc. Els CSV que el Rubén va generar fa un any, els bolcats de base de dades al portàtil de l'Iván, les còpies de fa cinc anys: aporten zero valor i tot el risc. La política de retenció —quant es guarda cada cosa i quan es destrueix— és part de la classificació, no un apèndix.

L'inventari documental es contrasta sempre amb la realitat, perquè la realitat sempre té sorpreses. Comencem per l'actiu A-01: el servidor de base de dades.

Important: totes les ordres d'aquesta lliçó s'executen sobre sistemes propis de Nimbus, amb autorització. Escanejar sistemes aliens sense permís exprés és il·legal; l'ètica i el marc legal d'aquestes activitats es tracten a 06-06.

Anatomia de l'ordre, opció a opció:

Sortida al servidor de base de dades de Nimbus:

Com es llegeix això, línia a línia:

• Línies 1 i 2 (postgres, port 5432): escolta a 127.0.0.1 (només el propi equip) i a 10.0.2.15 (la IP privada de la VPC). Això és correcte: no apareix 0.0.0.0, per tant no escolta a interfícies públiques. Compara-ho amb la troballa de la lliçó 01-02, on sí que ho feia.
• Línia 3 (sshd, port 22): escolta a 0.0.0.0, és a dir, a totes les interfícies. Aquí cal mirar la segona capa: encara que el sistema escolti a totes, el grup de seguretat del proveïdor pot restringir l'origen. Si no ho fa, és una troballa: l'accés administratiu hauria d'arribar només per bastió o VPN.
• Línia 4 (node_exporter, port 9100): mètriques de monitoratge, escoltant a totes les interfícies. Exposa informació detallada del sistema sense autenticació. Troballa típica i molt freqüent: s'instal·la per monitorar i ningú no ho restringeix.
• Línia 5 (python, port 8000): què fa un procés Python escoltant al servidor de base de dades? Aquest és exactament el tipus de sorpresa que justifica l'exercici. Podria ser l'script d'una demo antiga, un servidor de desenvolupament oblidat o alguna cosa pitjor. Requereix investigació immediata.
• Línia 6 (systemd-resolve, port 53 a 127.0.0.53): el resolutor de DNS local. Només local: correcte.

La regla d'or per llegir aquesta sortida: fixa't primer en l'adreça local, no en el port. 127.0.0.1 és només local (sense exposició). Una IP privada (10.x, 192.168.x, 172.16-31.x) és exposició interna. 0.0.0.0 o :: significa totes les interfícies, i aquí és on comença la feina.

Traducció: l'Iván va aixecar un servidor HTTP estàtic el dia d'una demo i porta 94 dies corrent, servint el contingut de /var/tmp/demo a qualsevol que arribi al port 8000. És un actiu no inventariat, sense propietari declarat, sense pedaços i amb contingut desconegut. A la lliçó 01-02 en diríem vulnerabilitat de configuració; aquí és el que il·lustra per què l'inventari és el control número u.

El sistema és només la meitat de la història. L'altra meitat és el tallafoc del proveïdor:

El diagnòstic complet només apareix creuant les dues capes. El port 5432 escoltava a la IP privada i a més està restringit a la VPC: doble capa correcta. El port 22, en canvi, escolta a totes les interfícies i està obert a 0.0.0.0/0: qualsevol bot d'Internet pot intentar autenticar-se contra l'SSH de la base de dades de Nimbus. Això és una troballa de prioritat alta.

Les eines especialitzades de descobriment i escaneig es veuen a 05-01 i 05-03; aquí l'important és el mètode: primer mira el que és teu, amb el que ja tens instal·lat.

La superfície d'atac és el conjunt de tots els punts pels quals un atacant podria intentar entrar, extreure dades o afectar el sistema.

És una propietat mesurable i reduïble, i aquesta és la bona notícia: a diferència de les amenaces, la superfície sí que està sota el teu control. Cada punt que elimines és un punt que no cal defensar, vigilar ni apedaçar mai més.

La superfície no és estàtica: respira. Cada desplegament de l'Iván pot afegir endpoints. Cada contractació afegeix una persona. Cada integració nova afegeix un tercer. Per això es mesura de manera contínua i no un cop l'any.

Superfície exposada ≠ superfície total. Cal distingir:

• Superfície externa: el que és assolible des d'Internet sense credencials. És la més urgent, perquè qualsevol persona del món la pot tocar.
• Superfície autenticada: el que és assolible amb un compte vàlid (inclòs un compte de prova gratuït, si n'hi ha).
• Superfície interna: el que és assolible després del primer compromís. És la que determina quant es propaga un incident.

Nimbus tendeix a mirar només la primera. Però recorda el principi «assumeix la bretxa» de la lliçó anterior: la superfície interna és la que decideix si un portàtil compromès acaba en una anècdota o en un ransomware de tota la infraestructura.

Reduir superfície és, amb diferència, la manera més barata de millorar la seguretat: el que no existeix no es pot atacar, no cal apedaçar-ho, no cal monitorar-ho i no apareix a la propera auditoria.

Què s'ha reduït i per què importa:

• Construcció en dues etapes: els compiladors i les eines d'instal·lació es queden a la primera etapa i no arriben a producció. Un atacant no pot compilar res.
• Imatge distroless: no hi ha sh, ni bash, ni curl, ni apt. Moltes tècniques de postexplotació assumeixen que hi ha una shell disponible; aquí, senzillament, no n'hi ha.
• USER 10001: el procés no corre com a root. Una execució de codi arbitrari no dona control del contenidor.
• Efecte col·lateral valuós: menys paquets significa menys CVE per revisar cada setmana. La reducció de superfície també redueix la feina de manteniment.

Els detalls de seguretat en contenidors es desenvolupen a 05-07; aquí n'hi ha prou amb veure el principi en acció.

Un actor d'amenaça és qui materialitza una amenaça. Conèixer-los importa perquè la motivació determina l'objectiu i la capacitat determina fins on pot arribar — i tots dos decideixen on inverteixes.

És el punt més important d'aquest apartat, perquè corregeix l'error mental més car en una pime: «a nosaltres no ens atacarà ningú, no som interessants».

La premissa és falsa perquè l'atacant oportunista no tria víctimes: troba sistemes. El procés és completament automatitzat:

Res d'aquesta cadena no requereix que algú hagi sentit a parlar de Nimbus. Tres conseqüències pràctiques:

1. L'exposició pesa més que l'atractiu. El que decideix si et comprometen no és com d'interessant siguis, sinó si tens alguna cosa oberta i sense pedaços. Aquell SSH a 0.0.0.0/0 de l'apartat 4.3 rep intents d'autenticació cada pocs minuts, tots els dies, sense que ningú no sàpiga què és Nimbus.
2. Els controls bàsics rendeixen desproporcionadament. Aplicar pedaços, tancar el que no es fa servir, MFA a tots els comptes administratius i còpies fora d'abast neutralitzen la immensa majoria d'aquests actors. No cal un centre d'operacions de seguretat per defensar-se d'un bot.
3. L'accés inicial es revèn. Hi ha intermediaris que comprometen sistemes i venen l'accés a grups de ransomware. Per això «només m'han minat criptomonedes, no és greu» és una conclusió perillosa: qui va entrar va poder deixar la porta oberta, i qui la faci servir després pot tenir altres plans.

Davant l'APT, la conclusió honesta és diferent: si un grup amb recursos estatals decidís atacar específicament Nimbus, Nimbus no el pot aturar. El que sí que pot és detectar i limitar l'abast, que és exactament l'enfocament «assumeix la bretxa» de la lliçó 01-03. I hi ha un matís rellevant: Nimbus podria ser un objectiu intermedi — no per les seves dades, sinó per ser proveïdor d'altres. Els atacs a la cadena de subministrament converteixen empreses petites en ponts cap a empreses grans.

El modelatge d'amenaces és un exercici estructurat per respondre, sobre un disseny concret: què pot sortir malament aquí? Es fa abans de construir (seguretat des del disseny) o en revisar l'existent, i no requereix eines: basten un diagrama i un mètode.

STRIDE és el mètode més utilitzat per començar. És una llista de sis categories d'amenaça, cadascuna associada a la propietat de seguretat que viola:

Reconeixeràs les sis: són les propietats de la lliçó 01-01 vistes des del costat de l'atacant. Aquesta és tota la gràcia d'STRIDE — converteix una llista de propietats en una llista de preguntes.

El modelatge es fa sobre un diagrama, no sobre l'aplicació sencera. Un DFD té quatre elements: entitats externes (actors fora del teu control), processos (el teu codi), magatzems de dades i fluxos. I un cinquè element que és on viu gairebé tot el valor de l'exercici: les fronteres de confiança, línies que separen zones amb diferent nivell de confiança.

Com es dibuixa un DFD útil (et servirà per a l'exercici):

1. Comença per les entitats externes: tot el que no controles. Aquí és on entra l'inesperat.
2. Afegeix els teus processos i magatzems.
3. Dibuixa els fluxos i numera'ls: els números et permeten enumerar amenaces de manera ordenada i no oblidar-te'n cap.
4. Traça les fronteres de confiança. Regla pràctica: cada vegada que una dada creua una frontera, cal analitzar-la. Aquí és on es concentren les amenaces.
5. No dibuixis tota l'empresa. Un DFD d'un flux concret, ben fet, val més que un diagrama gegant que ningú no mira.

Es recorre el diagrama element per element fent-se les sis preguntes. Extracte de l'anàlisi de Nimbus:

Tres regles perquè l'exercici sigui productiu:

• No busquis les sis lletres a tots els elements. Algunes no apliquen. És normal i no és una fallada del mètode.
• Prioritza les fronteres. Els fluxos que creuen una línia de confiança (F1, F2, F8, F11) concentren les amenaces més rellevants.
• Cada amenaça ha d'acabar en una decisió: mitigar, acceptar, transferir o eliminar. Un modelatge que produeix una llista bonica i cap decisió no ha servit de res. La formalització d'aquestes decisions —amb probabilitat, impacte i matriu— es fa a 04-01.

Aquest és el punt en què les quatre lliçons s'uneixen:

Tens el mapa del terreny. A partir d'aquí, cada mòdul aprofundeix en una part: com s'ataca i es defensa (2), com es protegeix la informació amb matemàtiques (3), com es gestiona el risc i es respon (4), quines eines es fan servir (5), què exigeix la normativa (6) i com aplicar-ho tot a un cas complet (7).

Errors comuns:

• Confondre inventari amb llista de servidors. L'inventari inclou dades, serveis SaaS, dominis, persones i tercers. Els actius que no són servidors són els que més s'obliden i els que més incidents causen.
• Fer l'inventari una vegada. Un inventari de fa un any descriu una empresa que ja no existeix.
• Inventariar sense propietari. Un actiu sense responsable no s'apedaça, no es classifica i no es retira. Si haguessis de triar un sol camp, tria propietari.
• Classificar-ho tot com a confidencial. Si tot és confidencial, res no ho és: l'equip deixa de distingir i ho tracta tot amb la mateixa (poca) cura.
• Oblidar la superfície interna. Molts es mesuren només des de fora. La superfície interna és la que determina l'abast d'un compromís.
• Creure que «no som objectiu». Els atacs oportunistes no trien; troben. És l'error de raonament més car en una pime.
• Modelar amenaces sense fronteres de confiança. Un DFD sense fronteres converteix l'exercici en un dibuix bonic. Les fronteres són on hi ha les amenaces.
• Acabar el modelatge sense decisions. Una llista d'amenaces sense mitigació assignada i sense responsable no canvia res.

Consells:

• Comença l'inventari pel que dona a Internet i pel que conté dades restringides. Això ja cobreix el gruix del risc.
• Dedica una hora al trimestre exclusivament a buscar el que sobra: subdominis, entorns, comptes, integracions i credencials sense ús. És l'hora de seguretat més rendible del trimestre.
• Quan revisis un servidor, creua sempre dues capes: el que escolta el sistema (ss) i el que permet el tallafoc del proveïdor. Una sola capa dona un diagnòstic fals.
• Fes el teu primer modelatge STRIDE sobre un sol flux —el de reserva, per exemple— i acaba'l. Un modelatge petit i acabat ensenya més que un d'ambiciós i abandonat.
• Desa el DFD al costat del codi, al repositori. Així s'actualitza quan canvia l'arquitectura i no es converteix en un document mort.

Durant una revisió apareixen cinc actius de Nimbus que no eren a la taula de l'apartat 2.1. Per a cadascun indica: tipus, propietari raonable, criticitat, classificació i una acció immediata.

1. El servidor demo.nimbusreservas.example, aixecat fa 94 dies per l'Iván, servint fitxers estàtics al port 8000 des del servidor de base de dades.
2. Un full de càlcul compartit per la Sara amb noms, DNI, salaris i comptes bancaris dels 38 empleats, en una carpeta del núvol amb enllaç «qualsevol amb l'enllaç pot veure».
3. Un compte de servei a GitHub anomenat nimbus-deploy-bot amb un token personal sense caducitat i permisos d'escriptura a tots els repositoris.
4. Un NAS a l'oficina de València on es copiaven les bases de dades fins fa dos anys; continua encès i ningú no recorda la contrasenya d'administració.
5. El grup de WhatsApp «Nimbus Suport Urgent», on el Rubén comparteix captures de pantalla d'incidències de clients.

Aquest és el resultat de sudo ss -tulpn al servidor d'aplicacions de Nimbus. Per a cada línia indica si és acceptable o no, quin risc introdueix i quina acció concreta de reducció de superfície aplicaries.

Nimbus llançarà una funcionalitat nova: recordatoris per SMS. El flux és:

1. El personal de la clínica activa els recordatoris des del tauler web.
2. Un worker consulta cada hora a PostgreSQL les cites de les properes 24 hores.
3. Per cada cita, crida l'API d'un nou proveïdor d'SMS (tercer) enviant el telèfon del pacient i un text amb la data, l'hora i el nom del servei («Rehabilitació de genoll»).
4. El proveïdor retorna un identificador d'enviament que es desa a la taula enviaments_sms.
5. El proveïdor envia un webhook a l'API de Nimbus quan l'SMS s'entrega o falla.

Es demana: (a) dibuixa el DFD en mermaid amb les seves fronteres de confiança; (b) identifica almenys una amenaça per cada lletra d'STRIDE, indicant l'element o flux afectat; (c) proposa una mitigació per a cadascuna.

Solució 1

Comentaris clau:

• El cas 2 és el més greu en termes de dades personals i probablement el més freqüent a la vida real. Un enllaç de tipus «qualsevol amb l'enllaç» és una publicació: els enllaços es reenvien, s'indexen i es filtren.
• El cas 3 il·lustra la reducció de superfície a la cadena de subministrament: un token sense caducitat amb accés total a tots els repositoris és una clau mestra que no expira mai.
• El cas 4 mostra per què l'inventari ha d'incloure la retirada: un actiu oblidat continua sent un passiu de risc mentre estigui encès.
• El cas 5 recorda que la superfície humana i la de tercers no sempre passen per sistemes corporatius.

Solució 2

Regla de decisió que resumeix l'exercici: per a cada servei en escolta, pregunta't si algú el necessita; si ningú no el necessita, elimina'l; si algú el necessita, restringeix qui hi pot arribar. Aplicant només això, aquesta màquina passa de sis portes obertes a una, controlada.

Solució 3

(a) DFD del flux de recordatoris per SMS:

(b) i (c) Amenaces STRIDE i mitigacions:

Amenaça transversal que convé afegir (bona pràctica en modelar): el flux introdueix un nou tercer a la cadena de subministrament, amb accés a telèfons de pacients i, si no es minimitza, a informació sobre la seva salut. Això requereix avaluació del proveïdor, contracte d'encàrrec de tractament, i decidir què passa amb aquestes dades quan s'acabi la relació. És matèria de 04-04 i 06-03.

Nota sobre implicacions legals: aquest exercici toca tractament de dades personals i la seva comunicació a un tercer, amb dades que poden revelar informació de salut. Les decisions concretes —base de legitimació, informació a l'interessat, contracte amb l'encarregat, necessitat d'avaluació d'impacte— s'han de validar amb el responsable de compliment o amb un professional de l'àmbit jurídic. El que aquí s'exposa té finalitats exclusivament formatives.

Has tancat el mòdul amb la peça més pràctica de les quatre. Saps que un actiu és tot allò que té valor —informació, programari, maquinari, serveis, persones i intangibles com la reputació— i has construït l'inventari de Nimbus amb els quatre camps que el fan útil: propietari, criticitat, classificació i dependències. Aquest inventari ha revelat dues coses que cap eina no t'hauria dit: que el compte del proveïdor de núvol és l'actiu del qual depenen gairebé tots els altres, i que hi ha cel·les amb dubtes —com la classificació de preproducció— que són, precisament, la primera feina pendent. Has après a classificar la informació en quatre nivells i les tres regles que eviten els errors habituals: la classificació s'hereta cap amunt, l'agregació pot pujar el nivell i el context defineix la sensibilitat — per això una agenda de fisioteràpia no és «només una agenda».

Has contrastat el paper amb la realitat fent servir ss -tulpn i has descobert un servidor oblidat corrent des de fa 94 dies, i has après la regla que fa útil aquesta sortida: mira l'adreça local abans que el port, i creua sempre la capa del sistema amb la del tallafoc del proveïdor. Sobre aquesta foto has mesurat la superfície d'atac en les seves cinc dimensions —xarxa, programari i APIs, humana, física i cadena de subministrament— i has vist que reduir-la és la inversió més rendible que existeix: el que no hi és, no s'ataca, no s'apedaça i no es vigila. Has conegut els actors d'amenaça i has corregit l'error de raonament més car de qualsevol pime: l'atacant oportunista no tria víctimes, troba sistemes, i per això l'exposició pesa més que l'atractiu. I has fet els teus primers passos amb STRIDE sobre un diagrama de flux de dades de Nimbus, aprenent que el valor de l'exercici és a les fronteres de confiança i a acabar cada amenaça amb una decisió.

Amb això es tanca el mòdul 1. Tens el vocabulari, el catàleg d'amenaces, els principis de disseny i el mapa exacte del que cal protegir a Nimbus. A partir d'ara deixem de descriure el terreny i entrem en el conflicte. Al Mòdul 2: Ciberseguretat delimitarem l'abast de la disciplina i els seus marcs de referència, recorrerem els tipus d'atac que s'executen contra sistemes com el de Nimbus, estudiarem a fons l'enginyeria social i el phishing —la via per la qual entren la majoria dels incidents reals—, veurem les mesures de protecció que els contraresten, aprofundirem en identitat, autenticació i control d'accés, i analitzarem casos d'estudi d'incidents reals per extreure'n les lliçons que es repeteixen una vegada i una altra. Comencem per Definició i Abast de la Ciberseguretat (02-01).