Tokenizzazione: il dato più sicuro è quello che non si conserva

Tokenizzazione è la tecnica che protegge un dato sensibile facendone sparire l’originale dai sistemi che lo usano. Al posto del numero di una carta di pagamento, di un codice fiscale, di un identificativo personale, si mette un surrogato senza alcun valore in sé, un token, e il dato vero viene custodito in un solo luogo protetto. Tutto il resto dell’organizzazione, le applicazioni, i database, i log, lavora soltanto con quei surrogati. La conseguenza è tanto semplice quanto potente: chi ruba i token non ruba nulla, perché un token, da solo, non significa niente e non riconduce a niente.

È un’idea che ribalta l’istinto difensivo comune. Di solito si cerca di proteggere meglio il dato sensibile là dove si trova: lo si cifra, si rafforzano gli accessi, si sorveglia chi lo tocca. La tokenizzazione segue la strada opposta, e parte da un principio più radicale: il dato più sicuro è quello che non si conserva affatto. Se la maggior parte dei sistemi non detiene mai il valore reale, ma solo un sostituto inutile, allora una loro compromissione smette di essere una fuga di dati e diventa la cattura di un mucchio di segnaposto privi di senso.

Sostituire, non cifrare

La distinzione più importante, e più fraintesa, è quella con la cifratura. Cifrare un dato significa trasformarlo con una chiave in un testo illeggibile, ma reversibile: chi possiede la chiave riottiene l’originale, e il testo cifrato resta legato matematicamente al dato di partenza. Ne discende una dipendenza scomoda: la sicurezza dell’intero sistema poggia sulla segretezza della chiave, e ogni componente che la detiene resta un punto critico. Se la chiave trapela, tutto ciò che ha cifrato torna in chiaro.

La tokenizzazione non trasforma il dato, lo rimpiazza. Il token, nella sua forma più solida, è un valore generato in modo casuale, senza alcun rapporto matematico con il dato che sostituisce. Non c’è una chiave che lo riporti all’originale, non c’è un algoritmo da invertire: l’unico modo per risalire dal token al dato vero è consultare l’archivio che ne conserva la corrispondenza. Non è il dato camuffato, è un’altra cosa che prende il suo posto. È questa la differenza che conta, perché elimina alla radice il problema della chiave da proteggere.

Il caveau e ciò che ne esce

Il cuore del modello è proprio quell’archivio, il token vault, l’unico punto in cui vive la corrispondenza tra ogni token e il dato reale che rappresenta. Il vault è isolato e sorvegliato con accessi rigorosamente controllati, ed è il solo componente dell’architettura che maneggia davvero l’informazione sensibile. Quando un sistema ha bisogno del valore reale, e solo se ne ha davvero bisogno, lo richiede al vault presentando il token; tutto il resto del tempo, ovunque, circolano soltanto i surrogati.

Per non rompere le applicazioni che li trattano, i token sono di norma costruiti in modo da conservare il formato dell’originale: un token che sostituisce un numero di carta ne mantiene la lunghezza e una forma compatibile, così i sistemi a valle continuano a funzionare senza modifiche. Le linee guida impongono però che non sia confondibile con un numero di carta reale, per esempio che non superi il controllo di validità di Luhn. Il risultato architetturale è netto: la superficie che custodisce dati sensibili si restringe a un solo punto fortificato, mentre tutto il resto diventa un territorio in cui una violazione non trova nulla di utile da portare via. È la traduzione pratica del principio per cui non si può perdere ciò che non si possiede, e si lega bene alle logiche di prevenzione della perdita di dati.

Tokenizzazione e la riduzione del perimetro

C’è una ragione molto concreta per cui la tokenizzazione è nata e si è diffusa nel mondo dei pagamenti, e ha a che fare con la conformità. Gli standard di sicurezza dei dati delle carte impongono controlli stringenti a ogni sistema che tratta il numero di carta reale. Sostituendo quel numero con un token, i sistemi che da quel momento maneggiano solo surrogati escono dal perimetro soggetto a quei controlli, perché non contengono più dati di carta da proteggere. Il vantaggio non è solo di sicurezza, è anche di costo e di conformità: meno sistemi nel perimetro significano meno audit, meno requisiti, meno rischio concentrato in meno punti.

Quella che è nata per le carte di pagamento si è poi estesa a ogni categoria di dato personale che valga la pena non disseminare: identificativi, dati sanitari, anagrafiche. La logica resta la stessa, ed è una logica di minimizzazione: ridurre al minimo indispensabile l’insieme dei sistemi che toccano davvero il dato reale, e quindi la superficie che un attaccante può colpire con profitto. In un’epoca in cui le violazioni sono date quasi per inevitabili, spostare il valore fuori dalla portata della maggior parte dei sistemi cambia la posta in gioco di un incidente.

Con caveau o senza: una distinzione che conta

Va detta con precisione una sfumatura che il marketing tende a confondere. Accanto alla tokenizzazione con vault esiste anche quella senza, la vaultless, che non conserva una tabella di corrispondenze ma genera il token direttamente dal dato con metodi algoritmici. Spesso, ma non sempre, questi si basano su una cifratura che conserva il formato: esistono infatti approcci vaultless progettati per essere realmente non invertibili per calcolo. La distinzione che conta, in fondo, non è vault contro non vault, ma reversibile contro non reversibile. Quando il token deriva dal dato tramite un algoritmo e una chiave, è di fatto recuperabile per calcolo, e somiglia molto di più a una cifratura che a una vera sostituzione. La proprietà più forte, quella per cui non esiste chiave da violare e il token resta scollegato dall’originale, appartiene ai token realmente casuali: per questi risalire al dato deve essere computazionalmente non fattibile non solo a partire dal singolo token, ma anche disponendo di molte coppie token-dato, una garanzia che una cifratura che conserva il formato non offre. Confondere un cifrato che conserva il formato con un token vero porta a sopravvalutare la protezione ottenuta.

Tre strumenti, tre scopi

Per usare bene la tokenizzazione conviene collocarla accanto alle due tecniche con cui viene scambiata. La cifratura serve quando il dato deve essere conservato o trasmesso in forma recuperabile, e si accetta il carico della gestione delle chiavi; protegge, ma il dato resta, cifrato, dentro il sistema. Il mascheramento dei dati, il data masking, sostituisce i valori sensibili con valori fittizi in modo irreversibile, ed è la scelta giusta dove il dato reale non serve affatto, come negli ambienti di sviluppo, test e analisi: una volta mascherato, non si torna indietro. La tokenizzazione sta in mezzo, ed è la risposta a un’esigenza che le altre due non coprono: usare un dato sensibile dove e quando serve davvero, mantenendolo però fuori dalla portata di tutto il resto.

In fondo, la tokenizzazione è la forma pratica di un’idea che la sicurezza scopre sempre troppo tardi: gran parte del rischio di un dato sta semplicemente nell’averlo. Tenere il valore reale in un solo luogo protetto e far circolare ovunque solo surrogati senza significato non rende un’organizzazione inviolabile, ma trasforma la maggior parte delle sue violazioni in non eventi, perché ciò che viene sottratto non vale nulla. Non sostituisce la cifratura e non sostituisce il mascheramento, ma risponde alla domanda che nessuno dei due sa affrontare: come si fa a usare un dato sensibile dappertutto senza conservarlo dappertutto. La risposta, spesso, è non conservarlo affatto.