NIS2 e DNS — Cosa devono sapere gli operatori UE regolamentati

La Direttiva NIS2 (Direttiva (UE) 2022/2555) è la regolamentazione di punta dell'UE in materia di cybersecurity. Estende e inasprisce la Direttiva NIS originale, alza i requisiti minimi di cybersecurity in tutta l'Unione e porta decine di migliaia di nuovi soggetti nell'ambito. Per chiunque gestisca DNS in o per l'UE, NIS2 non è più opzionale — è il livello legale minimo.

Questa guida copre cosa significa NIS2 specificamente per il DNS: quali soggetti rientrano nell'ambito, come appaiono le misure di gestione del rischio dell'Articolo 21 nelle operazioni DNS, i tempi di notifica degli incidenti che un fornitore DNS deve rispettare, e una checklist lato acquirente per valutare se il tuo fornitore DNS è pronto per NIS2.

Cosa è NIS2 e perché esiste

NIS2 è stata adottata a dicembre 2022 e gli Stati membri avevano fino al 17 ottobre 2024 per recepirla nel diritto nazionale. Sostituisce la Direttiva NIS del 2016 (NIS1), ampiamente criticata per applicazione incoerente, copertura settoriale ristretta e poteri di supervisione deboli.

L'obiettivo dichiarato della direttiva è stabilire un livello comune elevato di cybersecurity in tutta l'Unione. Lo fa:

1. Estendendo la lista dei settori coperti, inclusi infrastruttura digitale, pubblica amministrazione, produzione alimentare e gestione dei rifiuti.
2. Abbassando le soglie dimensionali — la maggior parte delle organizzazioni di medie dimensioni (>=50 dipendenti o >=10 mln EUR) sono ora nell'ambito.
3. Imponendo due livelli di supervisione: soggetti essenziali (supervisione proattiva, obblighi più elevati) e soggetti importanti (supervisione reattiva, requisiti leggermente più leggeri).
4. Innalzando le sanzioni: fino a 10 mln EUR o 2% del fatturato annuo globale per i soggetti essenziali, 7 mln EUR o 1,4% per i soggetti importanti.
5. Introducendo responsabilità personale degli organi direttivi che non rispettano gli obblighi di cybersecurity.
6. Armonizzando i tempi e i contenuti della notifica degli incidenti in tutta l'UE.

Se la tua organizzazione è nell'ambito, NIS2 non è un regime di conformità soft. I regolatori nazionali (BSI in Germania, ANSSI in Francia, NCSC-NL nei Paesi Bassi, ACN in Italia, ecc.) hanno ora poteri espliciti di ispezione, audit e sanzione.

Dove si colloca il DNS in NIS2

L'Allegato I di NIS2 elenca i settori ad alta criticità. Sotto la voce "infrastruttura digitale", sono nominati esplicitamente come soggetti essenziali:

• Gestori di punti di interscambio Internet
• Fornitori di servizi DNS (esclusi i gestori di server radice)
• Registri di nomi di TLD
• Fornitori di servizi di cloud computing
• Fornitori di servizi di data center
• Fornitori di reti di distribuzione di contenuti
• Prestatori di servizi fiduciari (eIDAS)
• Fornitori di reti pubbliche di comunicazioni elettroniche
• Fornitori di servizi di comunicazioni elettroniche accessibili al pubblico

L'espressione "fornitori di servizi DNS" è ampia. Cattura i fornitori DNS autoritativi (soggetti che rispondono a query su una zona — DNScale, Cloudflare DNS, Route 53, ClouDNS, DNS Made Easy, Dyn, ecc.), i gestori di resolver ricorsivi pubblici (Quad9, OpenDNS, Cloudflare 1.1.1.1, Google Public DNS) e i fornitori di servizi DNS aziendali / gestiti. Il DNS interno / privato usato solo da un'organizzazione generalmente non rientra nell'ambito come servizio, anche se può rientrare come parte dell'infrastruttura più ampia di quell'organizzazione.

Gli Stati membri possono estendere l'elenco — la bozza tedesca NIS2UmsuCG, ad esempio, tratta alcuni hosting provider in modo più ampio del minimo UE.

Articolo 21 — Le misure di gestione del rischio

L'Articolo 21 è il cuore operativo di NIS2. Obbliga i soggetti essenziali e importanti a prendere "misure tecniche, operative e organizzative adeguate e proporzionate" per gestire i rischi di cybersecurity. La direttiva elenca 10 categorie di misure:

1. Analisi dei rischi e politiche di sicurezza dei sistemi informativi
2. Gestione degli incidenti
3. Continuità operativa, inclusa gestione dei backup e recupero
4. Sicurezza della catena di approvvigionamento, inclusa sicurezza delle relazioni con fornitori e prestatori di servizi diretti
5. Sicurezza nell'acquisizione, sviluppo e manutenzione dei sistemi di rete e informativi, inclusa gestione e divulgazione delle vulnerabilità
6. Procedure per valutare l'efficacia delle misure di gestione del rischio di cybersecurity
7. Pratiche di base di igiene cyber e formazione in cybersecurity
8. Politiche e procedure sull'uso della crittografia e, se opportuno, della cifratura
9. Sicurezza delle risorse umane, politiche di controllo degli accessi e gestione degli asset
10. Uso dell'autenticazione a più fattori o di soluzioni di autenticazione continua, comunicazioni voce/video/testo sicure e sistemi di comunicazioni di emergenza sicuri

Per il DNS specificamente, questo si traduce in requisiti operativi concreti:

1. Gestione degli incidenti per downtime e compromissioni DNS

Un fornitore DNS deve avere procedure scritte per rispondere a:

• Downtime autoritativi in un PoP, in una regione o globalmente
• Attacchi DDoS contro la rete anycast
• Compromissione dei dati di zona (modifica non autorizzata dei record cliente)
• Compromissione di chiavi DNSSEC (esposizione di chiave privata KSK o ZSK)
• Compromissione di account operatore che possa portare a modifiche di record

Le procedure devono includere rilevamento, contenimento, eradicazione, ripristino e analisi post-incidente. Devono essere testate. I clienti dovrebbero aspettarsi un contatto di sicurezza, un runbook di risposta agli incidenti e un RTO/RPO pubblicato per il servizio DNS.

2. Crittografia ove appropriata

DNSSEC è il controllo crittografico più direttamente rilevante per il DNS. Ai sensi dell'Articolo 21(2)(h), un fornitore DNS che non offre affatto DNSSEC rischia di essere giudicato non conforme per i clienti ad alta criticità. Funzionalità DNSSEC attese nel 2026:

• Supporto algoritmi: ECDSA P-256 (algoritmo 13) o Ed25519 (algoritmo 15) — RSA-SHA256 (algoritmo 8) accettabile ma considerato legacy.
• Rotazione automatica delle chiavi (KSK e ZSK) senza downtime per il cliente.
• Memorizzazione sicura delle chiavi — basata su HSM o equivalente.
• Reporting pubblico del DS via API per automazione registrar.

Per i dati in transito tra interfacce operatore e cliente, TLS 1.2+ con cipher suite moderne è il minimo.

3. Sicurezza della catena di approvvigionamento — Articolo 21(2)(d)

Questa disposizione è dove NIS2 raggiunge i clienti dei fornitori DNS. L'Articolo 21(2)(d) obbliga ogni soggetto nell'ambito a gestire la sicurezza delle relazioni con i fornitori diretti. Se il tuo fornitore DNS ha un incidente di sicurezza che ti riguarda, i regolatori si aspettano che tu abbia fatto la due diligence in anticipo.

In pratica, questo significa:

• Documentare i fornitori nella tua catena DNS (registrar, hosting DNS primario, hosting DNS secondario, resolver ricorsivo gestito se applicabile).
• Ottenere prove della loro postura di sicurezza (certificazioni, relazioni di audit, politica di sicurezza pubblica).
• Stabilire SLA contrattuali per notifica incidenti e ripristino.
• Rivalutare con cadenza documentata (annualmente come minimo).

4. Autenticazione a più fattori

L'Articolo 21(2)(j) richiede MFA per le interfacce di gestione. Per il DNS questo significa:

• MFA sulla dashboard cliente del fornitore DNS.
• MFA presso il registrar dove sono gestiti i record NS (sicurezza della delega).
• Gestione delle chiavi API con permessi limitati e politica di rotazione.
• Niente credenziali condivise di lunga durata; gli account di servizio devono essere auditabili.

5. Continuità operativa e backup

Continuità specifica per DNS:

• Anycast multi-regione in modo che un singolo guasto regionale non metta una zona offline.
• DNS multi-provider per le zone di livello più alto — vedi /learning/multi-provider-dns-deployment.
• Backup dei dati di zona che possano essere ripristinati rapidamente presso un altro fornitore.
• Procedure di ripristino testate con RTO/RPO documentati.

Articolo 23 — Tempi di notifica degli incidenti

L'Articolo 23 stabilisce i tempi di notifica che i fornitori DNS devono rispettare. Un "incidente significativo" è uno che:

• Ha causato o può causare una sostanziale interruzione operativa dei servizi o una perdita finanziaria
• Ha colpito o può colpire altre persone fisiche o giuridiche causando un danno materiale o immateriale considerevole

Per il DNS, questo include downtime autoritativi prolungati, fallimenti di validazione DNSSEC dovuti a errore del fornitore, modifiche non autorizzate ai dati di zona del cliente o compromissione delle chiavi private DNSSEC.

Cadenza di notifica:

Questi tempi si applicano al fornitore DNS come soggetto nell'ambito. I clienti possono avere obblighi di notifica separati verso i propri regolatori se l'incidente DNS causa impatto a valle nel loro settore.

Le 24 ore di allarme precoce sono brevi. Un fornitore DNS deve avere monitoraggio, paging e un notificante designato pronti a presentare al CSIRT nazionale o all'autorità competente. Non è un esercizio trimestrale.

Cosa significa per i clienti DNS — una checklist pratica

Se la tua organizzazione è nell'ambito di NIS2 (o è fornitore di un soggetto coperto), ecco una checklist pratica per valutare il tuo fornitore DNS:

Due diligence del fornitore

• Il fornitore è nominato / disponibile a confermare per iscritto se è nell'ambito come fornitore di servizi DNS ai sensi di NIS2.
• Giurisdizione primaria del fornitore e autorità competente che lo supervisiona.
• Postura di sicurezza pubblica: security.txt, politica di divulgazione delle vulnerabilità e stato pubblicato per segnalazioni di sicurezza cifrate.
• Relazioni post-incidente pubbliche per incidenti significativi precedenti (se esistenti).
• Procedura documentata di risposta agli incidenti e SLA di notifica nel tuo contratto.

Controlli tecnici

• Supporto DNSSEC con algoritmi moderni (ECDSA P-256 o Ed25519).
• Memorizzazione sicura delle chiavi basata su HSM o equivalente.
• MFA sulla dashboard cliente.
• Chiavi API granulari (limitate alla zona, a tempo limitato, ruotabili) — vedi /learning/multi-user-accounts.
• Anycast multi-regione — vedi /learning/anycast-dns-network.
• Log di audit di tutte le azioni dashboard e API, conservati secondo la tua politica di conservazione.

Resilienza

• RTO/RPO documentati per il servizio autoritativo.
• Meccanismo per esportare i dati di zona su richiesta per la portabilità.
• Prontezza multi-provider (supporto Terraform / DNSControl) — vedi /learning/multi-provider-dns-deployment.

Considerazioni specifiche UE

• Il fornitore opera infrastruttura sotto giurisdizione UE se il tuo settore richiede residenza dei dati.
• Il traffico di query DNS può essere confinato ai PoP UE (ad esempio il set di nameserver UE di DNScale — vedi /learning/dns-delegation-by-region).
• Contratti sotto diritto UE e risoluzione delle controversie UE.

Dove si colloca DNScale

DNScale opera come fornitore DNS sotto giurisdizione UE con un modello operativo consapevole di NIS2:

• Operazioni UE: infrastruttura e operazioni all'interno dell'UE; il traffico di query può essere confinato ai PoP UE tramite il set di nameserver UE.
• DNSSEC: ECDSA P-256 di default; rotazione automatica delle chiavi; memorizzazione delle chiavi basata su HSM.
• MFA + chiavi API limitate: MFA dashboard, chiavi limitate alla zona, log di audit completo — vedi /learning/multi-factor-authentication-guide e la documentazione delle chiavi API DNScale.
• Anycast multi-regione tramite /learning/anycast-dns-network e /learning/global-dns-resolution-balancing per la resilienza.
• Prontezza multi-provider: i provider Terraform e DNSControl sono già disponibili — vedi /learning/terraform-provider-guide e /learning/dnscontrol-guide.
• Artefatti di sicurezza pubblici: security.txt e politica di divulgazione delle vulnerabilità in posizioni standard; relazioni post-incidente pubblicate quando applicabile.

Per i settori dove l'applicazione di NIS2 è più attiva — finanza, energia, pubblica amministrazione, sanità — spostare la fornitura DNS verso un fornitore sotto giurisdizione UE con controlli allineati a NIS2 riduce sia il rischio normativo sia il carico documentale della catena di approvvigionamento ai sensi dell'Articolo 21(2)(d).

Riferimenti

• Direttiva (UE) 2022/2555 — la Direttiva NIS2
• Linee guida ENISA sull'attuazione di NIS2 — risorse pratiche per i soggetti coperti
• Bozza BSI NIS2UmsuCG — recepimento tedesco
• Guida ANSSI NIS 2 — recepimento francese
• RFC 8945 — TSIG (autenticazione dei trasferimenti di zona, rilevante per le misure di crittografia)
• RFC 4034/4035 — protocollo core DNSSEC
• RFC 8901 — DNSSEC multi-firmatario (rilevante per i deployment multi-provider)

Letture correlate

• Best practice di sicurezza DNS — hardening operativo
• Gestione delle chiavi DNSSEC — crittografia in pratica
• Deployment DNS multi-provider — resilienza della catena di approvvigionamento
• DNScale vs Cloudflare — confronto sotto giurisdizione UE
• Migliori fornitori DNS UE — framework di valutazione
• Fornitori DNS conformi al GDPR — quadro normativo adiacente