Crittografia locale vs cloud classico: cosa cambia davvero quando i tuoi dati trapelano

Se gestisci una piccola attività o lavori da solo con documenti di clienti, la domanda non è davvero «i miei dati potrebbero trapelare?». Le violazioni capitano ad aziende molto più grandi della tua, e ai fornitori di cui si fidano. La domanda utile è: quando c’è una fuga, cosa esce davvero? La risposta dipende quasi interamente da una cosa che la maggior parte delle persone non controlla mai: chi detiene le chiavi dei tuoi file.

Questo articolo non è una consulenza legale. È una spiegazione in parole semplici di ciò che una violazione dei dati espone in due configurazioni: i tuoi file su un servizio cloud classico (Google Drive, Dropbox, Notion, la maggior parte degli strumenti SaaS), oppure i tuoi file crittografati in locale sul tuo computer prima che qualsiasi cosa ne esca.

Risposta rapida

In un servizio cloud classico i tuoi file sono di solito crittografati «a riposo» sui server del fornitore, ma le chiavi di decrittografia le detiene il fornitore. Quindi una violazione di quel fornitore, un dipendente infedele o una richiesta legale valida possono esporre il tuo contenuto reale in forma leggibile. Con la crittografia locale, lato client, i tuoi file vengono resi illeggibili sul tuo dispositivo con una chiave che non lo lascia mai in chiaro; il server (se sincronizzi) conserva sempre e solo blob crittografati opachi. Se quel server subisce una fuga, gli attaccanti ottengono un testo cifrato che non possono leggere senza la tua password. In una violazione la differenza è netta: il cloud crittografato a riposo lascia trapelare i tuoi documenti, la crittografia lato client lascia trapelare rumore.

Perché questo toglie il sonno ai piccoli team e ai freelance

Quando tratti i dati di altre persone (contratti dei clienti, note sanitarie, documenti finanziari, file sorgente, documenti delle risorse umane), una violazione non è solo un problema tuo. Potresti dovere una spiegazione a quelle persone, e forse a un’autorità di controllo.

Ai sensi del GDPR, una violazione dei dati personali può far scattare l’obbligo di notificarla alla tua autorità di controllo (in generale entro 72 ore dal momento in cui ne vieni a conoscenza) e, quando il rischio per le persone è elevato, di comunicarla anche agli interessati. Questo è il principio; le soglie e le formulazioni esatte stanno nel regolamento e nelle linee guida della tua autorità nazionale, quindi prendi questa parte come un orientamento, non come un parere legale.

Ecco la parte che cambia tutto, e in cui la crittografia smette di essere una funzione di sicurezza astratta: le autorità di controllo e le loro linee guida trattano in genere i dati resi incomprensibili a chi non è autorizzato (per esempio crittografati correttamente con chiavi che l’attaccante non possiede) in modo molto diverso dai dati trapelati in chiaro. Una crittografia forte non cancella magicamente ogni obbligo, ma può fare la differenza tra «i dati esposti sono illeggibili per chiunque li abbia rubati» e «dobbiamo dire a 4.000 clienti che i loro contratti sono in giro». È questa la vera posta in gioco dietro la noiosa espressione «chi detiene le chiavi».

La differenza di fondo: dove avviene la crittografia e chi detiene la chiave

Quasi tutti i servizi seri crittografano i dati «a riposo». L’espressione suona rassicurante ed è sottilmente fuorviante. Significa che i dati sono crittografati sui dischi del fornitore, con chiavi gestite dal fornitore. Protegge da qualcuno che ruba fisicamente un disco rigido da un data center. Non protegge da una violazione del fornitore stesso, perché la stessa infrastruttura che serve i tuoi file detiene anche le chiavi per decrittografarli.

La crittografia lato client inverte l’ordine. Il file viene crittografato sul tuo dispositivo, con una chiave derivata dalla tua password, prima ancora di essere scritto sul disco o caricato. Il servizio, se c’è, riceve qualcosa che non può leggere. È la proprietà che viene chiamata crittografia zero-knowledge: chi ospita conserva i tuoi dati ma è strutturalmente incapace di decrittografarli.

Queste due idee, end-to-end e zero-knowledge, vengono usate come sinonimi e non sono proprio la stessa cosa; se vuoi la distinzione precisa, l’abbiamo spiegata in crittografia end-to-end vs zero-knowledge. Per analizzare una violazione, la scorciatoia che conta è semplice: il server ha mai la chiave, sì o no?

Cosa espone una violazione, a confronto

Scenario	Cloud classico (crittografato a riposo)	Crittografia locale / lato client
Server del fornitore attaccati	L’attaccante può arrivare ai file in forma leggibile se arriva anche alle chiavi	L’attaccante ottiene blob crittografati opachi, inutili senza la tua password
Dipendente infedele o compromesso	Può potenzialmente accedere ai contenuti (strumenti di assistenza, pannelli di amministrazione)	Non può leggere i contenuti; le chiavi non sono sul server in forma utilizzabile
Richiesta di un’autorità al fornitore	Il fornitore può essere tenuto a consegnare dati leggibili	Il fornitore può consegnare solo testo cifrato che non può decrittografare
Il tuo portatile rubato	Dipende dalla crittografia del disco; i dati dell’app potrebbero essere leggibili	I file restano crittografati uno per uno; serve comunque la tua password
Fuga da un backup o da un bucket mal configurato	Documenti leggibili esposti	Blob crittografati esposti, non il contenuto

Nota le ultime due righe. La crittografia lato client non è uno scudo magico: se il tuo portatile è sbloccato e il tuo spazio di lavoro è aperto, un attaccante con accesso fisico è dentro il tuo perimetro di fiducia. La protezione è più forte proprio dove il cloud classico è più debole, cioè sul lato server, il posto che non controlli e non puoi verificare.

Ma «a riposo» basta mai?

A volte sì, e qui l’onestà conta. Se il tuo modello di minaccia è un disco rubato in un data center o un nastro di backup perso, la crittografia a riposo se ne occupa. Se hai bisogno che i server del fornitore elaborino attivamente i tuoi contenuti (ricerca full-text eseguita da loro, funzioni di IA, collaborazione lato server, conversione di formati), devono poterli leggere, e la crittografia lato client romperebbe quelle funzioni. È un compromesso reale, non una nota a piè di pagina del marketing. Molti team lo accettano deliberatamente.

Il problema è che la maggior parte delle persone non ha mai fatto questo compromesso in modo consapevole. Hanno dato per scontato che «crittografato» volesse dire «l’azienda non può leggere le mie cose», e per gli strumenti cloud classici questa ipotesi di solito è sbagliata. Notion, per esempio, crittografa i dati a riposo ma non è crittografato end-to-end e detiene le chiavi, come abbiamo spiegato nel dettaglio in Notion è crittografato?.

Com’è fatta davvero una buona crittografia lato client

Non tutte le app «crittografate» si equivalgono, quindi aiuta sapere cosa include un design serio. Gli elementi da verificare:

• Un cifrario autenticato robusto. Lo standard attuale è AES-256-GCM, che crittografa e insieme rileva le manomissioni. È la stessa classe di primitive usata da TLS, Signal e WireGuard.
• Una gerarchia di chiavi sensata. La chiave che crittografa i tuoi dati dovrebbe essere casuale e mai conservata in chiaro: è cifrata da una chiave derivata dalla tua password, così cambiare password significa cifrare di nuovo una sola chiave invece di ricrittografare tutto, e una copia rubata dei dati del server non apre nulla. Questo approccio a due livelli è il modello KEK/FEK.
• Una derivazione della chiave lenta. La tua password dovrebbe essere «stirata» con una funzione volutamente lenta, così che forzarla costi caro. PBKDF2 con un numero elevato di iterazioni o Argon2id sono le scelte abituali.
• Un percorso di recupero che non restituisca la chiave a un server. Una frase di recupero scritta (in stile BIP-39) fa sì che la rete di sicurezza sia tu, non il fornitore.

Se vuoi il modello mentale completo dei modelli di minaccia e di come scegliere uno strumento, come crittografare le tue note è un punto di partenza pratico.

Cosa significa per te, in concreto

Che tu cambi strumento o no, questi passi riducono la tua esposizione il giorno in cui avviene una fuga:

1. Fai l’inventario di chi può leggere i tuoi file sensibili. Per ogni strumento, fai al fornitore una sola domanda: i file sono crittografati end-to-end o lato client, oppure solo «a riposo»? Se è solo a riposo, dai per scontato che una violazione di quel fornitore esponga contenuti leggibili.
2. Attiva la crittografia completa del disco su ogni dispositivo (BitLocker su Windows, FileVault su macOS, LUKS su Linux). È la tua base per la riga «portatile rubato» qui sopra ed è gratuita.
3. Separa i dati più sensibili. Contratti dei clienti, cartelle cliniche e documenti finanziari meritano una crittografia lato client anche se le tue note generiche non ne hanno bisogno.
4. Tieni una copia locale crittografata di tutto ciò che è critico, così un guasto di un fornitore cloud o il blocco di un account non ti chiudono fuori anche dal tuo lavoro.
5. Scrivi il tuo metodo di recupero e conservalo offline. Crittografia lato client significa che nessuno può reimpostare la password al posto tuo, ed è questo il punto, e anche il rischio.
6. Prepara un riflesso per le violazioni. Sappi chi è la tua autorità di controllo e, a grandi linee, in cosa consiste il tuo obbligo di notifica prima di averne bisogno, perché i tempi sono stretti.

Dove si colloca Filarr (e dove no)

Filarr è uno spazio di lavoro crittografato local-first: note, file e un grafo che li collega, tutto crittografato sul tuo disco. In concreto, ogni file è crittografato singolarmente in AES-256-GCM con la chiave del tuo account (la FEK), con un valore casuale nuovo per ogni file; la FEK è cifrata da una chiave (la KEK) derivata dalla tua password con PBKDF2-SHA512 a 600.000 iterazioni (ben oltre le 210.000 raccomandate dall’OWASP per PBKDF2-SHA512). Il recupero è una frase BIP-39 di 24 parole che detieni tu, non il server.

La sincronizzazione cloud è facoltativa. Quando la attivi, i file vengono caricati già crittografati e il backend conserva solo blob opachi; la chiave non lo raggiunge mai in chiaro. Quindi, negli scenari di violazione qui sopra, una fuga dallo storage di sincronizzazione di Filarr espone testo cifrato, non i tuoi documenti. Se vuoi la meccanica esatta, abbiamo esaminato il codice in come la sincronizzazione cloud di Filarr resta zero-knowledge, e l’intera architettura difensiva è documentata in la sicurezza di Filarr, livello per livello.

Cosa Filarr non fa, detto chiaramente:

• Non ti rende conforme al GDPR. La crittografia è una misura tecnica; la conformità dipende dall’insieme del tuo trattamento, dai contratti, dalla conservazione e dalla base giuridica. Uno strumento non può certificarlo al posto tuo.
• Non protegge uno spazio di lavoro sbloccato e aperto su un computer compromesso. La crittografia lato client protegge i dati a riposo e in transito, non una sessione che hai lasciato aperta.
• È più giovane di Obsidian o di Notion, con un ecosistema di plugin più piccolo e un’app mobile che esiste solo su Android, da ottobre 2026. Se oggi ti serve un catalogo maturo di estensioni, è una lacuna reale.

La proposta onesta è circoscritta: se la tua preoccupazione è proprio «cosa trapela quando il mio fornitore subisce una violazione», la crittografia lato client cambia la risposta da «i documenti dei miei clienti» a «rumore illeggibile», ed è tutto qui il punto.

FAQ

Se un servizio crittografa i dati «a riposo», i miei dati non sono al sicuro in una violazione? Non necessariamente. La crittografia a riposo protegge dal furto di dischi fisici, ma le chiavi le detiene il fornitore, quindi una violazione dei suoi sistemi attivi, un dipendente infedele o una richiesta di un’autorità possono comunque esporre contenuti leggibili. È la crittografia lato client a mantenere il contenuto illeggibile anche per chi lo ospita.

La crittografia elimina il mio obbligo di notificare una violazione ai sensi del GDPR? No, ma può cambiare la valutazione del rischio. Le linee guida trattano in genere i dati che erano incomprensibili per l’attaccante (crittografati correttamente, chiavi non compromesse) in modo più favorevole rispetto ai dati trapelati in chiaro, il che può incidere sull’obbligo di comunicarlo agli interessati. È un orientamento, non una consulenza legale; consulta le linee guida della tua autorità nazionale per la tua situazione.

Qual è il rovescio della medaglia della crittografia lato client? Due cose. Il fornitore non può offrire funzioni che hanno bisogno di leggere i tuoi contenuti (ricerca lato server, IA sui tuoi dati, una parte della collaborazione), e nessuno può recuperare il tuo account se perdi la password e la frase di recupero. Scambi comodità e una rete di sicurezza con la garanzia che chi ti ospita non possa leggere i tuoi dati.

Local-first vuol dire solo offline? No. Local-first significa che i tuoi dati vivono sul tuo dispositivo e funzionano completamente offline, ma puoi comunque sincronizzarli tra dispositivi. La differenza rispetto al cloud classico è che la sincronizzazione è facoltativa e, fatta bene, trasporta solo blob crittografati che il server non può leggere.

Il mio portatile potrebbe comunque essere rubato. In quel caso la crittografia serve a qualcosa? Sì, in parte. File crittografati uno per uno più la crittografia completa del disco significano che un ladro con il computer spento si trova davanti la tua password, non i tuoi documenti. Ciò che non protegge è un dispositivo sbloccato con il tuo spazio di lavoro già aperto, ed è per questo che le abitudini a livello di dispositivo contano ancora.