← Volver ao Blog
Ciberseguridade Dinamarca RXPD Fugas de datos

A fuga do rexistro CPR danés e o ataque á Universidade de Copenhague: leccións para calquera empresa

Por PDCG Solutions·October 27, 2026·Última actualización: October 27, 2026

Dinamarca é un dos países máis dixitalizados do mundo, e precisamente por iso o ocorrido este outono importa moito máis alá das súas fronteiras. En poucas semanas, dous incidentes expuxeron datos de millóns de persoas, e ningún comezou cun ataque sofisticado ao sistema principal. Os dous comezaron nas marxes.

Traballamos con empresas de Dinamarca e Suecia, así que aquí vai un resumo do que se sabe e as leccións prácticas para calquera organización, tamén en Galicia.

O rexistro CPR: 8,8 millóns de persoas

O 5 de outubro de 2026, as autoridades danesas anunciaron un incidente grave no rexistro CPR, o rexistro central de todas as persoas con número de identificación danés (o equivalente ao noso DNI).

  • Usouse o acceso lexítimo dunha empresa danesa para consultar datos do rexistro.
  • Durante uns dez días de setembro fixéronse moitísimas consultas automatizadas.
  • Afecta a unhas 8,8 millóns de persoas, vivas e falecidas: nomes, enderezos e números CPR. Nas persoas con protección de nome e enderezo, estes datos quedaron fóra.
  • Detectouno un empregado da administración do rexistro o 2 de outubro. Cortouse o acceso da empresa e comunicouse á autoridade de protección de datos e á policía.

Aínda se investiga como conseguiron os atacantes ese acceso e que fixeron cos datos.

A Universidade de Copenhague: 525.000 persoas

O 23 de outubro, a Universidade de Copenhague (KU) comunicou un ciberataque detectado o día 20.

  • Os atacantes entraron por un dos seus contornos de probas.
  • Accederon a datos dunhas 525.000 persoas: nomes, números CPR, teléfonos e correos persoais.
  • Tamén se viron comprometidos os PIN das tarxetas de identificación dunhas 20.000 persoas, que xa teñen PIN novos.
  • Apagáronse varios sistemas administrativos por precaución. O 27 de outubro, a universidade aclarou que o que parecía un segundo ataque estaba ligado ao primeiro.

A Universidade Técnica de Dinamarca (DTU) e a Universidade de Aarhus tamén sufriron ataques nas últimas semanas, e a ministra de Educación Superior convocou os responsables das oito universidades danesas a unha reunión de seguridade.

Cinco leccións para calquera empresa

1. O acceso dos teus socios tamén é a túa superficie de ataque

O rexistro CPR non foi «hackeado» no sentido clásico: alguén usou un acceso ao que unha empresa tiña dereito. Calquera empresa que dá acceso aos seus datos a socios, provedores ou integracións debería preguntarse:

  • Cada socio ten acceso só ao que necesita?
  • Hai límites de volume (consultas por hora ou por día)?
  • O acceso está protexido con dobre factor e revísase periodicamente?

2. Detectar o raro, de forma automática

Unha avalancha de consultas automatizadas é xusto o tipo de patrón que un sistema pode detectar en minutos. Alertas por volume, horario ou orixe pouco habituais converten dez días en dez minutos.

3. Os contornos de probas tamén son produción

A fuga da KU comezou nun contorno de probas. Estes sistemas adoitan estar menos protexidos, pero están conectados á rede real e ás veces conteñen datos reais. Usa datos ficticios ou anonimizados para probar e protexe os contornos de probas igual que os de produción.

4. Non gardes datos que non necesitas

Números de identificación, teléfonos persoais e correos privados son moi valiosos para un atacante. Cada dato que non gardas é un dato que non se pode filtrar. Revisa que recolles e canto tempo o conservas.

5. Ten un plan para o día despois

Co RXPD, unha fuga de datos persoais normalmente debe comunicarse á autoridade de protección de datos en 72 horas; en España, á AEPD. Decide antes quen toma as decisións, quen informa os clientes e como, e a quen chamas para a parte técnica. E avisa os teus clientes do phishing que adoita chegar despois dunha filtración.

O fío común

Ningún dos dous incidentes necesitou unha vulnerabilidade brillante. Os dous aproveitaron puntos débiles arredor do sistema principal: o acceso dun socio e un servidor de probas. É a mesma mensaxe que a recente vulnerabilidade PHP2Shell: a seguridade depende de toda a cadea, tamén das partes menos vistosas.

Como che axudamos

En PDCG axudamos as empresas a revisar como están conectados os seus sistemas: quen ten acceso a que, que está exposto, como están montados os contornos de probas e onde se gardan os datos. Traballamos con infraestrutura europea e coa minimización de datos en mente. Mira consultoría tecnolóxica e hosting e cloud europeo, ou escríbenos.

Artigo baseado na información publicada ata o 27 de outubro de 2026. As dúas investigacións seguen abertas; actualizarémolo se hai novidades.