Gestione delle chiavi di crittografia: best practices 2026
Padroneggia la gestione delle chiavi di crittografia con best practices comprovate per generazione, archiviazione, rotazione e ciclo di vita delle chiavi nel 2026.
La gestione delle chiavi nel 2026 significa generare le chiavi con un CSPRNG (non /dev/urandom su VM con bassa entropia, usa getrandom() o BCryptGenRandom), archiviarle nell'hardware (AWS KMS, YubiHSM 2, Thales Luna, Secure Enclave), ruotarle su una pianificazione che corrisponde all'esposizione alle minacce (90 giorni per le chiavi di crittografia attive, annualmente per le KEK), e distruggerle con cancellazione crittografica o distruzione fisica. NIST SP 800-57 Part 1 Rev 5 copre il ciclo di vita; FIPS 140-3 certifica i moduli; PCI DSS 4.0 Requisito 3.6 audita il processo. Fai bene queste cose e la crittografia stessa (AES-256-GCM, X25519) conta quasi nulla.
Generare chiavi di cui fidarsi
La generazione delle chiavi è il punto di guasto silenzioso della crittografia. Il CVE OpenSSL specifico di Debian nel 2006-2008 (patch RNG specifica di Debian) ha reso prevedibile ogni chiave SSH generata sui sistemi interessati. Più di recente, Fortinet ha distribuito router nel 2021 con chiavi derivate da fonti di entropia bassa al momento dell'avvio. La generazione sicura usa il CSPRNG del sistema operativo — getrandom() su Linux 3.17+, BCryptGenRandom su Windows, SecRandomCopyBytes su macOS/iOS — o un RNG hardware in un HSM. crypto.getRandomValues() della Web Crypto API si ricollega alla sorgente del sistema operativo. Non implementare mai il tuo RNG, non fare mai seeding da time() o PID, e verifica all'avvio della VM che il pool sia stato seminato (controlla /proc/sys/kernel/random/entropy_avail > 256).
Struttura gerarchica delle chiavi: KEK, DEK e chiavi di sessione
I sistemi reali usano chiavi a strati. Una Data Encryption Key (DEK) cifra i dati effettivi con AES-256-GCM. Una Key Encryption Key (KEK) cifra le DEK, archiviata in un HSM. Una KEK radice (a volte una chiave master) cifra le KEK, detenuta in hardware resistente alle manomissioni. Ruotare la DEK ri-cifra i dati; ruotare la KEK ri-avvolge le DEK (veloce); ruotare la radice è un'operazione importante. Questo pattern a busta ti consente di ruotare frequentemente agli strati che possono, senza decrittografare petabyte. AWS KMS, Google Cloud KMS e HashiCorp Vault implementano tutti questo. Per i servizi di trasferimento file, la chiave AES per trasferimento è una DEK; la KEK derivata dalla password (tramite PBKDF2 o Argon2id) la avvolge.
Archiviazione: HSM, KMS e cosa è davvero diverso
Un Hardware Security Module è un box resistente alle manomissioni che genera, archivia e usa le chiavi senza mai esportarle. I dispositivi FIPS 140-3 Livello 3 (Thales Luna 7, AWS CloudHSM, YubiHSM 2) rilevano la manomissione fisica e azzerano. Un Key Management Service (AWS KMS, Google Cloud KMS, Azure Key Vault) è software che gira su HSM, accessibile tramite API. Per la maggior parte delle applicazioni, KMS è sufficiente — paghi 1$/mese per chiave, chiami Encrypt/Decrypt su HTTPS, e AWS gestisce l'operazione HSM. L'HSM diretto è necessario quando i regolatori lo richiedono (PCI DSS 4.0 Requisito 3.6.1.1 per l'emissione di carte) o quando non puoi fidarti della giurisdizione legale del cloud provider.
Pianificazioni di rotazione che corrispondono al rischio
NIST SP 800-57 definisce i criptoperiodi — il tempo in cui una chiave rimane attiva. Per le chiavi di dati simmetriche che cifrano attivamente nuovi dati, massimo 1-2 anni. Per le chiavi che decrittografano solo i dati esistenti, 3-5 anni. Per le KEK radice, 5-10 anni. PCI DSS Requisito 3.7.4 impone la definizione del criptoperiodo. In pratica, automatizza la rotazione: la rotazione automatica di AWS KMS è annuale; Google KMS è configurabile. Per i servizi di trasferimento file dove ogni upload riceve una chiave casuale fresca, la rotazione non si applica alle chiavi di dati (sono monouso) ma si applica ai certificati TLS (90 giorni tramite Let's Encrypt), alle chiavi di firma per i log di audit (annualmente), e alla chiave master che avvolge i segreti per utente.
Distruzione e cancellazione crittografica
Quando il criptoperiodo di una chiave termina o i dati devono essere eliminati per il GDPR Articolo 17, distruggi la chiave. Distruzione fisica (distruggidocumenti per smart card) per i token di backup offline. Cancellazione crittografica per le chiavi archiviate nel cloud: cifra la chiave con una chiave di avvolgimento, poi distruggi la chiave di avvolgimento — tutti i dati cifrati sotto la prima chiave diventano ciphertext che nessuno può decrittografare. Così i cloud provider rispettano le richieste di cancellazione su scala di terabyte senza effettivamente pulire ogni settore del disco. Documenta la distruzione in un log di audit con timestamp, ID chiave (non il materiale della chiave), e il metodo di distruzione. NIST SP 800-88 Rev 1 copre la sanitizzazione.
Controllo degli accessi e separazione dei compiti
Nessuna singola persona dovrebbe essere in grado di estrarre una chiave di produzione. Implementa il quorum m-di-n per i ruoli di amministratore HSM: qualsiasi 2 di 5 funzionari per esportare una chiave radice, qualsiasi 1 di 3 per ruotare una KEK, 0 richiesti per le operazioni DEK di routine. Le grant di AWS KMS ti consentono di delegare capacità ristrette (solo-encrypt, solo-decrypt) tramite policy IAM. Il Shamir Secret Sharing di HashiCorp Vault divide la chiave di unseal tra i trustee. Registra ogni uso della chiave con identità del chiamante, operazione e risorsa. PCI DSS 3.6.2 e SOC 2 CC6.1 auditano entrambi questo.
Crittografia a busta e BYOK
Bring Your Own Key (BYOK) consente ai clienti di caricare la propria KEK radice su un KMS cloud. Il cloud provider avvolge le chiavi di dati del tenant sotto la KEK del cliente, così la revoca del cliente rende i dati irrecuperabili senza il coinvolgimento del provider. AWS KMS Import Key, Google Cloud EKM (External Key Manager), Azure Key Vault BYOK — tutti risolvono questo. Per i servizi di trasferimento file che gestiscono clienti regolamentati (sanità, finanza), BYOK soddisfa i requisiti "il cliente controlla le chiavi" anche su infrastruttura condivisa. L'HSM del cliente nel suo data center genera la chiave; il provider non vede mai il materiale della chiave in chiaro.
Backup e ripristino del materiale delle chiavi
Le chiavi perse significano dati persi. Effettua il backup delle chiavi radice tramite divisioni Shamir Secret Sharing detenute da trustee geograficamente separati. AWS KMS offre l'esportazione del materiale della chiave solo per le CMK create con BYOK. YubiHSM 2 supporta il backup della chiave di avvolgimento. Documenta la procedura di ripristino, testala ogni anno (esegui effettivamente la procedura, non leggerla solo), e mantieni almeno due trustee attivi in qualsiasi momento — un bus factor di uno è inaccettabile. Per le chiavi meno critiche, backup offline cifrati su supporti air-gapped (nastro LTO, USB cifrata in una cassaforte) in 2+ siti. La procedura di ripristino appartiene al tuo disaster recovery runbook.
Il caso speciale della crittografia lato client
Per servizi come HexaTransfer dove gli utenti cifrano nel browser, la gestione tradizionale delle chiavi non si applica — non c'è nessuna chiave lato server da ruotare perché il server non vede mai le chiavi. Il browser deriva una chiave dalla password dell'utente, la usa una volta, e la scarta. La gestione delle chiavi si sposta sull'educazione degli utenti: scegli password forti, non riutilizzarle, usa un gestore di password. La responsabilità del servizio è usare un KDF forte (Argon2id con m=64MB, t=3, p=1, o PBKDF2 con 600k+ iterazioni), generare salt casuali correttamente, e azzerare il materiale delle chiavi dalla memoria dopo l'uso (tramite handle opachi di crypto.subtle o cancellazioni esplicite della memoria WebAssembly).
Monitoraggio e risposta agli incidenti
La compromissione delle chiavi è l'incidente peggiore. Monitora le operazioni KMS per anomalie: una chiave API che di solito fa 100 chiamate Decrypt/ora che improvvisamente ne fa 10.000 è un'esfiltrazione. Allerta sugli errori KMS (autenticazione fallita, chiave non trovata, quota superata). Collega gli avvisi a un runbook che include la rotazione delle chiavi, l'invalidazione delle credenziali e la cattura forense. Hai un piano di recupero dalla compromissione delle chiavi: quanto velocemente puoi ruotare la radice? Come re-cifri TB di dati? Testa il piano annualmente. Un KMS ben gestito con compromissione non rilevata è peggio di uno visibilmente rotto.
Provalo su hexatransfer.com — gratis, senza registrazione, fino a 10 GB.
Invia file di grandi dimensioni in modo sicuro con crittografia end-to-end
Trasferisci file fino a 10 GB gratuitamente con crittografia end-to-end. Nessun account necessario. I tuoi file vengono crittografati nel browser prima del caricamento — nessun altro può leggerli.
Invia un file