Un indirizzo IP può essere anonimo nel report consegnato al cliente e restare perfettamente riconoscibile nella console del SOC. Le nuove Linee guida dell’EDPB aiutano a capire perché; applicarle a SIEM e threat intelligence, tuttavia, richiede qualche cautela che nel testo del Comitato non si trova già confezionata.
Indice degli argomenti
Il log delle 2:17 e la domanda sbagliata
Alle 2:17 il SIEM segnala alcune autenticazioni anomale. L’indirizzo IP compare nel log della VPN, in una regola di correlazione e in un feed di threat intelligence; il report destinato al consiglio di amministrazione lo sostituisce con una sigla, mentre nella console del SOC sono sufficienti due interrogazioni per risalire al dispositivo, all’utente assegnatario e alla sede dalla quale si è collegato. Il fornitore esterno vede una parte della storia; l’azienda, grazie a directory, DHCP, EDR e badge, può ricostruirne molta di più. Chiedere se quell’indirizzo sia anonimo, senza aggiungere altro, porta quindi fuori strada: occorre sapere per chi dovrebbe esserlo, durante quale trattamento e con quali informazioni a disposizione.
È questa, a mio avviso, la parte più utile delle Linee guida 02/2026 sull’anonimizzazione, adottate dall’EDPB il 7 luglio e ancora in consultazione pubblica. Il Comitato afferma che lo stesso dato può risultare anonimo per un soggetto e personale per un altro, perché le capacità di identificazione non coincidono; contano i mezzi ragionevolmente utilizzabili, comprese le informazioni detenute da terzi, e conta la possibilità concreta di distinguere una persona dalle altre fino a trattarla in modo diverso. Il nome, in questa ricostruzione, è soltanto uno dei possibili punti di arrivo.
Il documento non dedica una sezione ai log di sicurezza e non parla di SIEM, SOC o MSSP. L’applicazione a questi servizi è dunque una nostra lettura, che deve restare riconoscibile come tale; la griglia proposta dall’EDPB sembra però scritta per mettere in difficoltà una vecchia abitudine del settore, quella di archiviare come “dato tecnico” tutto ciò che arriva da una rete. Un log può descrivere un server, un proxy condiviso o un’infrastruttura ostile senza dire nulla su una persona; può anche ricostruire orari, spostamenti, comportamenti e perfino errori di un dipendente. La colonna del data catalog rimane la stessa, il contenuto giuridico cambia.
Per capire dove avviene questo passaggio, le Linee guida suggeriscono di guardare all’intero contesto informativo e non al singolo campo ripulito. La sicurezza informatica complica il lavoro perché vive di correlazioni: il SOC cerca proprio l’evento raro, collega fonti nate in momenti diversi e prova a inferire ciò che l’attaccante, l’utente o il dispositivo stanno facendo. Sono capacità essenziali per la detection; dal punto di vista della protezione dei dati, sono anche i mezzi con i quali un record apparentemente impersonale torna ad avere un soggetto.
Quando l’indirizzo IP torna ad avere una persona
L’EDPB cita l’indirizzo IP fra gli identificatori che possono essere unici in un dato contesto. Il passaggio non autorizza la scorciatoia secondo cui ogni IP sarebbe sempre personale, per chiunque lo tratti; la Corte di giustizia, nel caso Breyer, aveva già mostrato un criterio più concreto. L’indirizzo dinamico registrato dal gestore di un sito costituisce dato personale quando quel gestore dispone di mezzi giuridici che gli permettono di ottenere dal provider le informazioni necessarie a identificare il visitatore. Le tessere del mosaico possono stare presso soggetti diversi, purché esista una strada ragionevolmente percorribile per metterle insieme.
Dentro un’azienda quella strada è spesso molto corta. Il DHCP assegna l’indirizzo interno; la VPN autentica l’account; l’EDR conserva l’utente connesso e l’inventario associa il dispositivo al dipendente. Ciascuna fonte può apparire innocua se osservata da sola, però il SIEM viene acquistato esattamente per incrociarle. Quando la correlazione rientra nelle normali attività di indagine, sostenere che l’organizzazione non possa risalire alla persona richiede una buona dose di fantasia; la pseudonimizzazione dell’username riduce l’esposizione per alcuni operatori, senza trasformare l’intero flusso in informazione anonima per il titolare.
Ci sono naturalmente casi diversi. L’IP pubblico di un’infrastruttura esposta, condiviso attraverso NAT da migliaia di utenti, può descrivere un asset; lo stesso vale per un server di comando e controllo pubblicato in una blacklist. Una connessione residenziale, un piccolo ufficio o un indirizzo accompagnato da timestamp molto precisi restringono invece il gruppo, talvolta fino a una sola persona. Per il Comitato non occorre arrivare subito al nome: basta poter distinguere il soggetto con sufficiente affidabilità e agire nei suoi confronti. Bloccare una sessione, sottoporla a controllo rafforzato o aprire un’indagine sono già effetti individuali.
No Record Isolation, No Linkage e No Inference
È qui che i tre criteri tecnici delle Linee guida — No Record Isolation, No Linkage e No Inference — acquistano un significato operativo. Un accesso fallito può isolare una sequenza riferibile allo stesso utente; l’orario e la sede possono collegarla al turno di lavoro; il confronto con i log dell’endpoint può ricostruire l’account. Se quella sequenza mostra collegamenti ricorrenti da una struttura sanitaria, oppure coincide con riunioni sindacali, il sistema consente anche inferenze molto delicate. L’EDPB richiede che l’inferenza sia specifica, significativa e collegata ai dati originari; una supposizione generica sulla popolazione non basta, mentre un’informazione capace di incidere sui diritti o sugli interessi dell’interessato merita un’analisi ben diversa.
La threat intelligence rende il quadro ancora più mobile. Un indicatore pubblicato in un feed può dire poco al pubblico e moltissimo al cliente che lo incrocia con i propri eventi; una geolocalizzazione, l’ASN, la reputazione dell’indirizzo e il fingerprint del dispositivo aggiungono pezzi che prima non esistevano. Fonte aperta non equivale ad anonimato, così come la provenienza dal dark web non rende automaticamente personale qualunque indicatore. La qualificazione dipende dall’uso e dai mezzi effettivamente disponibili: scegliere la prospettiva dopo avere visto quale risposta conviene sarebbe, oltre che giuridicamente debole, un pessimo modo di governare i dati.
Anche gli aggregati possono tradire. Dieci eventi attribuiti a un reparto sembrano una statistica; se il reparto è composto da due persone, una sola era in servizio e un altro report espone gli orari, il dettaglio riemerge senza particolare sofisticazione. Le Linee guida insistono su un punto che nei cruscotti aziendali si dimentica facilmente: il dataset può essere trattato in blocco come anonimo soltanto quando l’anonimizzazione regge per tutte le persone incluse. Gli outlier, i piccoli gruppi e le serie temporali ad alta precisione sono spesso il luogo in cui il volto ricompare.
Il SOC esterno non diventa cieco per contratto
La prospettiva contestuale sembra offrire una soluzione elegante: il cliente conserva la tabella di corrispondenza, il SOC esterno riceve token e, dal suo punto di vista, non conosce i nomi. Le Linee guida rendono l’operazione meno semplice. Quando un soggetto tratta le informazioni per conto di un titolare, la natura personale dei dati va valutata facendo riferimento alla prospettiva di quel titolare; se il cliente può identificare e l’MSSP opera sulle sue istruzioni, le informazioni restano personali anche nel trattamento affidato al fornitore. Diversamente, basterebbe esternalizzare una lavorazione per far evaporare le garanzie del GDPR.
Il risultato può cambiare quando il destinatario decide autonomamente finalità e mezzi. Un provider che costruisce un proprio prodotto di threat intelligence non occupa necessariamente la stessa posizione del SOC che gestisce la console del cliente; in quel caso bisogna verificare quali informazioni aggiuntive possa ottenere, se abbia rapporti con soggetti capaci di identificare, quanto sia credibile la separazione dalle fonti originarie e con quale probabilità i dati vengano ulteriormente trasferiti. Resta poi la prospettiva di chi trasmette: l’informazione può essere anonima per il destinatario e continuare a essere personale per il titolare che la prepara, la seleziona e la invia.
Neppure una clausola di non re-identificazione risolve tutto. L’EDPB osserva che il divieto contrattuale, anche vincolante, non equivale a un divieto stabilito dalla legge e può soltanto rafforzare misure tecniche affidabili, verificabili ed effettive. In un servizio SOC ciò porta a domande piuttosto concrete: gli analisti possono interrogare la directory del cliente? Le chiavi sono separate? Un operatore vede più tenant? Le esportazioni vengono controllate e gli accessi alle fonti ausiliarie restano tracciati? Se il contratto promette l’anonimato mentre l’architettura permette di ricomporre i dati con poche query, il problema non è terminologico.
La risposta più realistica sarà spesso una pseudonimizzazione a più livelli. L’analista di primo livello può lavorare con un identificatore stabile per la durata dell’allerta; chi svolge il triage accede al contesto tecnico, mentre l’associazione con la persona viene aperta quando l’incidente lo richiede e lascia una traccia. I dashboard direzionali possono applicare soglie minime e sopprimere i piccoli gruppi; le copie usate per addestrare regole di detection possono perdere precisione temporale o ruotare i token, se non serve seguire lo stesso soggetto per mesi. L’archivio probatorio conserva invece il dettaglio necessario, con autorizzazioni più strette. Chiamare anonimi tutti questi livelli insieme produce informative ambigue e contratti impossibili da rispettare; chiamarli personali, quando lo sono, consente di governarli senza impoverire l’indagine.
NIS2, incident response e anonimato che cambia nel tempo
La NIS2 ha bisogno dei log. Gli enti devono rilevare gli incidenti, contenerli e ricostruirne le cause; per le categorie alle quali si applica il regolamento di esecuzione 2024/2690, i requisiti entrano nel dettaglio della gestione dei log, del monitoraggio e della registrazione delle attività di risposta. Ridurre i dati significa eliminare ciò che non serve allo scopo, non privare l’organizzazione degli elementi senza i quali una compromissione resta incomprensibile. Timestamp, sorgente, destinazione e identità tecnica possono essere necessari; la loro utilità non autorizza conservazioni indefinite o accessi generalizzati.
Il raccordo con il GDPR dovrebbe allora partire dai singoli flussi. Il monitoraggio in tempo reale, la forensic analysis, la reportistica direzionale e la condivisione di indicatori hanno destinatari e granularità differenti; cambiano anche i tempi utili e le possibilità di collegamento. Per alcuni trattamenti la base giuridica discenderà da un obbligo normativo, per altri dal legittimo interesse a proteggere reti e servizi, con il bilanciamento richiesto dall’articolo 6. In entrambi i casi occorrono finalità definite, regole di accesso, retention motivata e una spiegazione onesta del fatto che quei dati possono riguardare persone.
Il passaggio delle Linee guida che interessa di più l’incident responder occupa poche righe: un incidente di sicurezza può costringere a rivalutare l’anonimato, soprattutto quando la precedente conclusione dipendeva dalla riservatezza di informazioni aggiuntive. Se l’attaccante sottrae sia il dataset trasformato sia la tabella che collega token, utenti e dispositivi, ciò che ieri risultava anonimo per un destinatario può essere identificabile oggi; l’organizzazione deve allora riesaminare i ruoli e verificare se ricorrono gli obblighi degli articoli 33 e 34 GDPR.
Il riesame dell’anonimato dopo un incidente
Nella pratica la sequenza emerge a strati. Si individua un accesso anomalo; qualche ora dopo si scopre che l’attaccante ha raggiunto il repository delle chiavi; soltanto in seguito ci si accorge che una copia di log, classificata come anonima e condivisa con un laboratorio, è tornata collegabile. La valutazione del personal data breach deve seguire l’ampliamento dei mezzi disponibili all’attaccante. Lo stesso evento può superare anche la soglia dell’incidente significativo NIS2, ma i due test restano distinti: un grave fermo di servizio può non coinvolgere dati personali, mentre l’accesso illecito a log personali non comporta da solo la comunicazione agli interessati, che dipende dall’elevatezza del rischio.
Il runbook dovrebbe far circolare le evidenze fra i due percorsi senza confondere le decisioni. Sistemi interessati, dati esfiltrati, chiavi compromesse, categorie di persone e misure di contenimento alimentano sia la valutazione NIS2 sia quella GDPR; soglie, destinatari e tempistiche vanno poi applicati secondo la disciplina pertinente. Serve anche un punto di riesame dell’anonimato, attivato quando cambiano l’architettura, le fonti acquisite dal SIEM, i privilegi dell’MSSP o le informazioni finite nelle mani dell’attaccante.
A mio avviso è questa la conseguenza più importante delle Linee guida per la cybersicurezza. Nei playbook la casella “dati personali: sì/no” fotografa un momento e spesso presuppone che il nome sia l’unico identificatore; occorre invece annotare rispetto a chi il dato dovrebbe essere anonimo, quali collegamenti risultano realisticamente disponibili e quale evento farebbe cadere quella conclusione. Il lavoro può portare a riconoscere che titolare e MSSP trattano dati personali, circostanza frequente nei servizi gestiti, oppure a costruire una separazione credibile per la reportistica e la condivisione esterna. In entrambi i casi si ottiene qualcosa di più utile di un’etichetta: si sa chi può vedere cosa, e per quale ragione.
Un indirizzo IP, in fondo, non cambia natura quando entra nel SIEM; cambia la quantità di mondo che il SIEM gli mette intorno. È lì che l’anonimato si rafforza o si perde, ed è lì che dovrebbero incontrarsi il DPO, il responsabile della sicurezza e chi gestisce l’incidente. Se questa conversazione avviene soltanto dopo l’esfiltrazione della tabella di corrispondenza, sarà già arrivata troppo tardi.
Partecipa alla community