Un firewall aziendale non diventa “cloud” soltanto perché si gestisce da un portale web. La differenza decisiva è dove passa il traffico e dove vengono applicate le regole: su un apparato nella sede, dentro una rete cloud, oppure in un servizio distribuito raggiunto dagli utenti via Internet. La scelta corretta parte quindi dai flussi reali, non dal catalogo del fornitore.
Per molte imprese la risposta non è esclusivamente hardware o cloud. Una sede con server locali può richiedere un apparato fisico in alta affidabilità, mentre utenti remoti e applicazioni SaaS possono essere protetti da controlli erogati come servizio. L’architettura ibrida è spesso più coerente, ma aumenta il bisogno di regole uniformi, log centralizzati e responsabilità chiare.
Firewall hardware e cloud: che cosa cambia davvero
Il firewall hardware è un dispositivo dedicato installato tra reti con livelli di fiducia diversi, per esempio tra la LAN aziendale e Internet. Può filtrare indirizzi, porte, applicazioni e contenuti, terminare tunnel VPN e ispezionare il traffico. L’apparato resta fisico, anche quando licenze, firme e configurazione dipendono da servizi online.
“Firewall cloud” indica invece famiglie differenti. Esistono firewall nativi inseriti nelle reti virtuali di un provider, macchine virtuali di sicurezza gestite dal cliente e servizi di sicurezza distribuiti che ricevono il traffico di sedi e utenti. Confonderli porta a preventivi incomparabili, perché cambiano perimetro, responsabilità e unità di costo.
Il NIST descrive il firewall come un dispositivo o programma che controlla il flusso tra reti o host con posture di sicurezza diverse. La definizione resta utile anche oggi: il prodotto non crea da solo una politica. Servono criteri per selezione, configurazione, test, gestione e revisione delle regole.
| Criterio | Hardware in sede | Firewall cloud o come servizio |
|---|---|---|
| Punto di controllo | Uscita della sede, segmenti interni e collegamenti locali | Reti virtuali, utenti remoti, filiali o traffico instradato al servizio |
| Spesa tipica | Acquisto o noleggio, licenze, supporto, energia e sostituzione | Canone o ore di utilizzo, dati elaborati, log e funzioni aggiuntive |
| Capacità | Limitata dal modello, dalle licenze e dalle funzioni attive | Scalabile entro quote, regioni e architettura del servizio |
| Continuità | Richiede coppia HA, alimentazione e collegamenti ridondanti | Richiede più zone o punti di presenza e routing progettato bene |
| Gestione | Patch, ricambi e ciclo di vita ricadono in parte sull’impresa | Infrastruttura gestita dal provider; policy e dati restano responsabilità del cliente |
| Utenti mobili | Spesso rientrano in sede tramite VPN | Possono raggiungere il punto di controllo più vicino senza backhaul |
Partire dai flussi, non dal numero dei dipendenti
Due imprese con cinquanta persone possono avere esigenze opposte. Un laboratorio con macchinari, file server e gestionali locali concentra il traffico nella sede. Una società di consulenza distribuita usa soprattutto posta, videoconferenze e applicazioni SaaS. Il conteggio degli utenti non descrive dove sono i dati né quali collegamenti vanno protetti.
Prima del preventivo conviene disegnare una mappa semplice: sedi, reti Wi-Fi, server, dispositivi industriali, cloud, fornitori esterni e utenti remoti. Per ogni flusso si annotano origine, destinazione, applicazione, quantità di dati, criticità e requisito di disponibilità. Questa mappa mostra quali pacchetti devono attraversare davvero il firewall proposto.
La segmentazione conta quanto il perimetro. Una sola rete piatta consente a un incidente su una postazione di raggiungere più facilmente server, telecamere o sistemi amministrativi. Regole tra VLAN o zone riducono i movimenti laterali, ma richiedono un firewall capace di sostenere anche il traffico interno senza diventare un collo di bottiglia.
Per capire l’effetto della connettività sul progetto, è utile leggere anche la guida sulla fibra aziendale, la banda garantita e gli SLA. Un firewall ridondante non compensa un unico circuito senza tempi di ripristino misurabili.
Throughput: il numero di targa non basta
Il throughput indicato in grande nelle schede tecniche può riferirsi al semplice inoltro di pacchetti in condizioni favorevoli. L’impresa deve chiedere la capacità con le funzioni che userà davvero: prevenzione intrusioni, controllo applicazioni, antivirus, filtraggio web e ispezione TLS. Attivare questi moduli richiede più calcolo e può ridurre sensibilmente la portata utile.
Oltre ai gigabit al secondo servono almeno tre dati: sessioni contemporanee, nuove connessioni al secondo e throughput VPN. Un portale con molte connessioni brevi può saturare la creazione delle sessioni prima della banda. Una sede con backup notturni cifrati può invece raggiungere il limite crittografico pur avendo pochi utenti.
Il dimensionamento deve considerare il picco, non soltanto la media mensile. Videoconferenze, sincronizzazioni cloud, aggiornamenti e copie di sicurezza possono sovrapporsi. È prudente misurare i flussi per alcune settimane, includere la crescita prevista e verificare le prestazioni con un test che riproduca dimensione dei pacchetti e servizi di sicurezza attivi.
L’ispezione TLS aggiunge un’altra variabile. Per leggere il traffico cifrato il sistema deve decifrare e ricifrare le connessioni, gestire certificati ed eccezioni e rispettare vincoli tecnici e organizzativi. Non tutto il traffico può o deve essere ispezionato; una lista di esclusioni senza governance rischia però di creare zone cieche.
VPN, filiali e lavoro remoto
Una VPN site-to-site collega reti intere; una VPN di accesso remoto collega il singolo utente. Per entrambe vanno verificati algoritmi supportati, autenticazione multifattore, gestione dei certificati, capacità cifrata e comportamento in caso di caduta. Un tunnel attivo non dimostra che il servizio applicativo sia disponibile o che il percorso di ritorno sia corretto.
Portare ogni utente remoto dentro la sede consente un controllo centralizzato, ma può allungare il percorso verso servizi SaaS e caricare linea e apparato centrali. Un servizio cloud distribuito può applicare le policy più vicino all’utente. In cambio, l’azienda dipende dalla disponibilità del servizio, dal client e dalla connettività Internet del lavoratore.
Le filiali richiedono una decisione simile. Un apparato locale mantiene alcune regole e collegamenti anche se il portale centrale non è raggiungibile. Una soluzione gestita può accelerare il dispiegamento e uniformare le configurazioni. Il capitolato deve dire cosa continua a funzionare durante un’interruzione del controllo, non soltanto durante un guasto della linea principale.
IDS e IPS: rilevare non significa bloccare sempre
Un sistema IDS segnala attività che corrispondono a firme o comportamenti sospetti. Un IPS è disposto sul percorso e può bloccarle. Nelle piattaforme moderne le due funzioni convivono, ma l’efficacia dipende da firme aggiornate, contesto, modalità scelta e capacità di gestire falsi positivi.
Attivare ogni firma con la massima severità non è automaticamente più sicuro. Una regola imprecisa può interrompere un gestionale o un collegamento con un fornitore. È preferibile partire da una policy documentata, osservare gli allarmi, correggere le eccezioni con scadenza e passare al blocco quando il comportamento normale è compreso.
I log devono consentire di risalire a regola, sorgente, destinazione, applicazione e azione. Conservare tutto senza filtri può far crescere costi e rumore; conservare troppo poco rende difficile ricostruire un incidente. La durata va definita rispetto a obblighi, rischio e capacità operativa, con accessi tracciati e protezione dall’alterazione.
Alta affidabilità: due scatole non bastano
Una coppia di firewall in HA riduce il rischio di guasto del singolo apparato, ma non elimina i punti unici di fallimento. Se entrambi usano lo stesso alimentatore a monte, lo stesso switch, lo stesso armadio o la stessa linea, una sola interruzione può fermarli insieme. La ridondanza va verificata da capo a capo.
Il failover deve essere provato con traffico reale. Occorre sapere se le sessioni attive sopravvivono, quanto dura il passaggio, come reagiscono VPN e routing e se le configurazioni sono sincronizzate. Un test programmato produce informazioni che la sola icona “verde” del cluster non può offrire.
Nel cloud l’alta disponibilità richiede più zone o endpoint e rotte simmetriche. L’esempio pubblico di AWS Network Firewall mostra che il costo viene calcolato anche per ogni endpoint e per i gigabyte elaborati. La disponibilità tecnica del servizio non evita quindi errori di routing o una distribuzione incompleta tra zone.
Come si calcola il costo totale di un firewall hardware
Il prezzo iniziale dell’apparato è solo una voce. Il conto completo comprende seconda unità per HA, moduli o porte, abbonamenti alle firme, supporto, ricambi, installazione, configurazione, migrazione, energia, spazio rack, monitoraggio e ore di amministrazione. Alla fine del ciclo vanno considerate anche sostituzione e smaltimento.
Le licenze possono essere legate al modello, al numero di utenti, al throughput o ai pacchetti di funzioni. Il preventivo deve specificare che cosa accade alla scadenza: alcune funzioni smettono di aggiornarsi, altre vengono disattivate, altre continuano senza supporto. Una voce “licenza tre anni” senza questo dettaglio non è confrontabile.
Il costo dell’interruzione merita una riga separata. Una coppia più costosa può essere razionale se una giornata di fermo blocca ordini, produzione o assistenza. Al contrario, un ufficio che lavora quasi tutto in SaaS può investire di più in doppia connettività e protezione degli utenti, anziché concentrare tutto sul perimetro della sede.
Come si calcola il costo di un firewall cloud
Nel cloud il costo può includere ore di esecuzione o endpoint, gigabyte elaborati, capacità riservata, ispezione avanzata, gestione centralizzata, regole di terzi, log, conservazione e trasferimento dei dati. Alcune architetture aggiungono gateway, bilanciatori o costi tra zone. Per questo il listino della singola funzione non coincide con il costo della soluzione.
La pagina ufficiale di AWS usa, in un esempio pubblico, una tariffa per ora dell’endpoint e una per gigabyte elaborato; mostra inoltre un caso con due zone e 5.000 GB mensili. Non è un preventivo universale: regione, servizi collegati, ispezione e traffico modificano il risultato. È però un buon modello per chiedere tutte le variabili.
Una formula di confronto può essere: costo fisso mensile più traffico elaborato, log ingeriti e conservati, funzioni avanzate, assistenza e ore interne. Per l’hardware si può trasformare l’acquisto in quota mensile sul ciclo previsto, poi aggiungere licenze e gestione. Le due somme vanno riferite allo stesso perimetro di traffico e allo stesso livello di disponibilità.
Un esempio per una PMI con due sedi
Immaginiamo un’impresa con ottanta persone, due uffici, server di file e produzione nella sede principale, applicazioni Microsoft 365 e sessanta accessi remoti occasionali. Ogni sede ha una linea primaria e una secondaria. Il traffico Internet complessivo arriva a quattro terabyte al mese, ma una parte resta locale tra reparti.
Una soluzione solo cloud dovrebbe instradare in modo affidabile utenti, sedi e reti virtuali verso i punti di controllo. È adatta se la maggior parte delle applicazioni è esterna e il servizio offre presenza vicina, client gestibili e policy uniformi. Va stimato l’effetto economico di quattro terabyte, dei log e dell’ispezione richiesta.
Una soluzione solo hardware protegge bene l’uscita e la segmentazione locale, ma gli utenti remoti potrebbero rientrare in sede prima di raggiungere il SaaS. Il dimensionamento deve includere VPN e ispezione al picco. Servono inoltre due apparati nella sede critica e un piano per la filiale.
Un disegno ibrido può lasciare alla coppia hardware il traffico locale e i server, affidando a un servizio distribuito gli utenti remoti. Il vantaggio esiste soltanto se identità, regole, log e gestione degli incidenti restano coerenti. Due console separate senza processo comune possono costare più e proteggere meno.
Gestione, aggiornamenti e responsabilità
Con l’hardware l’impresa o il partner devono pianificare firmware, backup di configurazione, sostituzione, compatibilità e fine supporto. Il cloud riduce la manutenzione dell’infrastruttura sottostante, ma non decide chi può comunicare con chi. Le regole troppo ampie, le credenziali deboli e i log ignorati restano problemi del cliente.
Il contratto deve separare attività incluse e attività a consumo: apertura regole, analisi allarmi, incident response, tuning IPS, rinnovo certificati, test HA e report. Un servizio “gestito 24/7” può limitarsi alla disponibilità della piattaforma, senza comprendere l’indagine su un allarme aziendale.
Le API e le automazioni richiedono credenziali dedicate, privilegi minimi e tracciamento. Lo stesso principio vale per strumenti di messaggistica e marketing collegati alla rete: la guida sul software SMS marketing mostra perché token, webhook e liste di contatti devono entrare nel modello di sicurezza.
Domande da inserire nel capitolato
Chiedere prestazioni con tutte le funzioni previste, quantità di sessioni, latenza, regioni o punti di presenza, comportamento offline e tempi di sostituzione. Il fornitore deve descrivere la topologia, non soltanto nominare il prodotto. Servono anche schema delle licenze, vincoli di uscita e formato di esportazione delle configurazioni.
Per i log vanno indicati volume stimato, destinazione, retention, accessi, cifratura ed eventuali costi di interrogazione. Per l’HA vanno descritti test, frequenza e risultati accettabili. Per la VPN servono metodi di autenticazione, client supportati, capacità reale e procedura di revoca degli accessi.
Infine, va richiesto un piano di migrazione e ritorno. Cambiare firewall modifica routing, indirizzi, certificati e dipendenze applicative. Un rollback provato, una finestra concordata e contatti di escalation riducono più rischio di una generica promessa di installazione “senza fermo”.
FAQ sul firewall aziendale
Un firewall cloud sostituisce sempre quello in sede?
No. Può proteggere utenti remoti e reti cloud, ma una sede con server, segmenti interni o dispositivi locali può richiedere ancora un punto di controllo sul posto. La risposta dipende dai flussi e dal comportamento previsto quando Internet non è disponibile.
Come si confronta il throughput di due modelli?
Si confrontano misure ottenute con le stesse funzioni attive: IPS, controllo applicazioni, VPN e, se prevista, ispezione TLS. Vanno considerati anche sessioni contemporanee, nuove connessioni al secondo, dimensione dei pacchetti e margine per i picchi.
L’alta affidabilità richiede sempre due apparati?
Per l’hardware, una coppia è la base più comune, ma servono anche alimentazione, switch e linee indipendenti. Nel cloud la ridondanza usa più zone o endpoint. In entrambi i casi il failover deve essere testato con applicazioni e VPN reali.
Quali costi nascosti controllare nel cloud?
Oltre al canone o alle ore: traffico elaborato, trasferimenti, log, retention, capacità riservata, ispezione avanzata, regole di terzi e supporto. Il calcolo deve includere l’intera architettura di rete, non soltanto la voce “firewall”.
Ogni quanto vanno riviste le regole?
Non esiste un intervallo unico. Le regole vanno riesaminate quando cambiano applicazioni, fornitori o sedi e secondo un calendario basato sul rischio. Ogni eccezione dovrebbe avere proprietario, motivazione e, quando possibile, una data di scadenza.
La scelta migliore è quella che applica regole verificabili nei punti in cui passa davvero il traffico, mantiene visibilità durante i guasti e assegna chiaramente gestione e risposta agli incidenti. Hardware, cloud e ibrido sono strumenti: senza inventario, misure e test, nessuno dei tre è una garanzia.