Casi toda organización que desarrolla u opera software tiene una segunda copia de sus sistemas en algún lugar, para probar cambios antes de ponerlos en producción. Casi todas esas copias, en algún momento, se llenan de datos reales, porque los datos reales facilitan las pruebas. La Universidad de Copenhague acaba de mostrar lo que eso cuesta cuando lo que vulneran es la copia.
Qué pasó
Vale la pena leer con atención cómo la universidad cuenta que detectó el ataque. Su personal de TI notó que "un sistema de TI había realizado una serie de acciones que no debía realizar", y esas acciones resultaron ser una cobertura de lo que estaba haciendo el atacante. El atacante había obtenido acceso a sistemas "normalmente restringidos a un número limitado del personal de TI de la universidad", intentó con varios, tuvo éxito con uno y desde ahí llegó a una base de datos con información personal. Los datos se habían actualizado parcialmente por última vez en enero de 2026.
La noche del viernes 23 de octubre, la universidad anunció que unos hackers habían accedido a "uno de los entornos de prueba de la universidad", con unas 525,000 personas afectadas. Esa misma noche cerró discretamente el acceso físico a "ubicaciones físicas críticas seleccionadas". Dos días después explicó por qué: se habían comprometido los PIN de unas 20,000 personas que usan tarjetas de acceso. Dijo que había reservado ese detalle hasta cambiar cada uno de esos PIN. El acceso se reabrió una vez emitidos los códigos nuevos.
La semana siguiente fue más desordenada. El 26 de octubre, la universidad anunció lo que llamó un nuevo ataque y apagó sistemas administrativos como precaución. A la mañana siguiente se corrigió: la actividad estaba relacionada con la brecha original, no era una segunda. Los sistemas fueron volviendo poco a poco durante el resto de la semana, y la intranet de empleados y estudiantes seguía limitada a la red del campus el 30 de octubre.
Las cartas de notificación salieron por Digital Post, el sistema oficial de correo digital de Dinamarca, el 27 de octubre, y por correo electrónico al día siguiente. A los estudiantes no les gustó el ritmo. "Es una lástima que nos enteremos tres días después", dijo a TV 2 quien preside el consejo estudiantil.
Un matiz sobre el término "entorno de pruebas". La universidad lo usó en sus anuncios públicos, pero la carta formal a las personas afectadas no lo usa; habla de sistemas restringidos y de una base de datos. La naturaleza exacta del sistema no se ha publicado. Lo que sí está claro es que los datos que contenía eran reales, recientes y extensos.
Una copia de los datos también son los datos
Hay buenas razones para que un sistema de pruebas termine con registros reales. Los datos realistas detectan errores que los datos inventados no, copiar producción es más rápido que construir una imitación convincente, y nadie piensa que la copia vaya a ser permanente.
El problema es que la copia rara vez hereda la protección del original. Los sistemas de prueba suelen tener más gente con acceso, menos monitoreo, parches menos frecuentes y nadie cuyo trabajo sea darse cuenta de cuándo deberían apagarse. También son fáciles de olvidar, que es el tema que vuelve una y otra vez en los incidentes que analizamos, desde el sitio de staging que nadie dio de baja en el artículo sobre php2shell hasta las plataformas dadas de baja en la filtración de México.
Nada de eso les importa a las 525,000 personas de esta base de datos. Para ellas no hay diferencia entre una brecha del sistema real y una de la copia. Los nombres, números de identidad y teléfonos son igual de reales en ambos casos, y también lo es el phishing que suele venir después.
Fíjate también en el rango de fechas. Registros desde 2002 significa que esta base de datos guardaba información de personas que dejaron la universidad hace más de dos décadas. Los datos que ya no se necesitan no pueden robarse si se borraron, y una copia de pruebas es el lugar menos defendible para conservarlos.
Cifrado, con la llave al lado
La universidad sí cifró los números CPR, que son el número de identidad nacional de Dinamarca y el dato más sensible del conjunto. También les dijo a las personas afectadas que hay "una alta probabilidad" de que el atacante pueda descifrarlos, porque "también se extrajo la información necesaria para descifrarlos".
Es la misma lección que la brecha de Railway del mismo mes, a menor escala. El cifrado solo protege los datos de alguien que no tenga también la forma de descifrarlos. Cuando la llave, o la información necesaria para obtenerla, está en el mismo lugar que los datos que protege, el cifrado sobre todo te ahorra tener que escribir "sin cifrar" en la carta de notificación.
Cuando una filtración de datos abre puertas
El detalle que hace inusual este incidente son los PIN. Una base de datos de nombres y números de identidad es un problema de privacidad. Una base de datos que además guarda los códigos de las tarjetas de acceso físico es un problema de seguridad en edificios llenos de gente, y por eso la primera respuesta visible de la universidad fue cerrar puertas, no enviar correos.
Vale la pena notar lo bien que salió esa parte. La universidad cerró el acceso a ubicaciones críticas la misma noche en que anunció la brecha, cambió 20,000 PIN y solo entonces explicó por qué. No se ha reportado ningún uso indebido de los PIN robados.
La parte que la universidad no puede resolver es la reutilización. Su carta pidió específicamente cambiar cualquier PIN que se hubiera reutilizado en otro lado, "por ejemplo, en tus tarjetas bancarias". Cuatro dígitos elegidos una vez y usados en todas partes son comunes, y una lista de ellos asociada a nombres sirve mucho más allá de un campus.
Qué significa esto para una organización más pequeña
Una empresa de 50 personas no tiene medio millón de registros, pero casi seguro tiene el mismo patrón en miniatura:
- Una copia de staging del sitio web o la tienda en línea, cargada con una exportación real de clientes.
- La laptop de un desarrollador o el entorno de un contratista con una copia de la base de clientes "para pruebas".
- Hojas de cálculo exportadas del CRM o del sistema de RR. HH. para una tarea puntual, que siguen en una carpeta compartida.
- Un entorno de demo o de prueba de un proveedor que alguien llenó con datos reales para ver cómo se veía.
- Sistemas de acceso a puertas, alarmas o control de entrada cuyos códigos se guardan en el mismo lugar que los registros del personal, y empleados que usan el mismo PIN para la puerta y para su tarjeta bancaria.
Nada de eso es exótico, y cada uno es una copia de datos reales con menos protección que el original.
Qué hacer en concreto
Encuentra las copias. Hazles una sola pregunta a tus desarrolladores, a tu proveedor de TI y a cualquier agencia con la que trabajes: ¿dónde existen copias de los datos de nuestros clientes o empleados fuera del sistema real? Anota las respuestas, incluidas las que suenen temporales.
Mantén los datos reales fuera de los sistemas de prueba. Usa datos inventados o enmascarados para probar siempre que se pueda. Donde de verdad haga falta usar datos reales, trata ese sistema exactamente como producción: los mismos controles de acceso, los mismos parches, el mismo monitoreo y una fecha en la que se apaga.
Borra lo que ya no necesitas. Define periodos de retención para los registros de clientes, empleados y candidatos, y aplícalos a todas las copias, no solo al sistema real. Los datos de personas que se fueron hace años son puro riesgo.
Mantén las llaves lejos de lo que protegen. Si tú o un proveedor cifran datos sensibles, pregunta dónde se guardan las llaves para descifrarlos. Si la respuesta es "en la misma base de datos" o "en el mismo servidor", el cifrado no está haciendo mucho.
Trata los códigos de acceso como credenciales. Los códigos de edificios, alarmas y puertas merecen el mismo cuidado que las contraseñas: guardados por separado, cambiados cuando alguien se va y nunca compartidos con nada más. Recuérdale a tu personal que no reutilice el PIN de la puerta en su tarjeta bancaria, ni al revés.
Planea la respuesta física con anticipación. Decide desde ahora quién puede cerrar un edificio, cómo se emitirían códigos o tarjetas nuevas y cómo se le avisaría al personal, para que una brecha como esta sea una tarde de molestias y no una semana.
El resumen
La Universidad de Copenhague manejó bien la parte más peligrosa: cerró puertas rápido y cambió cada PIN expuesto antes de decir una palabra sobre ellos. Lo que no pudo deshacer fue la decisión, tomada mucho antes de que llegara cualquier atacante, de guardar dos décadas de datos personales reales en un sistema que describió como un entorno de pruebas.
Toda organización tiene su propia versión de ese sistema. La pregunta útil no es si la tuya es tan grande como la de una universidad, sino si sabes dónde está.
Fuentes
- Orientering om bruddet på persondatasikkerheden — Universidad de Copenhague (versión en inglés)
- Driftsforstyrrelser på KU — Universidad de Copenhague, actualizaciones del incidente
- Underretning om brud på persondatasikkerheden — Universidad de Copenhague, carta de notificación del 27 de octubre de 2026 (en danés e inglés)
- Københavns Universitet har været udsat for cyberangreb — DR
- University of Copenhagen data breach exposes data of 525,000 people — BleepingComputer
- Copenhagen University data breach — Infosecurity Magazine
- Studerende utilfredse med KU efter cyberangreb — TV 2 Kosmopol
