Governare il perimetro. Perché la rete, fisica e logica, è oggi un obbligo giuridico

Dal GDPR alla NIS2, le norme non parlano di switch e firewall, ma ne presuppongono l’esistenza. Una lettura ragionata degli articoli che impongono di conoscere, separare e sorvegliare i propri confini digitali.

C’è un equivoco ricorrente nel dialogo tra giuristi e tecnici. Il giurista legge che il titolare deve adottare “misure tecniche e organizzative adeguate” e tende a considerarla una clausola generale, quasi un richiamo alla prudenza. Il tecnico conosce VLAN, firewall e sistemi di log, ma raramente li collega a una norma precisa. Ne deriva che la rete aziendale, cioè il luogo fisico e logico in cui i dati nascono, transitano e vengono conservati, resta spesso un’infrastruttura “di fatto”, cresciuta per stratificazioni successive e mai progettata come presidio di conformità.

Il quadro normativo vigente, letto nel suo insieme, conduce invece a una conclusione netta. Non si può dimostrare di proteggere i dati se non si è in grado di controllare il perimetro entro cui essi si muovono, tanto quello interno quanto quello che si estende verso fornitori, cloud e lavoro da remoto. E il perimetro non si controlla senza una rete dotata di caratteristiche determinate.

1. Il fondamento nel GDPR

Il punto di partenza è l’art. 5, par. 1, lett. f), del Regolamento (UE) 2016/679, che impone di trattare i dati garantendone un’adeguata sicurezza, compresa la protezione da trattamenti non autorizzati o illeciti e dalla perdita, distruzione o danno accidentali. Il par. 2 aggiunge il principio di responsabilizzazione. Il titolare non deve soltanto rispettare i principi, ma essere in grado di comprovarlo.

L’art. 24 traduce il principio nell’obbligo di attuare misure adeguate alla natura, al contesto e alle finalità del trattamento, mentre l’art. 25 richiede che tali misure siano incorporate fin dalla progettazione e per impostazione predefinita. Una rete “piatta”, in cui ogni dispositivo può dialogare con ogni altro, è l’esatto contrario della protezione by default.

Il cuore della questione è l’art. 32. Esso richiede, tra l’altro, la cifratura dei dati (par. 1, lett. a), la capacità di assicurare su base permanente riservatezza, integrità, disponibilità e resilienza dei sistemi (lett. b), la capacità di ripristinare tempestivamente disponibilità e accesso (lett. c) e una procedura per testare e valutare regolarmente l’efficacia delle misure (lett. d). Il parametro di adeguatezza è espressamente lo “stato dell’arte”.

Vi sono poi gli artt. 33 e 34. L’obbligo di notificare una violazione entro 72 ore dal momento in cui se ne viene a conoscenza presuppone che la violazione sia rilevabile. Un’organizzazione priva di registrazione degli eventi e di monitoraggio del traffico non “viene a conoscenza” dell’incidente, semplicemente lo ignora, talvolta per mesi. L’art. 33, par. 5, impone inoltre di documentare ogni violazione, adempimento impossibile in assenza di tracce tecniche affidabili.

2. Il salto di qualità della NIS2

Se il GDPR fissa il “perché”, la Direttiva (UE) 2022/2555, recepita con il D.Lgs. 4 settembre 2024, n. 138, comincia a indicare il “come”. L’art. 21, par. 2, della direttiva richiede misure fondate su un approccio multirischio volto a proteggere i sistemi informativi e di rete e il loro ambiente fisico. L’elenco comprende la gestione degli incidenti (lett. b), la continuità operativa e il backup (lett. c), la sicurezza della catena di approvvigionamento (lett. d), la sicurezza nell’acquisizione, nello sviluppo e nella manutenzione di reti e sistemi (lett. e), la crittografia (lett. h), il controllo degli accessi e la gestione degli attivi (lett. i), l’autenticazione a più fattori e le comunicazioni protette (lett. j). Nell’ordinamento interno gli obblighi corrispondenti si trovano agli artt. 24 e 25 del D.Lgs. 138/2024, mentre l’art. 23 attribuisce agli organi di amministrazione e direttivi la responsabilità di approvarne e sovrintenderne l’attuazione.

Il dettaglio cresce con il Regolamento di esecuzione (UE) 2024/2690, direttamente applicabile ad alcune categorie di soggetti digitali, tra cui fornitori di servizi DNS, cloud, data center e servizi gestiti. Nell’allegato, i profili propriamente di rete sono trattati al punto 6.7, dedicato alla sicurezza della rete, e al punto 6.8, dedicato alla segmentazione. Quest’ultimo prevede, tra le misure, la zona demilitarizzata, la separazione delle reti di amministrazione e la distinzione degli ambienti di produzione da quelli di sviluppo e test.

Sul piano nazionale, l’ACN ha definito le specifiche di base. La determinazione n. 379907 del 18 dicembre 2025 ha aggiornato e sostituito la precedente determinazione n. 164179 del 14 aprile 2025, confermando i termini di adeguamento, ossia diciotto mesi per le misure di sicurezza e nove per la notifica degli incidenti significativi, decorrenti dalla comunicazione di inserimento nell’elenco dei soggetti NIS. Per molti soggetti inclusi nella prima tornata, il termine per le misure di sicurezza matura proprio in queste settimane.

Un’osservazione di metodo. Chi non rientra nell’ambito NIS non è giuridicamente vincolato da questi atti. Tuttavia, poiché l’art. 32 GDPR rinvia allo stato dell’arte, è ragionevole ritenere che il corpus NIS costituisca oggi il parametro tecnico con cui un’autorità di controllo, o un consulente tecnico in sede giudiziale, valuterà l’adeguatezza delle misure di qualsiasi titolare.

3. Le caratteristiche della rete fisica

La rete fisica è la grande dimenticata della compliance, eppure l’art. 21 NIS2 ne fa esplicitamente oggetto di tutela quando menziona l'”ambiente fisico”. Le caratteristiche minime sono le seguenti.

  • Documentazione e inventario. Planimetrie aggiornate, schema dei percorsi, etichettatura univoca di prese, cavi, patch panel e apparati secondo criteri riconosciuti (ad esempio ANSI/TIA-606), allineata all’inventario degli attivi richiesto dall’art. 21, par. 2, lett. i).
  • Cablaggio strutturato a norma. Progettazione e posa conformi alle serie EN 50173 ed EN 50174, con certificazione strumentale delle tratte. Un cablaggio non certificato è un’incognita sulla disponibilità, e dunque sull’art. 32, lett. b).
  • Locali tecnici protetti. Armadi rack chiusi, locali ad accesso controllato e registrato, separazione tra spazi tecnici e aree aperte al pubblico. Per i data center il riferimento è la serie EN 50600.
  • Porte gestite. Disattivazione delle porte non utilizzate e assenza di punti rete attivi in sale d’attesa o aree comuni.
  • Continuità elettrica e ambientale. Gruppi di continuità, ridondanza delle linee, monitoraggio di temperatura e umidità, in coerenza con l’art. 32, lett. b) e c), GDPR e con l’art. 21, par. 2, lett. c), NIS2.
  • Punti di demarcazione chiari. Individuazione fisica del punto in cui termina la rete dell’organizzazione e inizia quella dell’operatore, presupposto per attribuire correttamente le responsabilità.

4. Le caratteristiche della rete logica

  • Segmentazione per zone di fiducia. Sottoreti o VLAN distinte per utenti, server, stampanti e dispositivi IoT, sistemi OT, ospiti, con una DMZ per i servizi esposti e una rete di gestione separata. Il traffico tra zone deve essere governato da regole esplicite secondo il principio “deny by default”.
  • Firewall perimetrali e interni. Non solo verso Internet, ma anche tra segmenti, con revisione periodica delle regole, che costituisce attuazione concreta dell’art. 32, par. 1, lett. d).
  • Controllo dell’accesso alla rete. Autenticazione dei dispositivi (802.1X o soluzioni NAC), Wi-Fi aziendale in modalità enterprise, rete ospiti isolata.
  • Accesso remoto e amministrativo protetto. VPN o soluzioni ZTNA con autenticazione a più fattori (art. 21, par. 2, lett. j), postazioni dedicate all’amministrazione.
  • Cifratura in transito. TLS per i servizi, IPsec per i collegamenti tra sedi, dismissione dei protocolli in chiaro (art. 32, lett. a, GDPR; art. 21, par. 2, lett. h, NIS2).
  • Registrazione e monitoraggio. Log centralizzati e protetti da alterazione, orologi sincronizzati, correlazione degli eventi. Per gli amministratori di sistema, il provvedimento del Garante del 27 novembre 2008 impone da tempo la registrazione degli accessi con garanzie di integrità e conservazione non inferiore a sei mesi.
  • Filtraggio del traffico in uscita. Il perimetro si controlla anche verso l’esterno, ed è lì che si intercetta l’esfiltrazione.
  • Backup segregati. Copie isolate logicamente dalla produzione, preferibilmente immutabili, e verificate con prove di ripristino periodiche.

5. Il perimetro esterno

Il perimetro non coincide più con le mura dell’azienda. Servizi cloud, applicazioni in abbonamento, manutentori collegati da remoto e lavoro agile lo hanno reso mobile e frammentato. L’art. 28 GDPR impone di ricorrere a responsabili che presentino garanzie sufficienti, l’art. 21, par. 2, lett. d), NIS2 estende la gestione del rischio alla catena di fornitura, gli artt. 44 e seguenti GDPR condizionano i trasferimenti verso Paesi terzi. Ne discende un obbligo pratico preciso. Occorre mappare i flussi in uscita, sapere dove risiedono i dati, quale fornitore vi accede, con quali credenziali e da quale punto della rete. Gli accessi di terzi devono essere nominativi, temporizzati, tracciati e revocabili. È questo il senso operativo dell’approccio “zero trust”, per cui nessuna connessione è attendibile per il solo fatto di provenire dall’interno.

6. Il limite del controllo

Controllare il perimetro non significa controllare le persone. L’art. 4 della L. 300/1970, come modificato dal D.Lgs. 151/2015, e l’art. 114 del Codice privacy pongono un argine preciso agli strumenti da cui possa derivare un controllo a distanza dei lavoratori. Lo stesso Garante, con il documento di indirizzo del 2024 sui metadati della posta elettronica, ha mostrato quanto una scelta di configurazione apparentemente tecnica possa assumere rilievo giuslavoristico. Gli strumenti di monitoraggio vanno quindi progettati con finalità esclusive di sicurezza, minimizzazione e, ove possibile, pseudonimizzazione dei log, adeguata informativa e, quando necessario, accordo sindacale o autorizzazione dell’Ispettorato. Una valutazione d’impatto ai sensi dell’art. 35 GDPR è spesso lo strumento più idoneo a bilanciare le esigenze.

Conclusione

Nessuna norma indica quale apparato acquistare, ma tutte pretendono risultati che solo una determinata architettura consente di raggiungere. Le violazioni degli artt. 25, 32 e 33 GDPR sono punite ai sensi dell’art. 83, par. 4, fino a 10 milioni di euro o al 2% del fatturato mondiale, e l’art. 34 NIS2 prevede soglie analoghe per i soggetti essenziali. Ma il rischio sanzionatorio non è l’unico. In un contenzioso, la prima domanda del consulente tecnico riguarda quasi sempre la documentazione della rete, i log disponibili e la segmentazione esistente. Dove queste risposte mancano, manca la prova della diligenza.

Prima di acquistare tecnologia, dunque, occorre disegnare il perimetro, documentarlo e verificarlo nel tempo. È lì che la sicurezza smette di essere una dichiarazione e diventa un fatto dimostrabile.