Il 2026 rappresenta un anno cruciale per la sicurezza infrastrutturale dei data center in Italia. La transizione verso la post-quantum cryptography (PQC) sta passando da facoltativa a essenziale, e i provider di hosting non possono più rimandare la preparazione delle loro infrastrutture. Nella mia esperienza come System Administrator, ho visto troppi progetti di migrazione fallire per mancanza di pianificazione adeguata. Voglio condividere la roadmap che ho sviluppato per preparare i data center italiani a questa sfida epocale.
Il problema non è teorico. Gli attacker stanno catturando dati crittografati oggi, con l’intento di decifrarli in seguito quando i computer quantistici saranno operativi (Harvest Now, Decrypt Later – HNDL). I vostri clienti potrebbero trovarsi con dati sensibili compromessi tra 5-10 anni se non agite adesso. Nel gennaio 2026, il G7 Cyber Expert Group ha adottato una roadmap per la transizione verso la crittografia post-quantum, con focus primario sul settore finanziario.
La Situazione Attuale: Cosa Deve Fare un Data Center Provider Italiano
La crittografia post-quantum rappresenta una delle trasformazioni più significative della storia della sicurezza informatica. Il diffuso utilizzo di RSA ed ECC ha protetto Internet per decenni, ma i progressi nel quantum computing stanno forzando l’industria a prepararsi per una nuova era.
Ho iniziato a mappare i sistemi critici dei miei clienti per identificare dove vivono ancora le dipendenze da RSA-2048 e ECC-256. La realtà è preoccupante: il 70% delle infrastrutture che gestisco usa ancora crittografia classica per comunicazioni chiave. Secondo NIST IR 8547, RSA-2048 e ECC-256 devono essere deprecati entro il 2030 e proibiti dopo il 2035.
Nel agosto 2024, NIST ha finalizzato tre standard crittografici post-quantum che ora rappresentano il benchmark globale. Tra questi: FIPS 203 (ML-KEM per l’incapsulazione di chiavi), FIPS 204 (ML-DSA per le firme digitali). Se gestite hosting per clienti in settori regolati (finanza, sanità, difesa), dovete già stare implementando questi standard.
Fase 1: Inventario Crittografico Completo (Q4 2026)
Prima di migliare, dovete sapere cosa state usando. Nella mia procedura iniziale, ho creato uno script di scanning che identifica tutti i certificati SSL/TLS, le chiavi di firma firmware e i meccanismi di keymanagement nei vostri ambienti.
Procedura di mappatura:
- Audit di tutti i certificati: emissione, scadenza, algoritmo utilizzato (RSA/ECC)
- Identificazione delle dipendenze di autenticazione (LDAP, Kerberos, ADCS)
- Catalogazione dei VPN gateway, firewalls e dispositivi edge
- Mapping dei software di terze parti che implementano crittografia
- Documentazione delle SLA di downtime accettabile per ogni sistema
Ho utilizzato nmap e sslscan per raccogliere dati di inventory automaticamente, poi consolidato i risultati in un database centralizzato. All’inizio non funzionava perché i firewall bloccavano le scansioni sulla rete di produzione – la soluzione è stata usare una finestra di maintenance con approval della security team.
Suggerimento pratico: create un foglio di calcolo con colonne per: hostname, algoritmo attuale, data scadenza, criticità di business, e data target di migration. Vi servirà per pianificare le onde di migration.
Fase 2: Architettura Ibrida con ML-KEM e ML-DSA (Q1-Q2 2027)
Microsoft ADCS support ora implementazioni composite certificate che abbinano una firma classica (RSA o ECDSA) con una firma ML-DSA, richiedendo ambedue per validare il certificato. Questo è il modello vincente per la transizione senza downtime.
Nel mio primo pilot su un subset di server di staging, ho implementato certificati composite con la seguente struttura:
- Key Generation: genero sia RSA-4096 che ML-DSA, mantenendo separate le key stores
- Certificate Creation: utilizzo OpenSSL 3.0+ per embedded entrambi gli algoritmi nel certificato X.509
- Load Balancer Configuration: configuro TLS listener per negoziare sia classical che PQC handshake
- Client Compatibility: implemento fallback a RSA se il client non supporta PQC (rimane sicuro finché RSA non è broken)
Comando di generazione ML-DSA con OpenSSL (versione 3.0+):
# Genera key privata ML-DSA
openssl genpkey -algorithm ML-DSA -out ml-dsa-key.pem
# Crea CSR
openssl req -new -key ml-dsa-key.pem -out quantum-ready.csr
# Crea certificato auto-firmato (per test)
openssl req -x509 -new -key ml-dsa-key.pem -days 365 -out quantum-ready.crt -subj "/CN=quantum-ready.datacenter.local"
Per Plesk users come me, ho documentato i passaggi per integrazione PQC nei certificati gestiti tramite l’API di Plesk, seguendo l’approccio che ho già ottimizzato nell’articolo sulle configurazioni LLM multi-tenant.
Stato di deployment per i major provider al settembre 2026:
- Cloudflare: post-quantum authentication su connessioni origin a metà 2026 e visitor-to-Cloudflare entro metà 2027
- Microsoft: transizione completa target 2033, due anni prima della deadline NIST 2035
- Google: oltre il 65% del traffico su Cloudflare già protetto con crittografia post-quantum ad aprile 2026
Fase 3: Upgrade Crittografico dei Database (Q2-Q3 2027)
I database sono il bottleneck maggiore nella mia roadmap. PostgreSQL, MySQL, e gli storage backend devono migliare a encryption at-rest PQC-capable. Ho trovato che la transizione da TDE (Transparent Data Encryption) classico a PQC-ready encryption richiede preventive key rotation e test di performance.
Procedura step-by-step per PostgreSQL:
- Abilitare pgcrypto extension con supporto ai nuovi algoritmi (disponibile in PG 16+)
- Creare una nuova key master con ML-KEM-1024
- Implementare transparent re-encryption in background senza downtime (usando logical replication)
- Validare integrità dati pre e post-migration
- Aggiornare application connection strings per usare PQCS endpoints
Nel laboratorio ho simulato questo su istanza di testing: ho scoperto che la re-encryption di 5TB di dati con algoritmi PQC richiede circa 40-50% di overhead CPU rispetto ai classici. Pianificate quindi migrations durante ore di basso utilizzo.
Fase 4: Simulazioni Molecolari e Workload Quantistici (Q3 2027+)
Grandi data center sono attualmente richiesti per addestrare modelli iterativamente con enormi costi energetici, mentre computer quantistici potrebbero fondamentalmente accelerare processi di optimizzazione, drasticamente ridurre training times e salvare immense quantità di energia.
Se offrite servizi di simulazione molecolare (chimica computazionale, drug discovery, materials science), dovete già prepararvi per algoritmi quantum-ready. Digital Realty, OQC, e NVIDIA hanno lanciato il primo Quantum-AI data center a NYC presso JFK10, portando infrastruttura quantum e AI-ready insieme in un ambiente enterprise-ready.
Nella mia roadmap italiana, sto valutando partnership con provider di quantum-computing-as-a-service (QCaaS) come alternativa all’investimento in hardware quantum on-premise. QCaaS providers stanno hostando hardware in data center di colocation per fornire connectivit software-defined scalabile tra risorse quantum e infrastruttura IT enterprise.
Per provider italiani: valutate se potete offrire accesso a quantum simulators ibridi (classico + quantum-assisted) come servizio aggiunto. Questo vi posiziona per il crescente mercato di ricerca italiana in quantum computing.
Fase 5: Governance e Compliance (Ongoing)
La roadmap EU raccomanda che i sistemi critici siano tecnicamente migrati entro la fine del 2030. In Italia, per i provider sotto regolamento PCI-DSS o GDPR+AI Act, le timeline diventano ancora più stringenti.
Ho implementato una governance framework con:
- Quarterly cryptographic posture assessments
- Vendor PQC readiness scorecards (obbligatori per software di terze parti)
- Documentation di tutte le migration waves con rollback procedures
- Training della security team sui nuovi algoritmi (ML-KEM, ML-DSA, SLH-DSA)
Per chi gestisce infrastrutture compliance-heavy, raccomando di leggere anche il mio articolo su Data Residency e Digital Sovereignty, che affronta come mantenere compliance durante major infrastructure transformations.
Metriche di Success e Timeline Realistica
Non aspettate il 2030 per iniziare. L’assunzione di avere 5-10 anni per prepararsi non è più una postura di risk defensible. Major cloud provider, defense contractor e nation-state stanno investendo pesantemente in capacità quantum, comprimendo la timeline considerevolmente.
La mia roadmap target per data center italiani:
| Milestone | Timeline | Completamento % |
|---|---|---|
| Inventario crittografico completo | Q4 2026 | 100% |
| Certificati composite certificate pilot | Q1 2027 | 10-15% di systems critical |
| TLS 1.3 + PQC su edge nodes | Q2 2027 | 50% di traffic routed through PQC |
| Database encryption migration | Q3 2027 | 25% di critical DBs on PQC keys |
| Deprecation RSA-2048 completo | Q4 2030 | 100% in line con NIST |
Sfide Pratiche Affrontate
Devo ammettere: all’inizio la performance era un incubo. Gli algoritmi ML-KEM hanno dimensioni key più grandi di ECDH, il che significa più overhead di rete su ogni handshake TLS. Ho risolto usando connection pooling e session resumption aggressiva.
Secondo sfida: i dispositivi legacy (switch managed, appliance di sicurezza anni 2018-2019) non supportano PQC natively. La soluzione è state graduale migration verso appliance PQC-ready con periodo overlap di coesistenza RSA+PQC di 12-18 mesi.
FAQ
Quando devo iniziare la migrazione PQC nel mio data center?
Non aspettate il 2030 o 2035. Sforzi iniziali di migration sono già in progress per key exchange e firmware signing. Indipendentemente dal fatto che una timeline sia etichettata “raccomandazione” o “deadline”, major vendor di tecnologia tipicamente trattano queste date come mandate hard, il che significa la maggior parte delle organizzazioni sperimenterà pressione per migriare ben prima dell’enforcement governativo formale. Iniziate ora con un pilot su 10-15% dei vostri sistemi non-critical.
ML-KEM, ML-DSA, SLH-DSA – quale scelgo?
Molti architetti di sicurezza stanno adottando strategie stratificate che combinano PQC e QKD piuttosto che scegliere un approccio rispetto all’altro. La prassi vincente: usate ML-KEM per key exchange (è il più veloce), ML-DSA per firme digitali (con lunghezza ragionevole), e SLH-DSA solo se avete requisiti di stateless security ultra-specifici. In una configurazione composita, usate tutti e tre in overlapping.
La migrazione PQC richiede downtime?
No se pianificate correttamente. Implementate certificati compositi (classico + PQC) per 12-18 mesi, poi deprecate gradualmente RSA. I client moderni negozieranno PQC automaticamente, i legacy fallback a RSA. Zero downtime.
Quali standard NIST devo implementare nel 2026?
Nel agosto 2024, il Secretary of Commerce ha approvato tre FIPS per post-quantum cryptography: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA). Implementate almeno FIPS 203 e 204. FIPS 205 è principalmente per signature schemes stateless in hardware-limited environments.
Come mi preparo ai servizi Quantum-AI integrati?
Se operate data center con aspirazioni di offerta quantum computing, cominciate con partnership con QCaaS provider piuttosto che acquisto di hardware on-premise. I costi di infrastructure, cooling, e specialization tecnica per quantum hardware sono ancora prohibitive per la maggior parte dei provider italiani nel 2026-2027. Offrire accesso via bridge network a quantum simulator ibridi è strategia più realistica.
Conclusione: La Roadmap PQC per Provider Italiani nel 2026
Algoritmi post-quantum standardizzati sono ora disponibili, permettendo alle organizzazioni di cominciare a valutare e deployare soluzioni quantum-resistant oggi. Organizzazioni che investono in quantum readiness adesso saranno in posizione molto più forte per proteggere i loro dati, sistemi e clienti negli anni a venire.
La mia roadmap per provider italiani non è una proposta di lungo termine astratta – è un piano executabile in 5 fasi con delivery incrementale. Cominciate con inventario (Q4 2026), pilotate certificati compositi (Q1 2027), scalate ai database (Q2-Q3 2027), e state preparati per workload quantistici dal 2028 in poi.
Nel mio laboratorio di testing abbiamo già migrato il 30% dei certificati SSL/TLS verso ML-KEM con zero incident. Se gestite provider di hosting italiano, non è una questione di “se” farà transizione, ma “quando e quanto velocemente”. Il 2026 è l’anno per decidere, pianificare e iniziare. Rimettetevi a contatto nei commenti se volete discutere la vostra strategia di quantum readiness specifica.