Déployer et exploiter Sophos Firewall sur AWS

Sophos Firewall 22 fonctionne dans AWS comme appliance EC2 virtuelle inline dans une VPC. Il faut d’abord définir le trafic à inspecter. Une firewall standalone peut contrôler le trafic entrant et sortant. Le template Sophos Auto Scaling est en revanche un design PAYG spécialisé dans le trafic DNAT ou WAF entrant.

Le parcours sûr consiste à choisir l’architecture et la licence, consigner le plan IP et de routage, lancer le template Marketplace approprié, limiter l’administration à une IP source fixe, valider un flux de bout en bout, puis seulement ouvrir d’autres services.

⚠️ Les AWS Security Groups restent une seconde couche de pare-feu. Une règle SFOS permissive ne sert à rien si une Security Group, une NACL ou une Route Table bloque le chemin. Inversement, il ne faut pas associer un port AWS ouvert à une règle Sophos trop large. Les Security Groups sont stateful et les Network ACL stateless : une NACL personnalisée doit donc autoriser l’aller et le retour.

Choisir standalone ou Auto Scaling

AWS ne prend pas en charge le HA natif de Sophos Firewall. Auto Scaling et Network Load Balancing forment un autre design cloud, sans synchronisation HA SFOS. Un design standalone doit donc inclure une procédure de reconstruction et une fenêtre d’interruption acceptée.

Le choix de l’instance repose sur trois vérifications : le type EC2 doit être proposé dans le template CloudFormation Marketplace ouvert pour la région et l’AMI choisies ; les performances CPU, RAM et réseau doivent convenir au débit et au profil de connexions ; avec BYOL, les droits CPU et les conditions applicables à cette licence précise doivent être confirmés.

La correspondance SFOS 22/23 indique par exemple m5.large avec 2 vCPU et 8 Go de RAM pour SFv2C4, ainsi que m5.xlarge avec 4 vCPU et 16 Go de RAM pour SFv4C6. Ces exemples de correspondance dépendent de la version et de l’offre ; ils ne constituent pas une garantie pour tous les templates actuels. Le suffixe RAM historique de la licence n’est donc pas un plafond fiable pour la RAM physique EC2 ; cela ne constitue pas non plus une garantie générale de droits RAM illimités. Avant l’achat, clarifier et documenter les droits de licence et d’offre précis avec Sophos ou le partenaire de licences ; en cas d’incertitude, ne pas déployer en production.

Choisir une taille proposée avec une marge de capacité et consigner le type EC2, l’AMI/la version SFOS ainsi que les conditions de licence confirmées dans le plan de déploiement.

Avec PAYG, la facturation logicielle ne s’arrête qu’après suppression de toutes les instances firewall concernées ; les ressources AWS conservées séparément peuvent continuer à générer des coûts.

Si le type prévu n’apparaît pas dans le template ou si CloudFormation refuse la combinaison région, AMI et taille, ne pas la forcer en modifiant manuellement le template. Choisir un type proposé qui satisfait la charge et la licence, ou arrêter le déploiement jusqu’à clarification de la région, de l’offre ou de la licence.

Clarifier la licence et le pilote avant l’achat

Si PAYG n’est pas disponible dans le pays ou l’offre concernés, Standalone BYOL avec une licence confirmée peut être envisagé ; cela ne rend pas le template Auto Scaling exclusivement PAYG utilisable avec BYOL. Il est également possible d’étudier, auprès de Sophos ou d’un partenaire, un Private Offer avec des tarifs et conditions négociés individuellement. BYOL évite les frais logiciels Marketplace, mais pas les coûts EC2 et d’infrastructure.

Pour un pilote, vérifier les droits d’essai réels, la durée et les conditions de l’offre choisie. La FAQ AWS historique décrit un essai logiciel PAYG de 30 jours ; cela ne garantit pas les conditions de l’offre sélectionnée aujourd’hui. Après la fin de son essai, toute utilisation supplémentaire du logiciel PAYG devient automatiquement payante. EC2, le stockage, le réseau et les autres infrastructures peuvent être facturés dès la période d’essai. Consigner la date de fin, le responsable des coûts, une alarme budgétaire et la décision de poursuivre l’exploitation ou de procéder au démantèlement à temps. Avec BYOL, utiliser une activation d’essai proposée lors de la configuration initiale ou une licence d’essai approuvée au préalable ; l’enregistrement seul ne garantit pas l’octroi d’une licence.

Une licence UTM de production ne peut être convertie en licence Sophos Firewall que par le processus de conversion prévu, sous réserve des droits applicables. Le transfert d’une licence firewall existante n’est lui aussi possible que dans les scénarios autorisés, et non par réutilisation arbitraire de la même clé. Confirmer ces deux points avec le partenaire de licences avant de démarrer BYOL. Activer une clé de licence décrit ensuite l’activation.

Dans le modèle de responsabilité partagée, les applications, les données, la configuration et la maintenance restent sous votre responsabilité. IPS, le filtrage web et WAF complètent les SG/NACL uniquement sur le chemin de trafic effectivement contrôlé. Synchronized Security nécessite des licences Endpoint adaptées, l’enregistrement et une policy Heartbeat/firewall ; il n’isole pas automatiquement tous les chemins de trafic latéral EC2 qui contournent les contrôles. Connexion à Central explique la connexion à la gestion centralisée.

Préparer le déploiement standalone

Consigner avant le lancement :

• compte AWS, région, Availability Zone et offre BYOL ou PAYG ;
• VPC nouvelle ou existante et CIDR public et privé sans chevauchement ;
• source d’administration fixe, par exemple 198.51.100.27/32, plutôt qu’un accès mondial ;
• Elastic IP, noms DNS et services entrants requis ;
• réseaux cibles privés, route par défaut et chemin retour de chaque flux de test ;
• type EC2 pris en charge, limite de licence, responsable des coûts et tags ;
• procédures de backup, firmware et reconstruction.

198.51.100.27/32 est une adresse de documentation à remplacer par l’adresse publique réelle de l’administrateur. Si elle change souvent, un VPN ou un jump host contrôlé est plus sûr qu’une large exposition de TCP 4444.

Dans une VPC existante, ne pas choisir les subnets uniquement par leur nom. Leurs Route Tables doivent correspondre au sens prévu. AWS explique l’insertion d’une appliance dans ses exemples de routage middlebox. Le Source/Destination Check doit également être désactivé sur les ENI de la firewall qui transfèrent du trafic tiers. Laisser CloudFormation régler ces détails, puis les vérifier sans les modifier à l’aveugle.

Déployer standalone avec CloudFormation

1. Ouvrir l’offre Sophos Firewall BYOL ou PAYG dans AWS Marketplace, cliquer sur View purchase options et accepter les conditions.
2. Sous Continue to Configuration, choisir l’option de fulfillment, la version logicielle SFOS actuelle et la région.
3. Sous Continue to Launch, choisir Launch CloudFormation et ouvrir le template dans la console AWS CloudFormation.
4. Saisir un Stack name unique. Pour une nouvelle VPC, vérifier que les plages ne chevauchent aucune VPC, aucun VPN ni réseau local existant.
5. Pour une VPC existante, associer VPC ID, un Public Subnet, un Private Subnet et une Elastic IP nouvelle ou inutilisée. Laisser Network Address Prefix for new VPC inchangé.
6. Utiliser uniquement une taille EC2 proposée par le template ouvert pour la région et l’AMI et, avec BYOL, la comparer à nouveau à la limite de licence consignée. Ne pas stocker les secrets dans des tickets, captures ou fichiers de paramètres lisibles publiquement.
7. Examiner les ressources IAM demandées. Ensuite seulement, confirmer I acknowledge that AWS CloudFormation might create IAM resources et cliquer sur Submit.
8. Attendre CREATE_COMPLETE. Lire l’Elastic IP sous Outputs, puis contrôler les deux status checks et les ENI attendues dans la console EC2.
9. Ouvrir WebAdmin depuis la source autorisée sur https://<EIP>:4444. Ne contourner l’avertissement du certificat local initial qu’après contrôle de l’IP cible, puis accepter les conditions et terminer l’enregistrement et le basic setup. Ouvrir ensuite Administration > Licensing et vérifier que la licence attendue est active ; en cas d’écart, corriger la taille d’instance ou l’affectation de licence avant d’autoriser le trafic de production.

Les paramètres Marketplace peuvent évoluer ; avant chaque déploiement en production, comparez les noms de champs visibles avec le template effectivement ouvert.

Ouvrir conjointement les règles AWS et SFOS

Le template Sophos standalone active par défaut uniquement l’accès d’administration pour WebAdmin et SSH. Cette affirmation ne s’applique pas systématiquement à Auto Scaling : Public Network CIDR y contrôle le trafic hors administration. IPsec, SSL VPN, RED, WAF, User Portal ou les applications publiées nécessitent en plus des règles AWS Security Group adaptées. Pour les SD-RED 20/60, prévoyez vers le pare-feu TCP 3400 pour le canal de contrôle et UDP 3410 pour le tunnel de données ; vérifiez séparément les autres prérequis de provisioning, de DNS et de NTP, ainsi que les autres variantes RED.

Pour chaque ouverture, documenter une fois protocole, port destination et source, mais les mettre en œuvre séparément :

1. La Security Group n’autorise que la source requise vers le port requis de la bonne ENI.
2. Une NACL personnalisée autorise la requête et le retour. AWS explique la différence dans Security Groups et Network ACLs.
3. La Route Table fait passer le trafic par la firewall et fournit un retour valide.
4. La règle firewall SFOS et, si nécessaire, la règle NAT utilisent des zones, hôtes et services précis, journalisent le trafic et appliquent les Security Profiles adaptés.

Ne jamais ouvrir SSH ou WebAdmin à 0.0.0.0/0 par précaution. Un accès AWS étroit ne remplace pas une règle SFOS précise et explicite.

Construire Auto Scaling pour le trafic entrant

Auto Scaling nécessite un compte AWS, l’offre Marketplace Sophos Cloud Firewall (PAYG) et un compte Sophos Fusion disposant des droits de gestion firewall requis. Dans Sophos Fusion (anciennement Sophos Central), sous My products > General settings > API credentials management, examiner les conditions et créer une credential avec un nom, une description et le rôle Service principal firewall. Conserver Client ID et Client secret dans un coffre de secrets à accès restreint, et non dans un fichier texte non protégé. Le mot de passe du compte Sophos ID est un secret distinct du secret client API.

1. Dans la région AWS souhaitée, sous EC2 > Network & security > Key pairs, créer une paire de clés adaptée ou réutiliser une paire existante. Conserver la clé privée en lieu sûr et noter le nom pour SSH KeyPair Name.
2. Dans Marketplace, ouvrir View purchase options et Continue to configuration. Choisir Sophos Auto Scaling Firewall for AWS comme Fulfillment option, puis la Software version approuvée et la Region. Sous Continue to launch, choisir l’action Launch CloudFormation, cliquer sur Launch, puis sur Next dans CloudFormation.
3. Attribuer un Stack name unique. Vérifier que AMI ID correspond à l’offre et à la version choisies, puis sélectionner sous Instance size une taille proposée suffisamment performante. Sélectionner deux AZ différentes sous AvailabilityZone 1 for deployment et AvailabilityZone 2 for deployment.
4. Nouvelle VPC : sous Network Address Prefix for new VPC, saisir les deux premiers octets d’une plage planifiée sans conflit ; laisser vides les champs destinés à une VPC existante. VPC existante : laisser le paramètre de préfixe inchangé et renseigner Deploy to an existing VPC, Existing public subnet ID 1, Existing public subnet ID 2 et Existing private subnet ID à partir du plan de déploiement. Les Public Subnets doivent appartenir aux AZ choisies et avoir Auto-assign public IPv4 address activé. Vérifier également les routes et les NACL.
5. Définir le nom du firewall, Admin Password pour WebAdmin/CLI, Secure Storage Master Key Password et SSH KeyPair Name. Protéger les deux mots de passe firewall séparément du secret API.
6. Saisir Sophos ID email address et Sophos ID password du compte prévu, Sophos Central client ID, Sophos Central client secret et Sophos Central AS Group name. Les noms de champs Central peuvent subsister dans le template malgré la marque Fusion ; le groupe est créé automatiquement dans le compte associé. Ne pas inclure de secrets dans des tickets, captures d’écran ou fichiers de paramètres publics.
7. Définir les paramètres réseau, de capacité et de journalisation suivants. Sous I accept the Sophos End User License Agreement and acknowledge the Sophos Privacy Policy, saisir exactement yes après examen ; respecter la casse. Choisir délibérément une option pour Opt in to the customer experience improvement program.
8. Ouvrir les options de stack avec Next, définir les tags de responsabilité et de coûts, puis examiner les droits IAM demandés. Ensuite seulement, confirmer I acknowledge that AWS CloudFormation might create IAM resources, vérifier le récapitulatif complet et lancer avec Submit.

Après CREATE_COMPLETE, vérifier les instances EC2 et, sous My products > Firewall management > Firewalls, le groupe créé automatiquement avec tous les workers PAYG approuvés attendus. Confirmer la synchronisation des policies avant d’exposer un service. Si un worker manque ou si l’enregistrement échoue, ne pas ouvrir d’autres ports ; vérifier les événements du stack, l’accès réseau et l’association compte/API, sans journaliser de secrets. Modifier ensuite la capacité sous EC2 > Auto scaling > Auto scaling groups > Capacity overview > Edit et confirmer avec Update. Documenter sans ambiguïté l’ID d’instance, l’AZ et le nom du firewall ; après chaque changement de capacité, vérifier à nouveau l’appartenance au groupe et Target Health.

DNAT derrière le Network Load Balancer

Un déploiement Auto Scaling opérationnel et vérifié est requis. Pour un service TCP approuvé, le listener NLB transmet à une Target Group de workers firewall, et non directement au backend. Le schéma original suivant illustre un exemple de chemin HTTPS, et non une connexion mesurée :

Client autorisé : port source éphémère
                 | TCP port destination 443
          Listener TCP NLB :443
                 |
       Target Group de workers firewall
         /                       \
 AZ 1 : Worker PortB      AZ 2 : Worker PortB
         \                       /
          DNAT vers le backend :443
          SNAT = MASQ du worker
                 |
          Serveur applicatif interne :443
                 | Réponse
          Même worker -> NLB -> Client

Schéma : deux AZ, un PortB actif par worker et un chemin retour MASQ. Les flèches décrivent le chemin logique des données ; la répartition de charge ne garantit pas une utilisation équilibrée. Adapter toutes les valeurs d’exemple au service approuvé.

1. Dans Fusion, sous My products > Firewall management > Firewalls, ouvrir Manage policy pour le bon groupe de firewalls Auto Scaling. Sous Hosts and services > IP host, créer deux plages d’adresses IPv4 pour les subnets WAN réels des deux AZ et un hôte IPv4 pour le serveur interne. Ne pas inclure la première adresse de chaque subnet ; inclure uniquement les adresses de workers réellement utilisables, sans les adresses réservées par AWS.
2. Sous Hosts and services > Services, créer un service TCP/UDP avec Protocol TCP. Pour cet établissement de connexion entrante, le port client éphémère est la source et le port du service publié est la destination. Le sens suivant s’applique à la requête, et non à la réponse ; 3389 ou 8080 ne sont pas ouverts en plus.

3. Enregistrer la règle firewall sous Rules and policies > Firewall rules et la règle NAT sous Rules and policies > NAT rules dans la policy de groupe. Vérifier la synchronisation sur chaque worker en cours d’exécution.
4. Sous EC2 > Load balancing > Target groups > Create target group, choisir Instances, un nom unique, Protocol TCP, Port 443 et la VPC du déploiement. Adapter délibérément le protocole, le port et, le cas échéant, le chemin du health check au service vérifié. Lors de la création, ne sélectionner manuellement aucune instance sous Available instances, en particulier pas le serveur backend.
5. Sous EC2 > Auto scaling > Auto scaling groups, choisir l’ASG firewall et lui associer la Target Group sous Integrations > Load balancing > Edit ; confirmer avec Update. L’ASG enregistre ainsi automatiquement ses workers, y compris ceux démarrés ultérieurement.
6. Avant de démarrer le listener, vérifier sous Load balancers l’association des Security Groups du NLB effectivement créé par le template. Si le NLB a été créé sans Security Group, il n’est pas possible d’en ajouter une ultérieurement. Dans ce cas, ne pas ouvrir de listener public tant qu’un chemin pris en charge et restreint par source n’a pas été approuvé ; utiliser sinon VPN/ZTNA. Ne pas modifier à l’aveugle le template géré ni promettre l’ajout ultérieur d’une SG.
7. Si le chemin restrictif est en place, configurer dans le NLB, sous Listeners > Add listener, TCP et le port 443, avec la Target Group de workers comme Default action. Limiter la SG du NLB aux CIDR clients autorisés et au port du listener ; sur le worker, autoriser séparément les ports cibles et de health check requis par le NLB. Le trafic sortant du NLB doit pouvoir atteindre les health checks. L’accès pour un health check ne constitue pas une ouverture publique de l’application. Restreindre également l’accès direct aux workers et au backend.
8. Avant la mise en production, vérifier que les workers attendus des deux AZ ainsi qu’un worker nouvellement démarré dans la fenêtre de changement approuvée apparaissent automatiquement dans la Target Group et réussissent les health checks prévus. Via le nom DNS du NLB, vérifier le flux applicatif positif et une tentative négative depuis une source non autorisée ; Log Viewer doit afficher la règle attendue et DNAT/MASQ. Ne pas se fier uniquement à healthy.

L’accès RDP public direct reste déconseillé ; privilégier VPN ou ZTNA. Si une cible reste unhealthy, vérifier d’abord l’association ASG, la policy synchronisée, le port/le chemin du health check, le trafic sortant du NLB, la SG du worker et les NACL. Si le backend ou le chemin retour est incorrect, laisser le listener fermé et corriger NAT/service/route. Interpréter les ports selon le sens de la requête sur le chemin client-listener-backend.

Valider un flux couche par couche

Noter un flux initial, par exemple 198.51.100.27:55000 -> NLB-DNS:443 -> App-Server:443. Le port source est seulement un exemple de port client éphémère. Contrôler dans cet ordre :

1. DNS et listener NLB pointent vers la cible attendue et la Target Group indique les workers attendus healthy.
2. Security Groups et NACL autorisent exactement l’aller et le retour.
3. Route Tables et ENI font passer le trafic par l’appliance ; Source/Destination Check est désactivé sur les interfaces de transit.
4. SFOS Log Viewer affiche la Rule ID attendue. Pour DNAT, destinations originale et traduite ainsi que le retour sont corrects.
5. Le test autorisé atteint l’application et un test depuis une source interdite reste bloqué.

Sans log SFOS, examiner ce qui précède la firewall : DNS, listener, Target Health, Security Group, NACL et route. Pour un drop avec une Rule ID inattendue, corriger zones, objets réseau, service et ordre. Si l’aller fonctionne sans réponse, contrôler Route Table, NACL, default gateway du serveur et, avec Auto Scaling, MASQ.

Exploiter et restaurer

Standalone et Auto Scaling nécessitent des runbooks différents. Pour standalone, documenter un backup SFOS et une restauration testée, le processus firmware, les paramètres CloudFormation et un exercice de reconstruction. Un snapshot EC2 ne remplace pas un backup SFOS exporté.

Les workers Auto Scaling sont éphémères. Avec CloudWatch, leurs logs apparaissent sous /sophos/xg/ ; configurer explicitement rétention, chiffrement, accès et coûts. Les instances EC2 terminées restent dans le groupe Fusion 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.

Le dossier d’exploitation couvre tags de responsabilité et de coûts, alarmes budgétaires, licence, rotation des secrets, rétention CloudWatch, nettoyage Fusion, approbation firmware, tests de changement et reprise. Répéter le test positif et négatif après toute modification de template, routage ou policy.

Arrêter le changement et revenir en arrière de manière ciblée

Avant le changement, sauvegarder les paramètres du stack et les ID de ressources, l’association listener/Target Group, les SG/NACL/Route Tables ainsi que la policy de groupe SFOS et le backup. En cas de mauvaise cible, de source inattendue, de synchronisation des policies manquante ou de perturbation d’une connexion existante, fermer d’abord le listener nouvellement ajouté ou la nouvelle exposition ; ensuite, rétablir uniquement les règles et routes nouvellement introduites à l’état sûr documenté. Vérifier à nouveau le trafic existant et le blocage des sources non autorisées. Ne pas supprimer une VPC partagée, des subnets, une passerelle ou des listeners existants pour résoudre un problème.

Pour un démantèlement PAYG planifié, il ne suffit pas de terminer certains workers : l’ASG peut les recréer. Supprimer d’abord la nouvelle exposition, effectuer la mise hors service approuvée via le cycle de vie du stack/de l’ASG et vérifier que ni les actions de scaling ni les instances du Warm Pool ne redémarrent des workers. Supprimer toutes les instances firewall PAYG associées et contrôler l’inventaire réel des ressources. Évaluer individuellement les volumes conservés, EIP, NLB, Log Groups et autres ressources payantes à partir de la liste des ressources, sans les supprimer systématiquement ; retirer les workers terminés du groupe Fusion. Vérifier ensuite la facturation et les coûts.