L'illusione della crittografia
Aggiornato per il 2026
Nel dicembre 2022, LastPass comunicò agli utenti una violazione. Il tono era rassicurante: le password erano "crittografate". Il contenuto dei vault era "al sicuro".
Entro il 2025, oltre $438 milioni erano stati sottratti agli utenti di LastPass. Il furto proveniva direttamente dai loro vault "sicuri".
Come? LastPass deteneva le chiavi.
Il tuo team di sicurezza deve conoscere questo fatto prima di scegliere qualsiasi strumento cloud. Si applica a qualsiasi piattaforma che gestisca file sensibili — comprese le piattaforme di anonimizzazione delle PII.
Crittografia lato server vs. architettura zero-knowledge
La maggior parte degli strumenti cloud afferma di "crittografare i tuoi file". Ma usano la crittografia lato server (SSE). Ecco cosa significa:
| Proprietà | Crittografia lato server | Architettura zero-knowledge |
|---|---|---|
| Dove avviene la crittografia | Sul server del fornitore | Sul tuo dispositivo (browser/desktop) |
| Chi detiene le chiavi | Il fornitore | Solo tu |
| Il fornitore può leggere i tuoi contenuti | Sì | No |
| Una violazione del server espone i file | Sì | No (solo testo cifrato) |
| Il fornitore può essere costretto a condividere i contenuti | Sì | No (non li possiede) |
| Accesso delle autorità | Tramite il fornitore | Impossibile senza la tua chiave |
LastPass deteneva le chiavi. Questo era il difetto fatale. Gli attaccanti si sono introdotti nel sistema e hanno ottenuto sia il testo cifrato che gli strumenti per violarlo, sfruttando ingegneria sociale, attacchi a forza bruta su password deboli e metadati di account obsoleti.
Perché questo è rilevante per il GDPR, Art. 25
L'Art. 25 del GDPR (Privacy by Design) è chiaro. I titolari del trattamento devono adottare "misure tecniche e organizzative adeguate", integrate sin dalla progettazione.
L'European Data Protection Board (EDPB) ha precisato che questo include la minimizzazione crittografica dei dati. Il sistema stesso deve impedire l'accesso ai dati. I soli controlli di accesso non sono sufficienti.
Un fornitore che detiene le tue chiavi non può soddisfare l'Art. 25 nella sua forma più rigorosa. Ecco perché:
- Una violazione del loro sistema potrebbe esporre i tuoi dati.
- Un'ingiunzione al fornitore potrebbe divulgare i tuoi contenuti.
- Un dipendente infedele potrebbe accedere ai tuoi file.
- Un attacco alla supply chain potrebbe esporre tutto.
Il Garante tedesco per la protezione dei dati (BfDI) ha emanato linee guida in merito. Lo stesso ha fatto la Datenschutzbehörde austriaca. Entrambe indicano l'architettura zero-knowledge come la migliore scelta tecnica per il trattamento ad alto rischio.
La realtà delle violazioni SaaS
Il rapporto AppOmni / Cloud Security Alliance 2024 ha rilevato un aumento del 300% nelle violazioni SaaS dal 2022 al 2024. I dati chiave:
- Tempo per una violazione: 9 minuti (un tempo misurato in ore)
- Ruolo delle terze parti nelle violazioni: raddoppiato anno su anno (Verizon DBIR 2025)
- Violazione Conduent: 25,9 milioni di record esposti (numeri di previdenza sociale, dati sanitari)
- Violazione fornitore NHS: 9 milioni di pazienti esposti
Le dichiarazioni di policy non bastano più. Un'architettura solida è il requisito minimo per qualsiasi trattamento ad alto rischio.
Come appare una vera architettura zero-knowledge
Un sistema zero-knowledge autentico ha queste caratteristiche precise:
1. Derivazione delle chiavi lato client La chiave deriva dalla tua password. Un KDF memory-hard (Argon2id, bcrypt o scrypt) viene eseguito sul tuo dispositivo. La chiave non lo lascia mai.
2. Crittografia lato client I tuoi contenuti vengono crittografati prima di lasciare il browser o l'app. Il server riceve solo testo cifrato. Senza la chiave, quel testo cifrato è inutilizzabile.
3. Nessuna chiave memorizzata lato server Il fornitore non conserva chiavi, frammenti di chiavi né backup delle chiavi. Utilizzi la tua frase di recupero per riottenere l'accesso.
4. Verificabilità crittografica Il sistema deve essere documentato in modo trasparente e aperto all'audit. Affermazioni vaghe su "crittografia end-to-end" senza dettagli tecnici sono un segnale d'allarme.
Come anonym.legal implementa il zero-knowledge
Il sistema zero-knowledge di anonym.legal utilizza:
- Derivazione delle chiavi Argon2id: 64 MB di memoria, 3 iterazioni — la scelta OWASP per applicazioni ad alta sicurezza
- Crittografia AES-256-GCM: eseguita completamente nel browser o nell'app desktop prima dell'invio di qualsiasi contenuto
- Frase di recupero BIP39 a 24 parole: l'unico modo per ripristinare l'accesso — non memorizzata da anonym.legal
- Nessun accesso alle chiavi lato server: i server di anonym.legal ricevono solo testo cifrato AES-256-GCM che non possono decrittografare
Una violazione completa dei server di anonym.legal produrrebbe solo blob crittografati. Senza la chiave di ciascun utente — che risiede solo sul suo dispositivo — questi blob sono inutilizzabili.
Consulta la nostra panoramica sulla sicurezza e conformità e la documentazione di conformità per i dettagli tecnici completi.
La checklist per la valutazione dei fornitori
Nella scelta di uno strumento cloud per dati sensibili, poni queste domande:
Domande sull'architettura:
- Dove avviene la crittografia — sul tuo dispositivo o sul server del fornitore?
- Chi genera le chiavi?
- Dove sono conservate le chiavi?
- Il fornitore può consegnare copie in chiaro dei tuoi contenuti in risposta a un'ingiunzione?
- Cosa accade ai tuoi file se il fornitore viene acquisito?
Domande sulla resilienza alle violazioni:
- Se il sistema del fornitore viene completamente compromesso, quali dati vengono esposti?
- Se un dipendente del fornitore agisce in malafede, a quali contenuti può accedere?
- Se un attacco alla supply chain colpisce il fornitore, cosa viene esposto?
Domande normative:
- Il fornitore può fornire documentazione per il GDPR Art. 25?
- Il sistema è stato verificato da un auditor esterno?
- Esiste una certificazione ISO 27001 o SOC 2 che copre la crittografia?
Qualsiasi fornitore che non possa rispondere "zero — il contenuto è crittografato prima di lasciare il tuo dispositivo" alle domande sulla violazione sta usando la crittografia lato server. Consulta le nostre FAQ e il glossario per ulteriori definizioni.
Il caso d'uso: due diligence di un assicuratore sanitario tedesco
Un responsabile della conformità di una grande Krankenkasse tedesca aveva bisogno di uno strumento cloud per l'anonimizzazione. Il compito: elaborare i log dei reclami degli assicurati. Il DPO aveva quattro requisiti:
- Il fornitore non può accedere ai dati degli assicurati
- Nessun trattamento al di fuori della Germania
- Misure tecniche GDPR Art. 32 documentate
- Rischio di violazione segnalabile al DPA ridotto al minimo
Un grande SaaS americano per l'anonimizzazione ha fallito al primo punto: il team di supporto poteva reimpostare i vault degli utenti — prova di accesso lato server alle chiavi. Un secondo strumento conservava il testo elaborato per 30 giorni per "audit trail" — di nuovo, accesso lato server.
anonym.legal soddisfaceva tutti e quattro i criteri. Il DPO poteva scrivere: "Anche una violazione completa del fornitore non produrrebbe dati degli assicurati utilizzabili — le chiavi esistono solo sulle nostre postazioni di lavoro." La documentazione GDPR Art. 32 era pronta in quattro ore.
Visita le nostre case study per altri esempi reali.
Il precedente ICO
Nel dicembre 2025, l'Information Commissioner's Office britannico ha multato l'entità UK di LastPass £1,2 milioni. Il motivo: "mancata adozione di misure di sicurezza tecniche e organizzative adeguate".
La multa non era per la violazione in sé. Era per le scelte architetturali che avevano reso la violazione così grave. Impostazioni KDF deboli, metadati esposti e archiviazione delle chiavi lato server hanno tutti contribuito.
I regolatori ora chiedono: il sistema ha limitato l'impatto di una violazione? L'architettura zero-knowledge risponde in modo inequivocabile. È la miglior prova di tale intento.
Quando l'architettura zero-knowledge non è la soluzione giusta
La crittografia zero-knowledge ha dei compromessi. Questi contano in alcuni casi d'uso:
Complessità di recupero: se gli utenti perdono le chiavi, i loro file sono persi definitivamente. Non esiste una backdoor. Un alto turnover del personale o cattive abitudini di gestione delle chiavi rendono questo un rischio concreto.
Attrito nella collaborazione: i contenuti crittografati possono essere condivisi solo se la controparte dispone degli strumenti di decrittografia corretti. È più lento della semplice condivisione tramite link nelle applicazioni cloud standard.
Casi limite normativi: alcune giurisdizioni richiedono l'accesso delle autorità ai dati tramite ordinanza del tribunale. I sistemi zero-knowledge lo impediscono per progettazione. Questo potrebbe creare problemi legali nei servizi finanziari o nelle telecomunicazioni, dove si applicano norme sull'intercettazione legale.
Overhead computazionale: la derivazione delle chiavi Argon2id e la crittografia AES-256-GCM aggiungono latenza. Questo conta soprattutto per l'elaborazione in tempo reale ad alto volume.
Per i team che elaborano milioni di documenti al giorno, un approccio ibrido potrebbe funzionare meglio: crittografa solo i campi più sensibili, lascia accessibili i metadati. Consulta i piani tariffari per i livelli di volume.
Conclusione
"Crittografiamo i tuoi file" non è una promessa di sicurezza. È una frase di marketing che richiede un'analisi critica.
Le vere domande sono semplici. Chi detiene le chiavi? Dove avviene la crittografia? Cosa viene esposto se i sistemi del fornitore vengono violati?
Per i team che trattano dati sensibili in conformità al GDPR, HIPAA o normative simili, queste scelte architetturali determinano sia il rischio legale che l'esposizione reale in caso di violazione.
LastPass crittografava i contenuti dei propri utenti. Un'architettura zero-knowledge avrebbe reso la violazione del 2022 un evento trascurabile. I $438 milioni sottratti agli utenti sono stati il costo di una scorciatoia architetturale.
anonym.legal utilizza l'architettura zero-knowledge per l'anonimizzazione delle PII. La derivazione delle chiavi Argon2id avviene nel browser o nell'app desktop. La crittografia AES-256-GCM avviene prima che qualsiasi contenuto lasci il tuo dispositivo. I server di anonym.legal conservano solo testo cifrato che non possono decrittografare. Scopri di più nella dichiarazione del fondatore o esplora il sistema di token.