Portare un FortiGate in AWS, Azure o GCP non è «lo stesso firewall sull’hardware di qualcun altro». Cambia il modello di licenza, cambia il modo in cui il traffico ti arriva, cambia l’alta disponibilità e cambiano gli oggetti indirizzo, perché in cloud gli IP sono effimeri per progetto. Il blueprint 7.6 chiede entrambe le soluzioni Fortinet: il prodotto che gestisci tu (FortiGate-VM) e il servizio gestito da Fortinet (FortiGate CNF).

Cosa cambia davvero nel cloud pubblico

Il primo problema è che perdi i punti di intercettazione: niente porta SPAN, niente tap, nessun cavo da spostare. Il traffico passa dal firewall solo se lo impone la tabella di routing del provider, e se nessuno scrive quella rotta il firewall resta acceso, licenziato e scavalcato.

Il secondo è che gli indirizzi non stanno fermi: con autoscaling e provisioning on demand le istanze nascono e muoiono di continuo, e una policy scritta su subnet statiche invecchia in poche ore. Il traffico est-ovest fra VPC, VNet e subaccount spesso non attraversa alcun perimetro.

Il terzo è la responsabilità condivisa, che vale anche sui costi. La documentazione Fortinet è esplicita: sei tu responsabile di tutto ciò che consumi (CPU, memoria, volumi, snapshot, trasferimento dati, banda) e i servizi attivi generano da soli file temporanei, log, volumi e snapshot che riempiono il disco e producono addebiti inattesi. Vanno impostati quote, avvisi di budget e allarmi sulla soglia di spazio disco.

FortiGate-VM: licenza, bootstrap e HA

La licenza FortiGate-VM si conta in vCPU allocate; sulla RAM non ci sono restrizioni. Gli stati che devi saper riconoscere sono sei: Valid, Validation overdue (non riesce a validarsi contro FortiGuard o FortiManager, ma da meno di 30 giorni), 30 day Grace Period, Duplicate copy (FortiGuard risponde 401; le policy continuano a funzionare, ma dopo 24 ore lo stato diventa invalido), Pending e Invalid. Invalid è quello che fa male: GUI limitata alla pagina di caricamento licenza, policy firewall non funzionanti, download FortiGuard non disponibili. Se qualcuno clona una VM invece di deployarne una nuova, finisce esattamente qui.

Esiste una licenza di valutazione permanente, che non scade, per il private cloud e per le istanze BYOL in cloud pubblico. I limiti la rendono utile solo in laboratorio: una copia per account FortiCloud, sola cifratura debole (tranne accesso GUI e comunicazione con FortiManager), massimo 1 CPU e 2 GB di memoria, massimo tre interfacce, policy e route, niente FortiCare, niente FortiGuard e al massimo due VDOM.

execute vm-license-options account-id utente@example.com
execute vm-license-options account-password ********
execute vm-license

Per il bootstrap si usa cloud-init, supportato su tutte le piattaforme cloud pubbliche e private. È un file MIME multipart con due allegati: uno chiamato config, che contiene una configurazione completa di backup oppure una parziale scritta in comandi CLI, e uno chiamato license. La VM nasce già licenziata e configurata: è il modo giusto di procedere in una pipeline infrastrutturale.

Sull’alta disponibilità c’è il punto che distingue chi ha davvero messo le mani in cloud. In AWS e in Azure il FortiGate-VM fa attivo/passivo con sincronizzazione HA unicast nativa fra primario e secondario, perché il livello 2 su cui poggia il FGCP on-premise lì non esiste. Quando rileva un guasto, l’istanza passiva diventa attiva e usa le chiamate API del cloud provider per riconfigurare le proprie interfacce: il ruolo IAM assegnato alla VM è quindi parte del disegno di HA, non un dettaglio amministrativo. L’attivo/attivo si costruisce sul bilanciatore del provider (elastic load balancing su AWS, Azure load balancer) e su AWS è supportato anche l’autoscaling.

SDN connector: policy che non invecchiano

Gli SDN connector risolvono il problema degli IP effimeri. Il connector si autentica all’API del cloud e sincronizza oggetti indirizzo dinamici, che poi usi come sorgente o destinazione nelle policy: se una risorsa cambia indirizzo o si sposta, la policy non si tocca.

Il flusso è di quattro passi: raccogliere le informazioni richieste, creare il connector, creare un indirizzo SDN e inserirlo in una policy. In GUI stanno sotto External Connectors. L’autenticazione cambia per piattaforma: AWS con access key, Azure con service principal, GCP con service account, OCI con certificati, IBM Cloud con API key; lato privato ci sono Kubernetes e VMware ESXi. Il parametro da non lasciare al caso è update-interval, che decide in quanto tempo la policy si accorge del cambiamento.

config system sdn-connector
    edit "aws-prod"
        set status enable
        set type aws
        set update-interval 60
    next
end

FortiGate CNF: il firewall come servizio

FortiGate Cloud-Native Firewall è software-as-a-service: elimina la necessità di configurare, provisionare e mantenere l’infrastruttura firewall, lasciando al team solo la gestione della policy. Gira su AWS e Azure, ospitato nell’infrastruttura del provider e collocato nella stessa region del workload protetto.

L’idea centrale è l’aggregazione: una sola istanza CNF copre più VPC (o più virtual network su Azure), più availability zone e più account della stessa region, con una policy condivisa. Sul piano funzionale offre blocco geo-IP e geo fencing, filtro degli IP malevoli tramite IP Reputation di FortiGuard, DNS filtering con categorie FortiGuard, IPS, sicurezza est-ovest agganciandosi alle transit network, policy dinamiche basate su paesi, FQDN e metadati delle risorse, più autoscaling, REST API e integrazione con AWS Firewall Manager.

La regola pratica: CNF quando vuoi una policy sola per region e zero manutenzione; FortiGate-VM quando ti servono funzioni del FortiOS completo o il controllo diretto dell’apparato. E CNF ragiona per region: una postura multi-region significa più istanze.