Zero-Trust nella LAN: attuare concretamente la microsegmentazione con regole del firewall e VLAN

„Zero Trust nella LAN“ suona come un grande progetto, ma nella pratica è soprattutto una cosa: mettere in ordine in modo consequenziale le assunzioni di fiducia inconsce nella rete interna. Nei LAN classici spesso vige il principio “interno = sicuro”, ed è proprio questo che gli attaccanti sfruttano dopo un primo accesso: si muovono lateralmente (East-West-Traffic), scansionano servizi, compromettono sessioni amministrative o sfruttano porte di gestione aperte. La microsegmentazione affronta questo rischio autorizzando esplicitamente la comunicazione nel LAN invece di tollerarla in modo generale — tipicamente tramite una combinazione di VLAN (segmenti logici Layer 2) e regole di firewall (Layer-3/4-Regeln, per lo più con stato/stateful).

Questo contributo mostra un approccio pragmatico per amministratori e System Engineer: prerequisiti, decisioni di design, insidie tipiche, passaggi di verifica concreti, implementazione a tappe e una strategia di fallback solida. Il focus non è sulle GUI specifiche dei vendor, ma sui meccanismi che funzionano in quasi ogni ambiente — sia con firewall centrale, routing al core, L3-switching o una firewall distribuita nella virtualizzazione.

Perché la microsegmentazione nella LAN fallisce nella pratica (e come evitarlo)

Le cause più frequenti dei progetti di segmentazione falliti non sono la mancanza di tecnologia, ma la carenza di lavoro preparatorio:

• Dipendenze dei servizi poco chiare: nessuno sa con affidabilità quali sistemi devono parlare con quali porte e in quali momenti. Risultato: “Any/Any” come soluzione d’emergenza.
• Zone troppo ampie: “Server”, “Client”, “Management” — suona ordinato, ma spesso è troppo generale. Un client compromesso avrà comunque troppi obiettivi raggiungibili.
• Mancanza di percorso operativo: senza logging, metriche e un runbook per il troubleshooting ogni blocco si trasforma in un intervento d’emergenza.
• Bypass tramite eccezioni: stampanti, scanner, sistemi legacy, OT/IoT — alla fine tutto ottiene autorizzazioni estese “temporanee”.

La contromisura è un approccio iterativo: prima visibilità (flow data, firewall-logs), poi zonizzazione, quindi progressivo “Default Deny” per segmento con eccezioni chiare e documentate. Importante: la microsegmentazione non è un progetto una tantum, ma un modello operativo (Policy Lifecycle, Change-Prozess, Review).

Inquadrare i termini: VLAN, microsegmentazione, Zero Trust, zone

VLAN (Virtual LAN) separa le domini di broadcast a livello Layer 2. È uno strumento di organizzazione e scalabilità, ma non una garanzia di sicurezza: non appena si effettua routing tra VLAN (Inter-VLAN-Routing), è la policy a decidere se il traffico è consentito.

Microsegmentazione significa un controllo degli accessi più granulare all’interno della rete interna. Può avvenire tramite VLAN più firewall, tramite una Distributed Firewall (regole direttamente sull’hypervisor/host) o tramite firewall host-based. Ciò che conta è che il movimento laterale venga ostacolato perché mancano percorsi standardizzati.

Zero Trust è un principio di sicurezza: nessuna assunzione implicita di fiducia basata sulla posizione in rete. Nella LAN significa concretamente: identità (chi), dispositivo/stato (con cosa), contesto (da dove) e privilegi minimi (solo ciò che è necessario). VLAN e regole di firewall sono gli strumenti per la parte di rete.

Modello a zone indica la suddivisione in zone di sicurezza (per es. User, Server, Management, Backup, DMZ, OT) e transiti definiti con regole chiare. In pratica, un buon modello a zone è la condizione necessaria affinché la microsegmentazione non si risolva in migliaia di eccezioni singole.

Opzioni architetturali: dove si applica tecnicamente la policy?

Prima di scrivere regole, definite dove deve avvenire l’applicazione (Enforcement). In esercizio si incontrano tre modelli:

1) Firewall centrale tra zone (classico)

Il routing inter-VLAN passa attraverso un firewall (o un cluster di firewall). Vantaggio: visibilità centrale, un unico set di regole, log coerenti. Svantaggio: il traffico Ost-West può generare hairpinning (deviazione attraverso il firewall) e quindi impattare latenza/throughput. Per molte infrastrutture di media dimensione rimane comunque il punto di partenza più stabile.

2) Routing sul Core/L3-Switch + ACL/funzione firewall

Il core effettua il routing tra VLAN e applica regole come ACL. Vantaggio: prestazioni molto elevate. Svantaggio: le ACL sono spesso meno comode rispetto a policy stateful (p.es. nessun flusso di ritorno automatico), il logging è, a seconda della piattaforma, limitato e le modifiche alle policy sono soggette a errori. Adatto per zone grossolane; per vera microsegmentazione solo con un processo ben definito.

3) Distributed Firewall (virtualizzazione/SDN)

Le regole vengono applicate vicino al workload (p.es. all’hypervisor). Vantaggio: granularità molto elevata, scala per East-West senza colli di bottiglia centrali. Svantaggio: maggiore dipendenza dallo stack di virtualizzazione/SDN, troubleshooting più complesso (più livelli) e i sistemi fisici devono essere gestiti separatamente.

Prerequisiti: cosa assicurarsi prima del primo “Deny”

Per evitare che la segmentazione diventi una serie di interruzioni, queste basi sono decisive:

• Inventory IP e VLAN pulito: quali reti esistono, a cosa servono, chi è connesso? La documentazione deve corrispondere alla realtà.
• Risoluzione dei nomi e orario: DNS e NTP sono servizi trasversali. Se la microsegmentazione blocca DNS/NTP, i malfunzionamenti appaiono casuali (login, certificati, Kerberos, monitoring). Pianificate esplicitamente questi flussi.
• Sorgente di identità: in molte ambienti ciò significa AD/LDAP, RADIUS/TACACS+ per l’accesso di rete, eventualmente PKI. Serve chiarezza su dove avviene l’autenticazione.
• Osservabilità: log del firewall, dati flow (NetFlow/IPFIX/sFlow) o almeno statistiche delle porte degli switch. Senza telemetria rimane solo trial-and-error.
• Processo di change e rollback: finestre di manutenzione, responsabili, canale di comunicazione, accesso di emergenza (Out-of-Band).

Design pratico: zone, gruppi di servizio e il percorso verso la microsegmentazione

Un approccio pratico è “prime le zone, poi i microsegmenti”:

Passo 1: definire zone ampie che riflettano la realtà operativa

Zone tipiche nelle reti aziendali:

• User/Client: dispositivi degli utenti finali.
• Server: server applicativi e di infrastruttura.
• Management: workstation amministrative, jump host, reti di gestione (iLO/iDRAC, gestione switch/firewall).
• Shared Services: DNS, NTP, PKI, logging, monitoring, server di aggiornamento, gestione della configurazione.
• Backup/Storage: server di backup, repository, reti di storage (separate, spesso con requisiti propri).
• DMZ/Exposed: sistemi con interfacce esterne.
• IoT/OT: dispositivi con baseline di sicurezza debole (stampanti, telecamere, automazione degli edifici).

Importante: ogni zona necessita di un comportamento predefinito chiaro. Per Zero-Trust nella LAN il target a medio termine è Default Deny tra le zone, con autorizzazioni esplicite. Nella fase di transizione il “Deny” può essere inizialmente solo in log/alert (se la piattaforma lo supporta) o introdotto mediante una zona pilota strettamente limitata.

Passo 2: gruppi di servizio invece di regole host-to-host

Nei firewall è operativamente più stabile lavorare con gruppi di oggetti: „AD-Controller“, „DNS-Resolver“, „Monitoring“, „DB-Cluster“, „Jump-Hosts“. Questo riduce il numero di regole, facilita gli audit e rende gestibili le successive migrazioni (cambio IP, nuovi server).

Un controllo di qualità pratico: se per un’applicazione fate riferimento a 40 host singoli, probabilmente manca un concetto di architettura o di naming (p. es. VIP, Load Balancer, Service Discovery) – oppure lo scope è troppo ampio.

Passo 3: Avviare i microsegmenti dove rischio e beneficio sono elevati

Si è dimostrato efficace iniziare con:

• Accessi di gestione: SMB/RDP/SSH/WinRM/interfacce HTTP di amministrazione solo dai Jump-Hosts, non dalla rete client completa.
• Risorse critiche: Domain Controller, repository di backup, PKI, cassaforte delle password – molto RESTrittivo, pochi flussi consentiti.
• IoT/OT: „Può comunicare solo con X e Y“ è di solito facile da definire e riduce fortemente i movimenti laterali.

Implementazione concreta: VLAN, routing e policy firewall a tappe

La seguente suddivisione in fasi è volutamente conservativa, perché limita i disservizi e permette di apprendere.

Fase A: creare la struttura VLAN senza modificare la comunicazione

È possibile spostare i dispositivi progressivamente in nuove VLAN finché l’inter-VLAN routing consente i percorsi precedenti. L’obiettivo iniziale è ordine e visibilità. PRESTate attenzione a:

• Ambiti DHCP per VLAN, Option 3 (Gateway) e Option 6 (DNS) corretti.
• Indirizzamento IP: reti comprensibili (p. es. per zona/sede), riserve per la crescita.
• Trunk/Native VLAN: un design errato qui genera „problemi fantasma“ (VLAN sbagliato, ARP-leaks). Verificate con costanza cosa è untagged.

Se volete rinfrescare le basi su Access/Trunk/Native VLAN, pianificate internamente un collegamento al vostro articolo sul design delle VLAN (aiuta anche in fase di troubleshooting).

Fase B: policy prima in Modus „Beobachten“ (Logs/Flows)

Prima di bloccare, volete sapere cosa accade realmente. Due fonti di dati pratiche:

• Log del firewall per il traffico inter-VLAN (se già instradato attraverso il firewall).
• Dati flow (NetFlow/IPFIX/sFlow) dal core o dallo switch di distribuzione – danno „chi parla con chi, quanto, quanto spesso“.

L’obiettivo è una matrice di comunicazione (Zona A → Zona B, porte/protocolli, direzione). Non deve essere perfetta, ma sufficiente per le prime regole.

Fase C: „Default Deny“ per zona pilota con regole esplicite di Allow

Selezionate una zona con uno scope contenuto (p. es. IoT o un piccolo blocco server) e impostate tra quella zona e il RESTo il Default Deny. Poi consentite solo i flow necessari, p. es. DNS, NTP, syslog/monitoring, aggiornamenti e destinazioni specifiche dell’applicazione.

Importante: utilizzate stateful regole quando possibile. Stateful significa che il firewall tiene traccia delle connessioni e consente automaticamente il traffico di ritorno. Con ACL stateless bisogna considerare esplicitamente la direzione di ritorno e le porte effimere (porte client dinamiche) — una fonte comune di errori.

Aperture minime tipiche spesso dimenticate

Questi flussi sono in molti ambienti „essenziali ma invisibili“. Se mancano, i malfunzionamenti appaiono casuali:

• DNS (UDP/TCP 53) verso i resolver previsti. TCP è rilevante per risposte di grandi dimensioni e trasferimenti di zona.
• NTP (UDP 123) verso sorgenti di tempo interne. La deriva dell’orario compromette Kerberos, le catene di certificati e la correlazione dei log.
• Autenticazione: a seconda dell’architettura Kerberos (TCP/UDP 88), LDAP/LDAPS (389/636), SMB (445) per percorsi specifici, eventualmente RADIUS (1812/1813).
• PKI/CRL/OCSP: la verifica dei certificati richiede l’accesso agli endpoint CRL/OCSP (interni o esterni). Senza ciò si verificano errori TLS che appaiono come „l’applicazione impazzisce“.
• Management: SNMP (idealmente v3), WMI/WinRM/RDP/SSH solo dalla zona di gestione, non dalle reti utente.
• Monitoring/Logging: Syslog, comunicazione degli agent, exporter, a seconda dello stack.

Il guadagno in sicurezza non deriva dal „fare tutto“, ma dal definire in modo controllato e coerente questi percorsi di base, invece di lasciarli implicitamente aperti.

Risoluzione dei problemi: quando dopo la segmentazione „all’improvviso“ qualcosa non funziona

La segmentazione raramente fallisce per l’idea, ma per la mancanza di una routine di diagnostica. Un percorso di verifica pratico:

1) Delimitare il problema: nome, IP, porta, direzione

Poneteci una domanda chiara: „Da sorgente a destinazione sulla porta/protocollo fallisce.“ Senza questa precisione perderete tempo in falsi problemi (DNS vs. routing vs. policy).

2) Verificare routing e Next-Hop

Quadro d’errore: i pacchetti aggirano il punto di enforcement sbagliato o seguono un percorso asimmetrico (andata diversa dal ritorno). Il routing asimmetrico è critico per i firewall stateful, perché i pacchetti di ritorno non corrispondono allo stesso stato.

Su un Linux-sistema può verificare il percorso così:

ip route get 10.20.30.40
ping -c 3 10.20.30.40
traceroute -n 10.20.30.40

Su Windows PowerShell è utile:

Test-NetConnection -ComputerName 10.20.30.40 -Port 443 -InformationLevel Detailed
tracert -d 10.20.30.40

3) Firewall: log invece di indovinare

Se utilizza un firewall centrale, la verità più rapida è il record di log: quale regola corrisponde? Viene scartato? Manca un gruppo di oggetti? Il traffico è „App-Identified“ o solo basato su porta? Controlli se la sessione viene effettivamente instaurata o fallisce al SYN (TCP) oppure se mancano risposte UDP.

Suggerimento pratico: attivate per le nuove policy temporaneamente logging mirato (non globale), altrimenti i sistemi SIEM/di log vengono sommersi dai dati.

4) Cattura dei pacchetti nel punto giusto

Un tcpdump sull’host è spesso più veloce di ogni ipotesi. Esempio: verificare la risoluzione DNS:

sudo tcpdump -ni any host 10.10.10.53 and port 53

Se vede solo le richieste ma non le risposte, spesso è un problema di policy/routing/state. Se non vede nulla, è più probabile che si tratti del firewall host, dell’interfaccia sbagliata o della destinazione errata (p. es. un altro server DNS assegnato via DHCP).

5) Insidie comuni nell’operazione di segmentazione

• Porte effimere: i porti sorgente dei client sono dinamici. Le regole dovrebbero in genere consentire ‚Client → Server: dst port X‘, non ’src port X‘.
• DNS su TCP: viene utilizzato per risposte di dimensioni maggiori. Consentire solo UDP non è sempre sufficiente.
• MTU/Frammentazione: nuovi percorsi possono avere MTU diverse. Bloccare ICMP (p. es. ‚Fragmentation needed‘) compromette il PMTUD.
• Hairpinning: il traffico East–West attraverso una firewall centrale può modificare le prestazioni. Misurate throughput e latenza durante i picchi di carico.
• Enforcement multiplo: firewall di rete più firewall host più regole SDN — l’analisi dei guasti richiede allora una sequenza: prima host, poi SDN, poi rete.

Pratiche operative consigliate per le regole firewall nella microsegmentazione

Alcune regole fanno la differenza tra ‚complesso‘ e ‚affidabile in esercizio‘:

Transizioni di zona esplicite invece di ‚Any tra VLAN‘

Formulate le policy lungo le vostre zone e i servizi, non per singoli indirizzi IP. Esempio: ‚Client → Web-Frontend‘, ‚Web → App‘, ‚App → DB‘. Questo non è solo sicurezza, ma anche trasparenza architetturale.

‚Deny with log‘ da usare in modo mirato

Per ogni zona pilota impostate un chiaro drop-log. Su questo costruite le successive regole di allow. Dopo la stabilizzazione riducete nuovamente il logging o passate a campionamento/alerting, così l’operatività non soffre per il carico di log.

Definire proprietario del servizio e finestre per le modifiche

La microsegmentazione è un’interfaccia tra rete e operation delle applicazioni. Stabilite chi richiede le approvazioni, chi le autorizza e come testate le modifiche. Senza questa governance nasce shadow‑IT sotto forma di ‚aprire temporaneamente e al volo‘.

Igiene delle regole: date di scadenza e review

Le eccezioni dovrebbero avere una data di scadenza (es. 30/60/90 giorni) e poi essere verificate attivamente. In molti ambienti questo è l’unico modo per mantenere la base di regole snella nel lungo periodo.

Validazione: passaggi di verifica prima e dopo il cutover

Pianificate i test come un piccolo rilascio. Una checklist compatta:

• Connettività: DNS, NTP, autenticazione (login), heartbeat del monitoring.
• Flussi di business: i 3–5 percorsi utente più importanti (p. es. accesso alla Web-App, archivio file, connessione client ERP, stampa).
• Flussi amministrativi: RDP/SSH/WinRM solo tramite jump host, nessun accesso diretto dalla zona client.
• Logging: i drop sono visibili, ma il volume di log rimane gestibile.
• Prestazioni: misurare latenza/throughput sui colli di bottiglia (firewall, core), non valutarli solo in modo soggettivo.

Per problemi TCP (SYN, retransmits, timeouts) è indicata un’analisi strutturata con Wireshark/pcaps; internamente è opportuno inserire un link al vostro Wireshark‑howto non appena avrete pubblicato il contributo nel magazine.

Strategia di rollback: come tornare indietro in sicurezza senza creare caos

Il Rollback non è „speriamo che non serva“. Definite in anticipo criteri e passaggi chiari:

• Criterio di rollback: ad es. „accesso all’applicazione core non possibile“, „monitoring-heartbeat > X sistemi non raggiungibili“, „telefonia non funzionante“.
• Leva tecnica: disattivare un gruppo di regole, ripristinare l’ordine delle policy o riportare il routing allo stato precedente — preferibilmente senza dover spostare nuovamente le VLAN.
• Soglia temporale: se dopo N minuti non si osserva stabilizzazione, eseguire il rollback.
• Operazioni successive: salvare i log, documentare i flussi interessati, quindi aggiungere regole Allow mirate.

Importante per la pratica: tenete pronti accessi „Break-Glass“ (ad es. gestione fuori banda, accesso console locale, account di emergenza), in modo da non rimanere esclusi dalla gestione di rete a causa della vostra stessa segmentazione.

Quando VLAN e regole del firewall da sole non sono sufficienti

Le VLAN e le policy centralizzate sono un buon punto di partenza, ma ci sono dei limiti:

• Stessa zona, elevata esigenza di protezione: se più sistemi critici si trovano nella stessa VLAN, la segmentazione VLAN non impedisce attacchi laterali all’interno del segmento. In quel caso aiutano microsegmenti (più VLAN), firewall distribuiti o regole a livello host.
• Ambienti dinamici: cambi frequenti (ad es. molte VM effimere) beneficiano di policy basate su identità o su tag (Workload-Tags), invece di un regolamento basato su IP.
• Autenticazione dei dispositivi: per una vera verifica di „chi può accedere alla rete“ è rilevante NAC (Network Access Control, ad es. 802.1X). Senza NAC la LAN rimane vulnerabile a dispositivi rogue, anche se il traffico inter-zone è strettamente controllato.

In molte aziende la roadmap realistica è: prima zone + policy centralizzate, poi gradualmente NAC/Device-Posture e politiche di workload più granulari dove conviene.

Conclusione: Zero-Trust nella LAN è un modello operativo, non un Big Bang

Zero-Trust nella LAN funziona quando si stabilisce la microsegmentazione come processo controllato: definire chiaramente le zone, rendere visibili i flussi, affinare le policy per tappe e mettere in sicurezza il funzionamento con logging, percorsi di troubleshooting e rollback. Le VLAN forniscono struttura, le regole del firewall forniscono applicazione — la combinazione è pratica finché i percorsi di routing sono chiari, i servizi di base sono aperti consapevolmente e le eccezioni non diventano la regola. Partite in piccolo, misurate l’impatto e ampliate i segmenti dove rischio e beneficio corrispondono.