Steganography, Tokenization e Data Masking#
Tre tecniche distinte che operano sulla visibilita' e protezione dei dati, ma con scopi e garanzie completamente diversi: la steganografia nasconde l'esistenza stessa del messaggio, la tokenizzazione sostituisce il dato sensibile con un riferimento non invertibile, il data masking produce una copia realistica ma fittizia per ambienti non di produzione.

Steganography#
La steganografia nasconde il messaggio all'interno di un carrier apparentemente innocuo senza cifrarlo. A differenza della crittografia (che rende il messaggio illeggibile), la steganografia lo rende invisibile: chi osserva il carrier non sa che esiste un messaggio nascosto.
Dev parallel: Come nascondere dati in un campo HTML
data-attribute di un elemento visivamente normale. Chi legge il DOM non sa che la riga contiene informazioni extra. La pagina appare identica.
Watermarking#
Il watermarking e' steganografia con obiettivo diverso: non nascondere comunicazioni ma tracciare la provenienza di un documento. Ogni copia distribuita porta un fingerprint unico che identifica il destinatario.
Tokenization#
La tokenizzazione sostituisce un dato sensibile con un token casuale. La differenza critica dalla cifratura e' che il token non ha relazione matematica con il dato originale: non esiste un algoritmo per passare dal token al dato. L'unico modo per recuperare il dato originale e' fare un lookup nel token vault.
Dev parallel: Stripe fa esattamente questo. Quando integri i pagamenti con Stripe, il numero carta non tocca mai il tuo server: Stripe ti da' un
tok_(token), che usi per tutte le operazioni successive. Se il tuo DB viene violato, l'attaccante trova solo token Stripe, non numeri di carta. Il vault e' sul lato Stripe, PCI DSS certificato.
Data Masking#
Il data masking sostituisce dati reali con dati realistici ma completamente fittizi. Lo scopo non e' proteggere i dati in produzione ma creare copie sicure per ambienti di sviluppo e test, dove i dati reali non devono mai entrare.
Dev parallel: Il classico problema di ogni dev team SaaS: come dare ai developer un database realistico per testare senza esporre i dati degli utenti reali? La risposta corretta e' data masking: dump di produzione → strumento di masking (Faker.js, Anonymizer) → DB anonimizzato per dev. Mai usare dati reali in staging.
Confronto Comparativo#
| Tecnica | Dato originale | Reversibilita' | Scopo principale |
|---|---|---|---|
| Encryption | Trasformato (ciphertext) | Si, con chiave | Confidenzialita' in transito/riposo |
| Tokenization | Non presente nel sistema | Solo via vault lookup | Compliance PCI DSS, pagamenti |
| Data Masking | Sostituito con dato fittizio | No (design) | Ambienti dev/test |
| Steganography | Nascosto nel carrier | Si, con tool/password | Covert communication |
| Watermarking | Embedded nel media | Si, con tool | Tracciabilita' leak |


