Tokenizzazione vs. crittografia: Scegliere l'approccio giusto per la protezione dei dati

La crittografia e la tokenizzazione proteggono entrambi i dati sensibili, supportano la conformità e appaiono in ogni principale framework di sicurezza. Eppure funzionano in modi fondamentalmente diversi, e selezionare l'approccio sbagliato per un dato caso d'uso può significare lasciare sul tavolo la riduzione dell'ambito di conformità o introdurre una complessità architettonica non necessaria.

Molti team di sicurezza faticano con questa decisione proprio perché le due tecniche si sovrappongono nel loro scopo. Entrambe rendono i dati sensibili illeggibili per le parti non autorizzate. Entrambe supportano i requisiti normativi.

Tuttavia, differiscono in base a dove risiedono i dati sensibili, come possono essere recuperati e quali sistemi rimangono nel campo di applicazione della conformità, distinzioni che influenzano direttamente il carico di audit, il design dell'infrastruttura e la postura di rischio.

L'approccio giusto dipende da come le identità, sia umane che non umane, accedono ai dati, dove si trovano questi dati e quali rischi stai realmente riducendo per migliorare la resilienza informatica e la tua postura generale di sicurezza dei dati.

Tokenizzazione vs. crittografia: Le basi

Prima di confrontare questi due approcci fianco a fianco, è importante capire come funziona ciascuno in modo indipendente.

Le seguenti sezioni definiscono la crittografia e la tokenizzazione, delineano i loro meccanismi fondamentali e evidenziano dove i loro obiettivi si sovrappongono e divergono.

What is tokenization?

La tokenizzazione sostituisce i dati sensibili con token casuali o che preservano il formato, mantenendo i dati originali in una vault di token separata e rinforzata. Un numero di carta a 16 cifre diventa un valore diverso a 16 cifre che sembra reale ma è completamente privo di significato senza accesso alla vault e alle sue mappature.

Le linee guida sulla tokenizzazione PCI definiscono tre approcci alla generazione di token:

• Funzioni crittografiche reversibili matematicamente
• Funzioni crittografiche unidirezionali non reversibili (basate su hash)
• Indice o assegnazione casuale in cui il token non ha alcuna relazione matematica con i dati originali

Quell'ultima categoria è dove la tokenizzazione ottiene la sua caratteristica di sicurezza distintiva. Se i token creati tramite assegnazione casuale vengono esposti in un sistema operativo, non rivelano i valori sottostanti.

Non esiste un algoritmo per invertire e non c'è una chiave di decrittazione che trasformi un token nei dati originali. L'unico percorso di ritorno ai dati reali passa attraverso la cassaforte stessa.

Che cos'è la crittografia?

La crittografia è una trasformazione reversibile che utilizza algoritmi e chiavi crittografiche per convertire il testo in chiaro in testo cifrato illeggibile. Dai a qualcuno la chiave di decrittazione corretta e otterrà di nuovo i dati originali.

In pratica, la crittografia appare ad ogni livello: disco completo, database (TDE), livello di campo, livello applicativo e in transito (TLS).

La dipendenza critica è la gestione delle chiavi. Le chiavi di crittografia seguono un ciclo di vita di pre-attivazione, utilizzo attivo, disattivazione, gestione delle compromissioni e distruzione. Ogni fase introduce requisiti operativi relativi alla generazione, distribuzione, rotazione e archiviazione sicura.

Differenze fondamentali tra tokenizzazione e crittografia

Entrambe le tecniche mirano a proteggere i dati sensibili, ridurre l'impatto degli incidenti e supportare la conformità normativa. Ma differiscono in diversi modi critici:

• Reversibilità: La crittografia è sempre reversibile con la chiave corretta. La tokenizzazione è reversibile solo per i sistemi con accesso al vault e alcuni tipi di token (basati su hash unidirezionale) non sono affatto reversibili.
• Formato dei dati: La crittografia standard può cambiare completamente il formato dei dati, a meno che non venga utilizzata la crittografia che preserva il formato (FPE). La tokenizzazione di solito preserva il formato originale, quindi un numero di carta a 16 cifre rimane di 16 cifre.
• Ambito di conformità:I dati crittografati rimangono nell'ambito di framework come PCI DSS e ogni sistema con accesso alle chiavi rimane nell'ambito. I token memorizzati al di fuori dell'ambiente dei dati dei token possono uscire dall'ambito PCI, riducendo potenzialmente significativamente il carico di audit.
• Prestazioni: La crittografia aggiunge un sovraccarico computazionale prevedibile senza dipendenze esterne. La tokenizzazione basata su vault introduce latenza attraverso ricerche nella vault; gli approcci senza vault scambiano i benefici dell'ambito per la velocità.
• Gestione delle chiavi: La crittografia richiede una gestione delle chiavi per tutto il ciclo di vita in ogni punto di decrittazione. La tokenizzazione concentra quel carico nella cassaforte, trasferendo la responsabilità operativa al fornitore della cassaforte.
• Miglior adattamento: La crittografia è più forte per i dati in transito, i dati non strutturati e i registri frequentemente accessibili. La tokenizzazione è ideale per i campi strutturati (PAN, SSN), i dati primari di archiviazione e la riduzione dell'ambito di conformità.

La fondamentale distinzione architettonica è che la crittografia mantiene i dati originali presenti nel tuo ambiente, resi illeggibili senza la chiave giusta, il che mantiene i dati ampiamente utilizzabili ma richiede una gestione delle chiavi robusta ovunque quelle chiavi esistano.

D'altra parte, la tokenizzazione rimuove completamente i dati sensibili dai sistemi operativi, concentrandoli in un'unica cassaforte rinforzata e minimizzando dove i dati originali risiedono. Tuttavia, aggiunge dipendenza a una cassaforte che diventa il tuo pezzo di infrastruttura più critico.

Quando utilizzare la tokenizzazione

La tokenizzazione offre il massimo valore quando i dati sensibili devono essere memorizzati o referenziati, ma raramente elaborati nella loro forma originale. Le sezioni sottostanti trattano i casi d'uso ideali per la tokenizzazione e le considerazioni pratiche per implementarla in modo efficace.

Scenari ottimali per la tokenizzazione

La tokenizzazione è la soluzione più adatta in tre ambiti:

• Dati della carta di pagamento e identificatori nazionali: PAN, SSN, identificazioni governative e valori strutturati simili in cui le applicazioni utilizzano i dati come riferimento ma raramente necessitano del valore sensibile completo. Se i tuoi sistemi memorizzano e trasferiscono principalmente un numero di conto senza elaborarlo effettivamente, questo è un candidato per la tokenizzazione.
• Identificatori dei clienti in ambienti SaaS e microservizi: Le architetture in cui più servizi gestiscono i dati dei clienti traggono vantaggio dalla tokenizzazione degli identificatori al momento dell'ingresso e dal passaggio solo di token a valle. Meno sistemi toccano dati personali reali, più piccola sarà l'impronta di conformità.
• Riduzione dell'ambito di conformità: Qualsiasi ambiente in cui ridurre il numero di sistemi soggetti ai requisiti PCI DSS o di un framework simile è una priorità. Sostituire i valori sensibili con token in database operativi e livelli applicativi può ridurre significativamente l'ambito della tua prossima valutazione.

In questi scenari, la tokenizzazione ti offre il miglior equilibrio tra protezione dei dati ed efficienza di conformità, mantenendo una postura di sicurezza dei dati coerente.

Quando utilizzare la crittografia

La crittografia non è un controllo universale, ma ci sono scenari in cui è chiaramente la scelta obbligatoria o fortemente preferita. Le seguenti sezioni delineano dove la crittografia si adatta meglio e come gli ambienti moderni hanno cambiato il modo in cui le organizzazioni la implementano e la gestiscono.

Scenari ottimali per la crittografia

La crittografia è il controllo obbligatorio o fortemente preferito in quattro domini:

• Dati in transito:La tokenizzazione protegge i singoli elementi di dati, non il canale di comunicazione stesso. TLS e la crittografia a livello di trasporto sono i controlli di base qui, e nessuna strategia di tokenizzazione li sostituisce.
• Dati non strutturati: Documenti, immagini, comunicazioni e grandi campi di testo non si adattano perfettamente al modello di dati strutturati della tokenizzazione. La crittografia gestisce questi in modo naturale a livello di file, disco o applicazione.
• Dati frequentemente accessibili: Quando molti sistemi devono elaborare i dati nella loro forma originale per operazioni e analisi, la crittografia mantiene i dati utilizzabili nel tuo ambiente senza viaggi di andata e ritorno al vault.
• Backup e archivi:I backup crittografati con chiavi memorizzate separatamente forniscono protezione che persiste durante il ciclo di vita dei dati. La regola fondamentale: non memorizzare mai le chiavi di crittografia insieme ai dati che proteggono.

In questi scenari, la crittografia ti offre generalmente il miglior equilibrio tra usabilità e miglioramento misurabile della tua postura di sicurezza.

Utilizzando insieme tokenizzazione e crittografia

In molti ambienti, l'architettura più forte non si basa su una sola tecnica. La tokenizzazione e la crittografia affrontano diversi vettori di rischio e combinarli strategicamente fornisce una protezione a strati senza complessità ridondante.

Perché sovrapporre entrambe le tecnologie

Ogni tecnologia ha un gap che l'altra riempie:

• La crittografia protegge i dati in transito e sicura i contenuti non strutturati, ma non rimuove i dati sensibili dai tuoi sistemi operativi né riduce l'ambito di conformità.
• La tokenizzazione rimuove valori sensibili dai livelli delle applicazioni e riduce la tua impronta di conformità, ma non protegge i canali di comunicazione su cui si basano quei sistemi né la cassaforte in cui sono memorizzati i dati originali.

Sovrapporre i due significa crittografare ciò che la tokenizzazione non può coprire (transito, dati non strutturati, il vault stesso) e tokenizzare ciò che la crittografia da sola lascia in ambito (campi sensibili strutturati a riposo in database operativi).

Ogni livello dovrebbe affrontare uno stato dei dati o un dominio di sicurezza distinto. Se entrambi i controlli vengono applicati agli stessi dati nello stesso sistema senza servire a scopi diversi, il risultato è una complessità aggiuntiva senza protezione aggiuntiva.

Come funziona nella pratica

Un'architettura a strati tipica segue questo flusso:

1. Ingestione: Un'applicazione web riceve dati della carta e invia immediatamente il PAN al vault dei token tramite una chiamata API su HTTPS. Il canale di comunicazione è crittografato; l'elemento di dati è in procinto di essere tokenizzato.
2. Archiviazione: La cassaforte memorizza il PAN originale (crittografato a riposo all'interno della cassaforte) e restituisce un token all'applicazione. L'applicazione memorizza solo il token nel proprio database, che si trova al di fuori dell'ambito PCI DSS.
3. Elaborazione: Quando l'applicazione deve elaborare un pagamento, invia il token di nuovo alla cassaforte. La cassaforte recupera il PAN originale e lo inoltra al processore di pagamento tramite un canale crittografato.
4. Contenimento dell'ambito: Solo il vault e i suoi componenti direttamente connessi rimangono nell'ambiente dei dati del titolare della carta. Ogni altro sistema nel flusso gestisce solo token o transito crittografato, non dati sensibili grezzi.

Questo schema offre protezione end-to-end: la crittografia copre i dati in movimento e i contenuti della cassaforte a riposo, mentre la tokenizzazione mantiene i valori sensibili fuori dai sistemi operativi e minimizza l'ambito di conformità.

Scegliere l'approccio giusto per il tuo caso d'uso

Con una chiara comprensione di come funziona ciascuna tecnologia e dove si inserisce, il passo successivo è mappare quelle capacità al tuo ambiente specifico. Le sezioni sottostanti forniscono criteri di valutazione e modelli decisionali per guidare quel processo.

Criteri di valutazione

La domanda principale è semplice: è necessario recuperare questi dati nella loro forma originale per l'elaborazione, o vengono principalmente memorizzati e consultati?

I dati che vengono utilizzati frequentemente per i processi a valle indicano la crittografia, mentre i dati che raramente lasciano il loro stato protetto indicano la tokenizzazione.

Oltre quel punto di partenza, cinque criteri pratici plasmano la decisione:

• Tipo e formato dei dati: I campi strutturati (PAN, SSN) sono candidati naturali per la tokenizzazione. I contenuti non strutturati (documenti, immagini, campi di testo libero) richiedono crittografia.
• Frequenza e modello di accesso: I dati che molti sistemi devono elaborare nella loro forma originale favoriscono la crittografia, evitando i viaggi di andata e ritorno al vault. I dati che vengono memorizzati e passati come riferimento favoriscono la tokenizzazione.
• Vincoli di prestazione: Carichi di lavoro ad alta capacità e bassa latenza potrebbero non tollerare le ricerche nel vault. Le prestazioni di crittografia sono principalmente determinate dalla propria capacità di elaborazione e I/O locale e di solito non richiedono viaggi di andata e ritorno a un vault o servizio esterno.
• Fattori normativi: Se ridurre l'ambito del PCI DSS è una priorità, la tokenizzazione offre un percorso che la crittografia non può. Se HIPAA è il framework principale, la tokenizzazione migliora la sicurezza ma non riduce l'ambito.
• Requisiti di integrazione di terze parti: I sistemi legacy che si aspettano formati di dati specifici possono beneficiare di token che preservano il formato. I sistemi che devono elaborare valori grezzi per analisi o operazioni richiedono crittografia.

Mappa questi criteri ai flussi di identità: quali utenti umani, applicazioni e servizi toccano i dati e come appare il ciclo di vita dei dati dalla raccolta all'archiviazione?

Modelli decisionali

Questi modelli si mantengono bene nella maggior parte degli ambienti:

• Usa la tokenizzazione quando fai principalmente riferimento ai dati e vuoi ridurre l'ambito di conformità. PAN, SSN e numeri di registrazione medica che i tuoi sistemi operativi memorizzano ma elaborano raramente nella loro forma originale.
• Utilizza la crittografia quando molti sistemi devono elaborare dati grezzi per operazioni, analisi o comunicazione. Documenti, registri delle transazioni, dati in transito e qualsiasi cosa non strutturata.
• Usa entrambi per carichi di lavoro ad alto rischio o regolamentati. Tokenizza i campi sensibili strutturati a riposo. Cripta tutto in transito. Cripta il tuo vault di token. Sovrapponi le protezioni in base allo stato dei dati, non in modo ridondante.

Quando applichi questi in modo coerente, riduci la complessità operativa mentre rafforzi la resilienza informatica e la prontezza per le audit.

Come Netwrix aiuta le organizzazioni a proteggere i dati sensibili

Scegliere tra tokenizzazione e crittografia richiede di rispondere a domande che la maggior parte delle organizzazioni non può rispondere con sicurezza:

• Dove vivono realmente i nostri dati sensibili?
• Quali sistemi contengono PAN o SSN che non abbiamo considerato?
• Chi ha accesso e questo accesso è ancora giustificato?
• Cosa è memorizzato nei file e dove vengono utilizzati?

Il Netwrix 1Secure Platform inizia con quella visibilità fondamentale, fornendo scoperta e classificazione automatizzate attraverso file system, database e piattaforme di collaborazione come SharePoint e Teams. Quel passo da solo può rimodellare la strategia di protezione. Poiché l'identità determina chi può accedere ai dati sensibili e a quali condizioni, la visibilità su identità e permessi è fondamentale per applicare la tokenizzazione o la crittografia in modo efficace.

Da lì, la piattaforma affronta il livello di governance che la crittografia e la tokenizzazione non possono: cosa succede dopo che gli utenti autorizzati ottengono accesso.

Calcola i autorizza i permessi effettivi attraverso le appartenenze ai gruppi annidati, identifica i proprietari dei dati, mette in evidenza gli account privilegiati obsoleti con accesso all'infrastruttura di gestione delle chiavi o alle vault dei token e monitora le anomalie di accesso.

La reportistica continua di conformità rispetto ai framework PCI DSS, HIPAA e NIST sostituisce le audit periodiche con prove on-demand.

Richiedi una demo di Netwrix per vedere come la piattaforma 1Secure supporta la tua strategia di protezione dei dati in ambienti ibridi.