VPM Telecomunicazioni
Torna al Blog
Cyber Security

NIS2: Cosa Cambia per Chi Ha Impianti IT Interni

Un percorso pratico per valutare infrastrutture IT interne, responsabilità, continuità operativa e misure di sicurezza nel contesto NIS2.

11 min
Copertina VPM Blog: NIS2: Cosa Cambia per Chi Ha Impianti IT Interni

Un impianto IT interno non è soltanto un armadio di rete, alcuni server e i PC degli uffici: è l'insieme dei servizi che permettono all'organizzazione di lavorare. Posta elettronica, identità digitali, collegamenti tra sedi, file condivisi, applicativi gestionali, Wi-Fi, backup e accessi remoti dipendono da scelte tecniche spesso stratificate nel tempo. La NIS2 rende ancora più importante conoscere questa superficie tecnologica e governarne i rischi.

La prima domanda non deve essere “siamo già conformi?”, ma “quali servizi sono davvero essenziali e come reagiremmo se non fossero disponibili o fossero compromessi?”. La direttiva NIS2 e il relativo quadro di recepimento nazionale prevedono obblighi per soggetti individuati secondo criteri, settori e dimensioni definiti dalla normativa. L'applicabilità al singolo soggetto va quindi verificata con attenzione, anche quando si utilizzano fornitori esterni o servizi cloud. Questo articolo offre indicazioni tecniche e organizzative utili, non sostituisce una valutazione legale o regolatoria.

Partire dall'impianto reale, non dal diagramma storico

In molte sedi il disegno di rete disponibile non corrisponde più alla configurazione in esercizio. Uno switch aggiunto per un reparto, una telecamera IP, un access point o una VPN attivata per un fornitore possono modificare in modo significativo il profilo di rischio. La base di un progetto credibile è un inventario aggiornato e verificabile.

L'inventario dovrebbe collegare ogni componente a una funzione e a un responsabile. Non occorre iniziare con uno strumento complesso: un censimento strutturato, validato dai referenti tecnici e di processo, permette già di individuare priorità e dipendenze.

  • Server fisici e virtuali, sistemi operativi, applicazioni e database.
  • Firewall, switch, access point, collegamenti Internet, VPN e dispositivi di telefonia IP.
  • Account amministrativi, sistemi di identità, caselle funzionali e accessi remoti.
  • Dispositivi industriali, IoT, videosorveglianza e apparati di sicurezza connessi.
  • Servizi cloud, licenze, domini, backup e contratti di assistenza.
  • Dati trattati, proprietari del servizio, sede fisica e livello di criticità.

Per ogni servizio è utile definire un tempo di indisponibilità tollerabile e un obiettivo di recupero proporzionato. Un gestionale fermo per alcune ore, un servizio di autenticazione indisponibile o una copia di backup non ripristinabile hanno conseguenze diverse. Questa analisi trasforma la sicurezza da lista di prodotti a decisione di continuità operativa.

Cosa richiede un approccio NIS2 alla sicurezza

La NIS2 porta l'attenzione sulla gestione del rischio, sulla continuità dei servizi, sugli incidenti, sulla catena di fornitura e sulla responsabilità degli organi di gestione. In termini pratici, non basta acquistare un firewall o un antivirus: servono misure coerenti, documentate, mantenute e proporzionate al contesto.

Il supporto tecnico può includere interventi su cybersecurity e reti e cablaggi, da definire in base all'infrastruttura e alle priorità; la valutazione dell'applicabilità e degli obblighi resta distinta e va affidata alle figure competenti.

Un buon progetto collega persone, processi e tecnologia. La direzione deve conoscere i rischi rilevanti, assegnare ruoli e autorizzare risorse; chi gestisce l'infrastruttura deve poter applicare procedure chiare; gli utenti devono sapere come riconoscere e segnalare eventi sospetti. La documentazione utile non è burocrazia fine a sé stessa: consente di ricostruire decisioni, verificare le configurazioni e lavorare anche quando il referente abituale non è disponibile.

Tra le aree da valutare rientrano la gestione delle vulnerabilità, il controllo degli accessi, la protezione delle comunicazioni, il backup, il monitoraggio, la gestione degli incidenti e la sicurezza dei fornitori. Le misure concrete dipendono dall'architettura, dai dati e dalla criticità dei servizi. L'obiettivo è ridurre sia la probabilità di un incidente sia l'impatto nel caso avvenga.

Criteri tecnici per l'impianto interno

La segmentazione è uno dei primi interventi da esaminare. Una rete piatta, in cui postazioni amministrative, server, Wi-Fi ospiti, stampanti e dispositivi IoT comunicano senza limiti, facilita la propagazione di un malware e rende più difficile individuare anomalie. VLAN, regole firewall tra segmenti e reti dedicate non sono una garanzia assoluta, ma limitano i movimenti laterali se progettate con regole esplicite.

Gli accessi privilegiati meritano un capitolo a parte. Account condivisi, credenziali amministrative usate per la posta quotidiana e accessi VPN senza autenticazione a più fattori sono debolezze ricorrenti. Occorre preferire account personali nominativi, privilegi minimi necessari, separazione tra uso ordinario e amministrazione, revisione periodica delle abilitazioni e MFA, in particolare per posta, VPN, console cloud e sistemi amministrativi.

Anche il patching deve essere governato come processo. Significa sapere quali sistemi esistono, ricevere gli avvisi rilevanti, valutare impatto e urgenza, testare dove possibile, distribuire gli aggiornamenti e verificare l'esito. I sistemi non più supportati richiedono una decisione esplicita: sostituzione, isolamento, compensazioni tecniche e un piano con responsabilità e scadenze. Rimandare indefinitamente non è una strategia.

Per il monitoraggio, centralizzare almeno i log essenziali di firewall, sistemi di identità, VPN, server critici e protezioni endpoint consente di indagare un evento con dati più affidabili. I log devono avere orari sincronizzati, tempi di conservazione definiti e accessi protetti. Un registro raccolto ma mai controllato offre un beneficio limitato: è necessario stabilire chi riceve gli avvisi e come li prende in carico.

Backup e continuità: la prova è il ripristino

Un backup dichiarato “attivo” non equivale a un ripristino possibile. Copie raggiungibili con le stesse credenziali amministrative dell'ambiente di produzione possono essere cancellate o cifrate durante un attacco. Una progettazione prudente usa copie separate, controlli di accesso dedicati e, dove appropriato, una copia isolata o immutabile. Frequenza, conservazione e priorità vanno definite per servizio, non applicate in modo uniforme.

È altrettanto importante provare il recupero. Un test programmato può verificare integrità dei dati, tempi effettivi, ordine di ripartenza delle applicazioni e disponibilità delle istruzioni. Il risultato va annotato: un errore scoperto durante una prova è un miglioramento; lo stesso errore scoperto durante un fermo operativo è un danno.

Errori frequenti

  • Considerare la NIS2 un adempimento solo informatico e lasciare fuori direzione, processi e fornitori.
  • Compilare un inventario una volta sola senza aggiornarlo dopo modifiche, dismissioni o nuovi servizi.
  • Esporre pannelli di amministrazione su Internet o mantenere VPN e dispositivi di rete non aggiornati.
  • Usare una sola rete per utenti, apparati tecnici, ospiti e dispositivi con firmware difficilmente aggiornabile.
  • Confondere il possesso di backup con la capacità documentata di ripristinare un servizio.
  • Affidarsi a un fornitore senza chiarire ruoli, canali di emergenza, accessi, livelli di servizio e obblighi di notifica.

Checklist operativa per iniziare

  • Verificare con i referenti competenti se l'organizzazione rientra nell'ambito di applicazione e quali obblighi le competono.
  • Aggiornare inventario, topologia e proprietari dei servizi critici.
  • Classificare i servizi per impatto, dipendenze e tempi di recupero.
  • Applicare MFA e rivedere gli account privilegiati, gli accessi remoti e le credenziali condivise.
  • Separare le reti e documentare le regole di comunicazione indispensabili.
  • Definire un ciclo di patching con eccezioni approvate e tracciate.
  • Testare backup e ripristino, inclusi i dati delle applicazioni e le configurazioni di rete.
  • Formalizzare la gestione degli incidenti con contatti, ruoli, raccolta evidenze ed escalation.
  • Riesaminare contratti e accessi dei fornitori che operano sui sistemi critici.
  • Pianificare formazione mirata e simulazioni di phishing o di segnalazione incidenti.

Un percorso misurabile

Il valore di un percorso NIS2 non sta nel produrre documenti isolati, ma nel rendere l'infrastruttura più conoscibile, difendibile e recuperabile. Conviene procedere per priorità: prima i servizi essenziali e le esposizioni più evidenti, poi il consolidamento di processi, controlli e verifiche periodiche. Una valutazione tecnica dell'impianto, integrata con la verifica dell'applicabilità normativa da parte dei soggetti competenti, permette di definire interventi realistici, responsabilità e tempi senza promettere una conformità automatica.