I firewall di ultima generazione saranno l’ultima generazione di firewall
Il punto della situazione su firewall fisici, SASE e modelli ibridi
Ciao, sono Ale.
Con questa newsletter mettiamo il dito su un nervo scoperto per molti system integrator e IT Manager. Le architetture SASE hanno riscritto le regole del gioco, ma molti non si sono ancora adeguati.
Oltre all’esperienza di decine di conversazioni negli ultimi mesi, un mio recente post su LinkedIn ha riacceso il dibattito.
La mia affermazione era netta:
La paura di eliminare il firewall fisico è l’ultima resistenza di un modello IT che non esiste più.
Ne è scaturita una discussione che mi permette oggi di riassumere lo stato dell’arte delle reti geografiche e della sicurezza.
Molte aziende adottano piattaforme SASE come CATO ma le limitano. Le usano per use case puntuali in parallelo ad architetture legacy o, come vediamo per CATO, come proxy per superare il Great Firewall cinese, ma poi mantengono i firewall fisici nelle altre location.
Nel caso di CATO pagano per la piattaforma globale per eccellenza e la riducono a un compito regionale.
Perché? Per il combinato disposto di due cause:
Non si fidano a eliminare del tutto il firewall fisico
Il loro fornitore non ha il grado di maturità necessario sulla tecnologia per spingerli a farlo
Il risultato è un’architettura ibrida inefficiente che perde tutti i vantaggi del SASE e accumula tutti gli svantaggi delle architetture legacy.
Il modello IT che non esiste più
Il firewall fisico appartiene a un’epoca diversa dell’IT.
Un’epoca in cui:
Gli utenti lavoravano in ufficio, connessi alla LAN
I dati risiedevano nel data center aziendale
Le applicazioni giravano on-premises
Il perimetro di rete era definibile geograficamente
Quel modello è finito progressivamente negli ultimi 15 anni e ora è definitivamente superato.
Oggi:
Gli utenti sono distribuiti (home office, smartworking, mobilità)
I dati sono nel cloud (AWS, Azure, GCP)
Le applicazioni sono SaaS (ERP, Microsoft 365, Salesforce, tool collaborativi)
I branch sono distribuiti geograficamente
Terze parti e partner accedono a risorse condivise IT e OT.
In questo ecosistema, il firewall fisico è un collo di bottiglia architetturale e presidia un confine che non esiste più.
Ogni connessione deve passare attraverso un punto fisico. Ogni sede ha bisogno della sua coppia di firewall in HA. Ogni accesso remoto richiede VPN che backhaulano il traffico verso il data center per ispezionarlo, anche se la destinazione è un servizio cloud.
Latenze. Complessità. Single points of failure. Costi hardware crescenti. Poca visibilità e controllo sulle periferie.
Perché mantenere l’ibrido non conviene
Molte aziende adottano SASE ma mantengono i firewall fisici “per sicurezza”. Questo crea un modello ibrido che è inefficiente a tutti i livelli. Due architetture in parallelo che amplificano i limiti delle architetture legacy
Inefficienza operativa
Gestire due architetture diverse significa:
Due set di configurazioni da mantenere allineate
Due skill set necessari nel team
Due vendor da coordinare
Due superfici di troubleshooting quando qualcosa non funziona
Si perde l’elemento vincente del SASE: la standardizzazione e la gestione centralizzata.
Invece di avere policy definite una volta e applicate globalmente, hai policy sui firewall locali + policy sulla piattaforma SASE. E devi tenerle sincronizzate manualmente.
Rischio cyber aumentato
Le configurazioni inconsistenti tra sedi diverse sono una superficie di attacco.
Un attaccante che compromette una sede con configurazioni più deboli può usarla come pivot verso il resto della rete. La segmentazione è efficace solo se è coerente ovunque.
Con firewall fisici distribuiti, la coerenza è un obiettivo, non una garanzia. Con SASE, è nativa.
Pressione sul personale
Gestire hardware legacy richiede tempo che il tuo team già non ha.
Firmware update sui firewall (con quale tempestività?). Sostituzione hardware quando va fuori supporto. Troubleshooting di problemi hardware. Gestione licenze per sede.
Le configurazioni in parallelo (locale + cloud) sono più onerose da implementare e manutenere. Ogni change richiede doppio lavoro.
E il personale che sa configurare firewall legacy è sempre più difficile da trovare e trattenere e aumenta il vincolo verso la tecnologia già nota.
Le obiezioni (e le risposte)
“Non esiste un modello universale. Se il progetto di firewall fisico è fatto bene, me lo tengo.”
Corretto: non esiste un modello universale.
Ma la domanda è: il tuo progetto “fatto bene” anni fa è ancora adeguato oggi?
Un’architettura “ben progettata” nel 2015 era centrata sul data center. Nel 2025, è centrata su identità e zero trust. Se hai utenti in mobilità, branch distribuiti, data center in cloud e servizi SaaS, cosa fai? Continui a seminare coppie di firewall e VPN in ogni sede?
Le architetture evolvono con l’ecosistema.
Il firewall fisico può ancora avere senso in casi specifici (ambienti OT isolati, requisiti compliance particolari). Ma nella stragrande maggioranza dei casi, è una zavorra.
“Dipende da costi, trust verso il vendor, threat model. Le best practice consolidate non si cancellano.”
Le best practice consolidate sono sacrosante. Concordo.
Ma la tecnologia si è evoluta talmente velocemente che ha introdotto semplificazioni utilissime per concentrarsi sul core business invece che sul tuning di N piattaforme eterogenee.
Quando dici “dipende dal livello di trust verso il fornitore”, stai implicitamente dicendo che ti fidi di più del tuo firewall fisico. Ma:
Il firmware del firewall viene da un vendor (Palo Alto, Fortinet, Cisco)
Le signature IPS/antimalware vengono aggiornate da quel vendor
Le vulnerability vengono patchate da quel vendor
La differenza è che con SASE, il vendor gestisce l’infrastruttura. Con firewall on-premises, tu gestisci l’hardware ma dipendi comunque dal vendor per sicurezza e aggiornamenti.
La questione del trust non cambia. Cambia dove si materializza la dipendenza.
Sul costo: mantenere firewall fisici ha costi nascosti. Licenze per sede, sostituzione hardware ogni 3-5 anni, personale per gestione, downtime per manutenzione.
SASE sposta da CapEx a OpEx, ma elimina molti costi nascosti.
“E la defense in depth? E la segmentazione? Modello stratificato?”
Con buona pace degli approcci “stratificati” basati su perimetro fisico: sono superati.
La defense in depth in SASE non solo esiste, ma è più completa:
Identità e autenticazione (chi sei)
Device posture (da dove ti connetti, com’è configurato il device)
Crittografia end-to-end
IPS, anti-malware, CASB, DLP inline
Tutto scalabile a tutto il traffico, senza i limiti fisici dei firewall.
Troppo spesso, nelle architetture con firewall fisici, non si fa nemmeno TLS inspection perché inginocchierebbe le appliance. O si creano cascate di tecnologie (firewall → proxy → DLP → sandbox) dove diventa difficile gestire anche solo il troubleshooting e che generano latenze.
La segmentazione e la segregazione si fanno anche in architetture SASE. Anzi, si aggiungono policy basate su identità in ottica zero trust.
Le regole sono valide per tutta la WAN immediatamente, senza doverle deployare in decine di siti. Coerenza e ordine garantiti.
E se non basta, ci sono analisi XDR inline su tutti gli eventi di rete e sicurezza.
“SASE sposta il rischio, non lo elimina. Firewall locale = gestione rischio.”
Questa è l’obiezione più tecnica e merita rispetto.
È vero: SASE sposta il rischio. Introduce dipendenze su connettività, identità, vendor.
Ma non elimina il concetto di firewall. Lo evolve.
In un’architettura SASE, il firewall come oggetto fisico non esiste più. Diventa una feature distribuita, insieme ad altre più legate all’identità.
Gartner ha iniziato a chiamarlo “Hybrid Mesh Firewall”: controlli distribuiti, policy centralizzate, enforcement ovunque serve.
L’attaccamento all’appliance “firewall” come la conosciamo è resistenza. Non al cambiamento in senso emotivo, ma a un modello architetturale che ha già cambiato.
Nella pratica, i problemi non nascono dall’architettura ibrida in sé. Nascono da scelte progettuali sbagliate e configurazioni incoerenti.
E il modello ibrido (firewall fisici + SASE) è quello che genera più facilmente configurazioni incoerenti.
Se mantieni controlli locali per compliance o continuità operativa in scenari specifici, ha senso. Ma nella maggior parte dei casi, è sovra-ingegnerizzazione che aggiunge complessità senza aggiungere sicurezza.
La SASE è evoluzione
Le soluzioni SASE non sono il silver bullet. Nessuna tecnologia lo è ma è innegabile che alza notevolmente l’asticella.
SASE copre molte necessità che tutte le aziende hanno, indipendentemente dal settore o dimensione:
Connettività sicura per utenti distribuiti (ZTNA)
Accesso sicuro a risorse cloud e on-premises
Policy di sicurezza coerenti ovunque
Scalabilità senza hardware aggiuntivo
Visibilità centralizzata su tutto il traffico
Eliminare i firewall fisici, a parte eccezioni puntuali, quando si adottano architetture SASE, è l’unico modo per:
Standardizzare la sicurezza
Smettere di subire l’obsolescenza dei componenti hardware
Ridurre la complessità operativa
Liberare il team da attività a basso valore (gestione hardware, aggiornamenti) per concentrarsi su attività ad alto valore (governance, policy, incident response, hardening)
La sicurezza è una questione di responsabilità tecnica non di ideologia, e la responsabilità tecnica, oggi, include capire quando un modello architetturale ha fatto il suo tempo.
Ale
Alcune cose che, se ti va, possiamo fare insieme:
LAB Napoli — Stai valutando le soluzioni SASE, ma hai bisogno di capire concretamente come funzionano? Allora il nostro LAB è perfetto per te.
Condividiamo — se hai un progetto che vuoi condividere con me o cerchi confronto su un argomento specifico.
Restiamo in contatto — ogni settimana condivido sul mio profilo LinkedIn insight legati alla tecnologia e soprattutto al suo impatto sul business.