La policy di cifratura DORA ai sensi dell'Articolo 6 degli RTS

L'Articolo 6 del Regolamento delegato (EU) 2024/1774 della Commissione, le norme tecniche di regolamentazione (RTS) sulla gestione del rischio ICT ai sensi del DORA, impone a un'entità finanziaria di disporre di una policy sulla cifratura e sui controlli crittografici, e tale policy deve contenere disposizioni per l'aggiornamento o la sostituzione della tecnologia crittografica in base agli sviluppi della crittoanalisi. Il testo non nomina alcun algoritmo e non fissa alcuna scadenza post-quantum. Di seguito separiamo il requisito letterale dalla nostra opinione su come redigere il documento e su come dimostrarne l'attuazione. ICT indica le tecnologie dell'informazione e della comunicazione. Questo contenuto ha valore informativo e non costituisce consulenza legale.

Cosa richiede letteralmente l'Articolo 6

Gli RTS sono vincolanti per le entità finanziarie che rientrano nel loro ambito di applicazione, e l'Articolo 6 è il loro articolo dedicato alla cifratura. Richiede una policy documentata sulla cifratura e sui controlli crittografici, adottata nell'ambito delle policy di sicurezza ICT e fondata sui risultati della classificazione dei dati e della valutazione del rischio ICT. La policy affronta la protezione dei dati negli stati in cui l'entità li gestisce effettivamente: a riposo, in transito e, ove pertinente e tecnicamente fattibile, in uso. Quando la cifratura dei dati in uso non è fattibile, ci si attende che l'entità tratti i dati in un ambiente protetto o applichi altre misure, registrando tale scelta. L'articolo rimanda alle migliori pratiche e agli standard riconosciuti anziché a un elenco fisso di algoritmi. E contiene la clausola più rilevante per il lavoro post-quantum: la policy deve includere disposizioni per aggiornare o sostituire la tecnologia crittografica in funzione dell'evoluzione della crittoanalisi. Il testo ufficiale è disponibile su EUR-Lex, e la nostra sintesi datata si trova nella pagina sugli RTS DORA. Verificate sempre la numerazione dei paragrafi sul testo consolidato prima di citarla in una risposta di audit.

L'Articolo 7 è la disposizione complementare: gestione delle chiavi crittografiche lungo l'intero ciclo di vita (generazione, rinnovo, conservazione, archiviazione, recupero, distruzione) e un registro dei certificati e dei dispositivi che memorizzano certificati, almeno per gli asset ICT che supportano funzioni essenziali o importanti. Leggete i due articoli insieme. La maggior parte delle prove che un valutatore richiede ai sensi dell'Articolo 6 si trova negli inventari e nei registri che l'Articolo 7 vi obbliga a mantenere.

Cosa l'Articolo 6 non dice

Non nomina ML-KEM (meccanismo di incapsulamento delle chiavi basato su reticoli modulari, standardizzato dal NIST come FIPS 203 il 13 agosto 2024), non menziona lo scambio di chiavi ibrido e non indica alcuna data di migrazione. Questi segnali provengono da altri documenti, ciascuno con il proprio status. NIST IR 8547 è una bozza pubblica iniziale (12 novembre 2024, tuttora una bozza) che propone di deprecare gli algoritmi vulnerabili ai computer quantistici con sicurezza a 112 bit dopo il 2030 e di vietare tutti gli algoritmi a chiave pubblica vulnerabili ai computer quantistici dopo il 2035. La Roadmap di implementazione coordinata dell'UE v1.1 (pubblicata il 23 giugno 2025) è una guida coordinata per gli Stati membri, non un regolamento vincolante per le imprese: fissa i primi passi, tra cui un inventario crittografico e roadmap nazionali entro la fine del 2026, la migrazione dei casi d'uso ad alto rischio entro la fine del 2030 e di quelli a rischio medio entro la fine del 2035. NIS2 Article 21(2)(h) richiede separatamente policy e procedure sull'uso della crittografia e, ove opportuno, della cifratura. Le entità soggette a entrambe le normative dovrebbero redigere un'unica policy e mapparla due volte, anziché mantenere due documenti.

Una struttura sezione per sezione

La struttura seguente è una nostra interpretazione, non un modello pubblicato da un'autorità di regolamentazione. È organizzata in modo che ogni sezione risponda a una domanda che un valutatore porrà probabilmente, e che la parte più volatile (gli algoritmi) si trovi in un allegato da versionare senza riaprire l'intera policy.

1. Finalità, ambito e governance. Quali entità, sistemi e terze parti sono coperti, chi approva la policy, chi ne è responsabile, con quale cadenza viene riesaminata.
2. Definizioni e ruoli. Custode delle chiavi, architetto crittografico, responsabile dell'asset, responsabile del certificato. Definite ogni acronimo una sola volta.
3. Collegamento con la classificazione dei dati. Per ciascun livello di classificazione, la protezione richiesta in ogni stato dei dati. È ciò che rende la policy basata sul rischio anziché generica.
4. Algoritmi, lunghezze delle chiavi e protocolli approvati (Allegato A). Una tabella versionata con tre colonne: preferito, accettabile, vietato. Citate lo standard alla base di ogni voce.
5. Dati a riposo. Dischi, database, object storage, backup, archivi, endpoint. Indicate il meccanismo e chi verifica la copertura.
6. Dati in transito. Versione minima di TLS, cipher suite e gruppi di scambio di chiavi approvati, traffico interno tra servizi, trasferimento di file, posta elettronica, amministrazione remota.
7. Dati in uso. Dove si applica e, dove non si applica, l'ambiente protetto o le altre misure adottate in alternativa, con la motivazione registrata.
8. Chiavi e certificati. Rimando all'Articolo 7: regole sul ciclo di vita, uso di hardware security module e di servizi di gestione delle chiavi, periodi di rotazione, il registro dei certificati e i relativi avvisi di scadenza.
9. Inventario crittografico e fornitori. Come viene costruito e aggiornato l'inventario, e cosa richiedete ai fornitori terzi di servizi ICT.
10. Sostituzione della tecnologia crittografica (Allegato B). La clausola di agilità, descritta nella sezione successiva.
11. Eccezioni e sistemi legacy. Un registro di eccezioni a tempo determinato, ciascuna con un controllo compensativo, un responsabile e una data di scadenza.
12. Prove e reporting. Quale artefatto dimostra quale clausola, chi lo produce e con quale frequenza.

La disposizione sul cambiamento: la crypto agility per iscritto

Una clausola secondo cui l'entità monitorerà gli sviluppi crittografici non costituisce una prova. Una clausola che un valutatore può verificare indica l'evento scatenante, il responsabile, l'inventario su cui agisce e il tempo necessario per intervenire. Bastano cinque elementi.

• Fonti degli eventi scatenanti. Documenti e fonti specifici che monitorate: standard e bozze del NIST, BSI TR-02102-1 (una linea guida tecnica, la cui versione 2026-01 raccomanda lo scambio di chiavi ibrido post-quantum e raccomanda lo scambio di chiavi classico da solo soltanto fino alla fine del 2031, fine del 2030 per esigenze di protezione molto elevate), le pubblicazioni dell'ANSSI (le cui raccomandazioni post-quantum non sono ancora obblighi regolamentari al di fuori del suo ambito regolamentato), gli avvisi di fine supporto dei fornitori e i risultati crittoanalitici pubblicati.
• Un responsabile delle decisioni. Un unico ruolo abilitato a modificare l'Allegato A, con un comitato che approva le modifiche e una registrazione della data, della motivazione e del documento di riferimento.
• Un inventario con responsabili. Non si può cambiare ciò che non si sa elencare. Un cryptographic bill of materials (CBOM) è un modo pratico per produrlo, e questa è una nostra interpretazione, non un requisito del testo.
• Classi di asset con date obiettivo. Raggruppate gli asset per esposizione e per la durata per cui i loro dati devono restare riservati, quindi assegnate a ciascun gruppo una data obiettivo anziché una sola data per l'intero parco.
• Una regola di rilascio sicuro. I nuovi algoritmi vengono abilitati affiancati da un fallback classico, testati in staging e solo allora promossi.

Perché iniziare dallo scambio di chiavi: il traffico registrato è protetto soltanto dallo scambio di chiavi che ha stabilito la sessione, quindi il traffico intercettato oggi può essere decifrato in futuro se tale scambio è vulnerabile ai computer quantistici. Firme e certificati possono migrare in un secondo momento, perché una firma verificata oggi non diventa falsificabile retroattivamente. È questa la ragione concreta per cui lo scambio di chiavi ibrido, ad esempio X25519MLKEM768 (codepoint IANA 0x11EC), rappresenta il primo passo concreto per un'entità finanziaria. I gruppi Kyber pre-standard come X25519Kyber768Draft00 (0x6399) sono obsoleti e dovrebbero figurare come vietati nell'Allegato A. Per i gruppi ML-KEM in OpenSSL è necessario OpenSSL 3.5 o successivo.

Section 10. Changing cryptographic technology

10.1 Annex A (approved algorithms) is reviewed at least every 12 months and on any
     of these triggers: a new or withdrawn standard, an update to a national
     technical guideline we track, a published cryptanalytic result, a supplier
     end-of-support notice, or a change in the classification of data we protect.
10.2 The CISO owns Annex A. Changes are approved by the ICT risk committee and
     recorded with a date, a rationale and the source document.
10.3 Each asset class in Annex B has a named owner and a target date for migration
     to the algorithms marked preferred in Annex A.
10.4 Where an asset cannot meet its target date, the owner records a time-limited
     exception with a compensating control and an end date.
10.5 A new algorithm is deployed with a classical fallback, validated in staging,
     and promoted only after a documented interoperability test.

Dal requisito alla prova

La colonna di sinistra parafrasa il requisito. La colonna centrale riporta la nostra interpretazione delle prove che lo soddisfano, non un elenco pubblicato da un'autorità.

Verificate le affermazioni sul transito prima che lo faccia un valutatore

Le affermazioni della policy sui dati in transito sono le più facili da verificare e le più facili da sbagliare, perché un load balancer, una content delivery network o un virtual host legacy possono contraddire silenziosamente la baseline. Iniziate con una verifica in sola lettura, con OpenSSL 3.5 o successivo:

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

Eseguitela su ogni hostname pubblico presente nel vostro registro, non solo sul sito principale. Se il vostro perimetro rientra anche nell'ambito di PCI DSS, lo stesso inventario alimenta il requisito 12.3.3, obbligatorio dal 31 marzo 2025, che richiede cipher suite e protocolli documentati e riesaminati almeno ogni 12 mesi, come descritto nella nostra nota sull'inventario crittografico PCI DSS. Un solo inventario, due mappature.

Quattro errori comuni

• Inserire scadenze nella policy come se le avessero fissate gli RTS. Citate le tempistiche esterne come eventi scatenanti di un riesame e spiegatene lo status, poiché linee guida e bozze non sono obblighi.
• Una policy senza un inventario alle spalle. La disposizione sul cambiamento non è verificabile senza un elenco degli asset, della loro crittografia e dei loro responsabili.
• Trattare una scansione esterna come un'attestazione. Una scansione descrive la configurazione visibile dall'esterno di un determinato endpoint in un determinato momento. Non è una certificazione né un'attestazione di conformità.
• Congelare l'elenco degli algoritmi nel corpo della policy. Mantenetelo in un allegato con un proprio numero di versione, così che un cambiamento nella crittoanalisi non richieda un ciclo completo di approvazione della policy.

Prossimo passo

Partite dalle prove che potete raccogliere oggi: elencate i vostri endpoint pubblici, registrate quale scambio di chiavi negozia ciascuno e allegate questo output alla sezione della policy sui dati in transito. Potete scansionare gratuitamente il vostro dominio con PQC Status per vedere le versioni TLS, le cipher suite, il supporto a ML-KEM ibrido e la catena di certificati visibili a un osservatore esterno, quindi usare le lacune individuate per fissare le date obiettivo per classe di asset nell'Allegato B. Ripetete la scansione dopo ogni modifica, così che il registro degli eventi scatenanti contenga prove datate del prima e del dopo.