El wifi de invitados es una base de datos de personas (y no está en tu inventario)

El 27 de agosto, Manchester Airports Group confirmó que un tercero no autorizado se había llevado datos de clientes de los aeropuertos de Manchester, Stansted y East Midlands. Las coberturas hablan de unos 8,7 millones de personas. Los campos: correo electrónico, teléfono, matrícula del vehículo y código postal. El origen: reservas de aparcamiento, de salas y de Fast Track, y las altas del wifi de los aeropuertos. La propia compañía subraya que no hubo interrupción operativa, que los aeropuertos siguieron funcionando y que en ningún momento se vio comprometida la seguridad aérea. Todo funcionó. Y aun así es el peor día del año para esa compañía.

Lo que se llevaron no vivía en un sistema crítico. Vivía en el formulario que la gente rellena de pie, con la maleta apoyada en la pierna, para tener wifi diez minutos. Esa es la parte de este incidente que sí te toca a ti, tengas un aeropuerto o una oficina de treinta personas con una sala de espera: el sistema que concentra más gente casi nunca es el que está arriba en tu lista de criticidad. Y no lo está porque la lista se ordena por lo que pasa si el sistema se apaga, no por cuánta gente hay dentro.

Lo que se llevaron, y lo que no había

Empecemos por lo honesto: la cifra no está en el comunicado. MAG dice que ha contactado directamente con los clientes afectados sin publicar ningún número; los 8,7 millones salen de lo que un portavoz apuntó a la prensa, y alguna publicación local ha llegado a hablar de 8,9 citando declaraciones privadas de la compañía. Nos quedamos con la cifra baja y con la duda declarada, porque el orden de magnitud es lo que importa aquí y el orden de magnitud está claro: son millones de personas que en su día tocaron una pantalla para aparcar o para conectarse.

Tampoco se sabe cómo entraron. MAG habla de un «tercero no autorizado», dice que contuvo el riesgo de inmediato y que suspendió temporalmente el portal Manage My Booking por precaución. Sí ha contado dos cosas a la prensa británica: que hubo petición de rescate y que no pagó, y que sabe quién está detrás y se lo ha dado a las autoridades. Pero no hay vector publicado, ningún grupo ha reclamado el ataque en público y nadie ha enseñado la puerta por la que se coló. Quien a día de hoy te cuente el cómo con detalle se lo está inventando.

Lo interesante está en la frase sobre los pagos. El comunicado no se queda en «el intruso no accedió a los datos de pago», que es lo que dice todo el mundo. Dice además, y literalmente, que ni la compañía ni el sistema afectado guardaban datos bancarios o de pago de los clientes. Léelo dos veces: un operador que cobra millones de estancias de aparcamiento al año no tiene tarjetas guardadas. La compañía no ha explicado por qué, y nosotros no lo sabemos; nuestra lectura —y la marcamos como lectura— es que detrás de una frase así hay una decisión de arquitectura tomada años antes: delegar el cobro y no quedarse una copia. El día del incidente, esa decisión valía más que cualquier producto de seguridad del catálogo.

La matrícula es el campo que hay que mirar

De los cuatro campos, tres son los de siempre. Un correo y un teléfono filtrados alimentan spam y phishing genérico, y la mayoría de los que leen esto llevan años en veinte filtraciones distintas. El código postal aporta poco por sí solo. La matrícula, en cambio, es otra cosa, y por dos motivos que conviene separar.

El primero es la credibilidad. Un correo que dice «hay un cargo pendiente de tu estancia en el aparcamiento» y que acierta tu matrícula no se parece en nada a los que llegan cada día. Ese es el salto de calidad del fraude cuando alguien junta cuatro campos que por separado no valían nada. Que eso vaya a pasar aquí no lo sabemos: es nuestra lectura de lo que se puede montar con esa combinación.

El segundo es el que casi nunca se dice: una matrícula no se cambia como una contraseña. Si te filtran la clave, la rotas esta tarde. Si te filtran el correo, te aguantas y filtras el buzón. La matrícula te acompaña hasta que vendes el coche, y en España eso son años. Lo mismo pasa con la fecha de nacimiento, el DNI o el número de teléfono de toda la vida. Hay datos que caducan y datos que no, y los que no caducan son los caros: los pagas una vez y sigues pagándolos una década. Merece la pena tenerlos separados en la cabeza cuando decides qué campos pide tu formulario.

No se cayó nada. Por eso pasó.

Llevamos años repitiendo que el fallo es inevitable y la avería es una decisión de diseño: que se rompa una pieza no tiene por qué parar tu empresa. Este caso obliga a girar la frase. Aquí no hubo avería en el sentido clásico: la seguridad aérea no se vio comprometida y las operaciones siguieron. Si mides tu riesgo en minutos de indisponibilidad —que es como lo mide casi todo inventario de riesgo que nos hemos encontrado—, este incidente sale con un cero redondo. Y sin embargo es el que va a salir en la prensa durante meses.

Aquí va la idea con la que nos quedamos nosotros, y es incómoda: si ordenas tus sistemas por criticidad operativa y luego los ordenas por cantidad de personas que hay dentro, las dos listas salen casi invertidas. El ERP, la centralita y el hipervisor están arriba en la primera y suelen guardar datos de unos cientos de empleados y clientes activos. El portal cautivo del wifi, el formulario de contacto de la web y la herramienta de mailing están abajo del todo en la primera —si se caen no pasa nada, la gente se enfada un rato— y son los que acumulan la tabla más larga de la casa, con años de gente que pasó por allí una vez.

Y como están abajo en la lista, heredan el trato de abajo —hablamos de lo que vemos en general, porque del caso de MAG no se ha publicado nada del vector—: se parchean los últimos, nadie sabe quién es el dueño, el acceso es más ancho de lo que debería y muchas veces ni siquiera están en la red que crees. Es la misma película que contábamos con los directorios que tienen más fichas que empleados: el sistema no falla, simplemente acumula, y nadie mira lo que ha acumulado hasta que alguien más lo mira primero.

Tu recepción tiene lo mismo, a otra escala

Casi todas las empresas con las que trabajamos tienen un SSID de invitados. Muchas tienen un portal cautivo que pide un correo antes de dejar navegar, porque venía en el asistente de configuración del fabricante y parecía lo serio. Casi ninguna sabe responder a la vez estas cuatro preguntas: dónde acaba ese correo, quién administra el sitio donde acaba, cuántas filas hay ahí dentro y desde cuándo.

La tercera respuesta suele sorprender. Un portal cautivo puesto hace cuatro años en una empresa con visitas a diario ha acumulado miles de correos que nadie ha usado nunca para nada —porque el «los pedimos por si acaso, para marketing» casi nunca acaba en una campaña real—. Y la segunda respuesta sorprende todavía más: en muchos equipos de gama media, el portal cautivo y su base de datos no están en tu oficina, están en la nube del fabricante del punto de acceso. Eso es un tratamiento de datos por cuenta de un tercero, con su contrato y su ubicación, y casi nunca aparece en el registro de actividades de tratamiento de la empresa.

Y hay un segundo riesgo que va en dirección contraria y que ya tratamos aparte: no solo el wifi de invitados guarda datos de quien se conecta, es que una red de invitados ajena puede hacerle cosas al que se conecta. Las dos caras del mismo cable. La de hoy es la de quien lo ofrece.

Seis preguntas y una tarde aburrida

No hace falta un proyecto. Hace falta una lista y alguien que la escriba. Estas son las seis preguntas con las que empezamos nosotros cuando entramos en una casa nueva:

• ¿Dónde recoges datos de alguien que no es empleado tuyo? Portal cautivo, formulario de la web, reservas, la hoja de visitas de recepción, la tablet del comedor, el sorteo de la feria del año pasado. Escríbelos todos, incluidos los que te dan vergüenza.
• ¿Quién es el dueño de cada uno y dónde acaba el dato? Si la respuesta es «en la nube del fabricante», eso es un proveedor: contrato, ubicación y qué pasa el día que tú te vayas de ese fabricante.
• ¿Cuándo caduca? Si nadie ha borrado nunca nada, la tabla llega hasta el primer día. Un borrado programado a doce meses no rompe absolutamente nada y te quita años de titular potencial. El RGPD no te da un plazo concreto: te obliga a justificar el que elijas, así que elígelo tú antes de que te lo pregunten.
• ¿De verdad necesitas ese campo? Pregúntalo campo a campo y en voz alta. Para dar wifi de cortesía a una visita, en muchos sitios basta con aceptar unas condiciones o con un código que caduca. El correo se pide «por si acaso», y ese «por si acaso» es el que sale en la nota de prensa.
• ¿En qué red está? La red de invitados no debería ver la LAN, ni la impresora, ni el NAS, ni el otro invitado. Aislamiento de cliente, su propia VLAN, su propio ancho de banda. Esto es configuración de una tarde, no una compra.
• ¿Sabrías decir cuánta gente hay dentro? El reloj de las 72 horas del artículo 33 del RGPD no se atasca en la parte legal, se atasca aquí. La pregunta que hunde una notificación no es «¿hay que notificar?», es «¿de cuántas personas exactamente estamos hablando y qué campos suyos había?». Si hoy no puedes contestarla con calma, el peor día tampoco.

Cuándo esto no es tu problema

Si tu wifi de invitados es una clave que se cambia de vez en cuando y no hay formulario ni registro de nada, no tienes este riesgo. Tienes otro distinto —no sabes quién se ha conectado— y en una empresa pequeña con pocas visitas probablemente esté bien así. No montes un portal cautivo para poder cumplir mejor con un formulario que no necesitabas: te habrás creado la base de datos que hoy no tienes.

Y tampoco te vamos a vender un proyecto de segmentación para un router de invitados. Lo caro de todo esto no es la tecnología: es el rato de inventario, que es aburridísimo y que nadie quiere hacer porque no se ve. La parte técnica —una VLAN aislada, un borrado programado, dos campos menos en un formulario— es de las pocas cosas de nuestro oficio que caben en una tarde y no se rompen luego.

Ningún sistema es secundario por lo poco que hace

Esa frase es, en el fondo, todo lo que significa Zero Trust cuando le quitas el envoltorio de fabricante: nada es de fiar por estar dentro, ni por ser pequeño, ni por llevar cuatro años funcionando sin dar guerra. El portal de invitados no es de confianza porque solo dé internet; el punto de acceso de la sala de espera no es de confianza porque esté en el techo de tu propia oficina. Lo que decide el riesgo no es lo que el sistema hace: es lo que el sistema guarda y a qué está conectado.

En la práctica son dos trabajos que hacemos siempre juntos. El primero es dibujar bien las redes y comunicaciones, para que la de invitados no vea nada de la tuya. Es la misma lógica que aplicamos a las APN privadas de operador: estar «dentro» tampoco garantiza estar solo. El segundo es escribir el inventario de qué dato vive dónde, que forma parte de cumplimiento y continuidad y que es el trabajo que nadie quiere hacer porque no se ve.

Nadie va a escribir un artículo sobre el día que borraste tres mil correos que no usabas de un portal cautivo. Es justo lo contrario de una noticia. Pero si algún día entran, la diferencia entre tu comunicado y el de otro se va a decidir por lo que hiciste esa tarde de hace dos años, no por lo que compres el día del incidente.

Fuentes (verificadas una a una): las citas literales sobre los datos afectados («car park, lounge and Fast Track bookings and in-airport WIFI sign-ups»), los cuatro campos, la frase de que ni MAG ni el sistema afectado guardaban datos bancarios o de pago, la suspensión temporal de Manage My Booking y la afirmación de que en ningún momento se vio comprometida la seguridad aérea ni las operaciones — declaración oficial de Manchester Airports Group. Cobertura, contexto y fechas — BleepingComputer, 27 de agosto de 2026 (de donde sale además el aviso de que MAG contactó a los afectados sin publicar cifra y de que los 8,9 millones de las coberturas locales citan declaraciones privadas no confirmadas) y Help Net Security, 28 de agosto de 2026. La petición de rescate, la negativa de MAG a pagarlo y que la compañía dice conocer la identidad del grupo — declaraciones a medios británicos recogidas, entre otros, por AeroTime. Principio de minimización y de limitación del plazo de conservación (artículo 5.1.c y 5.1.e) — AEPD, principios del RGPD; notificación de la brecha a la autoridad de control sin dilación indebida y, de ser posible, en 72 horas (artículo 33) — texto del artículo 33 del RGPD. Todo consultado el 29 de agosto de 2026. Son nuestras, y las marcamos como criterio y no como hechos publicados: la lectura de la frase sobre los pagos como decisión de arquitectura, la del fraude dirigido con matrícula, la comparación entre la lista de criticidad operativa y la de concentración de datos, y las seis preguntas del inventario.