Distribuire e gestire Sophos Firewall su AWS
Sophos Firewall viene eseguito in AWS come appliance EC2 inline in una VPC. Prima si sceglie tra firewall standalone e gruppo Auto Scaling. I modelli hanno limiti diversi per licenza, interfacce e traffico.
⚠️ Le AWS Security Groups restano un secondo livello firewall. Una regola SFOS non supera Security Group, NACL o Route Table bloccanti e una porta AWS aperta non va combinata con una regola Sophos ampia.
Standalone o Auto Scaling
| Modello | Uso | Limite importante |
|---|---|---|
| Standalone BYOL | Appliance a lungo termine con licenza Sophos | EC2 resta separato e i core devono corrispondere alla licenza. |
| Standalone PAYG | Uso orario e pilot | FullGuard è fatturato da AWS; verificare la regione. |
| Auto Scaling PAYG | DNAT o WAF inbound variabile | Solo PAYG, single-arm su PortB e solo traffico inbound. |
AWS non supporta HA nativo Sophos Firewall. Auto Scaling e load balancing sono un design cloud separato, non sincronizzazione HA SFOS.
Distribuire standalone con CloudFormation
- Scegliere BYOL o PAYG nel Marketplace, accettare i termini e selezionare regione e versione SFOS corrente.
- Usare Launch CloudFormation e scegliere VPC nuova o esistente.
- Per una VPC esistente associare VPC ID, subnet pubblica, subnet privata ed Elastic IP.
- Dimensionare EC2 per traffico e licenza; BYOL non supera i core licenziati.
- Verificare le risorse IAM e avviare lo stack.
- Dopo
CREATE_COMPLETE, leggere EIP in Outputs e attendere i check EC2. - Consentire inizialmente WebAdmin solo da un IP admin fisso su
https://<EIP>:4444e registrare la firewall. - Testare PortA, PortB, Route Tables, Source/Destination Check, Security Groups, NACL e ritorno.
IPsec, SSL VPN, RED, WAF e portali richiedono regole AWS aggiuntive; RED usa ad esempio TCP 3410. Non aprire SSH o WebAdmin a 0.0.0.0/0.
Gestire Auto Scaling in sicurezza
Auto Scaling registra i worker tramite un Service Principal Sophos Central. Definire due Availability Zones, capacità minimum, starting e maximum e Warm Pool Refresh. Trusted Network CIDR contiene l’IP admin come /32, non 0.0.0.0/0; ridurre poi Public Network CIDR alle fonti reali.
I worker sono effimeri. CloudWatch memorizza i log sotto /sophos/xg/. Le istanze terminate restano nel gruppo Central e vanno eliminate manualmente. Warm Pool non sostituisce la verifica della policy corrente su tutti i worker attivi.
DNAT dietro Network Load Balancer
Il listener NLB invia il servizio autorizzato alla Target Group delle firewall. La policy di gruppo contiene range WAN di entrambe le zone, host e servizio esatto. La regola corrisponde WAN-WAN e DNAT usa MASQ per un ritorno simmetrico.
L’esempio ufficiale usa RDP, ma la pubblicazione diretta non è consigliata. Preferire VPN o ZTNA. Se DNAT è necessario, limitare le fonti in NLB, AWS e SFOS, attivare IPS e logging ed eseguire un test negativo.
Collaudo e gestione
Verificare insieme route AWS, Security Groups, NACL, salute NLB, Rule ID, DNAT, ritorno, gruppo Central e log. Documentare owner, costi, firmware, licenza, retention CloudWatch, pulizia Central e rebuild CloudFormation. Uno snapshot EC2 non sostituisce un backup SFOS esportato.