Quando l’accesso legittimo diventa una falla

Il caso del registro danese e la lezione per chi affida dati ai fornitori

 

In breve

In Danimarca soggetti non autorizzati hanno sfruttato l’accesso legittimo di un’impresa al registro centrale della popolazione. Le autorità stanno ancora ricostruendo responsabilità e dinamica, ma un fatto è già chiaro: affidare un servizio non trasferisce il dovere di controllare come vengono usati gli account che aprono l’accesso ai dati.

 

Un incidente passato dal canale autorizzato

Il 5 ottobre il ministero danese competente per il registro centrale della popolazione ha comunicato un incidente di grandi dimensioni. Soggetti non autorizzati hanno utilizzato il canale concesso a un’impresa privata e hanno consultato nomi, indirizzi, numeri identificativi e altri dati relativi a circa 8,8 milioni di persone registrate.

Il numero supera la popolazione residente perché il registro contiene anche informazioni su persone emigrate, decedute o comunque iscritte in passato. Secondo la ricostruzione ufficiale disponibile, per chi dispone di protezione del nome e dell’indirizzo quei due dati non sono stati esposti. L’amministrazione ha sospeso l’accesso dell’impresa, mentre l’autorità danese per la protezione dei dati e la polizia stanno indagando.

Le parole usate per descrivere il caso contano. Le fonti primarie non provano che qualcuno sia entrato direttamente nell’infrastruttura centrale, né consentono di stabilire oggi chi abbia violato quali obblighi. Descrivono l’abuso di una funzione legittima assegnata a un soggetto privato. L’autorità privacy, che ha ricevuto la notifica il 4 ottobre, riferisce di numerose interrogazioni automatizzate rivolte a individuare numeri identificativi validi, ma mantiene aperta l’istruttoria sulla dinamica e sulle responsabilità.

 

Il contratto non vede ciò che accade all’account

Quando un fornitore riceve un accesso, l’organizzazione tende a concentrare l’attenzione sul momento iniziale: necessità del servizio, autorizzazioni, contratto, istruzioni e misure dichiarate. Sono passaggi essenziali, ma fotografano soprattutto ciò che dovrebbe accadere. L’incidente danese mostra il problema complementare, cioè la capacità di riconoscere ciò che sta accadendo davvero.

Un account può essere attribuito correttamente e usato in modo anomalo. Può eseguire un numero di ricerche incompatibile con il servizio, operare in orari insoliti o seguire sequenze ripetitive che non corrispondono al lavoro di una persona. Se il sistema registra questi segnali senza trasformarli in allarmi comprensibili, il tracciamento aiuta l’indagine ma non contiene l’incidente.

La differenza non dipende soltanto dalla tecnologia. Serve una responsabilità interna capace di collegare il comportamento dell’account al servizio affidato, decidere quando lo scostamento è significativo e attivare una sospensione senza perdersi tra il gestore contrattuale, il responsabile della sicurezza e chi presidia la protezione dei dati. È qui che la gestione del fornitore smette di essere un fascicolo e diventa un controllo operativo.

 

Un problema che riguarda anche enti e imprese italiane

Non occorre amministrare un registro nazionale per trovarsi nella stessa situazione. Un Comune concede accessi a società che gestiscono tributi, assistenza informatica, servizi online, impianti di videosorveglianza o applicativi collegati alle banche dati dell’ente. Un’azienda fa lo stesso con le piattaforme per il personale, l’assistenza clienti, le campagne commerciali, la contabilità o i servizi in cloud. In sanità e nella finanza, poi, pochi privilegi possono aprire insiemi di dati particolarmente delicati.

La prima domanda è chiara: quali soggetti esterni possono interrogare, modificare o esportare dati su larga scala? La risposta deve collegare ogni account a una persona o a una funzione, a un responsabile interno e a una necessità ancora attuale. Gli accessi storici, condivisi o più ampi del servizio effettivo sono difficili da controllare proprio quando diventano pericolosi.

La seconda domanda riguarda i limiti reali. Se un operatore deve cercare singole posizioni, il sistema dovrebbe rendere riconoscibili le interrogazioni massive. Se lavora in determinate fasce, un’attività notturna merita almeno una verifica. Se l’accesso serve per consultare, la possibilità di estrarre grandi quantità di dati non dovrebbe essere disponibile per semplice comodità. Non esiste una soglia valida per ogni organizzazione, ma esiste l’obbligo gestionale di definire il comportamento atteso e di accorgersi quando cambia.

 

La revoca fa parte del progetto

Molte procedure descrivono con cura come si concede un accesso e dedicano poche righe alla sua sospensione. In realtà, la revoca è uno dei controlli più importanti e deve essere progettata prima dell’incidente. Chi prende la decisione? Chi la esegue? Quanto tempo serve? Il servizio può continuare in modalità ridotta? Le registrazioni restano disponibili per ricostruire i fatti?

Queste domande non formano una checklist astratta. Servono a evitare che, davanti a un segnale grave, il contratto rinvii al fornitore, il fornitore rinvii al gestore tecnico e l’organizzazione scopra di non avere un comando rapido sul proprio rischio. L’amministrazione danese ha disabilitato l’accesso dell’impresa coinvolta; per ogni altra organizzazione, il dato utile è verificare in anticipo se la stessa azione sarebbe possibile e quali conseguenze avrebbe sui servizi essenziali.

 

La cautela che evita una diagnosi sbagliata

Un incidente molto esteso invita a conclusioni rapide. Parlare di “registro violato” è però più forte di quanto consentano oggi le fonti. Il canale del fornitore e l’infrastruttura centrale non sono la stessa cosa, e confonderli porta a cercare la correzione nel posto sbagliato.

Se il problema è l’abuso di un accesso legittimo, la risposta non si esaurisce nel correggere una vulnerabilità software. Occorre riesaminare privilegi, autenticazione, frequenza delle interrogazioni, capacità di rilevare gli scostamenti e governo della relazione con il soggetto esterno. Sarà l’indagine a chiarire che cosa sia accaduto in Danimarca; enti e imprese non devono attendere quell’esito per chiedersi se controllano davvero le porte che hanno aperto ai propri fornitori.

Fonti

1. Ministero danese dell’Istruzione superiore e della Scienza, Omfattende uautoriseret adgang til borgeres CPR-oplysninger, 5 ottobre 2026: https://ufm.dk/aktuelt/pressemeddelelser/2026/oktober/omfattende-uautoriseret-adgang-til-borgeres-cpr-oplysninger/
2. Autorità danese per la protezione dei dati, Datatilsynet er opmærksom på sag om opslag i CPR, 5 ottobre 2026: https://www.datatilsynet.dk/presse-og-nyheder/nyhedsarkiv/2026/okt/datatilsynet-er-opmaerksom-paa-sag-om-opslag-i-cpr
3. Federprivacy, Flash News, 6 ottobre 2026: https://www.federprivacy.org/
4. ITPro, Everything we know about the cyber attack that hit 8.8m Danes, 6 ottobre 2026: https://www.itpro.com/security/data-breaches/danish-data-breach-everything-we-know-about-the-cyber-attack-that-hit-8-8m-danes

 

Nota di trasparenza
Questo contenuto è stato predisposto con il supporto di strumenti di intelligenza artificiale ed è stato revisionato dalla redazione iSimply, che ne assume la responsabilità editoriale.