Un lunedì mattina, la telefonia IP si interrompe su un sito remoto per due ore. Il fornitore diagnostica uno switch saturo, installato tre anni prima senza documentazione. Questo tipo di guasto, spesso evitabile, illustra quanto un audit di rete informatica non si limiti a spuntare delle caselle: si cercano i punti ciechi che la quotidianità finisce per nascondere.
Shadow IT e attrezzature non inventariate: il vero punto di partenza di un audit di rete
Gli articoli sull’audit di rete iniziano spesso con la definizione del perimetro. Sul campo, il perimetro si muove continuamente. Telecamere IP collegate dal servizio di manutenzione, un punto di accesso Wi-Fi aggiunto in un open space, un NAS personale connesso al VLAN di ufficio: queste attrezzature “shadow IT” sfuggono all’inventario ufficiale.
Vedi anche : I migliori consigli per un shopping di bellezza online di successo
Prima ancora di avviare una scansione delle vulnerabilità, si risparmia tempo effettuando una scansione fisica e logica di tutte le porte attive. Ciò significa percorrere i rack di cablaggio, registrare le connessioni reali, quindi incrociare con le tabelle ARP e i log DHCP. La differenza tra le due liste fornisce la misura dello shadow IT presente sulla rete.
Questa fase di scoperta è tanto più critica quanto più gli ambienti ibridi (siti fisici, cloud, lavoro da remoto) moltiplicano i punti di ingresso. Dal 2023, i feedback mostrano un aumento significativo degli incidenti legati a attrezzature IoT non inventariate. Si può approfondire l’audit di rete informatica con E-novateur per strutturare questa fase di mappatura iniziale.
Leggi anche : Idee e suggerimenti per avere successo nei vostri lavori di ristrutturazione e arredamento della casa
Mappatura dei flussi inter-siti e multi-cloud: una fase spesso trascurata
La maggior parte degli audit di rete documenta correttamente il LAN. I flussi tra siti remoti, tra il datacenter e i fornitori di cloud, o tra due ambienti cloud distinti, sono molto meno frequentemente tracciati.
Mappare i flussi inter-cloud prima di testare la sicurezza evita di scoprire alla fine dell’audit che un tunnel VPN site-to-site utilizza ancora una crittografia obsoleta, o che un peering diretto tra due fornitori di cloud non è supervisionato da alcun sensore.
Ciò che la mappatura deve coprire concretamente
- Le connessioni WAN e SD-WAN tra ciascun sito, con i dati di throughput reali misurati (non solo i throughput contrattuali)
- I flussi applicativi verso i servizi SaaS critici (posta elettronica, ERP, telefonia), identificando i percorsi di routing e i punti di uscita Internet
- Le interconnessioni cloud-to-cloud e cloud-to-on-premise, con verifica delle regole di segmentazione e delle politiche di filtraggio applicate a ciascun gateway
Strumenti di tipo NDR (Network Detection and Response) o piattaforme SASE consentono di ottenere questa visibilità. Dipende dall’installazione: una PMI mono-sito con un solo tenant cloud non ha bisogno dello stesso strumento di un gruppo multi-sito.
Audit di rete e conformità NIS2: ciò che la direttiva cambia in pratica
La direttiva europea NIS2, la cui trasposizione nazionale è iniziata a partire dal 2024, impone alle entità classificate come “essenziali” o “importanti” di dimostrare una monitoraggio regolare delle loro reti con tracciabilità degli audit. In pratica, ciò significa che un audit occasionale effettuato una volta ogni tre anni non è più sufficiente.
NIS2 richiede piani d’azione documentati dopo ogni audit, con un monitoraggio delle rimedi. Per un’azienda che effettua il suo primo audit, la sfida è produrre un deliverable utilizzabile dalla direzione così come dal team tecnico.
Strutturare il rapporto per rispondere alle esigenze normative
Il rapporto di audit deve contenere almeno tre elementi distinti:
- Un inventario aggiornato delle risorse di rete (hardware, software, configurazioni), datato e firmato
- Una matrice delle vulnerabilità identificate, classificate per criticità, con per ciascuna la raccomandazione tecnica associata e un termine di correzione proposto
- Un piano di rimedi prioritario, validato da un responsabile identificato, con traguardi di monitoraggio trimestrali
Questo formalismo può sembrare pesante per una PMI. È meglio un documento breve e attuabile che un rapporto di 80 pagine mai letto. Raccomandiamo di separare il riassunto decisionale (massimo due pagine, destinato alla direzione) dai dettagli tecnici (allegati strutturati per categoria di attrezzatura).
Test di segmentazione della rete: verificare ciò che il firewall lascia realmente passare
Configurare VLAN e regole di filtraggio non garantisce nulla se nessuno verifica la loro reale efficacia. Si riscontrano regolarmente regole “any-any” lasciate in vigore dopo una migrazione, o eccezioni temporanee diventate permanenti.
Testare la segmentazione significa simulare uno spostamento laterale da una postazione utente standard verso i sottoreti sensibili (server, amministrazione, IoT). Se una postazione del VLAN di ufficio può raggiungere l’interfaccia di gestione di uno switch core di rete, la segmentazione è fallita, indipendentemente dalla politica documentata.
Questo test si effettua con strumenti semplici (Nmap, Netcat) o con soluzioni di pentest automatizzate. L’obiettivo non è produrre un rapporto di centinaia di porte scansionate, ma rispondere a una domanda binaria per ciascuna zona: il compartimentamento funziona o no.
Prioritizzare le correzioni dopo i test
Tutte le vulnerabilità di segmentazione non hanno lo stesso impatto. Una comunicazione aperta tra il VLAN delle stampanti e il VLAN dei server di file presenta un rischio moderato. Un accesso diretto dal Wi-Fi ospite verso la rete di amministrazione rappresenta una vulnerabilità critica da correggere con priorità.
Il classico tranello è voler correggere tutto simultaneamente. Si bloccano così flussi legittimi e si generano ticket di incidente a cascata. La sequenza più affidabile: correggere prima gli accessi all’amministrazione di rete, poi i flussi verso i dati sensibili, e infine le comunicazioni inter-VLAN secondarie.
Un audit di rete riuscito non si misura al numero di pagine del rapporto, ma al numero di correzioni effettivamente applicate tre mesi dopo. Il deliverable più utile rimane una tabella di monitoraggio condivisa tra la DSI e la direzione, aggiornata a ogni traguardo, con uno stato chiaro per ogni vulnerabilità identificata.