Checklist di preparazione post-quantum per i team di sicurezza

Una checklist di preparazione alla crittografia post-quantum (PQC) ha un solo compito: trasformare una migrazione pluriennale in voci che un team può completare in questo trimestre, ciascuna delle quali lascia un'evidenza leggibile da altri. L'ordine conta. Lo scambio di chiavi viene per primo perché il traffico registrato è protetto soltanto dallo scambio di chiavi; seguono inventario, fornitori, firme e monitoraggio. Ogni voce indica l'artefatto da produrre, non solo l'idea da considerare.

Come usare questa checklist

Affrontate le fasi in ordine, ma conducete la discovery (fase 2) e i quick win (fase 3) in parallelo: attendere un inventario completo prima di abilitare lo scambio di chiavi ibrido su un endpoint web pubblico ritarda l'unico controllo che mitiga il rischio sul traffico registrato. Assegnate a ogni voce un responsabile, una data e un artefatto. L'artefatto è il punto centrale: PCI DSS, DORA e NIS2 richiedono policy, inventari e riesami documentati, e una migrazione non documentata appare esattamente come una migrazione mai avvenuta. Questo articolo ha carattere informativo e non costituisce consulenza legale.

Quattro termini ricorrono nel testo. ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) è lo scambio di chiavi post-quantum standardizzato in NIST FIPS 203, pubblicato come standard definitivo il 13 agosto 2024. Un KEM (key encapsulation mechanism) è la primitiva che stabilisce un segreto condiviso. HNDL (harvest now, decrypt later) è la pratica di registrare oggi traffico cifrato per decifrarlo quando esisterà un computer quantistico sufficientemente potente. Un CBOM (cryptographic bill of materials) è un inventario leggibile dalle macchine degli asset crittografici.

Fase 1: governance e perimetro

• Nominate un unico responsabile e un gruppo di lavoro che includa architettura di sicurezza, PKI, rete, responsabili applicativi e procurement. Evidenza: un mandato di una pagina con nomi, perimetro e cadenza delle riunioni.
• Scegliete la tempistica su cui ancorare il piano (autorità di settore, linee guida nazionali, contratti con i clienti). Evidenza: una breve dichiarazione di applicabilità che indichi i framework vincolanti per voi e quelli che trattate come linee guida. La nostra panoramica delle scadenze ufficiali di migrazione post-quantum li elenca con le relative fonti.
• Inserite la crypto-agility nella policy di cifratura. Le norme tecniche di regolamentazione DORA, Regolamento delegato (UE) 2024/1774 della Commissione, Art. 6, richiedono una policy sulla cifratura e sui controlli crittografici che preveda disposizioni per aggiornare o modificare la tecnologia crittografica in base agli sviluppi della crittoanalisi. NIS2, Direttiva (UE) 2022/2555, Art. 21(2)(h), richiede politiche e procedure relative all'uso della crittografia e, se del caso, della cifratura. Evidenza: la versione approvata e datata della policy, con la clausola in evidenza.
• Identificate i dati con lunghi orizzonti di riservatezza: segreti, dati sanitari e finanziari, proprietà intellettuale, tutto ciò la cui esposizione nel 2040 sarebbe ancora dannosa. Evidenza: un elenco dei sistemi con la durata di segretezza richiesta per ciascuna classe di dati.
• Registrate HNDL nel registro dei rischi con il suo nome, indicando i sistemi interessati. Evidenza: la voce di rischio con responsabile e data di riesame.

Date di riferimento per la pianificazione

Fase 2: discovery e inventario

• Censite prima la superficie esterna: ogni hostname pubblico, le sue versioni TLS, i gruppi di scambio di chiavi offerti, le cipher suite e la catena di certificati. Evidenza: un export di scansione datato per ogni hostname, conservato come fotografia iniziale.
• Estendete all'interno: terminatori TLS e load balancer, concentratori VPN, parchi SSH, mutual TLS tra servizi, connessioni a database e code di messaggi, HSM, cifratura dei backup, pipeline di firma di firmware e software. Evidenza: un inventario con finalità, ubicazione e responsabile per ogni voce, che è anche ciò che il requisito 12.3.3 di PCI DSS v4.0.1 si aspetta per le cipher suite e i protocolli in uso.
• Rendete la discovery ripetibile, non un foglio di calcolo una tantum. OMB M-26-15 chiede alle agenzie statunitensi un inventario crittografico automatizzato e aggiornato in modo continuo; questo livello è un obiettivo ragionevole anche altrove, dove non si applica.
• Producete un CBOM. Si tratta di una nostra interpretazione, non di un requisito letterale dei testi citati: un CBOM è un modo pratico per documentare un inventario e confrontarlo tra una release e l'altra. Consultate cosa contiene un CBOM per la struttura.
• Segnalate ciò che è obsoleto e ciò che è vulnerabile ai computer quantistici: RSA, ECDSA, EdDSA, ECDH, DH su campi finiti e DSA sono violati dall'algoritmo di Shor su un computer quantistico sufficientemente grande, qualunque sia la dimensione della chiave. RC4 è vietato in TLS (RFC 7465), MD5 e SHA-1 sono obsoleti per le firme e il gruppo TLS Kyber pre-standard X25519Kyber768Draft00 (codepoint 0x6399) dovrebbe essere rimosso.

openssl version
openssl s_client -connect example.com:443 -tls1_3 -groups X25519MLKEM768 </dev/null 2>/dev/null | grep -i "Negotiated TLS1.3 group"
ssh -Q kex | grep mlkem
ssh -v user@example.com 2>&1 | grep "kex: algorithm"

Per i gruppi ML-KEM è necessario OpenSSL 3.5 o successivo. Se openssl s_client rifiuta il nome del gruppo, il client è troppo vecchio e il risultato non dice nulla sul server.

Fase 3: quick win sullo scambio di chiavi

• Abilitate lo scambio di chiavi ibrido sugli endpoint TLS pubblici. Offrite per primo X25519MLKEM768 (codepoint IANA 0x11EC) e mantenete dopo di esso X25519 classico come fallback. SecP256r1MLKEM768 (0x11EB) e SecP384r1MLKEM1024 (0x11ED) sono le alternative registrate. Le versioni attuali di Chrome, Edge e Firefox offrono già X25519MLKEM768 per impostazione predefinita, quindi l'adozione è immediata per il traffico dai browser. Evidenza: il diff della configurazione più una scansione prima e dopo.
• Testate prima in staging e prestate attenzione ai middlebox che tollerano male messaggi ClientHello più grandi. Evidenza: il resoconto del test in staging ed eventuali rilievi su MTU o frammentazione.
• Aggiornate SSH. OpenSSH 9.9 (19 settembre 2024) ha aggiunto mlkem768x25519-sha256, OpenSSH 10.0 (9 aprile 2025) lo ha reso l'accordo di chiavi predefinito e OpenSSH 10.1 (6 ottobre 2025) emette un avviso quando una connessione negozia un accordo di chiavi non post-quantum. Evidenza: report delle versioni sul parco macchine e scambio di chiavi negoziato per ogni jump host.
• Preferite AES-256 per i dati a riposo di lunga durata. Gli algoritmi simmetrici e le funzioni di hash non sono violati da Shor; l'algoritmo di Grover è il motivo per cui AES-256 è preferito per la protezione a lungo termine.

# nginx built against OpenSSL 3.5 or later: hybrid first, classical kept as fallback
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1;

Sintassi e build richiesta variano tra server e distribuzioni; la nostra guida per abilitare ML-KEM su nginx, Apache, HAProxy e Caddy fornisce le direttive per ciascun server. RFC 10024 (agosto 2026) specifica l'accordo di chiavi ibrido post-quantum e tradizionale per TLS 1.3.

Fase 4: fornitori e procurement

Gran parte del patrimonio IT appartiene ad altri. Inviate le stesse cinque domande a ogni fornitore critico e archiviate le risposte insieme al contratto.

1. Quali gruppi di scambio di chiavi TLS offre oggi il vostro servizio, e possiamo verificarlo dall'esterno?
2. Qual è la vostra roadmap datata per il supporto di ML-KEM, e quali note di rilascio lo annunceranno?
3. Quali implementazioni FIPS 203, 204 o 205 utilizzate, e in quali componenti?
4. Potete fornire un CBOM o un inventario crittografico equivalente per il prodotto fornito?
5. Come gestisce il contratto un cambio di algoritmo imposto da progressi della crittoanalisi?

Evidenza: risposte scritte e datate per ogni fornitore, più una clausola di crypto-agility nei rinnovi. Per i prodotti venduti nell'UE, il Cyber Resilience Act, Regulation (EU) 2024/2847, Annex I, Part I (2)(e), richiede di proteggere la riservatezza, ad esempio cifrando i dati pertinenti a riposo o in transito mediante meccanismi allo stato dell'arte; non cita algoritmi post-quantum. I suoi obblighi di segnalazione si applicano dall'11 settembre 2026 e il regolamento si applica integralmente dall'11 dicembre 2027.

Fase 5: firme, certificati e PKI

• Inventariate gli algoritmi di firma e i periodi di validità. Elencate ogni certificato e chiave di firma la cui validità si estende oltre le vostre date di riferimento. Evidenza: un registro dei certificati, che l'Art. 7 delle RTS DORA richiede per gli asset ICT a supporto di funzioni essenziali o importanti, insieme alla gestione delle chiavi lungo l'intero ciclo di vita.
• Riducete le durate e automatizzate il rinnovo affinché un cambio di algoritmo sia una modifica di configurazione e non un progetto. Evidenza: copertura dell'emissione automatizzata, come percentuale di certificati gestiti in automatico.
• Pianificate separatamente la firma del codice e del firmware. ML-DSA (FIPS 204) e SLH-DSA (FIPS 205) sono gli standard definitivi; LMS e XMSS sono specificati in NIST SP 800-208 e sono stateful, quindi la gestione dello stato è il problema ingegneristico più difficile. Per i National Security Systems statunitensi, CNSA 2.0 richiede l'uso esclusivo dei propri algoritmi entro fine 2030 per la firma di software e firmware e per le apparecchiature di rete tradizionali, ed entro fine 2033 per browser e server web, servizi cloud, sistemi operativi e apparecchiature di nicchia.
• Non imponete ancora certificati post-quantum sul web pubblico. Mantenete come priorità lo scambio di chiavi ibrido: il traffico registrato è protetto dallo scambio di chiavi, quindi firme e certificati possono migrare in seguito, secondo un calendario pianificato.
• Testate fin d'ora la tolleranza alle dimensioni: chiavi pubbliche e firme più grandi mettono sotto pressione gli archivi di certificati, i dispositivi embedded e i buffer di handshake. Evidenza: un report di laboratorio per ogni famiglia di dispositivi.

openssl x509 -in cert.pem -noout -subject -issuer -enddate
openssl x509 -in cert.pem -noout -text | grep -i -E "Signature Algorithm|Public-Key"

Fase 6: monitoraggio e riesame

• Riscansionate la superficie esterna a intervalli regolari e generate un avviso in caso di regressione. La sostituzione di un load balancer o una modifica della configurazione della CDN possono rimuovere silenziosamente il gruppo ibrido. Evidenza: uno storico mensile delle scansioni per hostname.
• Riesaminate cipher suite e protocolli almeno ogni 12 mesi. Questa cadenza è il testo letterale del requisito 12.3.3 di PCI DSS v4.0.1, obbligatorio dal 31 marzo 2025, insieme al monitoraggio della loro validità nel tempo e a una strategia documentata per i cambiamenti previsti nelle vulnerabilità crittografiche. Evidenza: il verbale firmato del riesame annuale.
• Seguite l'evoluzione degli standard. Il NIST ha selezionato HQC come quinto algoritmo e KEM di riserva l'11 marzo 2025, previsto come FIPS 207, senza alcuna bozza pubblicata a settembre 2026. NIST IR 8547 e SP 800-131A Rev. 3 restano bozze pubbliche iniziali.
• Riportate un solo numero ai vertici: la quota di endpoint critici che negoziano uno scambio di chiavi ibrido. Evidenza: un andamento trimestrale, non una fotografia una tantum.

Trasformate la checklist in una prima misurazione

La fase 2 e la fase 6 richiedono lo stesso input: una vista esterna di ciò che i vostri server negoziano effettivamente. Potete scansionare il vostro dominio con PQC Status gratuitamente per vedere le versioni TLS, i gruppi di scambio di chiavi offerti e la catena di certificati, quindi conservare l'export come baseline datata per la voce di inventario. Una scansione descrive solo la configurazione TLS visibile dall'esterno: non è una certificazione né un'attestazione di conformità. Il passo concreto successivo è eseguirla sui vostri tre hostname più esposti, archiviare i risultati e aprire un ticket per ogni hostname che non offre ancora un gruppo ibrido.