Qu’est-ce que le Firewall as a Service (FWaaS) ?

Qu’est-ce que le Firewall as a Service (FWaaS) ?

Le firewall as a service (FWaaS) est un modèle de sécurité réseau fourni depuis le cloud qui inspecte le trafic, applique les politiques et bloque les attaques depuis une infrastructure exploitée par le fournisseur, sans appliance sur site dans le chemin. Vos politiques résident dans un plan de contrôle unique, et des points d’application distribués les appliquent partout où les utilisateurs et les charges de travail se connectent.

Les attaquants n’ont pas besoin de franchir un périmètre s’ils peuvent s’y connecter. La CISA et le FBI citent des intrusions telles que Volt Typhoon, où les acteurs ont utilisé des identifiants valides pour se fondre dans le trafic normal, dans des directives conjointes sur l’accès réseau exhortant à abandonner l’accès distant étendu.

Si vos utilisateurs accèdent à des applications SaaS sans passer par le réseau d’entreprise, vos appliances ne se trouvent plus sur le chemin du trafic dont vous êtes responsable.

Comment le Firewall as a Service s’inscrit dans la cybersécurité

Le FWaaS modifie l’endroit où l’application des règles a lieu et qui en assure la maintenance. L’inspection passe du périmètre réseau à la périphérie du cloud, de sorte qu’un télétravailleur ouvrant une application SaaS se voit appliquer la même politique même si cette session ne traverse jamais le réseau d’entreprise. La rédaction des politiques se sépare également de leur application : vous rédigez les règles une seule fois dans une console centrale et le fournisseur les distribue, ce qui met fin à la dérive de configuration qui éloigne les firewalls des agences de ceux du siège.

Le renseignement sur les menaces suit le même chemin. Une signature ou un indicateur diffusé par le fournisseur atteint tous les points d’application en même temps, sans fenêtre de mise à jour par site à planifier et sans laisser de site de côté. Les déploiements de firewalls matériels laissent une faille dans ces trois endroits. Plus une grande partie de votre trafic contourne déjà le réseau d’entreprise, plus cette faille est importante.

Composants principaux du Firewall as a Service

Un service de firewall repose sur un moteur d’inspection, des points d’application distribués, un plan de politique central, un flux de renseignement sur les menaces et une couche de journalisation. Le dépannage comme la comparaison des fournisseurs deviennent plus rapides une fois que vous savez auquel de ces éléments appartient un problème donné.

1. Moteur d’inspection cloud-native

Le moteur d’inspection lit le trafic au niveau de la couche applicative et applique l’inspection approfondie des paquets, le déchiffrement TLS des charges utiles des paquets et la prévention des intrusions. NIST SP 800-215 répertorie ces trois capacités pour un firewall nouvelle génération et cite la fourniture en tant que service cloud, FWaaS, comme l’une de ses options de déploiement. Comme un moteur de firewall-as-a-service s’exécute sur une capacité de calcul cloud élastique, la profondeur d’inspection n’est pas limitée par le silicium d’une appliance que vous avez achetée il y a trois ans.

2. Points d’application distribués

Les fournisseurs exploitent des points d’application dans différentes régions géographiques, et chaque session est acheminée vers le plus proche pour inspection avant d’atteindre sa destination. Cette répartition géographique supprime le détour où un utilisateur à Singapour dépend d’une appliance dans l’Ohio pour atteindre une application hébergée à quelques kilomètres de son bureau.

3. Gestion centralisée des politiques

La politique réside dans un plan de contrôle unique qui diffuse les règles vers chaque point d’application. La rédaction de la politique et son application cessent d’être la même tâche. Une seule mise à jour se propage en quelques minutes, et aucun ingénieur n’a à intervenir sur des dizaines d’appliances pour maintenir les configurations des agences alignées sur la norme.

4. Intégration du renseignement sur les menaces

Les plateformes de firewall as a service ingèrent des flux provenant d’agences gouvernementales, de groupes de partage sectoriels et d’équipes de recherche des fournisseurs, puis mettent automatiquement à jour chaque point d’application. Votre équipe cesse de maintenir des abonnements aux flux et de planifier les diffusions de signatures. Un nouvel indicateur s’applique partout dès le premier passage.

5. Infrastructure de journalisation et d’analyse

Les journaux de chaque point d’application sont agrégés dans un stockage central pour l’investigation, les rapports de conformité et la corrélation avec le reste de votre télémétrie. Traitez la durée de conservation des journaux, le format d’exportation et les performances des requêtes comme des exigences d’approvisionnement : ils déterminent si les enregistrements FWaaS deviennent des sécurité réseau preuves exploitables ou une facture de stockage.

Une plateforme construite sur un schéma ouvert, comme le Singularity Data Lake de SentinelOne, conserve ces enregistrements aux côtés de la télémétrie des terminaux et des identités. Une seule requête couvre alors l’événement réseau et l’activité du terminal qui l’entoure.

Fonctionnement du Firewall as a Service

Le FWaaS intercepte le trafic au niveau de la couche réseau, l’inspecte à la périphérie du cloud et applique votre politique avant que la session n’atteigne sa destination. Chaque connexion passe par l’interception, l’évaluation de l’identité, la correspondance avec la politique, l’inspection et l’action, dans cet ordre :

1. Interception du trafic. L’appareil de l’utilisateur atteint l’infrastructure d’application via un routage basé sur un agent, une redirection basée sur le DNS ou un tunnel IPsec depuis un site. Aucun trafic ne contourne l’inspection.
2. Évaluation de l’identité. Le point d’application résout l’utilisateur, la posture de l’appareil, l’emplacement et l’application demandée avant qu’une politique ne soit appliquée.
3. Correspondance avec la politique. Le système vérifie la session par rapport à votre ensemble central de politiques : contrôles applicatifs, catégories d’URL, exigences de conformité et règles de prévention des menaces, de la correspondance la plus spécifique à la plus générale.
4. Inspection approfondie des paquets. Le FWaaS déchiffre la session TLS, analyse le contenu de la couche applicative et applique des signatures de prévention des intrusions pour une visibilité de couche 7.
5. Action et journalisation. Le FWaaS autorise, bloque, redirige ou isole la session selon le résultat de l’inspection, et écrit une entrée de journal avec l’identité, l’application, l’action et la règle correspondante.

L’évaluation de l’identité, la correspondance avec la politique et l’inspection se répètent à chaque session. La capacité des points d’application et l’hygiène des politiques déterminent si cette répétition protège réellement quelque chose ou ajoute seulement des sauts.

Capacités principales du FWaaS et méthodes d’inspection

Les capacités ci-dessous se chevauchent à peine. Cela compte au moment de l’approvisionnement : une capacité omise par le fournisseur devient une faille dans votre couverture, et non une version plus légère de la même protection.

• Contrôle des applications et filtrage d’URL : L’inspection de couche 7 identifie les applications par leurs modèles de comportement, et non par les numéros de port. Vous pouvez autoriser Salesforce tout en bloquant les comptes Dropbox personnels, même si les deux utilisent HTTPS sur le port 443.
• Prévention et détection des intrusions : La détection basée sur les signatures correspond à des modèles d’attaque connus. L’analyse comportementale identifie des anomalies suggérant des exploits zero-day ou des menaces persistantes avancées.
• Déchiffrement TLS/SSL: FWaaS termine les connexions TLS, inspecte le contenu déchiffré, puis le rechiffre pour la transmission. Cela permet de détecter les menaces dissimulées dans le chiffrement, désormais majoritaires dans le trafic web.
• Sécurité DNS: Le filtrage DNS bloque les domaines malveillants avant l’établissement des connexions, empêchant les communications de commande et contrôle des malwares ainsi que les tentatives de phishing.
• Anti-malware et sandboxing: L’inspection des fichiers analyse les téléchargements à la recherche de signatures de malware. Les fichiers suspects sont exécutés dans des environnements de sandboxing isolés pour une analyse comportementale.

FWaaS dans les déploiements hybrides et multi-cloud

La plupart des organisations exploitent une infrastructure sur site, plus d’un fournisseur cloud et une longue liste d’applications SaaS, et un service de pare-feu maintient un ensemble unique de politiques sur les trois. Les fournisseurs placent des points d’application dans les principales régions cloud, de sorte que le trafic entre environnements multi-cloud est inspecté sans revenir en hairpinning vers votre centre de données. L’intégration sur site passe généralement par un tunnel IPsec ou un circuit dédié reliant le site au point d’application le plus proche.

La difficulté consiste à vérifier que la politique que vous avez écrite est bien celle qui est appliquée. La gestion distribuée entre les régions réduit la visibilité sur l’ensemble de règles effectif à un point d’application donné, et une mauvaise configuration reste la cause la plus fréquente des défaillances de pare-feu.

Comment Firewall as a Service transforme l’application des règles réseau

Les règles que vous écrivez se ressemblent beaucoup, qu’elles soient sur une appliance ou dans un service cloud. Ce qui change, c’est tout ce qui se trouve en aval des règles : où l’application s’exécute, quelle puissance de calcul la prend en charge et qui la corrige.

Déchiffrer, inspecter et rechiffrer chaque session exige beaucoup de puissance de calcul, et les appliances atteignent un plafond qui impose un choix entre couverture d’inspection et débit. Un pare-feu cloud adapte cette puissance de calcul à la demande. Les équipes qui exécutent un déchiffrement complet adoptent généralement d’abord le modèle cloud.

Firewall as a Service et architecture SASE

Firewall as a Service fournit la couche d’application des règles réseau d’une architecture SASE. directives de la CISA et du FBI décrivent SASE comme une architecture cloud qui combine cinq capacités : réseau étendu défini par logiciel, Secure Web Gateway, Cloud Access Security Broker, Zero Trust Network Access et un pare-feu, qui, dans un déploiement SASE, fonctionne comme un service cloud. La moitié sécurité de cette architecture est le security service edge, et les mêmes directives désignent FWaaS comme l’une de ses quatre capacités de sécurité.

Les deux décomptes diffèrent d’un élément, et cet élément est le SD-WAN. Le SD-WAN est une capacité réseau, pas une capacité de sécurité ; le retirer des cinq laisse donc les quatre capacités de sécurité qui composent le security service edge. Les composants avec lesquels FWaaS partage un plan de contrôle sont :

• SD-WAN, pour le routage du trafic et les performances WAN entre les sites.
• Secure Web Gateway, pour le contrôle de l’accès web, la protection contre les menaces et la prévention des pertes de données.
• Cloud Access Security Broker, pour la visibilité et le contrôle de l’utilisation des applications SaaS.
• Zero Trust Network Access, pour les décisions d'accès au niveau des applications basées sur l'identité vérifiée et la posture de l'appareil.

Ce plan de contrôle partagé maintient la cohérence de la politique de sécurité SASE. Une seule console couvre le trafic web, applicatif et réseau, et les règles cessent de diverger comme le font des ensembles de politiques distincts au fil du temps. Une seule console signifie aussi une seule réponse pour un auditeur demandant quel contrôle s'est appliqué à une session donnée. Des cadres de sécurité SASE plus larges étendent la même logique à l'identité et à l'accès aux applications.

Principaux avantages du Firewall as a Service

FWaaS élimine la surcharge de gestion du matériel, s'adapte automatiquement lors des pics de trafic, se déploie en quelques jours au lieu de plusieurs semaines et bénéficie d'une validation des cadres de sécurité fédéraux.

1. Réduction de la complexité opérationnelle : Vous éliminez la gestion appliance par appliance. Au lieu de configurer individuellement 50 pare-feu de succursales, vous définissez les politiques une seule fois. L'infrastructure basée sur le cloud est devenue la structure SOC prédominante, la plupart des organisations intégrant des mécanismes de réponse automatisés.
2. Mise à l'échelle élastique : Les appliances matérielles échouent lors des pics de trafic parce que la capacité de traitement est fixe. FWaaS évolue horizontalement en ajoutant automatiquement des ressources de calcul. L'architecture cloud native gère plus efficacement les opérations gourmandes en calcul comme le déchiffrement TLS/SSL, car les fournisseurs maintiennent une capacité excédentaire entre les régions.
3. Déploiement rapide : L'ouverture d'une nouvelle succursale nécessite traditionnellement l'approvisionnement du matériel, l'expédition, l'installation et la configuration. FWaaS nécessite des identifiants d'authentification utilisateur et l'attribution de politiques. Selon l'analyse Magic Quadrant de Gartner, l'adoption de FWaaS passera de moins de 5 % en 2020 à plus de 30 % des nouveaux déploiements de pare-feu distribués pour succursales d'ici 2026.
4. Reconnaissance par les cadres gouvernementaux : Les directives multi-agences de la CISA, du FBI, du GCSB, de CERT-NZ et du CCCS identifient explicitement FWaaS comme une capacité de sécurité SSE essentielle aux côtés de Zero Trust Network Access, Cloud Secure Web Gateway et Cloud Access Security Broker. NIST SP 800-215 fournit une validation fédérale des cadres SASE avec FWaaS comme composant essentiel.

Ces avantages opérationnels rendent FWaaS convaincant pour les organisations distribuées, mais l'architecture cloud native introduit une nouvelle complexité à laquelle les pare-feu traditionnels ne sont pas confrontés.

Défis et limites du Firewall as a Service

L'application centralisée centralise aussi les défaillances, donc une mauvaise règle atteint désormais tout le monde en même temps. Exécuter l'inspection sur l'infrastructure de quelqu'un d'autre place aussi la latence, la juridiction et la disponibilité hors de votre contrôle.

• Complexité de configuration. La gestion centralisée des politiques est un avantage jusqu'à ce qu'une mauvaise règle se propage mondialement en quelques minutes. L'automatisation pilotée par API élargit le champ des erreurs, et une seule règle défectueuse peut affecter tous les utilisateurs à la fois. Vous avez besoin d'une validation automatisée des politiques et d'un environnement hors production qui reflète la production.
• Latence pour les applications en temps réel. Le routage via des points d'application cloud ajoute des millisecondes à chaque session. La plupart des applications métier ne le remarquent jamais. La voix en temps réel, les plateformes de trading et les environnements de technologie opérationnelle, si, et de petites augmentations à ce niveau provoquent une dégradation fonctionnelle.
• Granularité limitée pour la conformité spécialisée. Les plateformes cloud standardisées échangent la personnalisation contre l'échelle. Les organisations ayant des exigences de segmentation granulaires dans le cadre de PCI DSS, HIPAA ou CMMC constatent souvent qu'un service de pare-feu ne peut pas satisfaire tous les contrôles sans outillage complémentaire.
• Complexité de la résidence des données. L'inspection traite les données à l'emplacement du point d'application. Si le point d'application le plus proche se trouve en dehors d'une limite exigée par le RGPD, le CCPA ou une réglementation sectorielle, vous pouvez traiter des données réglementées dans une juridiction non conforme. Vérifiez la géographie des points d'application avant le déploiement.
• Dépendance à l'infrastructure du fournisseur. La disponibilité de votre application dépend de la disponibilité du fournisseur. Évaluez les SLA, l'architecture de redondance et la disponibilité historique publiée dans le cadre de la sélection du fournisseur, et sachez à quoi ressemble votre posture lors d'une défaillance régionale.
• Angles morts pour les attaques non réseau. FWaaS inspecte le trafic. Il n'empêche pas les malwares de s'exécuter au-delà des contrôles de sécurité des endpoints, un attaquant disposant d'identifiants valides, ou une attaque à l'exécution sur une charge de travail cloud. Dans le compromis SolarWinds de 2020, MITRE ATT&CK a documenté une porte dérobée signée avec les propres certificats de signature de code de SolarWinds, des noms d'hôte de commande et contrôle définis pour correspondre à des noms d'hôte légitimes dans l'environnement de la victime, et une infrastructure VPN provenant du propre pays de la victime. Rien de tout cela ne paraît anormal pour l'inspection réseau. Évaluer un binaire signé valablement sur la base de ce qu'il fait après son exécution relève de la couche d'exécution, où se situe un outil comme Singularity Endpoint.

Le coût de chacun de ces éléments dépend davantage du fournisseur que de l'architecture. Cela place toute la liste à l'ordre du jour de la sélection du fournisseur.

Erreurs courantes liées au Firewall as a Service

Les organisations échouent avec FWaaS en déployant des configurations non testées, en sélectionnant des fournisseurs sur la base d'affirmations marketing, en omettant l'examen juridique, en sous-estimant la complexité de l'intégration et en considérant la sécurité réseau comme une protection complète. Voici cinq erreurs courantes clés :

1. Déploiement sans test de configuration : Les organisations déploient des politiques directement en production sans validation hors production. Des erreurs de configuration uniques se propagent simultanément à tous les points d'application.
2. Sélection sur la base d'affirmations marketing : Les équipes d'approvisionnement présélectionnent les fournisseurs sur la base des spécifications plutôt qu'en exigeant des résultats de tests indépendants actuels utilisant des méthodologies reconnues.
3. Omission de l'examen juridique pendant l'approvisionnement : Les organisations découvrent des violations du RGPD ou du CCPA lors des audits de conformité parce qu'elles n'ont pas vérifié le traitement des données et les emplacements de stockage du fournisseur avant le déploiement.
4. Sous-estimation des exigences d'intégration : Les équipes supposent que les projections du fournisseur concernant la complexité de l'intégration sont exactes, puis découvrent des incompatibilités avec les plateformes SIEM, les fournisseurs d'identité et la protection des endpoints après l'achat.
5. Remplacement de piles de sécurité complètes : Les organisations traitent FWaaS comme une protection complète alors qu'il ne traite que les menaces au niveau réseau, laissant sans défense la compromission des endpoints et les attaques basées sur l'identité.

Éviter ces erreurs nécessite des pratiques d’approvisionnement et de déploiement délibérées qui valident les capacités avant tout engagement.

Bonnes pratiques de Firewall as a Service

La plupart des problèmes opérationnels dans un service de pare-feu commencent par un changement de politique que personne n’a testé ou un journal que personne n’a consulté. Les pratiques ci-dessous répondent à cela :

• Exécutez des workflows automatisés de validation des politiques qui testent chaque modification de règle dans un environnement de préproduction avant qu’elle ne soit propagée aux points d’application en production.
• Auditez l’ensemble de règles selon un calendrier pour détecter les règles inutilisées, masquées et contradictoires. La prolifération des règles transforme discrètement une politique propre en une politique imprévisible.
• Documentez les emplacements des points d’application, la géographie du stockage des journaux et les emplacements de traitement des données, et effectuez l’examen juridique pendant l’évaluation, pas après la signature du contrat.
• Connectez les journaux FWaaS à votre plateforme SIEM afin que les événements réseau soient corrélés avec les signaux des terminaux et des identités.
• Traitez FWaaS comme un contrôle de couche réseau dans une architecture en couches. Associez-le à la sécurité des terminaux, à la gestion des identités et des accès, et à la protection des charges de travail cloud pour couvrir les surfaces d’attaque que l’inspection réseau ne peut pas voir.

Consignez chaque élément dans un runbook avec une équipe responsable désignée, car un workflow de validation non attribué devient obsolète en moins d’un trimestre.

Renforcez la sécurité réseau avec SentinelOne

FWaaS sécurise le chemin réseau. Les attaques les plus dommageables opèrent au-delà, en utilisant des identifiants qui s’authentifient correctement, du code signé avec un certificat valide et des charges de travail jamais acheminées via un point d’application. Pour les couvrir, il faut une protection des terminaux, des identités et du cloud fonctionnant à partir des mêmes données.

La Singularity Platform applique une protection autonome par IA sur les surfaces d’attaque qu’un service de pare-feu ne peut pas atteindre. Singularity Endpoint utilise l’IA comportementale pour arrêter les ransomwares, les attaques sans fichier et les exploits zero-day au niveau de l’exécution, le point où une charge utile ayant passé l’inspection est finalement évaluée selon ce qu’elle fait. Singularity Identity détecte l’utilisation abusive des identifiants, les déplacements impossibles et les mouvements latéraux via Active Directory, une activité qu’un service de pare-feu interprète comme une session authentifiée légitime. Singularity Cloud Security ajoute une protection à l’exécution pour les charges de travail, les conteneurs et les environnements Kubernetes, où un attaquant se déplaçant depuis un terminal compromis ne franchit jamais du tout un point d’application.

La corrélation est ce qui transforme ces signaux en enquête. Singularity AI SIEM ingère les journaux FWaaS aux côtés de la télémétrie des terminaux, des identités et du cloud dans un lac de données unique à l’échelle du pétaoctet, et Purple AI exploite ces données via des requêtes en langage naturel et une investigation autonome, reconstituant une chaîne d’attaque à partir d’un seul événement réseau suspect sans collecte manuelle de données. Selon l’ étude IDC Purple AI, les clients ont identifié les menaces 63 % plus rapidement et réduit le temps de remédiation de 55 %.

SentinelOne a également été nommé leader des plateformes SOC dans l’ évaluation des opérations de sécurité de Latio, la première étude du cabinet sur les plateformes SOC couvrant les capacités EDR, XDR, SIEM, SOAR et MDR. 

Demandez une démo avec SentinelOne pour voir les angles morts qu’un service de pare-feu laisse ouverts.

Plate-forme Singularity™

Améliorez votre posture de sécurité grâce à la détection en temps réel, à une réponse à la vitesse de la machine et à une visibilité totale de l'ensemble de votre environnement numérique.

Obtenir une démonstration