Crittografia a riposo vs in transito: entrambe contano

La crittografia in transito protegge i dati che si spostano tra due punti — il tuo browser e un server, per esempio — usando TLS 1.3 con AES-256-GCM o ChaCha20-Poly1305. La crittografia a riposo protegge i dati memorizzati su disco, tipicamente con AES-256-XTS per la cifratura completa del disco o AES-256-GCM per i singoli file. Nessuna delle due da sola è sufficiente. TLS protegge dalla sorveglianza di rete ma decifra sul server; la crittografia a riposo protegge i dati memorizzati ma è inutile se le chiavi vivono accanto al testo cifrato. La vera sicurezza nasce dalla sovrapposizione di entrambe, idealmente insieme alla crittografia lato client (end-to-end) affinché il server non veda mai il testo in chiaro.

Due minacce diverse, due controlli diversi

Le minacce si presentano in modo diverso a seconda di dove si trovano i tuoi dati:

In transito (percorso di rete): un aggressore in un bar che usa un packet sniffer, un router ISP compromesso, un'intercettazione statale dei cavi sottomarini. I documenti Snowden del 2013 hanno rivelato il programma MUSCULAR della NSA che intercettava i link in fibra interni di Google. Difesa: TLS 1.3, preferibilmente con certificate pinning per le app.

A riposo (archiviazione): un laptop rubato, un nastro di backup perso, un bucket S3 mal configurato, un dipendente del datacenter con accesso ai dischi. La violazione Equifax del 2017 ha esposto 147 milioni di record in parte perché i dati erano memorizzati non cifrati. Difesa: LUKS, BitLocker, FileVault per i dischi; AES-256-GCM o AES-256-XTS per file o blocchi.

L'errore è trattare l'uno come sostituto dell'altro. TLS non protegge un dump del database. La cifratura del disco non ferma un attacco man-in-the-middle.

Come TLS 1.3 protegge i dati in transito

TLS 1.3, standardizzato nell'RFC 8446 (2018), è il default moderno. Usa:

• Forward secrecy di default tramite scambio di chiavi ECDHE effimero. Anche se la chiave a lungo termine del server viene compromessa, le sessioni passate rimangono protette.
• Solo cifrari AEAD — AES-128-GCM, AES-256-GCM, o ChaCha20-Poly1305. Le vecchie modalità CBC e RC4 sono eliminate.
• Handshake in un solo round trip (1-RTT), o zero round trip (0-RTT) per la ripresa.
• Handshake cifrato in modo che gli osservatori passivi non possano vedere la catena di certificati.

Ogni servizio di trasferimento file affidabile — WeTransfer, SwissTransfer, Tresorit, Proton Drive, HexaTransfer — usa TLS 1.3 con intestazioni HSTS che impongono HTTPS per almeno 12 mesi. Puoi verificarlo con lo strumento testssl di SSL Labs; qualsiasi punteggio inferiore ad A- indica problemi di configurazione.

Come funziona la crittografia a riposo sul server

Una volta che i file arrivano e TLS termina, entra in gioco la crittografia a riposo. Ci sono diversi livelli:

• A livello di blocco (disco completo): AES-256-XTS su LUKS (Linux), BitLocker (Windows), FileVault (macOS), o equivalenti cloud come la cifratura AWS EBS. Protegge contro i dischi rubati.
• A livello di filesystem: eCryptfs, Fscrypt su ext4/F2FS. I file di ogni utente sono cifrati con chiavi separate.
• A livello di object storage: AWS S3 SSE-KMS, Azure Blob con Storage Service Encryption, Google Cloud Storage con chiavi gestite dal cliente. Ogni oggetto viene cifrato con AES-256-GCM.
• A livello applicativo: il servizio cifra ogni file nel proprio codice prima di scrivere sullo storage, con chiavi detenute in un KMS o HSM.

Il livello applicativo è il più robusto perché la cifratura avviene prima che qualsiasi sistema di storage veda i dati. AWS KMS costa $1/chiave/mese più $0,03 per 10.000 richieste — abbastanza economico che i servizi seri lo usano per file.

La trappola delle "chiavi accanto al testo cifrato"

Ecco dove la crittografia a riposo spesso fallisce. Se le chiavi sono memorizzate sullo stesso server del testo cifrato, un aggressore che viola il server ottiene entrambi. Il fornitore può tecnicamente spuntare la casella "cifrato a riposo" per la conformità offrendo zero protezione reale contro una compromissione del server.

Le buone architetture separano le responsabilità:

• Testo cifrato su S3 o object storage equivalente.
• Chiavi di cifratura in AWS KMS, Google Cloud KMS, Azure Key Vault, o un HSM dedicato.
• Accesso alle chiavi controllato da credenziali IAM a breve termine e log di audit.

Le architetture eccellenti vanno oltre: le chiavi non esistono mai sul server. La crittografia lato client (E2EE) significa che il browser dell'utente genera la chiave, cifra il file e conserva la chiave. Il server memorizza il testo cifrato e non ha nulla da divulgare.

Dove appaiono le lacune di cifratura

Anche con entrambi i controlli attivi, i dati sono brevemente in chiaro in diversi punti:

• In memoria del server durante l'elaborazione dell'upload, la scansione antivirus, o la generazione di miniature. Un dump della memoria durante questa finestra rivela il testo in chiaro.
• Nei log di accesso se i nomi dei file o frammenti di contenuto vengono registrati per il debugging.
• Nei nastri di backup se i backup non ereditano la stessa cifratura.
• Durante la compressione o la transcodifica dove il servizio elabora il contenuto del file.
• Nella cache del browser dopo il download se l'utente non la svuota.

Queste lacune sono il motivo per cui la crittografia zero-knowledge (lato client) è importante. Quando i file vengono cifrati nel browser prima dell'upload, le lacune lato server diventano irrilevanti — il server vede solo testo cifrato.

Cosa fanno davvero i grandi servizi

Una classificazione approssimativa basata sulla documentazione pubblica:

• Google Drive, Dropbox, OneDrive: TLS 1.3 in transito, AES-256 a riposo con chiavi detenute dal fornitore. Non zero-knowledge — il fornitore può leggere i tuoi file.
• WeTransfer (livello gratuito): TLS 1.3, AES-256 a riposo su AWS S3. Le chiavi le tiene il fornitore.
• Box Enterprise: TLS 1.3, AES-256-GCM a riposo, chiavi gestite dal cliente opzionali (Box KeySafe).
• Tresorit, Proton Drive, SwissTransfer livello E2EE, HexaTransfer: TLS 1.3 in transito, AES-256-GCM a riposo, ma le chiavi per file sono generate lato client e non raggiungono mai il server. Effettivamente zero-knowledge.

Per i dati sensibili, solo l'ultima categoria fornisce una protezione significativa contro le minacce interne e le richieste legali valide.

Conformità e il requisito di difesa in profondità

I regolatori richiedono esplicitamente entrambe:

• GDPR Articolo 32 impone "pseudonimizzazione e cifratura dei dati personali" senza restrizioni sullo stato dei dati.
• HIPAA Security Rule 45 CFR § 164.312(a)(2)(iv) e (e)(2)(ii) richiede la cifratura per i dati ePHI sia in transito che a riposo.
• PCI DSS 4.0 Requisiti 3 e 4 separa "proteggere i dati del titolare della carta memorizzati" (a riposo) da "proteggere i dati del titolare della carta con crittografia robusta durante la trasmissione" (in transito).
• FIPS 140-3 la validazione si applica ai moduli crittografici usati in entrambi i contesti.

Fornire solo uno dei due è una violazione della conformità ancor prima di diventare un fallimento della sicurezza.

Come verificare che entrambi siano attivi

Cinque controlli rapidi per qualsiasi servizio di trasferimento file:

1. Esegui testssl.sh https://provider.com per confermare TLS 1.3 con soli cifrari robusti.
2. Controlla le intestazioni HSTS con max-age di almeno 31.536.000 (un anno).
3. Leggi il white paper di sicurezza per la menzione esplicita di AES-256-GCM o AES-256-XTS a riposo.
4. Conferma che le chiavi siano detenute in un KMS o HSM, non nel database dell'applicazione.
5. Cerca la certificazione SOC 2 Type II o ISO 27001 — entrambe richiedono controlli documentati a riposo e in transito.

Bonus: verifica se la crittografia lato client è disponibile come opzione. Se sì, attivala per tutto ciò che è sensibile.

Come stratificarle correttamente

Lo schema che funziona davvero:

1. Il browser cifra il file con una chiave AES-256-GCM casuale (lato client).
2. Il testo cifrato viaggia su TLS 1.3 verso il server (in transito).
3. Il server memorizza il testo cifrato su storage cifrato AES-256 (a riposo).
4. La chiave di decrittazione vive solo nel frammento URL di condivisione, mai inviata al server.

Tre layer indipendenti. Se uno si rompe, gli altri tengono. Questo è il design che usa HexaTransfer, insieme a Tresorit Send, i link condivisi di Proton Drive e la modalità E2EE di SwissTransfer.

Provalo su hexatransfer.com — gratis, senza registrazione, fino a 10 GB.