Les pare-feu d’applications web (WAF) basés sur un proxy font partie intégrante de la protection des applications. Outre le fait qu’ils sont indispensables pour assurer la conformité à la norme PCI-DSS, les WAF offrent une excellente protection contre les dix principaux risques de l’OWASP. Ils constituent également une solution privilégiée pour remédier aux vulnérabilités zero-day, soit grâce à la publication rapide de mises à jour de signatures, soit, dans certains cas, grâce à l’utilisation de fonctions programmatiques permettant d’appliquer des correctifs virtuels aux applications pendant le déploiement d’une solution à long terme.
La question est donc de savoir où placer une telle protection.
Il existe bien sûr plusieurs possibilités. Le chemin des données comporte plusieurs points d’insertion où un WAF peut être déployé. Mais cela ne signifie pas que chacun d’eux soit judicieux. Certains sont moins efficaces que d’autres, certains créent des points de défaillance inacceptables, tandis que d’autres génèrent une dette architecturale dont les intérêts deviennent très lourds au fil du temps.
Dans l’idéal, vous déploierez un WAF derrière votre couche d’équilibrage de charge. Cela permet d’optimiser l’utilisation, les performances et la fiabilité, tout en assurant la protection nécessaire à toutes les applications, en particulier celles exposées sur Internet.
Utilisation
Les ressources nécessaires (processeur, entre autres) pour prendre une décision d’équilibrage de charge sont minimes. C’est généralement pour cette raison qu’un équilibreur de charge peut prendre en charge simultanément des millions d’utilisateurs, tandis que les WAF consomment davantage de ressources, car ils inspectent l’intégralité de la charge utile et l’évaluent au regard de signatures et de politiques afin de déterminer si la requête est valide et sûre.
Les modèles modernes de centres de données s’inspirent largement du cloud et de sa structure de coûts basée sur l’utilisation. Le taux d’utilisation devient ainsi un facteur clé des coûts d’exploitation. Un taux d’utilisation plus élevé entraîne des besoins supplémentaires en ressources, ce qui pèse sur les budgets. Optimiser ce taux constitue donc une stratégie judicieuse pour maîtriser les coûts, aussi bien dans les centres de données que dans les environnements de cloud public.
Fiabilité
Il est courant de mettre à l’échelle les WAF horizontalement. Autrement dit, vous utilisez le LB pour mettre à l’échelle les WAF. Cette décision architecturale est directement liée à l’utilisation des ressources. Bien que de nombreux WAF offrent une bonne évolutivité, ils peuvent néanmoins être submergés par des pics soudains de trafic ou des attaques. Si le WAF est placé devant le LB, vous devez soit disposer d’un autre niveau de LB pour le mettre à l’échelle séparément, soit risquer de compromettre les performances et la disponibilité.
Performances
Les performances sont une préoccupation majeure dans une économie fondée sur les applications. Avec autant de variables et de systèmes interagissant avec les données tout au long de leur parcours, il peut être difficile de déterminer précisément où se situent les goulets d’étranglement, et plus encore d’optimiser chaque élément sans nuire aux autres. Comme cela a souvent été souligné, plus la charge d’un système augmente, plus ses performances diminuent. C’est l’une des conséquences imprévues d’une utilisation non optimisée, et l’une des principales raisons pour lesquelles les architectes réseau expérimentés fixent à 60 % le seuil d’utilisation des équipements réseau.
Le déploiement d’un WAF derrière la couche d’équilibrage de charge élimine la nécessité d’une couche dédiée en amont pour l’équilibrage de charge du WAF, supprimant ainsi une couche réseau entière. Même si le gain en temps de traitement peut sembler minime, les précieuses microsecondes consacrées à la gestion des connexions et à la mise à l’échelle des services WAF, puis à nouveau à la sélection d’une instance ou d’un serveur d’application cible, ont leur importance. La suppression de cette couche grâce au déploiement du WAF derrière la couche d’équilibrage de charge permet de récupérer de précieuses microsecondes que les utilisateurs d’aujourd’hui ne manqueront pas de remarquer et d’apprécier.
Visibilité
La visibilité est une exigence essentielle pour les solutions de sécurité placées sur le chemin des données. Sans la possibilité d’inspecter l’intégralité du flux – y compris la charge utile –, une grande partie des fonctions de sécurité d’un WAF perd tout son intérêt. Après tout, la plupart des codes malveillants se trouvent dans la charge utile, et non dans les en-têtes de protocole. Le positionnement d’un WAF derrière la couche d’équilibrage de charge permet de déchiffrer le trafic SSL/TLS avant de le transmettre au WAF pour inspection. Cette architecture est préférable, car l’équilibreur de charge aura probablement besoin, dans tous les cas, d’avoir une visibilité sur le trafic sécurisé afin de déterminer comment acheminer correctement les requêtes.
Cela étant dit, un WAF peut être placé pratiquement n’importe où dans le chemin de données. Il s’agit d’un service de sécurité de couche 7 basé sur un proxy et déployé comme intermédiaire sur le chemin réseau. Il pourrait tout à fait être placé en périphérie du réseau, si vous le souhaitiez. Toutefois, si vous souhaitez optimiser simultanément les performances, la fiabilité et l’utilisation de votre architecture, le mieux est de positionner ce WAF derrière la couche d’équilibrage de charge, au plus près de l’application qu’il protège.
Avec les bons outils, une couverture WAF complète peut réduire considérablement votre exposition aux risques ainsi que vos coûts d’exploitation. Découvrez comment protéger vos applications contre le Top 10 de l’OWASP et d’autres menaces grâce aux webinaires à la demande de F5, et explorez les nombreuses façons de déployer les fonctionnalités WAF de F5, notamment le service managé dans le cloud Silverline WAF.
L’architecte sécurité de F5 Brian McHenry et le principal évangéliste de la recherche sur les menaces David Holmes ont contribué à cet article. Des modifications mineures ont été apportées en août 2019.
À propos de l’auteur
Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.
Autres articles de Lori Mac VittieArticles de blog associés
F5 NGINXaaS pour Google Cloud : des applications résilientes et évolutives
Découvrez comment NGINXaaS s’intègre à Google Cloud pour renforcer les performances et la sécurité, et préparer vos applications critiques à un avenir propulsé par l’IA.
L’intégration de F5 Web Application Firewall (WAF) à AWS est disponible dès aujourd’hui
En faisant appel à un partenaire de déploiement AWS WAF tel que F5, vous pouvez renforcer la sécurité de vos applications web grâce à des règles personnalisées qui bloquent les schémas d’attaque courants, comme les injections SQL ou les attaques par scripts intersites (XSS).
Appliquer le principe de Peter Parker à l’inspection TLS
« Un grand pouvoir implique de grandes responsabilités. » Si l’on en trouve des échos chez Voltaire et Churchill, cette citation est surtout connue grâce aux bandes dessinées Spider-Man, où elle est attribuée à l’oncle Ben. Bien entendu, si cette phrase est si répandue dans la culture populaire, c’est notamment parce qu’elle peut s’appliquer à une multitude de situations et de sujets, y compris à l’inspection TLS.
Le NetOps a besoin de défenseurs, pas d’adversaires
Il est important de reconnaître que les équipes NetOps ne sont pas toujours celles qui font obstacle au déploiement de la dernière nouveauté, application ou service. Les freins à la rapidité sont souvent dus au fait que les organisations n’adoptent pas tous les principes du DevOps lorsqu’elles cherchent à transformer leurs opérations informatiques.
Mise à jour des services applicatifs : sécurité, rapidité et visiteurs suspects
Il est de nouveau temps de nous pencher sur les services applicatifs que les entreprises utilisent réellement pour rendre leurs applications plus rapides et plus sûres. On constate notamment une hausse du recours aux services de protection contre les bots, ainsi que la progression lente mais régulière de HTTP/2. Bien qu’il ne s’agisse pas d’une application…
Les templates prennent le contrôle du cloud
Les modèles s’imposent dans le cloud. Lisez le blog de F5 pour découvrir comment l’infrastructure en tant que code et les API déclaratives automatisent la mise à disposition des applications.