DORA articolo 7: gestione delle chiavi e registro dei certificati

L'articolo 7 del Regolamento delegato (EU) 2024/1774 della Commissione, le norme tecniche di regolamentazione (RTS) DORA sulla gestione dei rischi ICT, richiede due cose: la gestione delle chiavi crittografiche lungo l'intero ciclo di vita delle chiavi e un registro dei certificati per gli asset ICT che supportano funzioni critiche o importanti. Il registro è un artefatto di conformità, ma è anche l'elenco operativo di cui avrete bisogno il giorno in cui migrerete lo scambio di chiavi e le firme verso algoritmi post-quantum. Questa guida illustra i campi da registrare, i comandi in sola lettura che individuano i certificati e il modo in cui il registro si collega al più ampio inventario crittografico richiesto dall'articolo 6 DORA. Si tratta di informazioni, non di consulenza legale.

Che cosa chiede letteralmente l'articolo 7

Il testo delle RTS è breve e specifico. Le entità finanziarie devono disporre di politiche e procedure per la gestione delle chiavi crittografiche che coprano generazione, rinnovo, conservazione, backup, archiviazione, recupero, trasmissione, ritiro, revoca e distruzione delle chiavi. Separatamente, devono tenere un registro dei certificati e dei dispositivi di archiviazione dei certificati per gli asset ICT che supportano funzioni critiche o importanti, e gestire il rinnovo dei certificati in modo che la scadenza non interrompa tali funzioni. Il testo ufficiale è disponibile su EUR-Lex: Regolamento delegato (EU) 2024/1774 della Commissione.

Da questa formulazione derivano direttamente tre conseguenze, prima ancora di qualsiasi interpretazione.

• Il perimetro è definito dalle funzioni, non dall'infrastruttura. L'elemento scatenante è il supporto a una funzione critica o importante, quindi il registro segue la vostra classificazione delle funzioni, non un confine di rete.
• Nel perimetro rientrano i dispositivi, non solo i file. Per dispositivi di archiviazione dei certificati si intendono hardware security module (HSM), smartcard, trusted platform module e keystore delle appliance: inventariate quindi il supporto oltre alla credenziale.
• Il rinnovo è un controllo di disponibilità. Un certificato scaduto su un gateway di pagamento è un incidente ICT, ed è per questo che l'articolo 7 associa il registro alla gestione dei rinnovi.

Ciò che l'articolo 7 non dice è altrettanto importante. Non menziona algoritmi post-quantum, non fissa una data di migrazione e non richiede un formato di file specifico. È l'articolo 6 a richiedere disposizioni per l'aggiornamento o la modifica della tecnologia crittografica in funzione degli sviluppi della crittoanalisi, ed è questo l'aggancio alla crypto-agility. La nostra lettura, indicata come interpretazione: un registro che riporta l'algoritmo e la dimensione della chiave di ogni certificato trasforma l'articolo 6 da intenzione scritta in qualcosa di eseguibile, perché vi consente di elencare in pochi minuti ogni asset che si basa ancora su firme RSA o ECDSA.

Campi da registrare per ogni certificato

Mantenete il registro leggibile da una macchina (una riga per certificato, esportata dalle vostre fonti anziché digitata a mano). Le colonne seguenti coprono gli obblighi dell'articolo 7 e contengono i dati necessari a una migrazione post-quantum.

Due campi ripagano lo sforzo di aggiungerli, anche se nessun testo li richiede: la superficie di deployment (quale load balancer, ingress, broker o peer mutual TLS presenta il certificato) e un indicatore di prontezza post-quantum per asset, impostato in base a misurazioni anziché a intenzioni.

Ciclo di vita delle chiavi: che cosa documentare per le chiavi, non per i certificati

Un certificato è un oggetto pubblico con una data di scadenza. L'obbligo relativo al ciclo di vita delle chiavi riguarda materiale che non dovete mai esportare, quindi il registro riporta informazioni sulla chiave anziché la chiave stessa. Per ogni chiave, o per ogni classe di chiavi quando ne avete migliaia, registrate: metodo di generazione e fonte di entropia, algoritmo e parametri approvati, perimetro di conservazione (software, HSM, keystore cloud con il relativo livello di protezione), chi detiene i diritti di amministrazione e di recupero, modalità di backup e di escrow, durata di archiviazione per le chiavi che devono ancora verificare firme datate, criteri di ritiro, procedura di distruzione e relative evidenze, e il playbook in caso di compromissione con il relativo responsabile decisionale.

Distinguete tre categorie, perché i loro percorsi di migrazione differiscono. Le chiavi di key agreement proteggono la riservatezza in transito, e il traffico registrato può essere decifrato in seguito se il key agreement viene violato: per questo l'attacco harvest now, decrypt later rende lo scambio di chiavi la prima cosa da migrare. Le chiavi di firma autenticano, e una firma falsificata nel 2035 non può violare retroattivamente una sessione di oggi, quindi i certificati possono migrare dopo lo scambio di chiavi. Le chiavi di firma a lunga durata sono l'eccezione: le chiavi di firma di firmware e software che devono restare affidabili per un decennio meritano attenzione già ora, e il NIST ha standardizzato le firme hash-based stateful proprio per questo caso in SP 800-208 (LMS e XMSS, si veda SP 800-208).

Discovery: come popolare il registro

Nessuna singola fonte contiene tutti i certificati. Combinatene almeno quattro e considerate ciascuna come parziale.

1. Interrogare le autorità di certificazione

I database delle CA interne e i vostri account presso le CA pubbliche elencano tutto ciò che hanno emesso. Le emissioni pubbliche sono inoltre visibili nei log di Certificate Transparency, che rappresentano il modo più rapido per trovare certificati emessi per i vostri domini da team di cui ignoravate l'esistenza.

2. Scansionare ciò che è effettivamente in ascolto

I controlli in sola lettura su un host mostrano il certificato in produzione, che a volte non è quello che pensate di aver distribuito. Effettuate prima i test in un ambiente non di produzione e verificate di essere autorizzati a eseguire la scansione.

# Inspect the presented chain and the key algorithm
openssl s_client -connect host.example.com:443 -servername host.example.com -showcerts </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -serial -fingerprint -sha256 -text \
  | grep -E "Subject:|Issuer:|Not (Before|After)|Public Key Algorithm|Public-Key|Signature Algorithm|DNS:"

# Which key agreement group was negotiated (OpenSSL 3.5 or later for the ML-KEM groups)
openssl s_client -connect host.example.com:443 -servername host.example.com \
  -groups X25519MLKEM768:X25519 </dev/null 2>/dev/null | grep -E "Negotiated|Protocol"

3. Esplorare filesystem e keystore

# Certificates and keys on disk, with expiry, for one host
find /etc /opt /srv -type f \( -name "*.pem" -o -name "*.crt" -o -name "*.cer" \) 2>/dev/null \
  | while read -r f; do
      printf '%s\t' "$f"
      openssl x509 -in "$f" -noout -subject -enddate 2>/dev/null || echo "not a certificate"
    done

# Java keystore contents (read-only listing)
keytool -list -v -keystore /path/to/keystore.jks | grep -E "Alias name|Valid from|Signature algorithm"

4. Interrogare le piattaforme che gestiscono i certificati per voi

Secret Kubernetes e risorse cert-manager, certificate manager cloud, key vault cloud e partizioni HSM, service mesh che emettono certificati mutual TLS a breve durata, API gateway, message broker, configurazione TLS dei database, concentratori VPN e servizi di firma del codice. I certificati di mesh a breve durata sono di norma registrati meglio come riga di policy (emittente, algoritmo, durata, meccanismo di rotazione) che come milioni di righe individuali; indicatelo esplicitamente nel registro, in modo che un revisore veda che la scelta è stata deliberata.

# cert-manager inventory across a cluster (read-only)
kubectl get certificates -A \
  -o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,ISSUER:.spec.issuerRef.name,SECRET:.spec.secretName,RENEWAL:.status.renewalTime,EXPIRY:.status.notAfter

Fin dal primo giorno, l'automazione conta più della completezza. Le istruzioni federali statunitensi previste da OMB M-26-15 richiedono un inventario crittografico automatizzato e aggiornato in modo continuo, e il principio è facilmente trasferibile: un registro aggiornato da un job pianificato sopravvive, un foglio di calcolo aggiornato per buona volontà no.

Collegare il registro all'inventario crittografico

Il registro dei certificati è uno strato di un inventario più ampio. Manteneteli collegati anziché fusi: il registro dei certificati indica quali credenziali esistono e quando scadono, mentre l'inventario crittografico indica quali algoritmi utilizzano effettivamente il vostro software e i vostri protocolli, compresi key agreement, cifratura simmetrica dei dati a riposo, hashing e librerie. Una cryptography bill of materials (CBOM) è un modo pratico per descrivere lo strato software, come illustrato in che cos'è una CBOM; si tratta della nostra interpretazione delle buone pratiche, non di un requisito DORA.

Gli stessi artefatti servono a più framework, ed è questo l'argomento per costruirli una sola volta.

Sulle date, mantenete distinzioni precise. Il requisito 12.3.3 di PCI DSS v4.0.1 è obbligatorio dal 31 marzo 2025. La EU Coordinated Implementation Roadmap v1.1, pubblicata il 23 giugno 2025, è una guida coordinata per gli Stati membri e non un regolamento vincolante per le imprese: colloca gli inventari crittografici e le roadmap nazionali entro la fine del 2026, la migrazione dei casi d'uso ad alto rischio entro la fine del 2030 e quella dei casi a rischio medio entro la fine del 2035. NIST IR 8547 resta una bozza pubblica iniziale; propone di deprecare gli algoritmi vulnerabili ai computer quantistici con sicurezza a 112 bit dopo il 2030 e di non consentire più gli algoritmi a chiave pubblica vulnerabili ai computer quantistici dopo il 2035, e va citato come bozza. L'insieme completo delle scadenze datate è disponibile nel nostro hub normativo.

Errori frequenti

• Registrare solo i certificati web pubblici. Mutual TLS tra servizi interni, client di database, message broker, firma del codice e identità dei dispositivi superano di norma per numero quelli pubblici.
• Omettere l'ubicazione della chiave privata. Senza di essa non potete rispondere all'unica domanda che conta durante una compromissione: dov'è la chiave e chi può raggiungerla.
• Considerare la scadenza come unico evento del ciclo di vita. Una revoca mai provata è un controllo non testato.
• Lasciare che il perimetro cambi senza che nessuno se ne accorga. Quando una funzione viene riclassificata come critica o importante, i suoi certificati entrano nel perimetro. Rieseguite la regola di perimetro a intervalli pianificati e conservate l'output datato.
• Confondere la migrazione dei certificati con quella dello scambio di chiavi. Il key agreement ibrido protegge il traffico registrato oggi ed è già distribuibile; i certificati post-quantum dipendono dal supporto di CA e client. Iniziate dallo scambio di chiavi, come spiegato in crypto-agility.
• Mantenere algoritmi pre-standard obsoleti. I gruppi TLS delle bozze Kyber sono superati dai gruppi ML-KEM standardizzati; il gruppo ibrido da cercare è X25519MLKEM768.

Passo successivo: misurare prima di documentare

Un registro costruito sulle intenzioni invecchia male, quindi compilate le colonne relative ad algoritmo e prontezza a partire da misurazioni. Per ogni asset raggiungibile dall'esterno che supporta una funzione critica o importante, scansionate il vostro dominio con PQC Status per rilevare le versioni TLS negoziate, i gruppi di key agreement offerti, le cipher suite e la catena di certificati, quindi riportate questi valori direttamente nel registro. La scansione descrive esclusivamente la configurazione TLS visibile dall'esterno: non è una certificazione né un'attestazione di conformità, e la nostra pagina sulla metodologia spiega con precisione che cosa dimostra e che cosa non dimostra. Una volta registrata la superficie esterna, ripetete i comandi di discovery descritti sopra sui listener interni, assegnate un responsabile a ogni riga e pianificate l'esportazione in modo che il registro si aggiorni da solo.