Gestione delle chiavi crittografiche per ISO 27001, NIS2 e DORA
Alle 08:17 di un lunedì mattina, il Chief Information Security Officer (CISO) di una società SaaS europea riceve un messaggio dal responsabile dell’ingegneria: “Abbiamo ruotato la chiave di cifratura del database nel fine settimana, ma un’integrazione ha smesso di decifrare i record. Abbiamo eseguito il rollback usando una vecchia chiave dal vault.”
Dieci minuti dopo, il Responsabile della protezione dei dati (DPO) chiede se i record interessati includano dati personali dell’UE. La funzione Finanza chiede se l’evento possa diventare un incidente operativo soggetto a segnalazione per un cliente regolamentato. La funzione Acquisti chiede se la chiave gestita dal cliente sia di titolarità del provider cloud o della società. L’amministratore delegato pone l’unica domanda che conta in consiglio di amministrazione: “Possiamo dimostrare di averlo gestito correttamente?”
È il momento in cui “usiamo la cifratura” smette di essere una frase rassicurante e diventa un problema di evidenze.
Nel 2026, la gestione delle chiavi crittografiche si colloca all’intersezione tra i controlli ISO/IEC 27001:2022, l’igiene informatica NIS2, la gestione del rischio ICT DORA, le evidenze sulla sicurezza del trattamento richieste da GDPR Article 32, la responsabilità condivisa nel cloud e la pianificazione dell’agilità crittografica post-quantistica. Il punto non è se la cifratura esista. Il punto è se l’organizzazione possa dimostrare, mediante registrazioni, che le chiavi sono generate in modo sicuro, assegnate a proprietari, conservate in ambienti KMS o HSM approvati, ruotate secondo pianificazione, recuperate in modo sicuro, revocate in caso di compromissione e mappate al rischio aziendale.
Clarysec osserva ripetutamente lo stesso schema nelle attività di preparazione. La cifratura è implementata sistema per sistema, ma la governance delle chiavi è frammentata. I certificati sono gestiti in fogli di calcolo. Le autorizzazioni dei KMS cloud derivano da vecchi progetti. Gli sviluppatori sanno quali segreti sono rilevanti, ma il SGSI non lo sa. Gli auditor ricevono screenshot invece di evidenze sul ciclo di vita. I team NIS2 e DORA parlano di resilienza, i team privacy parlano di cifratura e pseudonimizzazione ai fini GDPR, e nessuno governa end-to-end il piano dei controlli crittografici.
Una risposta matura non consiste nell’aggiungere crittografia in modo isolato. Consiste in una gestione governata delle chiavi crittografiche collegata a trattamento del rischio, architettura cloud, supervisione dei fornitori, controllo degli accessi, registrazione degli eventi, risposta agli incidenti ed evidenze regolatorie.
Perché la gestione delle chiavi è ora un tema di governance
NIS2 rende le politiche di crittografia e cifratura parte delle misure minime di gestione dei rischi di cibersicurezza per soggetti essenziali e importanti. Article 21 richiede misure tecniche, operative e organizzative adeguate e proporzionate, tra cui analisi dei rischi, gestione degli incidenti, continuità operativa, sicurezza della catena di fornitura, sviluppo sicuro, igiene informatica, controllo degli accessi, gestione degli asset e politiche di crittografia e cifratura. Richiede inoltre agli organi di gestione di approvare e supervisionare le misure di gestione dei rischi di cibersicurezza.
Per i provider SaaS, cloud, di servizi gestiti e di cibersicurezza, l’applicabilità può essere più ampia di quanto molti team presumano. NIS2 copre settori quali infrastrutture digitali, fornitori di servizi di cloud computing, fornitori di servizi di data center, fornitori DNS, prestatori di servizi fiduciari, fornitori di servizi gestiti, fornitori di servizi di sicurezza gestiti, marketplace online, motori di ricerca e piattaforme di social networking quando sono soddisfatte le soglie dimensionali o di criticità.
DORA innalza il livello per gli enti finanziari. Dal 17 gennaio 2025, DORA richiede un quadro documentato di gestione del rischio ICT, responsabilità del consiglio di amministrazione, continuità operativa ICT e piani di risposta e ripristino, test di resilienza operativa digitale, gestione del rischio ICT delle terze parti e segnalazione degli incidenti. Per gli enti finanziari individuati dalle norme nazionali NIS2, DORA opera come atto giuridico dell’Unione specifico di settore per gli obblighi NIS2 equivalenti. Una fintech non dovrebbe mantenere governance crittografiche separate per NIS2, DORA e ISO. Ha bisogno di un unico modello di controllo difendibile.
GDPR aggiunge la dimensione delle evidenze privacy. GDPR Article 32 è il punto in cui la cifratura viene comunemente valutata come misura di sicurezza del trattamento, ma “i dati sono cifrati” non è una risposta completa. Autorità di regolamentazione e auditor chiedono chi controlla le chiavi, come viene limitato l’accesso, come viene rilevata una compromissione, come funziona il ripristino e se la progettazione è coerente con il rischio per le persone fisiche.
ISO/IEC 27001:2022 fornisce alle organizzazioni il sistema di gestione per collegare questi obblighi. Le clausole da 4.1 a 4.4 richiedono contesto, requisiti delle parti interessate, campo di applicazione del SGSI e processi interagenti. Le clausole da 5.1 a 5.3 richiedono leadership, politica, risorse e responsabilità assegnate. Le clausole da 6.1.1 a 6.1.3 richiedono valutazione del rischio, trattamento del rischio, selezione dei controlli, Dichiarazione di Applicabilità e approvazione del Proprietario del rischio. Le clausole da 8.1 a 8.3 richiedono esercizio controllato, rivalutazione del rischio quando si verificano cambiamenti, attuazione dei piani di trattamento del rischio e conservazione dei risultati documentati.
Per la gestione delle chiavi crittografiche, il SGSI deve rispondere a cinque domande:
- Quali asset informativi, flussi di dati e servizi richiedono protezione crittografica?
- Quali chiavi, certificati, segreti e servizi crittografici li proteggono?
- Chi possiede, amministra, approva e monitora tali asset crittografici?
- Come sono controllati generazione, conservazione, uso, rotazione, escrow, ripristino, revoca e distruzione?
- Quali evidenze dimostrano che i controlli hanno operato come previsto?
La dorsale dei controlli ISO 27001 per la gestione delle chiavi crittografiche
Clarysec tratta la gestione delle chiavi crittografiche come una catena di controlli, non come un singolo controllo. In Zenith Controls: la guida alla conformità trasversale Zenith Controls, il tema si mappa principalmente al controllo 8.24 di ISO/IEC 27002:2022, uso della crittografia, con importanti relazioni di supporto con 5.17, informazioni di autenticazione, e 5.23, sicurezza delle informazioni per l’uso dei servizi cloud.
Questa relazione è importante. Un fallimento nella gestione delle chiavi raramente è solo “cattiva cifratura”. Spesso è un problema di autenticazione, un problema di governance cloud, un problema di fornitore, una lacuna nella registrazione degli eventi o un fallimento della gestione delle modifiche.
| Area ISO/IEC 27002:2022 | Perché è rilevante per la gestione delle chiavi | Evidenze tipiche |
|---|---|---|
| 8.24 Uso della crittografia | Definisce casi d’uso crittografici approvati, algoritmi, protocolli, ciclo di vita delle chiavi e aspettative di implementazione | Politica crittografica, standard sugli algoritmi, procedura sul ciclo di vita delle chiavi, configurazione KMS, registrazioni di rotazione |
| 5.17 Informazioni di autenticazione | Protegge credenziali, segreti, token e materiale di autenticazione collegati a operazioni crittografiche privilegiate | Inventario dei segreti, log degli accessi al vault, riesami degli accessi privilegiati, evidenze MFA |
| 5.23 Sicurezza delle informazioni per l’uso dei servizi cloud | Definisce responsabilità condivisa, titolarità delle chiavi cloud, decisioni CMK o BYOK e governance del provider | Registro dei servizi cloud, matrice di responsabilità condivisa, architettura KMS, riesame della sicurezza del fornitore |
| Da 5.19 a 5.22 Sicurezza dei fornitori | Assicura che fornitori e prestatori di servizi ICT soddisfino i requisiti di cifratura, custodia delle chiavi, incidenti e audit | Contratti, due diligence, attestazioni del fornitore, riesami di monitoraggio |
| Da 5.24 a 5.28 Gestione degli incidenti | Collega la sospetta compromissione delle chiavi alla valutazione degli eventi, alla risposta, all’apprendimento e alla raccolta delle evidenze | Runbook degli incidenti, playbook di compromissione delle chiavi, log forensi, lezioni apprese |
| 8.15 e 8.16 Registrazione degli eventi e monitoraggio | Rileva uso non autorizzato delle chiavi, chiamate API sospette, tentativi di decifratura non riusciti e modifiche alle policy | Allerte SIEM, log di audit KMS, regole di rilevamento delle anomalie |
| 8.32 Gestione delle modifiche | Controlla rotazioni, migrazioni, aggiornamenti degli algoritmi, revoca di emergenza e attività di transizione post-quantistica | Ticket di modifica, approvazioni, piani di rollback, risultati dei test |
Il Zenith Blueprint: roadmap in 30 passaggi per l’auditor Zenith Blueprint rende operativo questo approccio nella fase di gestione del rischio, Passaggio 14, Politiche di trattamento del rischio e riferimenti normativi incrociati. Il modello di politica crittografica indica che l’organizzazione deve definire dove è necessaria la crittografia, approvare algoritmi e protocolli, definire la gestione delle chiavi, coprire casi d’uso come la cifratura completa del disco e le comunicazioni sicure, e collegare la politica a GDPR Article 32.
“Le chiavi di cifratura devono essere conservate in modo sicuro (ad es. in un vault delle chiavi/HSM) e l’accesso deve essere limitato al personale autorizzato.”
Attribuzione: Zenith Blueprint, fase di gestione del rischio, Passaggio 14, Politiche di trattamento del rischio e riferimenti normativi incrociati Zenith Blueprint
Nella fase Controlli in azione, Passaggio 20, il Zenith Blueprint approfondisce ulteriormente. La crittografia non consiste nell’“attivare la cifratura”. Consiste nell’integrare la crittografia nella progettazione, nelle politiche e nella gestione del ciclo di vita. Questo include dati a riposo, dati in transito, autenticazione di identità e transazioni, algoritmi approvati, vault delle chiavi, HSM, rotazione pianificata, revoca e convalida tramite test di penetrazione e revisione del codice.
Che cosa si aspettano gli auditor quando chiedono evidenze sulle chiavi
La maggior parte delle risultanze di audit inizia con una richiesta semplice: “Mostratemi la vostra politica di cifratura e le registrazioni di gestione delle chiavi.”
Le risposte deboli includono:
- “Il provider cloud cifra tutto per impostazione predefinita.”
- “Usiamo TLS.”
- “I segreti sono nel vault.”
- “Il team di ingegneria gestisce la rotazione.”
- “La chiave è gestita dall’applicazione.”
Queste affermazioni possono essere tecnicamente vere, ma non costituiscono evidenze complete. Un auditor ISO collegherà la gestione delle chiavi alla valutazione del rischio, alla Dichiarazione di Applicabilità, ai requisiti di policy, al controllo operativo e alla documentazione conservata. Un valutatore NIST CSF chiederà se gli asset crittografici sono identificati, protetti, monitorati e recuperati. Un auditor DORA cercherà una governance del rischio ICT approvata dal consiglio di amministrazione, dipendenze da terze parti, gestione degli incidenti e test di resilienza. Un revisore GDPR chiederà se cifratura e separazione delle chiavi riducono il rischio per le persone fisiche e se il titolare del trattamento può dimostrare la responsabilizzazione.
La Politica sui controlli crittografici enterprise di Clarysec Politica sui controlli crittografici affronta direttamente la lacuna di evidenze:
“Deve essere mantenuto un registro centralizzato di gestione delle chiavi per registrare tutte le chiavi crittografiche, il loro stato nel ciclo di vita, i custodi assegnati e i contesti d’uso.”
Attribuzione: Politica enterprise, Politica sui controlli crittografici, requisiti di governance, clausola 5.2 Politica sui controlli crittografici
Questa frase cambia il confronto in sede di audit. Invece di inseguire conoscenza informale, l’organizzazione può mostrare un registro che collega le chiavi ad asset, proprietari, classificazioni dei dati, sistemi, account cloud, date di rotazione, contesti d’uso ed evidenze.
Per le PMI, la Politica sui controlli crittografici per PMI di Clarysec Politica sui controlli crittografici per PMI dimensiona la stessa aspettativa:
“Il Fornitore di supporto IT deve mantenere un inventario aggiornato degli strumenti crittografici e dei certificati in uso”
Attribuzione: Politica PMI, Politica sui controlli crittografici per PMI, requisiti di governance, clausola 5.1.2 Politica sui controlli crittografici per PMI
Un istituto finanziario regolamentato può richiedere cerimonie HSM, conoscenza ripartita, doppio controllo, nomine formali dei custodi e riesami trimestrali degli accessi. Un piccolo provider SaaS può iniziare con un inventario mantenuto, algoritmi approvati, titolarità KMS documentata ed evidenze di rotazione. Entrambi necessitano di una governance proporzionata al rischio.
Il ciclo di vita delle chiavi che il tuo SGSI dovrebbe controllare
Un programma pratico di gestione delle chiavi segue il ciclo di vita. Ogni fase richiede un proprietario, un metodo approvato, un controllo tecnico, una registrazione di modifica ed evidenze di audit.
| Fase del ciclo di vita | Domanda di governance sulle chiavi | Aspettativa di controllo | Esempio di evidenza |
|---|---|---|---|
| Classificazione | Quali dati o transazioni richiedono protezione crittografica? | La classificazione dei dati identifica dati personali, dati finanziari, credenziali, log, backup e configurazioni sensibili | Registro di classificazione dei dati, matrice dei requisiti di cifratura |
| Progettazione | Quale metodo crittografico è approvato? | Algoritmi, protocolli, librerie e lunghezze delle chiavi approvati sono definiti e riesaminati | Standard crittografico, registrazione della decisione architetturale |
| Generazione | Come vengono create le chiavi in modo sicuro? | Le chiavi sono generate in KMS, HSM o moduli validati approvati, non manualmente né nel codice sorgente | Log di creazione delle chiavi KMS, registrazione della cerimonia HSM |
| Assegnazione | Chi possiede e amministra la chiave? | Sono assegnati un titolare del processo, un custode tecnico e un custode sostitutivo | Registro di gestione delle chiavi |
| Conservazione | Dove è conservata la chiave? | Le chiavi sono conservate in KMS, HSM o vault con controlli degli accessi e registrazione di audit | Policy KMS, configurazione del vault, log degli accessi |
| Uso | Quali sistemi possono usare la chiave? | Sono applicati principio del privilegio minimo, identità dei workload, separazione dei compiti e accesso API approvato | Policy IAM, mappatura degli account di servizio |
| Rotazione | Quando e perché la chiave viene ruotata? | Rotazione pianificata e rotazione basata su eventi in caso di compromissione o modifica del ruolo | Piano di rotazione, ticket di modifica, risultati dei test |
| Escrow e ripristino | Come possono i servizi essere ripristinati senza esporre le chiavi? | Le procedure di backup e ripristino sono testate e l’accesso è controllato | Test di ripristino, registrazione di approvazione dell’escrow |
| Revoca | Che cosa accade dopo una compromissione o una dismissione? | Chiavi e certificati sono revocati o disabilitati, i sistemi dipendenti sono aggiornati | Ticket di incidente, log di revoca |
| Distruzione | Come vengono distrutte le chiavi dismesse? | La cancellazione sicura o la cancellazione crittografica segue i requisiti di conservazione e legali | Registrazione di distruzione, pianificazione di cancellazione KMS |
La Politica sui controlli crittografici enterprise rafforza la generazione sicura:
“Generazione delle chiavi: eseguita utilizzando moduli hardware o software sicuri (ad es. HSM, sistemi convalidati FIPS 140-2).”
Attribuzione: Politica enterprise, Politica sui controlli crittografici, requisiti di applicazione della politica, clausola 6.3.1 Politica sui controlli crittografici
Specifica inoltre la rotazione:
“Rotazione delle chiavi: richiesta a intervalli definiti o immediatamente in caso di compromissione o modifica del ruolo.”
Attribuzione: Politica enterprise, Politica sui controlli crittografici, requisiti di applicazione della politica, clausola 6.3.4 Politica sui controlli crittografici
Per le PMI, lo stesso principio appare in un linguaggio operativo più semplice:
“La rotazione delle chiavi deve avvenire in conformità ai piani di scadenza o in caso di sospetta compromissione”
Attribuzione: Politica PMI, Politica sui controlli crittografici per PMI, requisiti di applicazione della politica, clausola 6.3.4 Politica sui controlli crittografici per PMI
Queste clausole sono rilevanti per NIS2 e DORA perché chiavi obsolete o governate in modo insufficiente non sono solo debolezze di riservatezza. Possono diventare ostacoli alla risposta agli incidenti, problemi di dipendenza dai fornitori, fallimenti del Disaster Recovery e problemi di notifica ai clienti.
KMS cloud, HSM e BYOK: la trappola della responsabilità condivisa
La cifratura cloud è una delle fonti più comuni di falsa rassicurazione. Un provider cloud può cifrare lo storage per impostazione predefinita, ma ciò non significa automaticamente che la tua organizzazione abbia governato la chiave.
Il Zenith Blueprint, fase Controlli in azione, Passaggio 23, spiega il controllo 5.23 di ISO/IEC 27002:2022 concentrandosi su governance cloud, visibilità e responsabilità condivisa. Sottolinea che il provider può mettere in sicurezza l’infrastruttura, ma il cliente resta responsabile dei propri dati, delle proprie configurazioni, delle proprie politiche di accesso e della propria preparazione alla risposta agli incidenti.
“I provider cloud mettono in sicurezza l’infrastruttura, ma sei comunque responsabile dei tuoi dati, delle tue configurazioni, delle tue politiche di accesso e della tua preparazione alla risposta agli incidenti.”
Attribuzione: Zenith Blueprint, fase Controlli in azione, Passaggio 23, controlli organizzativi 5.19-5.37 Zenith Blueprint
È qui che la responsabilità sulle chiavi cloud diventa un rischio a livello di consiglio di amministrazione. Una società SaaS può usare cifratura gestita dal provider per log a basso rischio, chiavi gestite dal cliente per database dei clienti, BYOK per tenant regolamentati e chiavi root supportate da HSM per firma o tokenizzazione. Ogni scelta ha implicazioni di conformità.
La Politica di utilizzo del cloud enterprise di Clarysec Politica di utilizzo del cloud fornisce una chiara direzione di controllo:
“Le chiavi gestite dal cliente (CMK) o Bring Your Own Key (BYOK) devono essere utilizzate ove supportato dal provider cloud.”
Attribuzione: Politica enterprise, Politica di utilizzo del cloud, requisiti di applicazione della politica, clausola 6.4.2 Politica di utilizzo del cloud
Questo non significa che ogni servizio cloud debba usare BYOK. Significa che l’organizzazione deve decidere in modo deliberato, in base a rischio, impegni verso i clienti, requisiti contrattuali e recuperabilità.
| Modello di titolarità delle chiavi | Caso d’uso idoneo | Focus di governance |
|---|---|---|
| Chiavi gestite dal provider | Telemetria a basso rischio, log non sensibili, cifratura standard della piattaforma | Confermare i controlli del provider, documentare la base di rischio, monitorare la configurazione del servizio |
| Chiavi gestite dal cliente | Banche dati di produzione, backup, record dei clienti, workload regolamentati | Assegnare il proprietario, limitare l’accesso, registrare l’uso delle chiavi, ruotare e testare il ripristino |
| BYOK o gestione esterna delle chiavi | Tenant ad alto rischio, segregazione contrattuale, impegni verso clienti regolamentati | Gestire importazione, custodia, revoca, condizioni del fornitore e test di resilienza |
| Chiavi supportate da HSM | Chiavi root di firma, autorità di certificazione, tokenizzazione e segreti ad alto valore | Applicare doppio controllo, registrazioni delle cerimonie, separazione dei compiti e monitoraggio rigoroso degli accessi |
DORA Article 28 e Article 30 rendono questo aspetto particolarmente rilevante per gli enti finanziari. Richiedono gestione del rischio ICT delle terze parti, registri degli accordi contrattuali ICT, due diligence, diritti di audit e ispezione, assistenza in caso di incidente, protezione dei dati e accesso, disposizioni di ripristino e restituzione. Se un provider cloud o un fornitore SaaS gestisce chiavi di cifratura per una funzione critica o importante, tale relazione deve essere visibile nel registro delle terze parti ICT e nei controlli contrattuali.
NIS2 richiede anche la sicurezza della catena di fornitura, comprese vulnerabilità specifiche dei fornitori, pratiche di cibersicurezza e procedure di sviluppo sicuro. Se un fornitore critico detiene le tue chiavi, opera il tuo KMS, fornisce il tuo HSM, gestisce il ciclo di vita dei certificati o ospita backup cifrati, il fornitore fa parte del tuo ambiente di controllo crittografico.
Approvazione degli algoritmi e agilità crittografica nel 2026
Una politica di gestione delle chiavi del 2026 non dovrebbe limitarsi a elencare “AES-256” e “TLS 1.2 o successivo”. Dovrebbe istituire un processo di approvazione e riesame che supporti l’agilità crittografica. Agilità crittografica significa che l’organizzazione può identificare dove sono utilizzati algoritmi, protocolli, certificati e lunghezze delle chiavi, valutare l’esposizione a debolezze o deprecazioni e migrare senza emergenze.
La politica PMI di Clarysec stabilisce:
“Possono essere utilizzati solo algoritmi e protocolli conformi alle migliori pratiche del settore e approvati dal Fornitore di supporto IT (ad es. AES-256, RSA 2048, TLS 1.2 o successivo)”
Attribuzione: Politica PMI, Politica sui controlli crittografici per PMI, requisiti di applicazione della politica, clausola 6.2.1 Politica sui controlli crittografici per PMI
Richiede inoltre documentazione:
“Tutti i metodi di cifratura (ad es. AES-256, TLS 1.2+) e i processi di gestione delle chiavi devono essere documentati”
Attribuzione: Politica PMI, Politica sui controlli crittografici per PMI, requisiti di governance, clausola 5.3.1 Politica sui controlli crittografici per PMI
La versione pronta per l’audit è uno standard crittografico approvato con:
- Algoritmi e protocolli consentiti per dati a riposo, dati in transito, firme, hashing delle password, tokenizzazione e backup.
- Algoritmi, protocolli e librerie non consentiti.
- Lunghezze minime delle chiavi e periodi di validità dei certificati.
- KMS, HSM, autorità di certificazione e piattaforme di gestione dei segreti approvati.
- Requisiti di generazione sicura di numeri casuali.
- Indicazioni per gli sviluppatori sulle librerie crittografiche.
- Processo di richiesta di eccezione per sistemi legacy.
- Trigger di riesame per vulnerabilità, modifiche normative, modifiche dei fornitori e pianificazione della transizione post-quantistica.
La pianificazione post-quantistica non richiede a ogni organizzazione di sostituire immediatamente tutta la crittografia. Richiede però un inventario. Senza un inventario crittografico, non è possibile sapere quali sistemi usano cifratura a chiave pubblica di lunga durata, quali certificati proteggono servizi critici, dove risiedono le chiavi di firma o quali fornitori devono supportare la migrazione. Il registro di gestione delle chiavi non è burocrazia. È il fondamento dell’agilità crittografica.
Uno sprint di 90 minuti sulle evidenze di gestione delle chiavi
Clarysec utilizza spesso un breve sprint sulle evidenze con leadership, sicurezza, cloud e team di conformità. L’obiettivo è trasformare rapidamente conoscenze sparse sulle chiavi in evidenze di audit.
Passaggio 1: selezionare un servizio critico
Scegli un sistema rilevante per NIS2, DORA o GDPR. Esempi includono identità dei clienti, elaborazione dei pagamenti, monitoraggio delle transazioni, database clienti di produzione, piattaforma di backup cifrata o API esposta ai clienti.
Passaggio 2: aprire il registro di gestione delle chiavi
Usa il requisito della Politica sui controlli crittografici per un registro centralizzato come struttura. Se non ne hai ancora uno, crea un registro semplice con questi campi:
| Campo del registro | Esempio di voce |
|---|---|
| ID chiave o certificato | prod-db-cmk-eu-west-01 |
| Contesto d’uso | Cifratura del database clienti di produzione |
| Dati protetti | Dati personali dei clienti UE e metadati di fatturazione |
| Proprietario | Responsabile della piattaforma |
| Custode | Responsabile della sicurezza cloud |
| Posizione di conservazione | Cloud KMS, regione UE |
| Tipo di chiave | Chiave simmetrica gestita dal cliente |
| Data di creazione | 2026-01-14 |
| Frequenza di rotazione | 180 giorni |
| Ultima rotazione | 2026-04-10 |
| Prossima rotazione | 2026-10-07 |
| Modello di accesso | Solo ruolo di servizio, amministrazione tramite gruppo di emergenza |
| Registrazione degli eventi | Log API KMS inoltrati al SIEM |
| Metodo di ripristino | Backup KMS e procedura di ripristino testata |
| Dipendenza dal fornitore | KMS del provider cloud |
| Mappatura di conformità | ISO 8.24, 5.17, 5.23, GDPR Article 32, NIS2 Article 21, rischio ICT DORA |
| Link all’evidenza | Ticket di modifica, screenshot KMS, riesame IAM, query log, test di ripristino |
Passaggio 3: tracciare accessi e doppio controllo
Per le operazioni crittografiche ad alto impatto, applica doppio controllo e principio del privilegio minimo. La Politica sui controlli crittografici enterprise stabilisce:
“I principi di doppio controllo e privilegio minimo devono essere applicati alle operazioni crittografiche sensibili (ad es. importazione di chiavi root, amministrazione HSM).”
Attribuzione: Politica enterprise, Politica sui controlli crittografici, requisiti di applicazione della politica, clausola 6.6.2 Politica sui controlli crittografici
Chiediti:
- Chi può disabilitare o eliminare la chiave?
- Chi può modificare la policy della chiave?
- Chi può decifrare direttamente i dati?
- I ruoli di emergenza sono monitorati e limitati nel tempo?
- L’MFA è applicata per le operazioni privilegiate sulle chiavi?
- Le azioni privilegiate sono registrate e riesaminate?
Passaggio 4: estrarre cinque registrazioni di evidenza
Raccogli cinque registrazioni che dimostrano il funzionamento del controllo:
- Log di creazione o importazione della chiave.
- Policy di accesso KMS o HSM corrente.
- Ultimo ticket di modifica per la rotazione della chiave.
- Query SIEM che mostra l’uso della chiave o azioni amministrative.
- Evidenza del test di recovery o ripristino.
Passaggio 5: mappare rischio e normativa
Aggiungi una breve dichiarazione di rischio: “L’uso non autorizzato o la perdita di questa chiave potrebbe esporre dati personali dell’UE, interrompere il servizio ai clienti e compromettere il ripristino di sistemi critici.” Quindi mappala agli obblighi pertinenti.
| Obbligo | Che cosa supporta l’evidenza |
|---|---|
| Clausole 6 e 8 di ISO/IEC 27001:2022 | Trattamento del rischio, controllo operativo, risultati documentati |
| ISO/IEC 27002:2022 8.24 | Uso approvato della crittografia e controllo del ciclo di vita delle chiavi |
| NIS2 Article 21 | Politiche di crittografia e cifratura, igiene informatica, controllo degli accessi, gestione degli asset |
| DORA Articles 5, 6, 17, 28 e 30 | Governance ICT, quadro del rischio ICT, processo di gestione degli incidenti, dipendenze da terze parti e contratti |
| GDPR Article 5 e Article 32 | Responsabilizzazione, integrità e riservatezza, sicurezza del trattamento |
| NIST CSF 2.0 | Identificare gli asset, proteggere i dati, rilevare anomalie, rispondere e ripristinare |
In 90 minuti, il team può di solito capire se la governance delle chiavi sia reale o solo presunta.
Segnalazione degli incidenti: quando la compromissione delle chiavi fa partire il tempo
Una sospetta compromissione delle chiavi non è automaticamente una violazione soggetta a notifica, ma può far partire il termine regolatorio.
Ai sensi di NIS2, i soggetti essenziali e importanti devono notificare senza indebito ritardo gli incidenti significativi che incidono sulla fornitura del servizio. Il modello per fasi include un preallarme entro 24 ore dalla conoscenza, una notifica dell’incidente entro 72 ore, aggiornamenti sullo stato ove richiesti e una relazione finale non oltre un mese dalla notifica dell’incidente.
Ai sensi di DORA, gli enti finanziari devono rilevare, gestire e notificare gli incidenti connessi all’ICT, registrare incidenti e minacce informatiche significative, classificare gli incidenti in base alla gravità e alla criticità del servizio interessato, comunicare con le parti interessate, segnalare gli incidenti gravi all’alta direzione e alle autorità competenti, condurre analisi della causa radice e porre rimedio. L’esternalizzazione della segnalazione può essere possibile, ma la responsabilità resta in capo all’ente finanziario.
Ai sensi del GDPR, la domanda diventa se si sia verificata una violazione dei dati personali, ossia distruzione, perdita, modifica, divulgazione non autorizzata o accesso accidentali o illeciti a dati personali. Una cifratura forte con chiavi non compromesse può modificare in modo sostanziale l’analisi del rischio di violazione. Una gestione debole delle chiavi può indebolire tale argomento.
I playbook di compromissione delle chiavi devono definire:
- Come viene rilevata una sospetta esposizione della chiave.
- Chi dichiara un incidente crittografico.
- Come vengono identificati dati, servizi, clienti e giurisdizioni interessati.
- Come le chiavi vengono revocate o ruotate.
- Come vengono ripristinati i sistemi dipendenti.
- Come viene preservata l’integrità delle evidenze.
- Come vengono assunte le decisioni di notifica legali, regolatorie e ai clienti.
Il registro di gestione delle chiavi diventa essenziale durante questo processo. Senza di esso, i responder perdono tempo a identificare ciò che una chiave proteggeva. Con esso, possono delimitare rapidamente l’impatto.
La prospettiva dell’audit: un unico set di controlli, molti destinatari delle evidenze
Auditor diversi affrontano la gestione delle chiavi crittografiche da prospettive diverse, ma convergono sulle stesse evidenze.
| Prospettiva dell’auditor | Domanda probabile di audit | Evidenze efficaci |
|---|---|---|
| Auditor ISO/IEC 27001:2022 | La gestione delle chiavi crittografiche è stata selezionata mediante trattamento del rischio, documentata nella Dichiarazione di Applicabilità e gestita come pianificato? | Valutazione del rischio, Dichiarazione di Applicabilità, politica crittografica, registro di gestione delle chiavi, registrazioni di rotazione |
| Valutatore NIST CSF | Gli asset crittografici sono identificati, protetti, monitorati e recuperabili? | Inventari degli asset e dei dati, controlli degli accessi, log KMS, allerte SIEM, registrazioni di risposta e ripristino |
| Auditor DORA | Le dipendenze delle chiavi fanno parte della gestione del rischio ICT, della supervisione delle terze parti, dei test di resilienza e della segnalazione degli incidenti? | Quadro del rischio ICT, registro delle terze parti, contratti cloud KMS, test di continuità, processo di classificazione degli incidenti |
| Revisore GDPR | La cifratura riduce il rischio per le persone fisiche e il titolare del trattamento può dimostrare la responsabilizzazione? | Classificazione dei dati, separazione delle chiavi, log degli accessi, progettazione della cifratura, valutazione del rischio di violazione |
| Auditor ISACA o COBIT 2019 | Sono definiti obiettivi di governance, titolarità del rischio, prestazioni dei controlli e responsabilità della direzione? | RACI, metriche dei controlli, riesame della direzione, registro delle eccezioni, tracciamento delle azioni correttive derivanti dall’audit |
Un solido pacchetto di audit per la gestione delle chiavi crittografiche contiene di norma:
- Politica sui controlli crittografici approvata.
- Politica di utilizzo del cloud approvata quando la cifratura cloud è rilevante.
- Standard crittografico ed elenco degli algoritmi.
- Registro di gestione delle chiavi.
- Inventario dei certificati e dei segreti.
- Architettura KMS, HSM e vault.
- Evidenze di riesame IAM e degli accessi privilegiati.
- Registrazioni di rotazione e revoca.
- Evidenze dei test di backup, escrow e ripristino.
- Regole di registrazione degli eventi e monitoraggio per le attività sulle chiavi.
- Mappatura tra fornitori e responsabilità condivisa nel cloud.
- Playbook di incidente per sospetta compromissione delle chiavi.
- Eccezioni e accettazioni del rischio.
- Registrazioni del riesame della direzione e delle azioni correttive derivanti dall’audit.
Questo pacchetto trasforma un’affermazione di controllo in prova.
Risultanze comuni negli audit sulla gestione delle chiavi
Le risultanze più comuni sono evitabili:
- Nessun inventario unico di chiavi, certificati e strumenti crittografici.
- Cifratura predefinita del provider cloud trattata come piena governance delle chiavi.
- Nessun proprietario o custode assegnato alle chiavi di produzione.
- La rotazione esiste per i certificati, ma non per le chiavi applicative o le CMK dei database.
- Segreti e chiavi nello stesso vault senza classificazione.
- Gli sviluppatori possono creare chiavi al di fuori dei modelli approvati.
- Nessuna evidenza che gli amministratori KMS siano riesaminati.
- Le procedure di ripristino esistono ma non sono mai state testate.
- La compromissione delle chiavi non è inclusa nei playbook di risposta agli incidenti.
- Algoritmi legacy restano nei servizi interni perché nessuno possiede le azioni correttive.
- Impegni BYOK vengono assunti nei contratti con i clienti ma non sono riflessi nelle operazioni.
- La cifratura gestita dal fornitore non è inclusa nei riesami del rischio dei fornitori.
Ogni risultanza rimanda alla governance. Per questo la crittografia non può essere trattata come un progetto puramente ingegneristico. Deve collegarsi al campo di applicazione del SGSI, al trattamento del rischio, alle politiche, ai fornitori, al cloud, agli accessi, alla registrazione degli eventi, agli incidenti e alla continuità.
Rendere la governance delle chiavi pronta per l’audit prima del prossimo incidente
Se la tua organizzazione si sta preparando per NIS2, DORA, evidenze GDPR Article 32, certificazione ISO/IEC 27001:2022 o agilità crittografica post-quantistica, inizia da una domanda: puoi produrre oggi un registro di gestione delle chiavi completo?
In caso contrario, Clarysec può aiutarti a costruire il sistema di controllo attorno a tale registro.
Usa il Zenith Blueprint Zenith Blueprint per strutturare il lavoro attraverso la fase di gestione del rischio Passaggio 14 e la fase Controlli in azione Passaggio 20. Usa Zenith Controls Zenith Controls per mappare i controlli ISO/IEC 27002:2022 8.24, 5.17 e 5.23 su NIS2, DORA, GDPR, NIST e aspettative di audit. Usa la Politica sui controlli crittografici di Clarysec Politica sui controlli crittografici, la Politica sui controlli crittografici per PMI Politica sui controlli crittografici per PMI e la Politica di utilizzo del cloud Politica di utilizzo del cloud per trasformare i requisiti in regole operative.
Il prossimo passo pratico è semplice: scegli un servizio critico, inventaria le sue chiavi, dimostra la titolarità, valida gli accessi, estrai le evidenze di rotazione e testa il ripristino. Se richiede più di un giorno, la tua governance crittografica richiede attenzione prima che autorità di regolamentazione, auditor o team di risposta agli incidenti pongano la stessa domanda sotto pressione.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
