Autant que nous voudrions croire le contraire, les applications cloud natives sont des applications Web. Nous pouvons créer des services, mais leurs API sont souvent RESTful, et là où nous avons peut-être utilisé diverses technologies d’appel de procédure à distance dans le passé, nous passons maintenant au gRPC basé sur QUIC. Tout cela indique que nous exécutons la majorité des interactions de nos applications avec le monde extérieur via des procédures Web via le même ensemble restreint de ports.
Au début d’Internet, nous avions la possibilité pour séparer les applications par ports IP, en utilisant des pare-feu pour bloquer le trafic indésirable en évitant l’accès aux ports indésirables. Les agresseurs devaient analyser toute la gamme des numéros de port possibles avant de découvrir des vulnérabilités, réduisant ainsi la taille de la surface d’attaque facilement disponible et limitant la menace au minimum. Maintenant, cependant, ils peuvent simplement accéder aux ports HTTP, HTTPS et QUIC familiers et tenter de s’introduire en utilisant un ensemble réduit d’outils.
Le passage aux API Web a rendu beaucoup plus facile pour les agresseurs pour opérer à grande échelle et plus difficile pour les défenseurs de déterminer le trafic légitime et de bloquer les analyses et les attaques indésirables. Bien qu’il puisse être plus facile au début d’obstruer tout le trafic, puis d’analyser les paquets HTTP, le volume important de trafic que nous exécutons sur ces ports peut surcharger un pare-feu traditionnel. Il y a la question de savoir comment nous identifions et traitons le trafic que nous voulons. Comment pouvons-nous faire la différence entre les questions valides et destructrices sur une API, bloquant à la fois les attaques par déni de service et les attaques qui utilisent des charges utiles manipulées pour mettre en péril vos applications ?
Protégez les applications Azure avec Azure WAF
Dans Azure, c’est le rôle du logiciel de pare-feu d’application Web Azure (Azure WAF). Proposé en tant qu’élément autonome et dans le cadre de la suite de diffusion de contenu Azure Front Door, Azure WAF sépare le trafic que nous voulons, ou les grandes stars, du trafic que nous ne voulons pas, ou les mauvais acteurs. Si vous envisagez d’exécuter une application Azure destinée au public, un outil comme celui-ci est essentiel. Les applications personnelles qui traitent Azure comme une extension de votre réseau, utilisant des VPN ou des connexions directes via des services comme ExpressRoute, ne sont pas susceptibles d’avoir besoin d’un WAF car seul le trafic fiable et validé doit avoir accès.
Microsoft a en fait régulièrement mis à niveau Azure WAF, et une version majeure actuelle d’Azure Front Door est accompagnée d’une toute nouvelle version de WAF. Azure WAF peut être trouvé en deux versions : le WAF global pour les applications Web massives appartient à Front Door, et le WAF régional est pour vos propres installations virtuelles.
Lequel vous utiliserez dépendra de la façon dont vous déployez votre application; Si vous déployez globalement dans plusieurs régions Azure à l’aide des équilibreurs de charge de Front Door pour diriger le trafic vers les circonstances d’application à proximité, vous êtes susceptible d’utiliser Global et de bénéficier de son déploiement dans des centres d’information périphériques cosmopolites locaux. Code que les êtres d’une seule région sont les plus susceptibles d’utiliser Régional, avec Azure WAF exécuté dans le cadre d’une entrée d’application Azure dans votre infrastructure d’application, déployé à l’aide d’outils tels que ARM.
Lancer Azure WAF dans un infrastructure virtuelle
Si vous exécutez Azure WAF dans votre région, vous avez la possibilité d’utiliser des instances v1 et v2. La V2 a été lancée récemment et constitue une amélioration substantielle par rapport à la v1, ajoutant des fonctions de mise à l’échelle et de fiabilité. Si vous utilisez actuellement la v1, vous ne mettrez pas automatiquement à niveau vers la toute nouvelle version et vous devrez mettre à jour manuellement, en migrant les paramètres et le trafic vers un nouveau WAF v2 avant de supprimer les instances v1. Un point essentiel est que vous ne pouvez pas déplacer les adresses IP vers une toute nouvelle entrée, il faudra donc une toute nouvelle adresse. Il existe un script PowerShell pour Azure CLI qui vous aidera dans la procédure de mise à jour.
La méthode la plus simple pour publier une instance Azure WAF v2 dans un nouvel environnement consiste à utiliser un modèle ARM. Cette approche vous permet de développer la sécurité des applications dans n’importe quelle version automatisée, une clé envisagez de fournir des versions idempotentes dans le cadre de tout pipeline CI/CD (combinaison constante et livraison continue).
Vous devrez d’abord configurer un entrée d’application pour votre réseau virtuel. Cela peut être aussi basique que vous le souhaitez ; ce qui est nécessaire, ce sont les politiques du logiciel de pare-feu que vous appliquez. Microsoft utilise les ensembles de règles Open Web Application Security Job (OWASP) pour son Azure WAF, alors choisissez la variation que vous désirez et utilisez-la pour votre passerelle d’application avec des règles qui gèrent les paramètres de demande fondamentaux, par exemple, en limitant la taille des corps de demande pour diminuer le risque que des charges utiles de demande destructrices surchargent votre API avec du code exécutable. D’autres défenses incluent des défenses contre les attaques par injection SQL, les scripts intersites et les requêtes malformées.
Le moteur WAF le plus récent pour la version v2 utilise la version 3.2 de l’ensemble de règles de base OWASP, qui minimise le risque de positifs incorrects et inclut des règles qui assistent les applications Java sécurisées. Choisir l’ensemble de règles fait partie de l’établissement de votre logiciel pare-feu. Si vous souhaitez utiliser 3.2 et le nouveau moteur, vous devez le configurer avec votre instance WAF en considérant que l’installation par défaut est l’ancienne version 3.1. La toute nouvelle version présente des avantages significatifs : elle dépend 8 fois plus rapidement des mêmes installations virtuelles et peut traiter des demandes beaucoup plus importantes. Il existe 14 groupes de directives différents dans CRS 3.2, ce qui vous permet d’ajuster les directives utilisées en fonction des exigences de votre application.
Intégration d’Azure WAF avec d’autres outils de sécurité Azure
Azure WAF est intégré aux outils de sécurité Azure de Microsoft, composé de Microsoft Protector for Cloud. Cela vous offre un ensemble d’options intrigantes pour gérer votre WAF, déplacer la gestion de votre groupe d’infrastructure vers votre groupe de sécurité, en utilisant leurs outils pour gérer les directives une fois qu’il est déployé. Les professionnels de la sécurité peuvent créer des programmes de pare-feu, gérer des directives et déployer directement depuis le portail Protector for Cloud. Un choix avantageux est la possibilité de trouver des applications non protégées à l’aide d’outils d’analyse intégrés, ce qui permet à Azure WAF de protéger instantanément les applications sensibles.
En plus d’envoyer des signaux aux outils Protector for Cloud, Azure WAF s’intègre à Outils de gestion des événements de sécurité Sentinel de Microsoft. Votre groupe de sécurité peut les utiliser pour déterminer rapidement les attaques possibles et utiliser un mélange de journaux d’intelligence artificielle pour traquer de nouveaux risques qui n’auraient peut-être pas été apparents au premier abord. L’utilisation d’un WAF comme capteur supplémentaire dans votre environnement de sécurité est un excellent concept, car il se trouve sur l’une des surfaces d’attaque apparentes et peut fonctionner comme un avertissement précoce.
De manière remarquable, Microsoft sort Azure WAF du domaine familier centre de documentation avec prise en charge sur le réseau mondial de diffusion de contenu d’Azure, Azure CDN. Cela peut être considéré comme une option pour Cloudflare, fournissant une sécurité bien en dehors de votre application en protégeant le contenu mis en cache avec des limites de contrôle de débit pour arrêter les attaques DDoS tôt. Avec des innovations telles qu’Azure Static Web Apps tirant le meilleur parti d’Azure CDN pour héberger des applications à grande échelle, l’utilisation d’Azure WAF à la périphérie du réseau Azure prend tout son sens.
Microsoft facilite l’inclusion d’Azure WAF à vos applications, ce qui est une approche sensée pour motiver l’adoption. La sécurisation des applications cloud natives ne devrait pas être difficile. L’intégrer à une infrastructure programmable simplifie la mise en œuvre, en respectant les meilleures pratiques d’architecture cloud native. Avec les innovations Web cruciales pour la livraison d’applications contemporaines, un WAF est un composant essentiel de vos installations ; tout ce qui compte n’est pas de savoir si vous en installez un, mais où.
.
Toute l’actualité en temps réel, est sur L’Entrepreneur
