Segmentazione di rete: come ridurre il movimento laterale degli attaccanti
Quando un attaccante supera il primo ostacolo — un phishing riuscito, una credenziale rubata, una vulnerabilità su un servizio esposto — il problema smette di essere il punto d'ingresso e diventa ciò che trova davanti. In una rete piatta, davanti c'è tutto: server, workstation, database, sistemi di backup, apparati di gestione. In una rete segmentata, davanti ci sono confini, regole e punti di controllo. La differenza, durante un incidente, si misura in ore e in sistemi compromessi.
Questa guida spiega perché la segmentazione è una delle difese più efficaci contro il movimento laterale, come si progetta e quali errori fanno fallire i progetti. Le affermazioni su tecniche d'attacco, modelli di sicurezza e policy sono basate su fonti primarie verificate alla data di redazione (16 settembre 2026).
Che cos'è il movimento laterale
Il movimento laterale è la fase in cui un attaccante, già presente nell'ambiente, cerca di spostarsi da un sistema all'altro per raggiungere l'obiettivo reale: un database, un server applicativo, un sistema con privilegi elevati. MITRE ATT&CK lo definisce come l'insieme delle tecniche usate per entrare e controllare sistemi remoti su una rete (tattica TA0008, aggiornata all'11 agosto 2025).
Non serve un exploit spettacolare: nella maggior parte dei casi l'attaccante usa strumenti legittimi e credenziali valide, che sono più difficili da distinguere da un'attività normale. Tra le tecniche catalogate da ATT&CK troviamo:
- l'uso dei servizi remoti (RDP, SMB, SSH, WinRM, VNC) per accedere ad altri host con account compromessi;
- il pass the hash e il pass the ticket, che sfruttano hash e ticket Kerberos senza conoscere la password in chiaro;
- lo sfruttamento di servizi remoti vulnerabili;
- il trasferimento di strumenti tra i sistemi compromessi;
- l'abuso di strumenti di distribuzione software aziendali (ad esempio SCCM o Intune) per eseguire comandi su larga scala.
Il punto comune è chiaro: ciò che abilita il movimento laterale è la possibilità di comunicare liberamente tra host. Se quella possibilità non esiste, l'attaccante si trova bloccato anche con le credenziali in mano.
Perché una rete piatta amplifica il danno
In una rete piatta ogni host può parlare con ogni altro host, spesso senza regole intermedie. Un'unica workstation compromessa può quindi raggiungere direttamente il file server, il database e i sistemi di amministrazione. Il "raggio d'azione" di un singolo errore diventa l'intera rete.
Il documento NIST SP 800-207 (Zero Trust Architecture) mette in discussione proprio l'assunto alla base delle reti piatte: non bisogna concedere fiducia implicita a un asset o a un account solo perché si trova in una certa posizione di rete. Prima di stabilire una sessione verso una risorsa, autenticazione e autorizzazione vanno verificate in modo esplicito. La segmentazione è lo strumento che traduce questo principio in qualcosa di concreto: anche un dispositivo autenticato non deve poter raggiungere ciò che non gli serve.
Macro-segmentazione e microsegmentazione
Cisco distingue due livelli di granularità che, nella pratica, si combinano.
- Macro-segmentazione (o segmentazione a zone): divide la rete in segmenti distinti in base a criteri ampi — reparto, funzione, applicazione o sede — creando confini di alto livello che controllano il traffico tra le aree.
- Microsegmentazione: è un approccio molto più granulare, in cui i workload vengono separati in base a etichette assegnate dall'amministratore, al comportamento di comunicazione osservato o a policy applicative.
I due livelli non sono alternativi. La macro-segmentazione riduce la superficie complessiva — separa la rete utenti dai server, la DMZ dall'ambiente interno, la gestione dal traffico ordinario. La microsegmentazione limita il danno all'interno di una stessa zona, quando due workload che non dovrebbero parlarsi si trovano sulla stessa rete.
Cisco riassume i benefici in cinque esiti: applicare il minimo privilegio, limitare il raggio d'azione di un incidente, migliorare la risposta agli incidenti, aumentare la resilienza operativa e supportare la conformità normativa separando dati e sistemi sensibili.
Progettare le zone con criterio
Una segmentazione utile non nasce dal prodotto, ma dalla progettazione. I passi che consigliamo sono questi:
- Classificare gli asset per sensibilità dei dati, funzione e requisiti normativi: non tutti i server meritano la stessa zona.
- Definire zone e livelli coerenti: utenti, server applicativi, database, DMZ, rete di gestione (out-of-band), sistemi OT, backup.
- Mappare i flussi reali prima di scrivere le regole. Il traffico che conta non è quello nord-sud (verso Internet), ma quello est-ovest tra server e tra zone interne.
- Scrivere policy di minimo privilegio: consentire solo le comunicazioni necessarie, nella direzione necessaria, e impostare di default il blocco di tutto il resto. La guida NIST SP 800-41 Rev. 1 ricorda che i firewall servono esattamente a controllare il traffico tra reti con postura di sicurezza diversa: la loro efficacia dipende da una policy esplicita, documentata e applicata con criterio.
Un errore frequente è autorizzare "any-any" tra due zone "tanto sono interne". È il modo più rapido per annullare il beneficio della segmentazione: se la regola è permissiva, il confine esiste solo sulla carta.
Microsegmentazione e Zero Trust
La microsegmentazione porta la logica di zona al livello di singolo workload. Invece di ragionare solo su indirizzi IP e sottoreti, si ragiona su identità, etichette e contesto. Le implementazioni possibili vanno dalle policy sui firewall ai segmenti definiti da etichette di gruppo (come i tag di sicurezza nelle architetture di rete aziendali), fino alle policy per pod nei cluster Kubernetes.
Qui la segmentazione incontra il modello Zero Trust del NIST SP 800-207: la decisione di consentire una comunicazione non dipende dalla posizione, ma da chi sta parlando, con quale dispositivo, verso quale risorsa e in quale contesto. In questo senso la segmentazione non è solo una barriera: è il punto in cui le policy di accesso diventano verifica continua.
Perché i progetti di segmentazione falliscono
La segmentazione è tecnicamente semplice da descrivere e difficile da realizzare. Un'analisi Cisco su 400 progetti di segmentazione falliti in organizzazioni statunitensi con più di 500 dipendenti ha rilevato che l'84% ha incontrato la maggior parte (o tutti) i fattori di fallimento valutati, e che oltre il 70% dei rimedi proposti riguardava project management IT generico invece di soluzioni specifiche per la segmentazione.
Le lezioni pratiche sono ricorrenti:
- Partire dalla visibilità, non dalle regole. Senza una mappa dei flussi reali, le policy nascono da assunzioni e bloccano applicazioni legittime.
- Procedere per gradi. Introdurre le regole in modalità di monitoraggio, osservare cosa verrebbe bloccato, poi passare all'applicazione.
- Coinvolgere le applicazioni, non solo la rete. Chi conosce le dipendenze tra servizi deve partecipare alla definizione delle zone.
- Non fermarsi al primo rilascio. Le architetture cambiano: nuove applicazioni, migrazioni al cloud, accessi remoti. Le policy vanno riviste.
Verificare che la segmentazione funzioni
Una segmentazione non verificata è una segmentazione presunta. Le attività di controllo minime sono:
- raccogliere flow log (NetFlow/IPFIX) e analizzare il traffico est-ovest;
- eseguire test periodici dei confini: un host della zona utenti non deve raggiungere il database, un server applicativo non deve parlare direttamente con la rete di gestione;
- monitorare i tentativi bloccati: un picco di connessioni negate può essere il segnale di un attaccante che sta cercando di muoversi lateralmente;
- mantenere aggiornata la documentazione delle zone e delle regole, così che un cambiamento sia una decisione e non un effetto collaterale.
Checklist di segmentazione
| Elemento | Domanda di controllo |
|---|---|
| Inventario | So quali asset esistono e a quale zona appartengono? |
| Flussi est-ovest | Conosco le comunicazioni reali tra i workload? |
| Deny-by-default | Le regole bloccano tutto ciò che non è esplicitamente consentito? |
| Direzione del traffico | Le policy sono direzionali o permissive in entrambi i versi? |
| Segmentazione rete di gestione | L'accesso amministrativo è isolato dal traffico utenti? |
| DMZ | I servizi esposti sono separati dall'ambiente interno? |
| Microsegmentazione | I workload critici sono separati anche dentro la stessa zona? |
| Verifica | Eseguo test periodici dei confini tra le zone? |
| Monitoraggio | Analizzo flow log e tentativi di connessione negati? |
| Revisione | Le policy vengono aggiornate quando cambia l'architettura? |
Il consiglio di Digital Lab
La segmentazione è una delle poche misure di sicurezza che riduce il rischio sia prima sia durante un incidente: prima, perché rende più difficile il movimento laterale; durante, perché circoscrive il danno e rende più rapida la risposta. Non è un prodotto da acquistare, ma un progetto che unisce competenze di rete, sicurezza e applicazioni.
Le fonti di questa guida (Cisco, NIST SP 800-207, NIST SP 800-41 Rev. 1 e MITRE ATT&CK TA0008) sono verificate alla data di redazione del 16 settembre 2026. Poiché tecniche d'attacco e best practice evolvono, conviene rivedere periodicamente zone, flussi e regole, e formare il team su come progettare e verificare una rete segmentata.
Vuoi costruire competenze solide su routing, switching e sicurezza di rete, con laboratori pratici su apparati reali e docenti certificati? Scopri i corsi Cisco di Digital Lab.