Déployer et exploiter Sophos Firewall sur AWS
Sophos Firewall fonctionne dans AWS comme appliance EC2 inline dans une VPC. Il faut d’abord choisir entre une firewall standalone et un groupe Auto Scaling. Les modèles n’ont pas les mêmes limites de licence, d’interfaces et de trafic.
⚠️ Les AWS Security Groups restent une seconde couche de pare-feu. Une règle SFOS ne contourne pas une Security Group, une NACL ou une Route Table bloquante, et un port AWS ouvert ne doit pas être associé à une règle Sophos large.
Standalone ou Auto Scaling
| Modèle | Usage | Limite importante |
|---|---|---|
| Standalone BYOL | Appliance durable avec licence Sophos | EC2 reste facturé et les cores doivent correspondre à la licence. |
| Standalone PAYG | Utilisation horaire et pilotes | FullGuard est facturé par AWS ; vérifier la disponibilité régionale. |
| Auto Scaling PAYG | DNAT ou WAF entrant variable | PAYG uniquement, single-arm via PortB et trafic entrant seulement. |
AWS ne prend pas en charge le HA natif Sophos Firewall. Auto Scaling et load balancing forment un autre design cloud, sans synchronisation HA SFOS.
Déployer standalone avec CloudFormation
- Choisir BYOL ou PAYG dans Marketplace, accepter les conditions et sélectionner région et version SFOS actuelle.
- Utiliser Launch CloudFormation et choisir une VPC nouvelle ou existante.
- Pour une VPC existante, associer VPC ID, subnets public et privé et Elastic IP.
- Dimensionner EC2 selon trafic et licence ; BYOL ne dépasse pas les cores sous licence.
- Contrôler les ressources IAM et lancer la stack.
- Après
CREATE_COMPLETE, lire l’EIP sous Outputs et attendre les contrôles EC2. - Autoriser d’abord WebAdmin uniquement depuis une IP d’administration fixe sur
https://<EIP>:4444, puis enregistrer la firewall. - Tester PortA, PortB, Route Tables, Source/Destination Check, Security Groups, NACL et retour.
IPsec, SSL VPN, RED, WAF et portails nécessitent des règles AWS supplémentaires ; RED utilise par exemple TCP 3410. Ne jamais ouvrir préventivement SSH ou WebAdmin à 0.0.0.0/0.
Exploiter Auto Scaling en sécurité
Auto Scaling enregistre les workers via un Service Principal Sophos Central. Définir deux Availability Zones, les capacités minimum, starting et maximum et le Warm Pool Refresh. Trusted Network CIDR contient l’IP d’administration en /32, jamais 0.0.0.0/0, puis Public Network CIDR est réduit aux sources réelles.
Les workers sont éphémères. CloudWatch stocke les logs sous /sophos/xg/. Les instances terminées restent dans le groupe Central et doivent y être supprimées manuellement. Le Warm Pool ne remplace pas la vérification que chaque worker actif a reçu la policy actuelle.
DNAT derrière le Network Load Balancer
Le listener NLB envoie le service autorisé à la Target Group des firewalls. La policy de groupe contient les plages WAN des deux zones, l’hôte et le service exact. La règle correspond de WAN à WAN et DNAT utilise MASQ pour un retour symétrique.
L’exemple officiel utilise RDP, mais une publication RDP directe n’est pas recommandée. Préférer VPN ou ZTNA. Si DNAT est indispensable, limiter les sources dans NLB, AWS et SFOS, activer IPS et logging et effectuer un test négatif.
Validation et exploitation
Contrôler ensemble routes AWS, Security Groups, NACL, santé NLB, Rule ID, DNAT, retour, groupe Central et logs. Documenter responsable, coûts, firmware, licence, rétention CloudWatch, nettoyage Central et reconstruction CloudFormation. Un snapshot EC2 ne remplace pas un backup SFOS exporté.