Dove conservare le chiavi di crittografia? Guida pratica

Categoria

Sicurezza locale

Pubblicato

Settembre 22, 2026

Tempo di lettura

12 min di lettura

Capire cos’è una chiave di crittografia aiuta a conservarla correttamente. Prima di scegliere dove conservarla, è utile distinguere tra chiave di crittografia o password, perché proteggono l’accesso ai dati in modi diversi. Le chiavi di crittografia dovrebbero essere conservate separatamente dai dati che cifrano, all’interno di un archivio di chiavi protetto quando possibile. Su un dispositivo personale, questo significa in genere usare il portachiavi del sistema operativo, un gestore di credenziali o un keystore protetto dall’hardware e legato alla sicurezza del dispositivo. Nelle applicazioni, la protezione locale nelle app può aggiungere ulteriori controlli oltre alla scelta del luogo di conservazione. In un’organizzazione, significa spesso usare un sistema dedicato di gestione delle chiavi (KMS), un modulo di sicurezza hardware (HSM) o un servizio di gestione dei segreti con rigorosi controlli di accesso. Le chiavi di crittografia non dovrebbero trovarsi in file di testo in chiaro, nel codice sorgente dell’applicazione, nei messaggi in chat, nei fogli di calcolo o accanto ai file cifrati che consentono di decifrare.

Il motivo è semplice: la crittografia è forte quanto la protezione che circonda la sua chiave. Se un attaccante copia sia un archivio cifrato sia il file leggibile che contiene la chiave, la crittografia offre poca protezione pratica. Una buona conservazione delle chiavi rende molto più difficile estrarle, copiarle o usarle impropriamente, anche quando vengono esposti un dispositivo, un backup o la cartella dati di un’applicazione.

Una chiave di crittografia è materiale crittografico segreto usato per cifrare o decifrare dati. Una password può aiutare una persona a sbloccare una chiave, ma password e chiave di crittografia non sono necessariamente la stessa cosa. Le applicazioni moderne generano spesso una chiave casuale per cifrare i dati e poi proteggono quella chiave con un’altra chiave derivata da una password o custodita nell’archivio sicuro del dispositivo.

Questo approccio a livelli si chiama key wrapping oppure crittografia a busta (envelope encryption). Evita di usare un unico segreto facile da gestire per proteggere direttamente tutti i file e consente di ruotare, revocare o proteggere l’accesso alle chiavi con maggiore attenzione.

I dati cifrati possono essere conservati in molti luoghi. La chiave dovrebbe essere custodita in un luogo con controlli di accesso più forti rispetto ai dati stessi.

Non esiste un’unica posizione adatta a ogni sistema di crittografia. La scelta corretta dipende dal fatto che la chiave protegga file su un solo telefono, un database applicativo, un sistema aziendale condiviso o un backup a lungo termine. La regola decisionale resta la stessa: usa l’archivio di chiavi più protetto che sia pratico per il sistema, mantenendo al tempo stesso un percorso di recupero proporzionato al rischio.

Per la crittografia locale dei file, l’archiviazione protetta dal sistema operativo è in genere il punto di partenza appropriato. Alcuni esempi sono il portachiavi del dispositivo, il vault delle credenziali o il keystore della piattaforma. Questi servizi sono progettati per impedire che una normale applicazione, o chi esplora lo spazio di archiviazione del dispositivo, possa leggere un segreto come se fosse un file di testo.

Un’app ben progettata dovrebbe mantenere separati il contenuto cifrato dei file e il materiale delle chiavi conservato localmente. Dovrebbe inoltre richiedere l’autenticazione del dispositivo, come un PIN o la biometria dove supportata, prima di consentire l’uso di chiavi sensibili. È più pratico che chiedere alle persone di gestire ogni giorno file crittografici manualmente, e la privacy non dovrebbe dipendere da un’attenzione costante da esperti.

Per un approfondimento sulla protezione locale, leggi la nostra guida alla crittografia lato dispositivo. Spiega perché cifrare i dati sul dispositivo cambia chi può accedere ai contenuti e dove viene riposta la fiducia.

La conservazione delle chiavi protetta dall’hardware usa un componente del dispositivo dedicato alla sicurezza per generare, custodire o usare una chiave. A seconda della piattaforma e della configurazione, la chiave può non essere esportabile: il software può chiedere all’hardware di svolgere un’operazione crittografica, ma non può recuperare il segreto grezzo. Questo rende più difficile estrarre una chiave da un sistema operativo compromesso o da una cartella dell’applicazione copiata.

La protezione hardware è particolarmente utile per le chiavi che proteggono file locali sensibili, credenziali di autenticazione o la chiave privata usata per sbloccare altre chiavi di crittografia. Non garantisce che un dispositivo non possa essere compromesso. Un malware in esecuzione in una sessione utente sbloccata potrebbe comunque richiedere operazioni consentite, mentre gli attacchi fisici variano in base al dispositivo e alle capacità dell’attaccante. Il vantaggio è che rubare una chiave non è più semplice come copiare un file.

Per questo, la conservazione protetta dall’hardware dovrebbe essere abbinata al blocco dello schermo, ad aggiornamenti di sicurezza tempestivi, alla cifratura del dispositivo e a un piano di recupero. L’hardware è una barriera protettiva, non un sostituto del resto del modello di sicurezza.

• File di testo in chiaro: file chiamati key.txt, secret.key o .env sono facili da copiare, indicizzare, allegare, includere nei backup o condividere accidentalmente.
• Codice sorgente o repository pubblici: una chiave inserita anche una sola volta può restare nella cronologia dei commit, nei log di compilazione, nei fork, nelle cache e sui dispositivi degli sviluppatori anche dopo la rimozione.
• La stessa cartella dei dati cifrati: una singola cartella copiata non dovrebbe contenere sia il lucchetto sia la sua chiave.
• Email, note o chat: questi sistemi creano copie aggiuntive, registri di conservazione, notifiche e rischi legati al recupero degli account.
• Archiviazione locale del browser o preferenze dell’app mobile: questi percorsi sono in genere inadatti a segreti crittografici grezzi e di lungo periodo, salvo siano protetti da un’architettura che usa il keystore della piattaforma.
• Backup non cifrati: un dispositivo attivo protetto non aiuta se la sua chiave grezza viene copiata in un backup non protetto.

Un errore frequente è trattare un file di chiave come un promemoria della password. Una chiave di crittografia grezza concede direttamente l’accesso e va gestita più come una credenziale di alto valore che come un documento. Se una chiave è stata esposta nel controllo versione, nei log o in una cartella condivisa, considerala compromessa, sostituiscila e, quando possibile, cifra nuovamente i dati interessati o applica nuovamente il wrapping delle chiavi.

Questo metodo è una checklist di progettazione illustrativa, non un test di prodotto né una garanzia di sicurezza. Usalo per valutare se un approccio alla conservazione delle chiavi è proporzionato ai file e ai sistemi che protegge.

1. Classifica ciò che la chiave sblocca. Una chiave per dati temporanei e a basso rischio richiede meno protezione di una che sblocca documenti di identità, file dei clienti o un intero archivio cifrato.
2. Separa dati e chiavi. Conserva il contenuto cifrato e la sua chiave grezza in domini di protezione diversi. Non collocare entrambi nella stessa cartella condivisa o nello stesso backup.
3. Preferisci l’uso non esportabile. Quando il dispositivo o il servizio lo supporta, usa una chiave che possa cifrare o decifrare senza essere copiata all’esterno come byte grezzi.
4. Richiedi un’autorizzazione significativa. Associa l’uso di chiavi sensibili a un PIN del dispositivo, a una richiesta biometrica, a un’identità di servizio o a una policy di accesso definita con cura.
5. Pianifica il recupero prima di affidarti alla chiave. Decidi chi può recuperare l’accesso dopo la perdita di un dispositivo, di un account o l’uscita di un dipendente, e assicurati che anche il materiale di recupero sia protetto.
6. Limita e rivedi gli accessi. Elimina le chiavi da log, script e postazioni degli sviluppatori; ruotale dopo una sospetta esposizione o un cambio di ruolo.

Considera uno scenario illustrativo: un freelance cifra una cartella che contiene documenti di identità dei clienti. Salvare una chiave grezza accanto alla cartella è comodo, ma un laptop rubato o un backup copiato possono esporre entrambi. Una progettazione più sicura conserva la chiave di cifratura dei file nel keystore protetto del dispositivo, richiede l’autenticazione del dispositivo per usarla e mantiene una copia di recupero cifrata separata dal laptop. Il compromesso è che il recupero richiede una configurazione consapevole; il vantaggio è che una normale copia dei file non copia automaticamente anche la chiave.

Una protezione robusta delle chiavi può creare un reale problema di disponibilità: se l’unica chiave utilizzabile è legata a un dispositivo perso o danneggiato, i dati cifrati potrebbero non essere recuperabili. Questo risultato può essere desiderabile per informazioni effimere, ma di solito è inaccettabile per documenti che una persona o un’organizzazione deve conservare.

Per i dati personali, il recupero può consistere in un backup cifrato protetto da una passphrase forte e distinta, conservato separatamente. Per i team, può richiedere un processo di recupero approvato, più custodi autorizzati o un KMS con permessi di recupero strettamente controllati, per evitare le conseguenze della perdita di una chiave. Non risolvere il recupero mantenendo una copia non cifrata della chiave nel cloud o nella posta in arrivo: sposteresti soltanto il punto debole.

Il tema delle file encryption keys è esplorato in un articolo dedicato, che spiega la relazione tra un file e la sua chiave quando i file protetti vengono aperti, condivisi o persi.

Quando si condividono file sensibili, la domanda di sicurezza non riguarda solo il fatto che il trasferimento sia cifrato. Riguarda anche se le chiavi locali, l’accesso al dispositivo, i backup e la disponibilità successiva del file vengono gestiti in modo responsabile. Un’app dovrebbe evitare di lasciare chiavi grezze nelle normali cartelle dell’applicazione e usare, quando disponibili, le capacità di archiviazione sicura del dispositivo.

Oblivio è progettata per le situazioni in cui mantenere il controllo sui file sensibili è importante anche dopo l’invio. Protegge i dati locali con una chiave cifrata e collega l’accesso all’app a un PIN e, dove supportata, alla biometria. Il suo approccio più ampio combina gestione locale cifrata e condivisione con cifratura end-to-end, scadenza dell’accesso, revoca e una cronologia operativa principalmente basata sul dispositivo. Questi controlli non eliminano la necessità di proteggere il dispositivo, ma aiutano a rendere la gestione più sicura dei file una scelta normale, anziché un progetto di sicurezza manuale.

Per i file che devono restare privati sul dispositivo, leggi come la crittografia lato dispositivo protegge le foto private. Lo stesso principio vale per scansioni, contratti e altri file che non dovrebbero essere leggibili solo perché è stata copiata una posizione di archiviazione.

• Cerca segreti incorporati nei repository di codice, nelle impostazioni di distribuzione e nelle unità condivise.
• Controlla se i backup cifrati contengono anche file di chiavi leggibili o codici di recupero.
• Assicurati che le chiavi delle applicazioni non siano nella stessa directory delle esportazioni cifrate.
• Attiva il blocco del dispositivo e usa un PIN robusto; la biometria è comoda, ma il PIN resta importante.
• Documenta il recupero dei dati importanti e proteggi separatamente quel metodo di recupero.
• Sostituisci le chiavi che potrebbero essere state copiate in ticket, email, screenshot o cronologie del controllo versione.

Conserva le chiavi di crittografia in sistemi protetti e con accesso controllato, non in file di testo. Sui dispositivi individuali, usa l’archiviazione sicura del sistema operativo e, quando disponibile, la protezione supportata dall’hardware. Per i sistemi di produzione e condivisi, usa un KMS o un HSM con permessi ristretti, audit e procedure di recupero. Tieni le chiavi separate dai dati cifrati e considera il recupero parte della gestione delle chiavi, non un ripensamento successivo.

Se condividi regolarmente documenti che non dovrebbero restare accessibili a tempo indeterminato, Oblivio può aiutarti ad applicare un modello più controllato a destinatari, durata dell’accesso e revoca, senza trattare un normale allegato come scelta predefinita per ogni file sensibile.