Crittografia e gestione delle chiavi per asset: implementare concretamente i requisiti di conformità

«Crittografia ovunque» suona semplice – nella pratica però i programmi raramente falliscono per la crittografia in sé, bensì per ambito di applicazione non chiaro, mancanza di responsabilità e gestione delle chiavi non verificabile in audit. Proprio nel contesto degli asset (dispositivi, server, database, storage, istanze SaaS, backup, immagini di container, archivi di configurazione e secret) non decide il procedimento usato, ma se implementate crittografia e gestione delle chiavi per gli asset come standard operativo continuo: con classificazione dei dati, policy chiare, controlli misurabili e evidenze solide per le verifiche.

Questo contributo mostra un approccio orientato all’attuazione: quali requisiti di compliance si trovano tipicamente dietro, come definire con precisione il perimetro, quali decisioni architetturali influenzano davvero esercizio e audit – e come, con checklist pragmatiche, modelli di ruoli e punti di controllo tecnici, raggiungere uno stato che funzioni nella pratica quotidiana e resista in sede di audit.

Crittografia e gestione delle chiavi per gli asset nella pratica

La crittografia riduce il rischio in modo affidabile solo se le chiavi (Keys) sono controllate per tutto il loro ciclo di vita. „Gestione delle chiavi“ comprende più di un semplice deposito per le Keys: riguarda la creazione, la conservazione, il controllo degli accessi, la rotazione, il backup/recovery, la revoca e la tracciabilità. Negli audit emergono tipicamente i seguenti schemi:

• Assegnazione non chiara: quali chiavi proteggono quali asset? Chi è il Owner (funzionale) e chi il Custodian (operativo)?
• Standard incoerenti: crittografia del database sì, backup non cifrati; TLS sul load balancer, ma connessioni interne service-to-service senza mTLS.
• Scarsa separazione dei ruoli: gli amministratori possono allo stesso tempo gestire le chiavi e leggere i dati – mancante „Separation of Duties“ (separazione delle attività critiche).
• Mancanza di processi di rotazione e deprovisioning: chiavi obsolete restano attive per sempre; al termine della vita di un sistema non è chiaro cosa cancellare, archiviare o revocare.
• Nessuna evidence verificabile: non esistono log centrali, eventi delle chiavi né modifiche tracciabili.

Importante per i decisori: molte prescrizioni (DSGVO, ISO 27001, attuazioni NIS2, policy interne al settore) non richiedono «un prodotto specifico», ma misure tecniche e organizzative adeguate e la possibilità di dimostrarle. Proprio qui si decide se la crittografia diventi una risorsa operativa o una lacuna in sede di audit.

Inquadramento normativo: cosa tipicamente si intende, anche quando non è esplicitato

Le normative sono spesso formulate deliberatamente in modo indipendente dalla tecnologia. Nella pratica si giunge quasi sempre alle stesse aspettative:

• Riservatezza e controllo degli accessi: protezione dei dati personali, dei segreti aziendali, dei dati finanziari o di produzione – inclusa la protezione in transito e a riposo.
• Integrità e protezione dalle manomissioni: tracciabilità delle modifiche, protezione contro modifiche non autorizzate (es. artefatti firmati, log a prova di revisione).
• Tracciabilità: audit trail, policy documentate, revisioni periodiche.
• Basato sul rischio: misure di protezione più elevate per asset critici (es. dati „gioiello della corona“, servizi centrali di identità, materiale di chiavi).

Per l’attuazione conta meno la formulazione giuridica che la domanda concreta: quali dati/asset causano quale danno se vengono sottratti o manomessi? Da questo si deduce dove è necessario imporre quali controlli crittografici – e dove è sufficiente un «best effort».

Definire con precisione lo scope: quali «asset» devono far parte della vostra strategia di crittografia?

Nel management degli asset la maggiore fonte di errore è un focus troppo ristretto sulla «crittografia del disco». La compliance invece guarda end-to-end. Gruppi tipici di asset che dovRESTe includere esplicitamente:

• Endpoint: laptop, workstation, dispositivi mobili; incl. profili locali, cache offline, notebook di sviluppo, jump host per amministratori.
• Server/VM/Host: dischi del sistema operativo, volumi dati, swap, directory temporanee, log.
• Storage: SAN/NAS, object storage, condivisioni file, sistemi di archiviazione.
• Database: crittografia a riposo (nel storage) e in transito (trasporto); eventualmente crittografia a livello di colonna/campo.
• Backup & repliche: backup offsite, repository di snapshot, tape/cold storage, ambienti DR.
• Cloud-Assets: database gestiti, storage account, secret store, dischi di compute, Kubernetes-ETCD.
• Secret legati alle applicazioni: API key, certificati, token, password; frequentemente distribuiti in CI/CD, repository di configurazione, allegati ai ticket.

Operativamente vi serve un System-of-Record: tipicamente una CMDB (Configuration Management Database, ossia un database di inventario e di relazioni per gli elementi di configurazione) o almeno un inventario coerente degli asset con ID univoci. Senza questa mappatura la gestione delle chiavi non è scalabile.

Classificazione dei dati come fulcro: da «nice to have» a una policy attuabile

La compliance raramente richiede una classificazione perfetta, ma richiede misure coerenti per classi definite. Una classificazione pratica per molte aziende:

• Pubblico: pubblicazione non critica.
• Interno: uso interno, danno moderato in caso di perdita.
• Confidenziale: danno significativo; dati contrattuali, finanziari, dei clienti o di sicurezza.
• Strettamente confidenziale: critico per l’esistenza dell’azienda; materiale di chiavi, database di identità, gioielli della corona.

La classificazione non deve essere impostata manualmente ovunque. Ciò che conta è la traduzione in controlli minimi: «Confidenziale» significa ad es. sempre crittografia a riposo e in transito, key-store centrale, logging dell’utilizzo delle chiavi, intervalli di rotazione definiti. «Strettamente confidenziale» può inoltre imporre l’obbligo di HSM, approvazioni a quattro occhi, ruoli amministrativi separati e regole di monitoraggio più RESTrittive.

Esempio: Policy-Matrix come contratto operativo tra IT, Security e reparto

Una Policy-Matrix (tabella) diventa nella pratica un contratto operativo: stabilisce quali misure sono obbligatorie per ciascuna classe e in che modo vengono approvate le eccezioni. Colonne importanti sono: tipo di asset, classe dei dati, crittografia «at REST», crittografia «in transit», proprietario della chiave, opzione KMS/HSM consentita, logging/evidenze, rotazione, requisiti di backup/recupero.

Componenti tecnici di base: KMS, HSM, BYOK/HYOK classificati in modo chiaro

Affinché i decisori possano valutare rischi e costi, conviene una chiara classificazione dei termini chiave:

• KMS (Key Management Service/System): Sistema centrale per la generazione e la gestione delle chiavi crittografiche, incluse le policy di accesso e i log di audit. Può essere gestito on‑premises o come servizio cloud.
• HSM (Hardware Security Module): Hardware specializzato che conserva il materiale delle chiavi con protezione avanzata ed esegue le operazioni crittografiche nella componente hardware. Obiettivo: le chiavi non lasciano l’HSM in chiaro.
• BYOK (Bring Your Own Key): Si utilizza un servizio cloud ma si forniscono le proprie chiavi (o Root‑Keys) per aumentare controllo e tracciabilità.
• HYOK (Hold Your Own Key): Le chiavi RESTano completamente sotto il vostro controllo (es. HSM on‑prem). Il servizio cloud non può decifrare senza la vostra autorizzazione. Maggiore complessità, maggiore sovranità.

Importante: non tutti gli asset richiedono un HSM. Spesso un HSM è sensato per chiavi root/master e per classi particolarmente critiche, mentre le successive Data Encryption Keys (DEKs) sono gestite in un KMS e ruotate regolarmente. Questo concetto è noto in molte architetture come Envelope Encryption: una master‑key protegge molte chiavi a vita breve che a loro volta cifrano i dati. Il vantaggio: rotazione e controllo degli accessi diventano operativamente gestibili.

Crittografia at REST: cosa proteggere realmente – e cosa spesso viene trascurato

«At REST» significa: i dati sono memorizzati su un supporto di storage (disco, volume, object storage, backup). Misure tipiche sono la cifratura full‑disk/volume, la cifratura lato storage o la cifratura a livello di database (TDE, Transparent Data Encryption). I punti ciechi più frequenti:

• Backup: i repository di backup sono un bersaglio privilegiato perché contengono „tutto“. La cifratura qui deve essere la norma, inclusa la gestione delle chiavi al momento del ripristino.
• Snapshots e repliche: gli snapshot possono conservare i dati in uno stato che include chiavi „vecchie“ o ACL obsolete. La governance deve stabilire se gli snapshot utilizzano chiavi proprie e per quanto tempo possono persistere.
• Dati temporanei: file di export, dump di debug, staging ETL, directory di cache. Se dati classificati come „riservati“ finiscono in questi luoghi, i vostri controlli spesso non coprono tali scenari.
• Log: i log applicativi o di accesso spesso contengono ID, token, dati personali o messaggi di errore con frammenti di dati. La politica sui log è parte integrante della strategia di cifratura.

Dal punto di vista dell’audit non conta solo che la cifratura sia attivata, ma chi controlla le chiavi, se esiste una ripristinabilità e come prevenite la decifratura non autorizzata.

Crittografia in transit: TLS è obbligatorio, ma non è sufficiente

„In transit“ indica la trasmissione di dati tra client, servizi e sistemi. Lo standard è TLS (Transport Layer Security). Le insidie tipiche in termini di compliance emergono meno nel frontend e più all’interno:

• Service-to-Service: API interne, pipeline di dati, messaging. Senza una TLS-Policy coerente si creano lacune dovute a eccezioni „temporäre“.
• Zertifikatslaufzeiten und Renewal: I certificati scaduti rappresentano un rischio operativo e portano a misure d’emergenza affrettate che compromettono l’auditabilità.
• Legacy-Protokolle: Vecchi setup SMB/NFS, connessioni a database insicure, interfacce di dispositivi o OT. Qui servono misure di migrazione o di compensazione (segmentazione, jump-hosts, proxy).

Per la governance è decisivo stabilire se considerare la cifratura in transito come una „configurazione per team“ o come una baseline centrale con standard minimi vincolanti (policy dei cipher, versione minima TLS, origine dei certificati, automazione del rinnovo, monitoraggio).

Operationalizzare il ciclo di vita delle chiavi: dalla creazione alla cancellazione

Una gestione delle chiavi verificabile dipende dal ciclo di vita. In esercizio si dimostra efficace una chiara separazione:

• Owner (funzionale): risponde del fabbisogno di protezione, delle approvazioni, delle eccezioni e dei tempi di conservazione.
• Custodian (operazioni IT/Security): gestisce KMS/HSM, applica le policy, monitora gli eventi, esegue tecnicamente la rotazione.
• Consumer (applicazione/servizio): utilizza le chiavi tramite interfacce definite, senza portare via il materiale chiave.

Fasi del ciclo di vita che dovreste formalizzare in policy e runbook:

• Create: generazione delle chiavi con parametri definiti (algoritmo, lunghezza della chiave, scopo d’uso).
• Activate: autorizzazione all’uso, collegata a ruoli/identità (IAM), idealmente con privilegi minimi.
• Rotate: sostituzione pianificata, senza perdita di dati e senza downtime – incluso il percorso di migrazione per chiavi di database/storage.
• Suspend/Revoke: blocco immediato in caso di sospetto (Incident Response) – con impatto sulla disponibilità chiarito in anticipo.
• Archive/Destroy: fine del periodo di conservazione o fine del sistema; cancellazione documentata e verificabile (o archiviazione, se richiesta per obblighi legali).

Rotation: vantaggio in termini di sicurezza solo se gestite le conseguenze operative

La rotazione delle chiavi è spesso richiesta negli audit, ma temuta in esercizio. Il punto critico: la rotazione non riguarda solo la chiave, ma frequentemente anche la Re-Encryption (ri-cifratura) o la gestione di più versioni attive della chiave. Pianificate la rotazione quindi in base al rischio:

• Root-/Master-Keys: ruotano raramente e devono essere protette al massimo (es. HSM, autorizzazioni rigorose).
• Data Encryption Keys: ruotano più frequentemente; tecnicamente spesso rappresentabili come versioning nel KMS.
• Zertifikate: automatizzare il rinnovo; durate brevi hanno senso solo se sono presenti automazione e monitoraggio.

Dal punto di vista aziendale la rotazione è un change controllato con una chiara logica di rollback. Senza un percorso di test la rotazione genera più interruzioni che sicurezza.

Prospettiva di audit: quali evidenze tipicamente richiedono i revisori

Gli audit raramente falliscono perché „non esiste crittografia“, ma perché le prove mancano o sono contraddittorie. Tipiche evidenze che dovreste standardizzare:

• Documenti di policy: classificazione dei dati, policy di crittografia, processo di eccezione, modello di ruoli.
• Elenco degli asset: ambito degli asset rilevanti con classificazione (o ereditarietà tramite tipi di sistema), idealmente supportato da CMDB.
• Prove di configurazione: per Cloud/Storage/DB: crittografia abilitata, origine delle chiavi definita (chiavi gestite dal provider vs. chiavi gestite dal cliente), TLS forzato.
• Eventi delle chiavi: log sulla creazione delle chiavi, rotazione, disattivazione, modifiche alle policy, accessi (chi, quando, per quale scopo).
• Test di controllo: campionamenti, p.es. „il backup di un sistema confidenziale è crittografato“, „il ripristino richiede un’approvazione definita“, „i certificati vengono rinnovati prima della scadenza“.

Praticamente utile è un „pacchetto di audit“ per ogni sistema critico: 1–2 pagine di sintesi più link/export ai log e alla configurazione. Questo riduce considerevolmente l’impegno di audit, perché le domande possono essere risposte in modo ripetibile.

Implementazione pratica: un piano di 90 giorni che non trascura l’operatività quotidiana

Per molte organizzazioni un piano iterativo è più realistico rispetto a un approccio „big bang“. Una procedura collaudata in tre fasi:

0–30 giorni: trasparenza e baseline minima

• Consolidare l’inventario: quali asset contengono dati „confidenziali/strettamente confidenziali“?
• Definire la baseline: minimo TLS, crittografia dei backup, archiviazione centrale dei secret (nessun ticket/nessun wiki).
• Interventi rapidi: forzare la crittografia full-disk sui laptop, attivare la crittografia dei backup, irrobustire gli accessi ai key store.
• Definire ruoli e on-call: chi può bloccare le chiavi? chi decide sulla decrittazione d’emergenza?

31–60 giorni: decisioni su KMS/HSM, policy, automazione

• Stabilire lo standard KMS (on-prem o cloud) e definire le interfacce.
• Introdurre uno schema di nomenclatura per le chiavi e il tagging (mappatura a Asset-ID/servizio/ambiente).
• Pilotare la rotazione per tipi di chiavi selezionati (es. DEKs, certificati).
• Centralizzare il logging: eventi delle chiavi, modifiche alle policy, accessi in SIEM/Log-Management.

61–90 giorni: evidenze di audit, processo di eccezione, rafforzamento delle risorse critiche

• Creare pacchetti di audit per i 10 sistemi critici principali.
• Rendere vincolante il processo di eccezione (data di scadenza, mitigazioni, approvazione del responsabile).
• Valutare l’uso di HSM per le chiavi root/master o per classi strettamente confidenziali.
• Runbook di incident response: revoca delle chiavi, compromissione dei certificati, sospetto sul repository dei backup.

Linee guida alla decisione: quale variante architetturale si adatta a rischio e operatività?

Una decisione centrale è il livello di controllo sulle chiavi rispetto alla realtà operativa:

• Provider-managed Keys: minimo carico operativo, ma controllo ridotto; adatto per dati a bassa classificazione o workload non critici.
• Customer-managed Keys (KMS): buon equilibrio tra controllo e sforzo operativo; comune per dati „confidenziali“.
• Master-Keys protetti da HSM: massima protezione del materiale chiave, ma maggiore complessità (approvvigionamento, HA, backup, know-how operativo).
• BYOK/HYOK: maggiore sovranità, ma dipendenze aggiuntive di integrazione e disponibilità; utile in presenza di pressioni regolamentari o requisiti di protezione particolari.

Valutate le varianti non solo in base alla sicurezza, ma anche in termini di recuperabilità (es. dopo un guasto di sito), capacità di cambiamento (rotazione senza downtime) e auditabilità (log centralizzati, responsabilità chiare).

Governance: responsabilità, approvazioni e punti di controllo che funzionano realmente

La cifratura fallisce spesso alle interfacce tra i team. Una governance praticabile stabilisce poche, ma regole stringenti:

• Policy Owner: il team Security/Compliance è responsabile della policy crittografica e delle eccezioni.
• Responsabilità di piattaforma: l’IT operativo è responsabile di KMS/HSM, configurazioni standard, monitoring e runbook.
• System Owner: il reparto di linea o i responsabili di prodotto IT decidono sulla classificazione e sui rischi accettati.
• Change Control: le modifiche alla policy delle chiavi sono ad alto impatto e richiedono approvazioni regolate.

Come punti di controllo operativi si sono dimostrati efficaci: revisioni periodiche delle key policy, controlli automatizzati per risorse non cifrate, verifica della cifratura dei backup, monitoring dei certificati e un processo di offboarding vincolante per gli asset.

Liste di controllo concrete e modelli per „Gestione asset“

Lista di controllo: l’asset è cifrato in conformità alla compliance

• L’asset è identificato in modo univoco nell’inventario/CMDB (proprietario, criticità, classe dei dati).
• Cifratura at REST attiva (Disk/Volume/DB/Storage) e documentata.
• Cifratura in transit forzata (TLS-Policy, origine dei certificati, monitoring).
• Fonte delle chiavi definita (provider-managed / KMS / HSM / BYOK/HYOK).
• Diritti di accesso minimi e basati sui ruoli (nessun ‚onnipotente‘ senza giustificazione).
• Logging attivo: eventi chiave e accessi analizzabili centralmente.
• Rotazione regolata (intervallo, responsabile, percorso di test, rollback).
• Backup cifrato, processo di RESTore testato e approvato.
• Eccezioni documentate (motivazione, misure compensative, data di scadenza, sign-off).

Modello: autorizzazione per eccezione (contenuto minimo)

• Asset interessato (ID), classe dei dati, motivazione business
• Quale controllo non è rispettato (at REST / in transit / rotazione / logging)
• Misure compensative (segmentazione, rafforzamento degli accessi, monitoring)
• Accettazione del rischio: titolare (Owner), data, data di scadenza
• Piano di remediation (milestones)

Esempi tecnici: evidenze e controlli nella quotidianità (copiabili)

Quali comandi siano sensati dipende molto dall’ambiente. Gli esempi seguenti sono intenzionalmente generici e servono come modello per runbook ed evidenze di audit.

Linux: Status der Full-Disk-Verschlüsselung (LUKS) prüfen

# Blockgeräte und Dateisysteme anzeigen
lsblk -f

# LUKS-Metadaten eines Geräts prüfen (Beispiel: /dev/sda3)
sudo cryptsetup luksDump /dev/sda3

# Aktive Device-Mapper-Mappings anzeigen (zeigt, ob ein verschlüsseltes Mapping aktiv ist)
sudo dmsetup ls --tree

TLS: Zertifikatskette und Ablaufdatum eines Endpunkts prüfen

# Zertifikat und Ablaufdaten anzeigen (Beispielhost und Port anpassen)
echo | openssl s_client -connect example.internal:443 -servername example.internal 2>/dev/null 
  | openssl x509 -noout -issuer -subject -dates -fingerprint -sha256

Evidenza di backup: dimostrare la cifratura nel repository (check di esempio)

# Esempio: verificare se una directory di backup si trova su un filesystem cifrato
# (praticamente, ad es. per mount NFS, repository locali o staging dei backup)
backup_path="/srv/backup"
df -T "$backup_path"

# Mostrare le opzioni di mount (Nota: la cifratura effettiva può trovarsi a livelli inferiori,
# pertanto fornire anche una prova dello storage/volume)
findmnt -no SOURCE,TARGET,FSTYPE,OPTIONS "$backup_path"

Nota per gli audit: un singolo comando è raramente „la prova“. Meglio una catena di evidenze ripetibile: Asset-ID → Configurazione → Fonte della chiave → Log → Protocollo di test di ripristino.

Costi, rischi e conseguenze operative: cosa prevedere realisticamente

Le decisioni su KMS/HSM, BYOK/HYOK e rotazione non sono solo questioni di sicurezza. Fattori tipici che guidano costi e sforzo:

• Operazioni e disponibilità: un KMS/HSM centrale diventa infrastruttura critica. Interruzioni possono impedire la decifratura, l’avvio dei servizi o i ripristini.
• Complessità nelle migrazioni: migrazioni di database, cambi di storage, spostamenti cloud – ovunque le chiavi devono migrare correttamente, senza che Key-IDs, policy o audit trail vadano persi.
• Monitoring e gestione degli incidenti: gli eventi legati alle chiavi devono essere integrati nel security monitoring. Senza allerta i log RESTano solo archivio.
• Set di competenze: la crittografia non va „reinventata“, ma i team hanno bisogno di routine su policy, rotazione, recovery e troubleshooting.

Dal punto di vista del rischio, due estremi sono pericolosi: „cifrare tutto, a prescindere da come“ (porta a sistemi non recuperabili o a chiavi fantasma) e „solo l’essenziale“ (genera lacune nei backup, nelle interfacce interne e nei segreti). La via stabile è basata sul rischio, ma con standard minimi rigorosi.

Insidie tipiche e come evitarle

• Chiavi nei file di configurazione: prevenirlo con standard centralizzati per il secrets store e scansioni nei repository/log di CI.
• „Break Glass“ senza controllo: gli accessi di emergenza sono necessari, ma devono essere registrati, temporaneamente limitati e approvati.
• Flussi di dati poco chiari: senza una mappa dei flussi di dati mancano i punti in cui i dati atterrano temporaneamente (export, ETL, server di integrazione).
• Rotazione senza test: pilotare la rotazione prima su sistemi non critici, con chiara opzione di rollback e monitoring.
• Copertura incompleta degli asset: gli asset di backup/DR devono rientrare nello stesso ambito e sotto gli stessi controlli.

Conclusione: la cifratura conforme alla compliance è uno standard operativo, non la chiusura di un progetto

Le prescrizioni di compliance possono essere applicate praticamente se trattate la cifratura come una disciplina operativa e di asset: con classificazione chiara, controlli minimi vincolanti, gestione centrale delle chiavi, logica pulita di ruoli e autorizzazioni e prove ripetibili. Tecnicamente i componenti sono per lo più disponibili – la differenza la fanno governance, processi di ciclo di vita e la capacità di mantenere sotto controllo rotazione, ripristino e gestione degli incidenti.

Se volete portare la cifratura e la gestione delle chiavi per gli asset al livello di maturità successivo, non iniziate dagli algoritmi, ma dall’ambito, dalla responsabilità, dalle evidenze e dalle tre aree che negli audit fanno quasi sempre male: Backup, flussi di dati interni e ciclo di vita delle chiavi.