--- term: 'Crittografia dei dati a riposo e in transito' seoTitle: 'Crittografia a riposo vs. in transito: TLS, AES-256, chiavi' headline: 'Che cos''è la crittografia dei dati a riposo e in transito?' slug: crittografia-dei-dati category: auth-security shortDefinition: 'La crittografia a riposo è un controllo che rende illeggibili senza chiavi i dati archiviati; quella in transito protegge i dati che attraversano le reti.' relatedTerms: - data-layer-vs-application-layer-security - row-level-security - api-key-security - tenant-isolation contrastsWith: - data-layer-vs-application-layer-security aboutTerms: - 'Encryption at Rest' - 'Encryption in Transit' - 'TLS' - 'Key Management' faq: - question: 'Che cos''è la crittografia a riposo?' answer: 'Cifrare i dati archiviati – dischi, database, backup, archiviazione a oggetti – perché chiunque ottenga il supporto di archiviazione senza le chiavi si ritrovi con testo cifrato. Lo standard è AES-256; la protezione riguarda l''hardware rubato, i backup trapelati e i livelli di archiviazione violati.' - question: 'Che cos''è la crittografia in transito?' answer: 'Cifrare i dati mentre attraversano le reti, perché il traffico intercettato risulti illeggibile – è il compito di TLS, ossia quello che porta la S di HTTPS. Protegge dalle intercettazioni e dagli attacchi man-in-the-middle su qualunque hop tra client e server.' - question: 'Qual è la differenza tra crittografia a riposo e in transito?' answer: 'Stati dei dati diversi, minacce diverse. Quella a riposo difende le copie archiviate dal furto dei supporti e dei backup; quella in transito difende i dati in movimento dalle intercettazioni. Sono complementari, non alternative – ogni framework di sicurezza serio pretende entrambe, perché ciascuna ferma attacchi che l''altra non vede.' - question: 'HTTPS e TLS sono la stessa cosa?' answer: 'HTTPS è HTTP trasportato su TLS, il protocollo crittografico che mette in sicurezza la connessione. TLS 1.3 è la versione attuale – handshake più rapidi, cifrari deboli rimossi, forward secrecy obbligatoria; le versioni 1.0 e 1.1 sono formalmente deprecate e vanno disattivate.' - question: 'Che cos''è AES-256?' answer: 'L''Advanced Encryption Standard con una chiave da 256 bit – un cifrario simmetrico a blocchi standardizzato dal NIST, di fatto immune alla forza bruta e la scelta de facto per i dati a riposo. In pratica conviene una modalità autenticata come AES-GCM, che oltre a nascondere il contenuto rileva le manomissioni.' - question: 'Qual è la differenza tra crittografia simmetrica e asimmetrica?' answer: 'La simmetrica usa una sola chiave condivisa in entrambe le direzioni – veloce, adatta ai grandi volumi di dati (AES). L''asimmetrica usa una coppia di chiavi pubblica/privata – più lenta, adatta allo scambio di chiavi, ai certificati e alle firme. TLS usa entrambe: un handshake asimmetrico concorda una chiave di sessione simmetrica che cifra il traffico vero e proprio.' - question: 'In che cosa la crittografia end-to-end differisce da quella in transito?' answer: 'Nel perimetro di fiducia. TLS protegge ogni hop, ma il server decifra e può leggere tutto. La crittografia end-to-end significa che solo gli utenti che comunicano detengono le chiavi – nemmeno l''operatore del servizio può leggere i contenuti. L''E2EE protegge dal server; TLS protegge il percorso che ci porta.' - question: 'La crittografia a riposo protegge dagli attacchi informatici?' answer: 'Solo da una categoria precisa: chi mette le mani sull''archiviazione – dischi rubati, backup trapelati, bucket mal configurati. Un attaccante che compromette l''applicazione o ruba credenziali legge i dati senza ostacoli, perché l''app li decifra legittimamente. La crittografia non è controllo degli accessi; completa le ACL, non le sostituisce mai.' codeLanguages: [javascript, dart, swift, kotlin] externalAuthorities: - name: 'NIST FIPS 197 — Advanced Encryption Standard (AES)' url: 'https://csrc.nist.gov/pubs/fips/197/final' - name: 'RFC 8446 — TLS 1.3' url: 'https://datatracker.ietf.org/doc/html/rfc8446' - name: 'NIST SP 800-57 — Key Management Recommendations' url: 'https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final' - name: 'OWASP Cryptographic Storage Cheat Sheet' url: 'https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html' - name: 'Encryption — Wikipedia' url: 'https://en.wikipedia.org/wiki/Encryption' cta: title: 'Cifrato di serie, da un capo all''altro dello stack' text: 'Back4app serve ogni API, file e Live Query su TLS e archivia dati e backup cifrati – ti resta la policy: password solo sottoposte ad hash (già integrato), crittografia a livello di campo per ciò che è davvero sensibile e ACL per l''accesso.' linkText: 'Inizia gratis' linkUrl: 'https://www.back4app.com/signup' author: 'Back4app Engineering' publishedDate: '2026-10-14' translationKey: data-encryption-at-rest-transit --- **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](https://csrc.nist.gov/pubs/fips/197/final) 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 | Domanda | Risposta | | --- | --- | | A riposo | AES-256 su dischi, database, backup – contro i supporti rubati | | In transito | TLS 1.2+ su ogni connessione – contro intercettazioni e MITM | | Il punto cieco | Nessuna delle due ferma un'app compromessa – la crittografia non è controllo degli accessi | | Il problema vero | La gestione delle chiavi – chiavi conservate accanto ai dati sono teatro | | La confusione da mandare in pensione | Le password si sottopongono a *hashing* (bcrypt/argon2), mai a crittografia | ## Le due protezioni – e che cosa ferma davvero ciascuna La tabella dell'onestà che le pagine in classifica omettono – colonna più importante inclusa: ```text 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:** ```javascript // 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 // Flutter / Dart — Back4app Flutter SDK // Every SDK call rides TLS — and passwords are HASHED, never stored readable final user = ParseUser('ada', secret, 'ada@example.com'); 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 ``` **Swift:** ```swift // 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 ``` **Kotlin:** ```kotlin // 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](https://datatracker.ietf.org/doc/html/rfc8446) 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: | Livello | Come | Sconfigge | Non tocca | | --- | --- | --- | --- | | Disco intero (LUKS/dm-crypt) | L'OS cifra il volume | Hardware rubato o dismesso | Chiunque si trovi sul sistema in esecuzione | | Trasparente (TDE) | Il database cifra i file in scrittura | File di dati e backup rubati | Chiunque abbia le credenziali del database | | A livello di campo/colonna | Colonne specifiche cifrate, le chiavi stanno nell'app | DBA curiosi, violazioni più ampie del DB | La compromissione dell'app stessa | | A livello applicativo | Cifrato *prima* di raggiungere l'archiviazione | Tutto ciò che sta sotto l'app | L'app e il suo key store | ```mermaid flowchart LR accTitle: L'envelope encryption (cifratura a busta) tiene le chiavi separate dai dati accDescr: I dati dell'applicazione sono cifrati con una chiave dati. La chiave dati è a sua volta cifrata da una chiave di cifratura delle chiavi custodita in un servizio di gestione delle chiavi o in un modulo hardware di sicurezza, così un database rubato contiene testo cifrato e chiavi avvolte ma nulla che decifri senza il servizio di chiavi protetto separatamente. D["Dati"] -->|"AES-256-GCM"| C["Testo cifrato
nel database"] DEK["Chiave dati (DEK)"] -->|"cifra"| D KEK["Chiave di cifratura delle chiavi (KEK)"] -->|"avvolge"| DEK KMS["Servizio di chiavi / HSM
sistema separato, verificato"] -->|"custodisce"| KEK T["Ladro con il database in mano"] -.->|"ottiene testo cifrato +
chiavi avvolte – nulla si apre"| C ``` 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 | | Crittografia | Hashing | | --- | --- | --- | | Reversibile | Sì – con la chiave | No – per progetto | | Adatto a | Dati che vanno riletti | Password, controlli di integrità | | Standard | AES-256-GCM | bcrypt, scrypt, argon2 (lenti + con salt) | | Il fallimento | Perdere le chiavi o farle trapelare | Hash veloci e senza salt (MD5, SHA-256 semplice) | 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 | Situazione | A cui ricorrere | | --- | --- | | Qualunque dato, qualunque app | TLS su tutto + crittografia a riposo della piattaforma – il pavimento | | Incubo del backup rubato | Backup cifrati + chiavi conservate altrove | | Colonne sensibili (sanità, documenti) | Crittografia a livello di campo o applicativo, chiavi in variabili d'ambiente o in un KMS | | "Non dovremmo poterlo leggere nemmeno noi" | Crittografia end-to-end – accettandone i costi di prodotto | | Password | Hashing (bcrypt/argon2) – mai crittografia | | Problemi di accesso, non di furto | [ACL e sicurezza a livello di riga](/glossary/it/sicurezza-a-livello-di-riga-rls/) – la crittografia non aiuta | ## Limiti e trade-off - **La crittografia non è controllo degli accessi.** Il punto della [sicurezza a livelli](/glossary/it/sicurezza-dati-vs-applicazione/) 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](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final) 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](/glossary/it/sicurezza-delle-chiavi-api/) applicata ai dati. Poi il pezzo che la crittografia non può fare: [le ACL e i permessi di classe](/glossary/it/liste-di-controllo-degli-accessi-acl/) governano chi legge che cosa, perché il controllo che ferma un attaccante munito di credenziali non è mai stata la crittografia, ma l'autorizzazione.