Crittografia a riposo vs end-to-end

"Crittografato a riposo" e "crittografato end-to-end" sembrano simili ma proteggono da minacce completamente diverse. Scoprite la differenza tecnica, gli scenari di violazione coperti da ciascuno e perché confonderli può costare milioni.

Scorrete le pagine funzionalità di dieci costruttori di moduli qualsiasi e troverete la parola "crittografia" su nove di essi. Guardate più da vicino e noterete qualcosa di rivelatore: la maggior parte non dice mai di quale tipo. "I vostri dati sono crittografati" non è una specifica — è un'impressione. E nel mondo della protezione dei dati, quell'ambiguità è esattamente il luogo in cui vive il costo reale.

Esistono due modelli di crittografia fondamentalmente diversi in uso comune: la crittografia a riposo e la crittografia end-to-end. Sembrano simili, usano entrambi algoritmi forti e producono entrambi testo cifrato su disco. Ma risolvono problemi completamente diversi — e se scegliete il modello sbagliato per la violazione che affronterete domani, il conto può raggiungere otto cifre.

A chi è rivolto questo articolo

A chiunque stia scegliendo una piattaforma che archivia dati sensibili — in particolare decisori, responsabili IT, DPO e acquirenti. Non è necessaria una formazione in crittografia; l'attenzione è su cosa ciascun modello protegge nella pratica.

I due modelli, in linguaggio chiaro

Crittografia a riposo

I dati arrivano al server in chiaro (via HTTPS), il server li elabora, e prima di scriverli su disco li crittografa con una chiave che il server controlla. Quando i dati servono, il server usa la stessa chiave per decifrarli. La crittografia è reale, ma il server possiede sia i dati sia la chiave nei momenti che contano.

Crittografia end-to-end

I dati vengono crittografati sul dispositivo del mittente prima ancora di essere trasmessi. Il testo cifrato viaggia via HTTPS e viene archiviato sul server come testo cifrato. Il server non detiene mai la chiave di decifratura. Solo il destinatario previsto — con una chiave sul proprio dispositivo — può leggere il testo in chiaro. Il server è ridotto da custode dei dati a corriere di testo cifrato.

La trappola della formulazione

Fate attenzione a formule come "crittografato in transito e a riposo". Questa frase è tecnicamente vera per quasi ogni SaaS sul mercato ed è compatibile con il fatto che il server legga i vostri dati quando vuole. Non è un sinonimo di crittografia end-to-end.

Dove i due modelli divergono davvero

La domanda da porre su qualsiasi schema di crittografia è: chi può decifrare i dati, e in quali circostanze? La crittografia a riposo risponde: "il server — quando vuole." L'end-to-end risponde: "solo il destinatario — e solo sul proprio dispositivo." Lo spazio tra queste due risposte è il luogo in cui avvengono la maggior parte delle violazioni reali.

Scenario	Crittografia a riposo	Crittografia end-to-end
Qualcuno ruba fisicamente il disco dal data center	Protetto — disco inutile senza la chiave	Protetto
Un aggressore entra nel server applicativo e scarica il database	Esposto — il processo ha la chiave in memoria	Protetto — esce solo testo cifrato
Dipendente del fornitore malevolo / costretto / compromesso	Esposto — ha la chiave di decifratura	Protetto — non ha alcuna chiave
Mandato governativo al fornitore	Il fornitore deve consegnare dati leggibili	Il fornitore può consegnare solo testo cifrato
Bucket mal configurato o backup aperto	Esposto	Protetto — solo testo cifrato
Azienda acquisita, nuovo proprietario cambia la policy	Esposto sotto la nuova policy	Ancora protetto — nessuna chiave da consegnare

La crittografia a riposo è essenzialmente un controllo di sicurezza fisica travestito da digitale. Protegge significativamente un unico e ristretto vettore di attacco — la perdita o il furto del supporto fisico — e poco altro. Praticamente tutte le violazioni di dati di cui avete letto nelle notizie sono avvenute attraverso il livello applicativo, dove la crittografia a riposo non offre protezione.

Perché la differenza può letteralmente costare milioni

Secondo il rapporto IBM Cost of a Data Breach 2024, il costo medio globale di una violazione dei dati ha raggiunto 4,88 milioni di USD — il più alto mai registrato. Le violazioni sanitarie sono costate in media 9,77 milioni di USD, e le violazioni che coinvolgono dati personali dei clienti erano la categoria più costosa in ogni settore.

Ma i numeri dei titoli nascondono la struttura del costo. Una singola violazione genera spese in quattro categorie distinte:

Rilevamento e indagine — forensica, contenimento, consulenti esterni
Notifica e risposta — informazione degli interessati, segnalazione al regolatore, monitoraggio del credito
Sanzioni regolatorie — multe GDPR fino al 4 % del fatturato globale, sanzioni penali nLPD fino a CHF 250'000 sulle persone responsabili
Perdita di business e reputazione — abbandono, accordi ritardati, ricostruzione della fiducia

Ecco la parte cruciale: sia sotto GDPR sia sotto la nLPD svizzera, se i dati compromessi sono stati resi incomprensibili per qualsiasi parte non autorizzata — cioè crittografati end-to-end con chiavi protette — la notifica individuale potrebbe non essere richiesta, e le autorità tipicamente considerano l'incidente come materialmente meno grave. Questa sola distinzione può trasformare una violazione da una catastrofe a nove cifre a un incidente interno contenuto.

GDPR Art. 34(3)(a) e nLPD Art. 24

Entrambe le normative citano esplicitamente la crittografia che rende i dati incomprensibili come fattore che può eliminare l'obbligo di notifica individuale in caso di violazione. La crittografia a riposo non soddisfa questo test se il server è stato compromesso insieme alle sue chiavi — la crittografia end-to-end sì.

Com'erano davvero le violazioni recenti

Senza nominare incidenti specifici — la maggior parte sono storie in corso con sensibilità legali — ecco lo schema che ricorre in quasi tutte le grandi violazioni dell'ultimo decennio:

Compromissione iniziale

Un aggressore ottiene credenziali valide (phishing, furto di token, compromissione della supply chain) o sfrutta una vulnerabilità applicativa.

Escalation dei privilegi

Si sposta lateralmente verso un account di servizio con accesso in lettura al database — lo stesso account che l'applicazione usa legittimamente.

Esfiltrazione dei dati

Interroga il database. Ogni riga viene letta in chiaro, perché l'applicazione ne ha bisogno così. La crittografia a riposo è trasparente a questo livello — non fornisce alcun attrito a un aggressore con accesso applicativo valido.

Scoperta (giorni o mesi dopo)

La violazione viene rilevata. Inizia l'indagine. Scattano gli obblighi di notifica. I costi legali, di comunicazione e di rimedio iniziano ad accumularsi.

La lezione silenziosa è che "crittografato a riposo" non ha protetto una singola vittima in questo schema. La crittografia era reale, la certificazione valida, e i dati sono stati comunque esposti. La crittografia end-to-end è il modello che cambia l'esito al passaggio 3: l'aggressore legge il database e ottiene testo cifrato che non può usare.

Quando la crittografia a riposo è comunque la scelta giusta

Questo articolo non sostiene che la crittografia a riposo sia inutile. Ha un ruolo legittimo e importante — semplicemente non quello che la maggior parte delle pagine marketing le assegna.

Dati operativi che il servizio stesso deve leggere in continuazione — indici di ricerca, analitica aggregata, metriche operative
Sistemi in cui il server è il lettore previsto — CRM in cui il personale interroga legittimamente i dati, inventario e-commerce, infrastruttura di logging
Conformità a requisiti di base come le clausole PCI DSS a riposo, o la specifica "addressable" di HIPAA, dove chiavi lato server sono accettabili
Difesa dal furto fisico dell'hardware — un vettore di attacco legittimo, seppur più raro

La domanda chiave è: il server deve leggere questi dati per fare il suo lavoro? Se sì, la crittografia a riposo è appropriata e l'end-to-end è impossibile. Se no — come avviene per la maggior parte delle risposte ai moduli, messaggi sicuri, file privati e record sensibili — l'end-to-end è il modello da chiedere.

Sette domande da porre a qualsiasi fornitore che dichiari "crittografia"

Il modo più rapido per tagliare il testo di marketing è fare domande tecniche specifiche. Un fornitore onesto risponderà direttamente; una risposta evasiva è essa stessa un'informazione.

Dove, fisicamente e logicamente, esistono i miei dati in chiaro in qualsiasi momento?
Quali dei vostri processi o dipendenti possono decifrare i miei dati se lo scelgono?
Se riceveste domani un mandato legale per i miei dati, cosa potreste consegnare?
In caso di violazione del server, i dati rubati sarebbero leggibili dall'aggressore?
Avete la capacità tecnica di resettare o recuperare i miei dati se perdo le credenziali?
Chi controlla le chiavi di crittografia, e dove sono archiviate?
Posso verificare le vostre dichiarazioni tramite audit indipendenti, codice open-source o comportamento di rete osservabile?

Se la risposta alla domanda 5 è "sì, possiamo recuperare i vostri dati", allora per definizione il fornitore detiene chiavi e il sistema non è crittografato end-to-end. Non è intrinsecamente male — significa solo che dovreste valutarlo come sistema basato sulla fiducia, non come sistema a conoscenza zero.

Dove si posiziona Schweizerform

Schweizerform è stato costruito per essere crittografato end-to-end di default. Ecco come risponderemmo onestamente alle sette domande sopra:

Il vostro testo in chiaro esiste in due luoghi: il browser del rispondente al momento dell'invio e il vostro browser quando visualizzate la risposta. Non esiste mai sui nostri server.
Nessuno dei nostri processi o dipendenti può decifrare i vostri dati — non deteniamo le chiavi.
Un mandato legale produrrebbe testo cifrato, materiale di incapsulamento delle chiavi cifrato e metadati. Nessuna risposta in chiaro.
Una violazione del server esporrebbe testo cifrato. Nessun aggressore in quello scenario può leggere le risposte.
Non possiamo recuperare i vostri dati se perdete il Codice di Accesso — è una proprietà deliberata, non un limite che abbiamo trascurato. Il recupero richiede il flusso di chiave di recupero configurato in anticipo.
Le chiavi sono controllate da voi. La chiave privata RSA del modulo è crittografata con una chiave derivata dal vostro Codice di Accesso, e quel codice non raggiunge mai i nostri server.
Potete verificare il payload cifrato nei devtools del browser — la scheda di rete di qualsiasi risposta mostra solo testo cifrato.

La conclusione

La crittografia a riposo e la crittografia end-to-end non sono due punti sullo stesso spettro. Sono due risposte diverse a due domande diverse. La prima è una commodity che quasi ogni SaaS fornisce; la seconda è una scelta architetturale deliberata che modifica significativamente l'esito di una violazione.

Per la maggior parte dei sistemi operativi, la crittografia a riposo basta. Per i moduli che raccolgono dati sensibili — medici, legali, finanziari, HR, whistleblower — non basta. In quei domini, la differenza tra i due modelli può davvero essere contata in milioni: in multe evitate, notifiche non richieste e fiducia non perduta.

Schweizerform offre crittografia end-to-end di default su ogni piano, incluso quello gratuito — con hosting svizzero e architettura allineata alla nLPD dal primo giorno.

Avvertenza: Questo articolo è informazione generale, non consulenza legale, regolatoria o di conformità. I quadri giuridici (GDPR, nLPD, HIPAA, PCI DSS) sono riassunti a livello concettuale; esenzioni e obblighi sulle violazioni dipendono dai fatti specifici e dall'interpretazione giurisdizionale. I dati di costo citati sono medie di settore, non stime della vostra esposizione specifica. Per decisioni che riguardano dati sensibili o regolamentati, consultate un professionista qualificato in ambito legale o di conformità nella vostra giurisdizione.