Che cos'è la crittografia dei dati a riposo e in transito?

La crittografia a riposo è un controllo che rende illeggibili senza chiavi i dati archiviati; quella in transito protegge i dati che attraversano le reti. I dati vivono in tre stati – a riposo sull’archiviazione, in transito sul filo e in uso in memoria – e i primi due sono l’obbligo di base di qualunque applicazione: AES-256 per ciò che sta fermo, TLS per ciò che si muove. Il terzo stato (protetto dagli ambienti di esecuzione fidati e, alla frontiera, dalla crittografia omomorfica) è reale ma, per la maggior parte dei team applicativi, è il livello di qualcun altro.

Punti chiave

Le due protezioni – e che cosa ferma davvero ciascuna

La tabella dell’onestà che le pagine in classifica omettono – colonna più importante inclusa:

             Standard        Copre                Ferma                     NON ferma
In transito  TLS 1.2+/HTTPS  ogni hop di rete     intercettazioni, MITM,    endpoint compromessi –
                                                  sniffing al bar           il server lo legge senza problemi
A riposo     AES-256 (GCM)   dischi, DB, backup   dischi rubati, backup     credenziali rubate,
                                                  trapelati, bucket aperti  SQL injection, bug applicativi
In uso       TEE             RAM in elaborazione  lettura della memoria     – in gran parte una questione di piattaforma

Nessuna delle due ferma un attaccante di cui l'app stessa si fida. L'app detiene le
chiavi e decifra a richiesta – la crittografia completa il controllo degli accessi, non lo sostituisce.

Come si presentano le impostazioni predefinite dal codice applicativo:

// JavaScript / Node.js — Back4app JS SDK
// Every SDK call rides TLS — and passwords are HASHED, never stored readable
const user = new Parse.User();
await user.signUp({ username: 'ada', password: secret });
// On the wire: TLS 1.2+ (the https serverURL is the whole config)
// At rest: bcrypt hash — even the database never holds the password itself

// Extra-sensitive fields: encrypt server-side in a Cloud Code beforeSave
// so plaintext never reaches storage — AES-256-GCM, key in env, not in code

// Flutter / Dart — Back4app Flutter SDK
// Every SDK call rides TLS — and passwords are HASHED, never stored readable
final user = ParseUser('ada', secret, '[email protected]');
await user.signUp();
// On the wire: TLS 1.2+ (the https server URL is the whole config)
// At rest: bcrypt hash — even the database never holds the password itself

// Extra-sensitive fields: encrypt server-side in a Cloud Code beforeSave
// so plaintext never reaches storage — AES-256-GCM, key in env, not in code

// iOS / Swift — Back4app Swift SDK
// Every SDK call rides TLS — and passwords are HASHED, never stored readable
var user = User()
user.username = "ada"
user.password = secret
let signedUp = try await user.signup()
// On the wire: TLS 1.2+ (the https server URL is the whole config)
// At rest: bcrypt hash — even the database never holds the password itself

// Extra-sensitive fields: encrypt server-side in a Cloud Code beforeSave
// so plaintext never reaches storage — AES-256-GCM, key in env, not in code

// Android / Kotlin — Back4app Android SDK
// Every SDK call rides TLS — and passwords are HASHED, never stored readable
val user = ParseUser()
user.username = "ada"
user.setPassword(secret)
user.signUp()
// On the wire: TLS 1.2+ (the https server URL is the whole config)
// At rest: bcrypt hash — even the database never holds the password itself

// Extra-sensitive fields: encrypt server-side in a Cloud Code beforeSave
// so plaintext never reaches storage — AES-256-GCM, key in env, not in code

Come funziona TLS, in un paragrafo

Il trucco elegante: la crittografia asimmetrica è lenta ma non richiede alcun segreto condiviso; quella simmetrica è veloce ma ne richiede uno. Così l’handshake TLS usa la prima per stabilire la seconda – il client verifica il certificato del server (il controllo d’identità che rende rilevabile l’intercettazione), le due parti concordano una nuova chiave di sessione tramite scambio asimmetrico, e tutto ciò che segue viaggia su crittografia simmetrica veloce. TLS 1.3 ha stretto ogni vite: un round trip invece di due, cifrari legacy e scambio di chiavi RSA rimossi, forward secrecy obbligatoria – così il traffico registrato non si può decifrare più tardi nemmeno se la chiave di lunga durata del server trapela. Appendice mobile che i risultati di ricerca saltano: le app possono inoltre fare pinning dei certificati attesi, scambiando la resilienza contro autorità di certificazione canaglia con una maggiore cura operativa al momento della rotazione.

I livelli a riposo: disco vs. database vs. campo vs. applicazione

“Cifrato a riposo” copre quattro promesse molto diverse, ognuna delle quali sconfigge un attaccante diverso:

La regola che vale per tutta la tabella: i livelli più alti proteggono da più cose e costano di più. La crittografia a livello di campo è il compromesso onesto – le colonne cifrate non si possono indicizzare né cercare normalmente (la crittografia deterministica restituisce le ricerche per uguaglianza, a un certo costo in informazione che trapela) – ed è per questo che resta riservata a ciò che è davvero sensibile: dati sanitari, documenti d’identità, segreti. Ed è qui che vive il classico fallimento da audit: il database cifrato i cui backup partono in chiaro.

La crittografia end-to-end è una promessa diversa

TLS su tutto significa comunque che il server legge tutto: decifra ogni connessione per progetto. La crittografia end-to-end sposta le chiavi sugli utenti: solo mittente e destinatario possono decifrare, e l’operatore serve testo cifrato che non è in grado di aprire. È una decisione di prodotto diversa, non un’impostazione più forte: l’E2EE significa nessuna ricerca lato server, nessuna moderazione dei contenuti, nessun recupero se gli utenti perdono le chiavi. I modelli di minaccia si incastrano con ordine – TLS difende il percorso, la crittografia a riposo difende l’archiviazione, l’E2EE difende dal servizio stesso – e la maggior parte delle applicazioni si ferma correttamente ai primi due, mentre i prodotti di messaggistica e i gestori di segreti giustificano il terzo.

Hashing vs. crittografia

Un richiamo manda in pensione una confusione diffusa: le password si sottopongono a hashing, mai a crittografia. Nessuno – server incluso – dovrebbe poter recuperare una password; l’accesso confronta hash. Cifrare le password significa che esiste una chiave capace di decifrarle tutte, che è esattamente la catastrofe che l’hashing esiste per escludere.

Casi d’uso tipici

• Ogni app web e mobile – TLS su tutte le connessioni e archiviazione cifrata sono il minimo per sedersi al tavolo, non delle feature.
• Dati regolamentati – il GDPR nomina la crittografia tra le misure tecniche appropriate (con un alleggerimento sull’obbligo di notifica delle violazioni), le norme sanitarie la impongono per i dati dei pazienti e gli standard dei pagamenti richiedono numeri di carta illeggibili a riposo e crittografia robusta in transito.
• Backup e dismissione – backup cifrati e crypto-shredding (distrutta la chiave, i dati muoiono in ogni copia) chiudono il capitolo della copia rubata.
• Protezione dei campi con dati personali – crittografia a livello applicativo per le colonne la cui fuga è un titolo di giornale, non un incidente.
• Client mobile su reti ostili – TLS più validazione del certificato come difesa che viaggia con l’utente.

Quale livello serve? Matrice decisionale

Limiti e trade-off

• La crittografia non è controllo degli accessi. Il punto della sicurezza a livelli in una riga: la crittografia a riposo è trasparente per l’app in esecuzione, quindi i permessi – ACL, CLP, policy di riga – restano la difesa contro ogni attaccante munito di credenziali.
• La gestione delle chiavi è il progetto vero. Le indicazioni del NIST esistono perché generazione, separazione, rotazione e revoca – non la scelta dell’algoritmo – sono il punto in cui i deployment cedono.
• La crittografia a livello di campo combatte contro il database. Nessun indice, nessuna query LIKE, migrazioni delicate; conviene cifrare i campi che ne hanno bisogno, non lo schema.
• TLS finisce al terminatore. Proxy e load balancer che decifrano a metà percorso ricreano hop in chiaro; il traffico interno richiede la stessa disciplina del bordo.
• Conformità ≠ sicurezza. Una crittografia a casella spuntata, con le chiavi accanto ai dati, soddisfa gli auditor e nessun altro; la colonna del modello di minaccia è quella su cui progettare.

Crittografia su Back4app

Back4app è una piattaforma open-source di Backend as a Service (BaaS) che combina database gestito, API REST e GraphQL generate automaticamente, autenticazione, archiviazione di file e funzioni serverless con Cloud Code. Il pavimento lo fornisce la piattaforma: ogni connessione REST, GraphQL e Live Query viaggia su TLS, e dati e backup sono cifrati a riposo – i due livelli di base arrivano come impostazioni predefinite invece che come progetti. La quota che resta a chi sviluppa è esattamente quella che abbozzano le schede di codice: le password passano per l’hash bcrypt di Back4app di serie (mai archiviate, mai recuperabili – la regola dell’hashing imposta per struttura); i campi davvero sensibili ricevono una crittografia a livello applicativo in un beforeSave di Cloud Code, con la chiave nella configurazione lato server invece che nel codice, così il testo in chiaro non raggiunge mai l’archiviazione; e i segreti restano fuori da log, URL e bundle client – la disciplina delle chiavi API applicata ai dati. Poi il pezzo che la crittografia non può fare: le ACL e i permessi di classe governano chi legge che cosa, perché il controllo che ferma un attaccante munito di credenziali non è mai stata la crittografia, ma l’autorizzazione.