El wifi de convidats és una base de dades de persones (i no és al teu inventari)

El 27 d'agost, Manchester Airports Group va confirmar que un tercer no autoritzat s'havia endut dades de clients dels aeroports de Manchester, Stansted i East Midlands. Les cobertures parlen d'uns 8,7 milions de persones. Els camps: correu electrònic, telèfon, matrícula del vehicle i codi postal. L'origen: reserves d'aparcament, de sales i de Fast Track, i les altes del wifi dels aeroports. La mateixa companyia subratlla que no hi va haver interrupció operativa, que els aeroports van continuar funcionant i que en cap moment no es va veure compromesa la seguretat aèria. Tot va funcionar. I tot i així és el pitjor dia de l'any per a aquesta companyia.

El que es van endur no vivia en un sistema crític. Vivia al formulari que la gent omple dreta, amb la maleta recolzada a la cama, per tenir wifi deu minuts. Aquesta és la part d'aquest incident que sí que et toca a tu, tinguis un aeroport o una oficina de trenta persones amb una sala d'espera: el sistema que concentra més gent gairebé mai no és el que és a dalt de la teva llista de criticitat. I no hi és perquè la llista s'ordena pel que passa si el sistema s'apaga, no per quanta gent hi ha a dins.

Què es van endur, i què no hi havia

Comencem pel que és honest: la xifra no és al comunicat. MAG diu que ha contactat directament amb els clients afectats sense publicar cap número; els 8,7 milions venen del que un portaveu va apuntar a la premsa, i alguna publicació local ha arribat a parlar de 8,9 citant declaracions privades de la companyia. Ens quedem amb la xifra baixa i amb el dubte declarat, perquè aquí el que importa és l'ordre de magnitud i l'ordre de magnitud és clar: són milions de persones que un dia van tocar una pantalla per aparcar o per connectar-se.

Tampoc no se sap com van entrar. MAG parla d'un «tercer no autoritzat», diu que va contenir el risc immediatament i que va suspendre temporalment el portal Manage My Booking per precaució. Sí que ha explicat dues coses a la premsa britànica: que hi va haver petició de rescat i que no va pagar, i que sap qui hi ha al darrere i ho ha donat a les autoritats. Però no hi ha vector publicat, cap grup no ha reclamat l'atac en públic i ningú no ha ensenyat la porta per on es va colar. Qui avui t'expliqui el com amb detall s'ho està inventant.

El més interessant és la frase sobre els pagaments. El comunicat no es queda en «l'intrús no va accedir a les dades de pagament», que és el que diu tothom. Diu a més, i literalment, que ni la companyia ni el sistema afectat guardaven dades bancàries o de pagament dels clients. Llegeix-ho dues vegades: un operador que cobra milions d'estades d'aparcament l'any no té targetes desades. La companyia no ha explicat per què, i nosaltres no ho sabem; la nostra lectura —i la marquem com a lectura— és que darrere d'una frase així hi ha una decisió d'arquitectura presa anys abans: delegar el cobrament i no quedar-se'n una còpia. El dia de l'incident, aquesta decisió valia més que qualsevol producte de seguretat del catàleg.

La matrícula és el camp que cal mirar

Dels quatre camps, tres són els de sempre. Un correu i un telèfon filtrats alimenten spam i phishing genèric, i la majoria dels qui llegeixen això fa anys que són en vint filtracions diferents. El codi postal aporta poc per si sol. La matrícula, en canvi, és una altra cosa, i per dos motius que convé separar.

El primer és la credibilitat. Un correu que diu «hi ha un càrrec pendent de la teva estada a l'aparcament» i que encerta la teva matrícula no s'assembla gens als que arriben cada dia. Aquest és el salt de qualitat del frau quan algú ajunta quatre camps que per separat no valien res. Que això passi aquí no ho sabem: és la nostra lectura del que es pot muntar amb aquesta combinació.

El segon és el que gairebé mai no es diu: una matrícula no es canvia com una contrasenya. Si et filtren la clau, la rotes aquesta tarda. Si et filtren el correu, t'aguantes i filtres la bústia. La matrícula t'acompanya fins que véns el cotxe, i a Espanya això són anys. El mateix passa amb la data de naixement, el DNI o el número de telèfon de tota la vida. Hi ha dades que caduquen i dades que no, i les que no caduquen són les cares: les pagues un cop i les continues pagant una dècada. Val la pena tenir-les separades al cap quan decideixes quins camps demana el teu formulari.

No va caure res. Per això va passar.

Fa anys que repetim que la fallada és inevitable i l'avaria és una decisió de disseny: que es trenqui una peça no ha d'aturar la teva empresa. Aquest cas obliga a girar la frase. Aquí no hi va haver avaria en el sentit clàssic: la seguretat aèria no es va veure compromesa i les operacions van continuar. Si mesures el teu risc en minuts d'indisponibilitat —que és com el mesura gairebé tot inventari de risc que ens hem trobat—, aquest incident surt amb un zero rodó. I tanmateix és el que sortirà a la premsa durant mesos.

Aquí va la idea amb què ens quedem nosaltres, i és incòmoda: si ordenes els teus sistemes per criticitat operativa i després els ordenes per quantitat de persones que hi ha a dins, les dues llistes surten gairebé invertides. L'ERP, la centraleta i l'hipervisor són a dalt de la primera i solen guardar dades d'uns quants centenars d'empleats i clients actius. El portal captiu del wifi, el formulari de contacte del web i l'eina de mailing són a baix de tot de la primera —si cauen no passa res, la gent s'enfada una estona— i són els que acumulen la taula més llarga de la casa, amb anys de gent que hi va passar un cop.

I com que són a baix de la llista, hereten el tracte de baix —parlem del que veiem en general, perquè del cas de MAG no s'ha publicat res del vector—: se'ls apliquen els pedaços els últims, ningú no sap qui n'és l'amo, l'accés és més ample del que hauria de ser i moltes vegades ni tan sols són a la xarxa que et penses. És la mateixa pel·lícula que explicàvem amb els directoris que tenen més fitxes que empleats: el sistema no falla, simplement acumula, i ningú no mira el que ha acumulat fins que algú altre ho mira primer.

La teva recepció té el mateix, a una altra escala

Gairebé totes les empreses amb què treballem tenen un SSID de convidats. Moltes tenen un portal captiu que demana un correu abans de deixar navegar, perquè venia a l'assistent de configuració del fabricant i semblava el més seriós. Gairebé cap sap respondre alhora aquestes quatre preguntes: on acaba aquell correu, qui administra el lloc on acaba, quantes files hi ha a dins i des de quan.

La tercera resposta sol sorprendre. Un portal captiu posat fa quatre anys en una empresa amb visites cada dia ha acumulat milers de correus que ningú no ha fet servir mai per a res —perquè el «els demanem per si de cas, per a màrqueting» gairebé mai no acaba en una campanya real—. I la segona resposta sorprèn encara més: en molts equips de gamma mitjana, el portal captiu i la seva base de dades no són a la teva oficina, són al núvol del fabricant del punt d'accés. Això és un tractament de dades per compte d'un tercer, amb el seu contracte i la seva ubicació, i gairebé mai no apareix al registre d'activitats de tractament de l'empresa.

I hi ha un segon risc que va en direcció contrària i que ja vam tractar a part: no només el wifi de convidats guarda dades de qui s'hi connecta, és que una xarxa de convidats aliena pot fer coses a qui s'hi connecta. Les dues cares del mateix cable. La d'avui és la de qui l'ofereix.

Sis preguntes i una tarda avorrida

No cal cap projecte. Cal una llista i algú que l'escrigui. Aquestes són les sis preguntes amb què comencem nosaltres quan entrem en una casa nova:

• On reculls dades d'algú que no és empleat teu? Portal captiu, formulari del web, reserves, el full de visites de recepció, la tauleta del menjador, el sorteig de la fira de l'any passat. Escriu-los tots, inclosos els que et fan vergonya.
• Qui n'és l'amo de cadascun i on acaba la dada? Si la resposta és «al núvol del fabricant», això és un proveïdor: contracte, ubicació i què passa el dia que tu marxis d'aquell fabricant.
• Quan caduca? Si ningú no ha esborrat mai res, la taula arriba fins al primer dia. Un esborrat programat a dotze mesos no trenca absolutament res i et treu anys de titular potencial. El RGPD no et dóna un termini concret: t'obliga a justificar el que triïs, així que tria'l tu abans que t'ho preguntin.
• De debò necessites aquest camp? Pregunta-ho camp a camp i en veu alta. Per donar wifi de cortesia a una visita, en molts llocs n'hi ha prou amb acceptar unes condicions o amb un codi que caduca. El correu es demana «per si de cas», i aquest «per si de cas» és el que surt a la nota de premsa.
• A quina xarxa és? La xarxa de convidats no hauria de veure la LAN, ni la impressora, ni el NAS, ni l'altre convidat. Aïllament de client, la seva pròpia VLAN, el seu propi ample de banda. Això és configuració d'una tarda, no una compra.
• Sabries dir quanta gent hi ha a dins? El rellotge de les 72 hores de l'article 33 del RGPD no s'encalla a la part legal, s'encalla aquí. La pregunta que enfonsa una notificació no és «cal notificar?», és «de quantes persones exactament parlem i quins camps seus hi havia?». Si avui no pots contestar-la amb calma, el pitjor dia tampoc.

Quan això no és el teu problema

Si el teu wifi de convidats és una clau que es canvia de tant en tant i no hi ha formulari ni registre de res, no tens aquest risc. En tens un altre de diferent —no saps qui s'hi ha connectat— i en una empresa petita amb poques visites probablement estigui bé així. No muntis un portal captiu per poder complir millor amb un formulari que no necessitaves: t'hauràs creat la base de dades que avui no tens.

I tampoc no et vendrem un projecte de segmentació per a un router de convidats. El que és car de tot això no és la tecnologia: és l'estona d'inventari, que és avorridíssima i que ningú no vol fer perquè no es veu. La part tècnica —una VLAN aïllada, un esborrat programat, dos camps menys en un formulari— és de les poques coses del nostre ofici que caben en una tarda i que després no es trenquen.

Cap sistema no és secundari pel poc que fa

Aquesta frase és, en el fons, tot el que significa Zero Trust quan li treus l'embolcall de fabricant: res no és de fiar per ser a dins, ni per ser petit, ni per portar quatre anys funcionant sense donar guerra. El portal de convidats no és de confiança perquè només doni internet; el punt d'accés de la sala d'espera no és de confiança perquè sigui al sostre de la teva pròpia oficina. El que decideix el risc no és el que el sistema fa: és el que el sistema guarda i a què està connectat.

A la pràctica són dues feines que fem sempre juntes. La primera és dibuixar bé les xarxes i comunicacions, perquè la de convidats no vegi res de la teva. És la mateixa lògica que apliquem a les APN privades d'operador: ser «a dins» tampoc no garanteix estar sol. La segona és escriure l'inventari de quina dada viu on, que forma part de compliment i continuïtat i que és la feina que ningú no vol fer perquè no es veu.

Ningú no escriurà un article sobre el dia que vas esborrar tres mil correus que no feies servir d'un portal captiu. És just el contrari d'una notícia. Però si algun dia entren, la diferència entre el teu comunicat i el d'un altre es decidirà pel que vas fer aquella tarda de fa dos anys, no pel que compris el dia de l'incident.

Fonts (verificades una a una): les citacions literals sobre les dades afectades («car park, lounge and Fast Track bookings and in-airport WIFI sign-ups»), els quatre camps, la frase que ni MAG ni el sistema afectat guardaven dades bancàries o de pagament, la suspensió temporal de Manage My Booking i l'afirmació que en cap moment no es va veure compromesa la seguretat aèria ni les operacions — declaració oficial de Manchester Airports Group. Cobertura, context i dates — BleepingComputer, 27 d'agost de 2026 (d'on surt també l'avís que MAG va contactar els afectats sense publicar cap xifra i que els 8,9 milions de les cobertures locals citen declaracions privades no confirmades) i Help Net Security, 28 d'agost de 2026. La petició de rescat, la negativa de MAG a pagar-lo i que la companyia diu conèixer la identitat del grup — declaracions a mitjans britànics recollides, entre d'altres, per AeroTime. Principi de minimització i de limitació del termini de conservació (article 5.1.c i 5.1.e) — AEPD, principis del RGPD; notificació de la bretxa a l'autoritat de control sense dilació indeguda i, si és possible, en 72 hores (article 33) — text de l'article 33 del RGPD. Tot consultat el 29 d'agost de 2026. Són nostres, i les marquem com a criteri i no com a fets publicats: la lectura de la frase sobre els pagaments com a decisió d'arquitectura, la del frau dirigit amb matrícula, la comparació entre la llista de criticitat operativa i la de concentració de dades, i les sis preguntes de l'inventari.