Où se situe un WAF dans le chemin de données ?
Les pare-feu d’applications Web (WAF) basés sur un proxy sont un élément essentiel de la protection des applications. En plus d'être une exigence pour se conformer à la norme PCI-DSS, les WAF sont excellents pour se protéger contre le Top 10 de l'OWASP. Ils constituent également une solution de référence pour traiter les vulnérabilités zero-day, soit par la publication rapide de mises à jour de signatures, soit, dans certains cas, par l’utilisation de fonctions programmatiques pour corriger virtuellement les applications pendant qu’une solution à long terme est déployée.
La question est : où placer une telle protection ?
Il existe bien sûr des options. Le chemin de données contient plusieurs points d’insertion sur lesquels un WAF peut être déployé. Mais cela ne signifie pas que chaque point d’insertion est une bonne idée. Certains sont moins efficaces que d’autres, certains introduisent des points de défaillance inacceptables et d’autres encore introduisent une dette architecturale qui entraîne de lourdes pénalités d’intérêt au fil du temps.
Idéalement, vous déploierez un WAF derrière votre niveau d’équilibrage de charge. Cela optimise l’utilisation, les performances et la fiabilité tout en offrant la protection nécessaire à toutes les applications, mais particulièrement à celles exposées sur Internet.
Utilisation
Les besoins en ressources (CPU et autres) impliqués dans la prise de décision d’équilibrage de charge sont minimes. C'est généralement la raison pour laquelle un LB est capable de prendre en charge simultanément des millions d'utilisateurs, et les WAF nécessitent une utilisation plus importante, car ils inspectent l'intégralité de la charge utile et l'évaluent par rapport aux signatures et aux politiques pour déterminer si la demande est valide et sûre.
Les modèles de centres de données modernes s’inspirent largement du cloud et de sa structure de coûts basée sur l’utilisation. L’utilisation devient un facteur clé des coûts opérationnels. Une utilisation plus élevée entraîne des besoins en ressources supplémentaires, ce qui consomme des budgets. L’optimisation de l’utilisation est donc une stratégie judicieuse pour limiter les coûts, tant dans le centre 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. Même si de nombreux WAF s'adaptent bien, ils peuvent néanmoins être submergés par le trafic Flash ou les attaques. Si le WAF est positionné devant le LB, vous avez besoin d'un autre niveau LB pour le mettre à l'échelle séparément, sinon vous risquez d'avoir un impact sur les performances et la disponibilité.
Performance
La performance est une préoccupation majeure dans une économie applicative . Avec autant de variables et de systèmes interagissant avec les données lorsqu'elles parcourent le chemin de données, il peut être frustrant de déterminer exactement où les performances sont ralenties, sans parler de régler chacun d'eux sans impacter les autres. Comme cela a été noté à plusieurs reprises auparavant, à mesure que la charge sur un système augmente, les performances diminuent. Il s’agit de l’une des conséquences imprévues de l’absence d’optimisation de l’utilisation, et de l’une des principales raisons pour lesquelles les architectes réseau expérimentés utilisent un seuil d’utilisation de 60 % sur les périphériques réseau.
Le déploiement d’un WAF derrière le niveau LB élimine le besoin d’un niveau d’équilibrage de charge WAF désigné en amont, ce qui supprime une couche entière de réseau de l’équation. Même si le temps de traitement éliminé peut sembler minime, ces précieuses microsecondes passées à gérer les connexions et à mettre à l'échelle les services WAF, puis à le faire à nouveau pour choisir une instance/un serveur d'application cible sont importantes. L’élimination de ce niveau en déployant le WAF derrière le niveau LB redonne de précieuses microsecondes que les utilisateurs d’aujourd’hui non seulement remarqueront, mais apprécieront.
Visibilité
La visibilité est une exigence clé pour les solutions de sécurité dans le chemin de données. Sans la possibilité d’inspecter l’intégralité du flux – y compris la charge utile – la plupart des fonctions de sécurité d’un WAF deviennent inutiles. Après tout, la plupart des codes malveillants se trouvent dans la charge utile, et non dans les en-têtes du protocole. Le positionnement d'un WAF derrière le niveau LB permet le décryptage SSL/TLS avant que le trafic ne soit transmis au WAF pour inspection. Il s’agit d’une architecture plus souhaitable car il est probable que l’équilibreur de charge aura de toute façon besoin d’une visibilité sur le trafic sécurisé, pour déterminer comment acheminer correctement les demandes.
Cela dit, un WAF s’intègre dans le chemin de données à peu près partout où vous le souhaitez. Il s’agit d’un service de sécurité basé sur un proxy L7 déployé comme intermédiaire dans le chemin réseau. Il pourrait apparemment se situer à la périphérie du réseau, si vous le souhaitez. Mais si vous souhaitez optimiser votre architecture en termes de performances, de fiabilité et d’utilisation en même temps, votre meilleure option est de positionner ce WAF derrière la couche d’équilibrage de charge, plus près de l’application qu’il protège.
Avec les bons outils, une couverture WAF complète peut réduire considérablement vos expositions, ainsi que vos coûts d’exploitation. Apprenez-en davantage sur la protection de vos applications contre le Top 10 de l'OWASP et d'autres menaces avec les webinaires à la demande de F5 et explorez les nombreuses façons dont vous pouvez déployer les fonctionnalités WAF de F5, y compris le service géré WAF Silverline basé sur le cloud de la société.
L'architecte de sécurité de F5, Brian McHenry , et l'évangéliste principal en recherche sur les menaces, David Holmes, ont contribué à cet article. Modifications mineures apportées en août 2019.