Sophos Firewall : Matériel, virtuel ou cloud ?

Sophos Firewall peut être utilisé comme XGS Hardware Appliance, appareil virtuel, Software Appliance ou Cloud Deployment. Techniquement, le système d’exploitation Sophos Firewall fonctionne partout, mais le modèle de fonctionnement n’est pas le même. La décision affecte les performances, le support, la conception du port, HA, la récupération, les licences, la surveillance et la question de savoir qui est responsable de quelle plate-forme en cas de perturbation.

Pour les nouveaux projets, il ne faut pas simplement demander quelle variante est la moins chère. Ce qui compte, c’est quelle variante convient au site, à la plate-forme de virtualisation, à l’architecture cloud et à l’équipe d’exploitation. Le Sophos Firewall Guide des tailles est également important pour le dimensionnement performant.

Décision rapide

• XGS Hardware Appliance : Convient principalement lorsqu’un emplacement nécessite un pare-feu dédié et clairement pris en charge avec des ports physiques.
• Appliance virtuelle : Convient principalement si une plate-forme de virtualisation stable est disponible et si les zones du réseau peuvent être proprement séparées virtuellement.
• Software Appliance : Convient généralement si votre propre matériel doit être délibérément exploité et pris en charge en tant que plate-forme de pare-feu.
• Cloud Deployment : Convient le plus souvent pour protéger les charges de travail dans AWS ou Azure ou pour les connecter aux réseaux locaux.

La règle la plus importante : un pare-feu virtuel ou cloud n’est pas un laissez-passer gratuit pour moins de planification. CPU, la RAM, le stockage, les commutateurs virtuels, le routage, HA, la sauvegarde et la surveillance doivent être planifiés avec autant de soin que le matériel.

Quand faire attention

La décision ne doit pas se baser uniquement sur ce qui est techniquement possible. Certains environnements semblent flexibles sur le papier, mais créent des risques inutiles en fonctionnement.

• L’hyperviseur est déjà largement utilisé : IPS, TLS Inspection, VPN et la journalisation nécessitent une CPU et une réserve d’E/S prévisibles.
• WAN, LAN, DMZ et la gestion passent par le même goulot d’étranglement physique : Une séparation logiquement propre n’est d’aucune utilité si le chemin réel des données est surchargé ou mal segmenté.
• Aucune équipe ne se sent coresponsable de l’hyperviseur et du pare-feu : Les incidents subsistent entre les équipes plateforme, réseau et pare-feu.
• HA n’était prévu que comme une case à cocher : Sans tests d’hôte, de stockage, de réseau et de restauration, la haute disponibilité n’est pas prouvée.
• Le routage cloud n’est pas entièrement documenté : Le pare-feu protège uniquement le trafic qui y est réellement acheminé.
• La restauration n’a jamais été pratiquée : Une sauvegarde n’est fiable que si une restauration a été testée de manière réaliste ou au moins correctement planifiée.

Dans de tels cas, un XGS Hardware Appliance n’est souvent pas moins moderne, mais simplement la décision opérationnelle la plus robuste. A l’inverse, un pare-feu virtuel ou cloud peut s’avérer très utile si la plateforme, la conception du réseau, la surveillance et les responsabilités sont clairement clarifiées.

XGS Hardware Appliance

Un XGS Hardware Appliance est généralement la variante la plus planifiable pour les emplacements classiques. Le matériel, les ports, le support, la RMA, le cycle de vie et le système d’exploitation du pare-feu forment un système coordonné.

Avantages :

• un matériel pare-feu dédié,
• des équipements portuaires fixes et des options d’extension,
• affectation claire des liens WAN, LAN, DMZ, HA et gestion,
• processus de support et de remplacement matériel facile,
• aucune dépendance aux ressources de l’hyperviseur,
• Bien adapté aux succursales, aux sièges sociaux et aux pare-feu de périphérie. Le plus grand avantage réside dans le fonctionnement : en cas de problème, vous n’avez pas besoin de clarifier au préalable si l’hyperviseur, le vSwitch, le stockage, le routage cloud ou le pare-feu lui-même en sont la cause. Pour de nombreux sites de PME, cela est plus important qu’une flexibilité maximale.

Appareil virtuel

Un Sophos Firewall virtuel a du sens s’il existe déjà une plate-forme de virtualisation propre et que le pare-feu doit être intégré dans un centre de données, un environnement multi-tenant ou une conception de segmentation interne.

Les plates-formes virtuelles pertinentes incluent VMware, Microsoft Hyper-V, KVM, Nutanix Prism et Citrix Hypervisor. Il est important que la plateforme, les outils de gestion et la configuration du réseau soient à jour et pris en charge.

Questions opérationnelles importantes :

• Les ressources CPU sont-elles garanties ou fortement sursouscrites ?
• La RAM et le stockage sont-ils suffisamment dimensionnés ?
• Les cartes réseau virtuelles et les groupes de ports sont-ils clairement séparés ?
• Existe-t-il des chemins réseau dédiés pour WAN, LAN, DMZ, HA et la gestion ?
• Le mode promiscuous, le trunking VLAN ou SR-IOV sont-ils requis ?
• Existe-t-il un concept de sauvegarde et de restauration propre ?
• Est-il clair qui dépanne ensemble l’hyperviseur, le stockage et le pare-feu ?

Un pare-feu virtuel peut très bien fonctionner. Cependant, les choses deviennent rapidement problématiques lorsqu’il s’exécute sur un hôte surchargé ou lorsque WAN, LAN et la gestion semblent logiquement propres, mais fonctionnent physiquement à travers les mêmes goulots d’étranglement.

Software Appliance

Un Software Appliance est installé sur son propre matériel. Cela peut être utile pour les laboratoires, les environnements spéciaux ou les conceptions très ciblées. Dans le cadre d’opérations client normales, vous devez choisir consciemment cette variante, car la sélection du matériel, les pilotes, les pièces de rechange, la surveillance et l’assistance relèvent davantage de la responsabilité de l’opérateur.

Vérifier:

• Le matériel est-il adapté à un fonctionnement continu ?
• Les cartes réseau, le stockage et la configuration BIOS/UEFI sont-ils adaptés ?
• Existe-t-il du matériel de remplacement ?
• Le processus d’installation et de récupération est-il documenté ?
• Qui est responsable des erreurs matérielles ?

Pour les emplacements standards, un XGS Hardware Appliance est souvent plus simple. Pour des cas particuliers techniques, un Software Appliance peut quand même convenir si l’équipe opérationnelle maîtrise bien la plateforme.

Cloud Deployment

Les déploiements cloud sont particulièrement utiles lorsque les charges de travail dans AWS ou Azure doivent être protégées ou lorsque les réseaux cloud sont connectés à des emplacements locaux. Différentes questions sont importantes dans le cloud par rapport à l’emplacement traditionnel.

Planifier :

• Conception VPC/VNet,
• les tables de routage,
• Zones de disponibilité,
• des IP élastiques ou IP publiques,
• Site à Site VPN ou SD-WAN,
• Journalisation et évaluation centrale,
• Coûts du cloud par exemple, stockage, trafic et conception HA,
• Responsabilité opérationnelle entre l’équipe cloud et l’équipe pare-feu.

Un pare-feu cloud ne remplace pas une conception de réseau cloud propre. Seuls les chemins réellement acheminés via le pare-feu sont protégés.

Performances et dimensionnement

En ce qui concerne le matériel, les performances dépendent du modèle que vous choisissez. Pour les déploiements virtuels, logiciels et cloud, les performances dépendent davantage de la plate-forme.

Particulièrement pertinent :

• CPU performances et CPU réservation,
• RAM,
• latence de stockage,
• des cartes réseau virtuelles,
• chemin réseau hyperviseur ou cloud,
• nombre de séances,
• TLS Inspection,
• IPS,
• VPN débit,
• Journalisation et reporting. Les valeurs des fiches techniques doivent donc toujours être lues dans leur contexte. Le débit du pare-feu sans inspection de sécurité n’est pas le même que la protection contre les menaces, TLS Inspection ou IPsec VPN sous charge réelle. Les différences expliquées Sophos Firewall Interpréter correctement les données de performances.

HA et récupération

La haute disponibilité diffère considérablement selon la plateforme.

Lorsqu’il s’agit de matériel, HA est généralement plus facile à comprendre : deux appareils, un lien HA, des interfaces définies, un périphérique de remplacement clair. Des questions supplémentaires se posent pour les déploiements virtuels et cloud :

• Les nœuds HA s’exécutent-ils sur différents hôtes ?
• Le stockage, le réseau et l’hyperviseur sont-ils vraiment redondants ?
• Les adresses MAC virtuelles et les règles vSwitch sont-elles compatibles ?
• Existe-t-il des dépendances au routage cloud ou à l’équilibrage de charge ?
• Les sauvegardes et restaurations fonctionnent-elles sur une nouvelle instance ?
• La panne d’un hôte ou d’une zone de disponibilité a-t-elle été testée ?

Les bases des variantes HA sont disponibles dans Sophos Firewall Configuration de la haute disponibilité (HA). Pour la récupération, la lecture de Sophos Firewall Créer ou restaurer une sauvegarde est obligatoire.

Licences et assistance

L’attribution de licences doit être envisagée dès le début, car les pare-feu matériels, virtuels et logiciels peuvent être traités différemment. Pour les instances de pare-feu Sophos virtuelles et logicielles, la façon dont les cœurs CPU, le numéro de série, le support et l’abonnement sont planifiés est particulièrement pertinent. Pour les bases de la licence de base, Sophos Firewall - Licence de base convient. Le changement dans les licences virtuelles et logicielles, dans lesquelles la RAM n’est plus au centre de la limite de licence, est répertorié dans l’article de blog Sophos Firewall VM & SW - Only CPU counts - No more RAM limit.

Ce qui est important en fonctionnement :

• Documenter la licence et l’état du support.
• Enregistrez proprement le numéro de série et le statut d’enregistrement.
• Vérifiez les licences HA avant de construire.
• Vérifiez l’éligibilité du micrologiciel et du support avant les mises à niveau.
• Connaître le processus RMA ou de récupération pour la plateforme choisie.

Avant les mises à niveau majeures, Sophos Firewall avant SFOS 22 Vérifier la mise à niveau doit également être utilisé car la prise en charge de la plate-forme, l’espace de stockage, la sauvegarde, HA et les anciennes configurations VPN peuvent être pertinentes pour la mise à niveau.

Matrice de décision

• Emplacement classique avec WAN, LAN et DMZ : Principalement du matériel. Virtuel uniquement avec une bonne stratégie de virtualisation.
• Centre de données avec équipe d’hyperviseurs existante : Le matériel est possible, le virtuel a souvent du sens.
• Charges de travail cloud dans AWS ou Azure : Plus de matériel virtuel ou cloud, pas classique.
• Support facile et RMA importants : Plus de matériel. Qu’il s’agisse du virtuel ou du cloud, tout dépend de l’équipe de la plateforme.
• De nombreux ports physiques requis : Plus de matériel. Virtuel uniquement avec une conception épurée de la carte réseau et du vSwitch.
• Mise à l’échelle dynamique et Infrastructure as Code : Plus de virtuel ou de cloud.
• Petite équipe informatique sans connaissances spécialisées en hyperviseur : Principalement du matériel ; Planifiez soigneusement les pare-feu virtuels.
• Conception de locataires ou de segmentation dans le centre de données : Le matériel est possible, le virtuel a souvent du sens.

Erreurs courantes

• Exécutez un pare-feu virtuel sur un hôte surréservé.
• Ne pas séparer proprement WAN, LAN et la gestion sur l’hyperviseur.
• Sélectionnez le matériel uniquement en fonction du prix plutôt que de la taille.
• Déployer un pare-feu cloud, mais ne pas entièrement réfléchir aux tables de routage.
• Planifiez HA mais ne testez pas les pannes d’hôte, de stockage ou de cloud.
• Créez une sauvegarde, mais ne pratiquez jamais la restauration.
• Vérifiez l’état de la licence et du support uniquement lors de la mise à niveau du micrologiciel.
• Activez les fonctionnalités de sécurité telles que TLS Inspection ou IPS ultérieurement, sans réserve de performances.
• Réunissez l’équipe plateforme, l’équipe réseau et les gestionnaires de pare-feu uniquement en cas de perturbation.

Liste de contrôle

• Localisation clairement définie : localisation, data center ou cloud.
• Fonctionnalités de trafic, de bande passante et de sécurité enregistrées pour le dimensionnement.
• Variantes matérielles, virtuelles, logicielles ou cloud délibérément choisies.
• Responsabilité du pare-feu, de l’hyperviseur, du cloud et du réseau documentée.
• HA et conception de récupération vérifiées.
• Processus de sauvegarde et de restauration testé ou planifié.
• Licence, support et enregistrement clarifiés.
• Surveillance du pare-feu et de la plate-forme sous-jacente disponible.
• Mise à niveau et prise en charge de la plateforme vérifiées.
• Personne responsable de la plateforme, du réseau, du pare-feu, de la sauvegarde et de la restauration nommée.

FAQ