Modello di valutazione del rischio quantistico, con un metodo di punteggio trasparente

Un modello di valutazione del rischio quantistico è un'unica tabella con una riga per asset crittografico e sei colonne che ne determinano la priorità: asset, algoritmo in uso, durata di conservazione dei dati, esposizione, tempo di migrazione e dipendenza dai fornitori. Il metodo di punteggio descritto di seguito è volutamente trasparente: ogni numero deriva dalle vostre stime e dalle scadenze di migrazione pubblicate, mai da una data prevista per l'arrivo di un computer quantistico. Copiate la struttura, conservate le evidenze accanto a essa e avrete un inventario difendibile in sede di audit.

Le sei colonne e la domanda a cui risponde ciascuna

Mantenete il modello essenziale. Sei colonne bastano per stabilire le priorità, e una tabella essenziale viene effettivamente compilata. Responsabile, riferimento del ticket e data di revisione sono elementi amministrativi: utili, ma non modificano una priorità.

Perché lo scambio di chiavi richiede un indicatore dedicato

Il traffico registrato è protetto unicamente dallo scambio di chiavi. È tutta la logica di harvest now, decrypt later (HNDL): un avversario memorizza oggi il testo cifrato e lo decifra quando la matematica lo consentirà. Le firme si comportano diversamente, perché falsificare una firma in futuro non espone retroattivamente una sessione passata. Per questo il modello include un indicatore di vulnerabilità che distingue i due casi, invece di trattare tutti gli algoritmi vulnerabili ai computer quantistici come un unico rischio.

Punteggio: tre fasce per colonna

Ogni colonna riceve un punteggio di 1, 2 o 3, con le definizioni delle fasce scritte nel modello, in modo che due valutatori giungano allo stesso numero a partire dagli stessi fatti. Le fasce di durata di conservazione indicate di seguito sono un punto di partenza: adattatele al vostro piano di conservazione e ai vostri contratti, e registrate l'adattamento nel modello affinché il punteggio resti verificabile.

Ne derivano due somme, che devono restare separate. L'urgenza, U = Q + S + E, da 3 a 9, misura il costo di un ritardo. Il tempo di attuazione, L = M + D, da 2 a 6, misura quanto dura la modifica una volta avviata. Farne la media in un unico valore distrugge proprio l'informazione di cui avete bisogno, perché una riga urgente ed economica e una riga costosa e lenta richiedono decisioni diverse.

La disuguaglianza di Mosca come ragionamento, non come profezia

Michele Mosca ha formulato il problema della migrazione con tre grandezze: X, il tempo durante il quale i vostri dati devono restare riservati; Y, il tempo necessario per migrare; Z, il tempo che manca prima che l'algoritmo possa essere violato. Se X più Y è maggiore di Z, i dati che lasciano oggi i vostri sistemi sono già fuori dalla loro finestra di protezione.

Z non è conoscibile, e questo sito non ne pubblica alcuna stima. La sostituzione utile consiste nel rimpiazzare Z con un orizzonte di pianificazione di cui siete responsabili: la prima scadenza datata nel vostro perimetro normativo. La disuguaglianza smette allora di essere una previsione e diventa un calcolo di conformità, senza alcuna probabilità inventata.

Il calcolo è breve. Una riga con una durata di conservazione di 10 anni e un tempo di migrazione di 2 anni richiede 12 anni di protezione. Un orizzonte a fine 2030 dista circa 4 anni. Dodici è maggiore di quattro, quindi l'indicatore è attivo: iniziate subito. Questa affermazione non dice nulla su quando esisterà un computer quantistico, ma soltanto che la finestra di protezione si estende oltre la data fissata dal vostro stesso ambito. Registrate l'orizzonte utilizzato in una colonna accanto all'indicatore, così un revisore potrà contestare l'orizzonte senza rifare la valutazione.

Trasformare i punteggi in un ordine di lavoro

1. Le righe con l'indicatore di Mosca attivo e Q pari a 3 vengono per prime, a partire dalla U più alta. Sono le righe HNDL, in cui un ritardo non può essere recuperato in seguito.
2. A parità di urgenza, mettete per primo il tempo di attuazione più lungo. La sostituzione di un HSM deve iniziare prima di una modifica di configurazione di una riga, anche se la modifica di configurazione si conclude prima.
3. Le righe con Q pari a 1 escono dalla coda ed entrano in un elenco di monitoraggio, rivisto con la stessa cadenza di tutto il resto, perché un'implementazione ibrida oggi può regredire domani.

U = Q + S + E          # urgency, 3 to 9
L = M + D              # lead time, 2 to 6
sort by (mosca_flag, Q, U, L), all descending

Non ci sono pesi né moltiplicazioni, ed è una scelta deliberata. Un punteggio composito ponderato nasconde quale stima il revisore contesta. Quattro componenti visibili consentono a un auditor di contestare una singola cella, non l'intera classifica.

Compilare le colonne con evidenze, non con opinioni

Tre fonti coprono la maggior parte delle righe. Per tutto ciò che ha un endpoint pubblico, leggete direttamente il gruppo negoziato. OpenSSL 3.5 o successivo è necessario per i gruppi ML-KEM, e i nomi dei gruppi ibridi sono registrati presso IANA: X25519MLKEM768 (codepoint 0x11EC), SecP256r1MLKEM768 (0x11EB) e SecP384r1MLKEM1024 (0x11ED).

openssl s_client -connect example.com:443 -groups X25519MLKEM768 </dev/null 2>/dev/null \
  | grep -i 'Negotiated TLS1.3 group'

ssh -Q kex | grep mlkem

Per l'accesso amministrativo, OpenSSH ha reso mlkem768x25519-sha256 l'accordo di chiavi predefinito nella versione 10.0 (9 aprile 2025), e la 10.1 (6 ottobre 2025) emette un avviso quando una connessione negozia un accordo di chiavi non post-quantistico, secondo le note di rilascio di OpenSSH. Per codice, librerie e artefatti di build, un CBOM (cryptographic bill of materials) compila la colonna degli algoritmi su larga scala, il che è importante perché un inventario compilato a mano invecchia il giorno stesso in cui viene completato. Testate qualsiasi modifica dei gruppi in ambiente di staging e mantenete un fallback classico come X25519 elencato dopo X25519MLKEM768.

Collegare il modello agli obblighi

Questa sezione ha carattere informativo e non costituisce consulenza legale. Quando una riga qui sopra riflette la nostra lettura anziché il testo stesso, è indicata come interpretazione, e la vostra copia del modello dovrebbe mantenere visibile questa distinzione per gli auditor.

Prima misurare, poi assegnare i punteggi

Punteggi basati su una configurazione presunta non valgono nulla. Partite dai fatti visibili dall'esterno: eseguite una scansione gratuita del vostro dominio con PQC Status per vedere i gruppi TLS negoziati, le versioni e la catena di certificati, riportate il risultato nelle colonne Algoritmo ed Esposizione delle prime righe, quindi procedete verso l'interno con ssh -Q kex e un CBOM. Una scansione descrive soltanto la configurazione TLS visibile dall'esterno: non è una certificazione né un'attestazione di conformità, ma è l'unica colonna che nessuno può contestare.