Nouvelles fonctionnalités et certifications du Pare-feu Azure au premier trimestre 2020

Publié le 18 février, 2020

Principal Program Manager, Azure Networking

Ce billet de blog a été coédité par Suren Jamiyanaa, Principal Program Manager, Azure Networking

L’adoption, l’intérêt et les commentaires positifs que suscite notre service ainsi que la diversité des cas d’utilisation par nos clients ne cessent de nous émerveiller. Aujourd’hui, nous sommes ravis de partager plusieurs nouvelles fonctionnalités du Pare-feu Azure développées en fonction de vos principaux commentaires :

  • Certification ICSA Labs Corporate Firewall.
  • La prise en charge du tunneling forcé est maintenant disponible en préversion.
  • Les groupes IP sont à présent disponibles en préversion.
  • Les plages d’adresses IP privées SNAT configurées par le client sont à présent généralement disponibles.
  • L’assouplissement des restrictions de ports élevés est à présent généralement disponible.

Le Pare-feu Azure est une offre de pare-feu en tant que service (FWaaS) cloud native qui vous permet de gérer et de journaliser tous vos flux de trafic à l’aide d’une approche DevOps. Le service prend en charge les règles de filtrage au niveau de l’application et du réseau et est intégré au flux Microsoft Threat Intelligence pour filtrer les adresses IP et les domaines malveillants connus. Le Pare-feu Azure est hautement disponible grâce à la mise à l’échelle automatique intégrée.

Certification ICSA Labs Corporate Firewall

L’entreprise ICSA Labs est l’un des principaux fournisseurs en matière de test et de certification de produits informatiques de sécurité et d’intégrité, ainsi que d’appareils connectés au réseau. Elle mesure la conformité, la fiabilité et les performances des produits de la plupart des principaux fournisseurs de technologies.

Le Pare-feu Azure est le premier service de pare-feu cloud à obtenir la certification ICSA Labs Corporate Firewall. Pour obtenir le rapport de certification du Pare-feu Azure, consultez les informations disponibles ici. Pour plus d’informations, consultez la page du programme ICSA Labs Firewall Certification.

MicrosoftReportCoverPageFeb18th

Figure 1 : Pare-feu Azure à présent certifié par ICSA Labs.

Prise en charge du tunneling forcé maintenant disponible en préversion

Le tunneling forcé vous permet de rediriger tout le trafic Internet lié du Pare-feu Azure vers votre pare-feu local ou une appliance virtuelle réseau à proximité pour une inspection supplémentaire. Par défaut, le tunneling forcé n’est pas autorisé sur le Pare-feu Azure pour s’assurer que toutes ses dépendances Azure sortantes sont satisfaites.

Pour prendre en charge le tunneling forcé, le trafic de gestion des services est séparé du trafic client. Un sous-réseau dédié supplémentaire nommé AzureFirewallManagementSubnet est requis avec sa propre adresse IP publique associée. Le seul itinéraire autorisé sur ce sous-réseau est un itinéraire par défaut vers Internet, et la propagation de route BGP doit être désactivée.

Dans cette configuration, AzureFirewallSubnet peut à présent inclure des itinéraires vers n’importe quel pare-feu local ou appliance virtuelle réseau pour traiter le trafic avant qu’il ne soit transmis à Internet. Vous pouvez également publier ces itinéraires via BGP vers AzureFirewallSubnet si la propagation de route BGP est activée sur ce sous-réseau. Pour plus d’informations, consultez la documentation sur le tunneling forcé Pare-feu Azure.


Création d’un pare-feu avec le tunneling forcé activé

Figure 2 - Création d’un pare-feu avec le tunneling forcé activé

Groupes IP à présent en préversion

Les groupes IP sont une nouvelle ressource Azure de niveau supérieur qui vous permet de regrouper et de gérer des adresses IP dans les règles de Pare-feu Azure. Vous pouvez attribuer un nom à votre groupe IP et en créer un en entrant des adresses IP ou en téléchargeant un fichier. Les groupes IP facilitent votre expérience de gestion et réduisent le temps consacré à la gestion des adresses IP en les utilisant dans un seul pare-feu ou sur plusieurs pare-feu. Pour plus d’informations, consultez la documentation sur les groupes IP dans le Pare-feu Azure.

Les règles d’application de Pare-feu Azure utilisent un groupe IP

Figure 3 - Les règles d’application de Pare-feu Azure utilisent un groupe IP.

Plages d’adresses IP privées SNAT configurées par le client

Le Pare-feu Azure fournit la traduction d’adresses réseau source (SNAT) automatique pour tout le trafic sortant vers les adresses IP publiques. Le Pare-feu Azure ne fournit pas de traduction d’adresses réseau source (SNAT) lorsque l’adresse IP de destination est une plage d’adresses IP privées, tel que spécifié par la norme IANA RFC 1918. Si votre organisation utilise une plage d’adresses IP publiques pour des réseaux privés ou s’il est possible de forcer le trafic Internet du Pare-feu Azure via un pare-feu local, vous pouvez configurer le Pare-feu Azure pour qu’il ne propose pas la traduction d’adresses réseau source (SNAT) avec des plages d’adresses IP personnalisées supplémentaires. Pour plus d’informations, consultez la page sur les plages d’adresses IP privées SNAT du Pare-feu Azure.

Pare-feu Azure avec des plages d’adresses IP privées personnalisées

Figure 4 - Pare-feu Azure avec des plages d’adresses IP privées personnalisées.

Assouplissement des restrictions de ports élevés à présent généralement disponible

Depuis sa préversion initiale, le Pare-feu Azure avait une limitation empêchant les règles de réseau et d’application d’inclure les ports source ou de destination au-dessus de 64 000. Ce comportement par défaut bloquait les scénarios basés sur RPC et spécifiquement la synchronisation Active Directory. Avec cette nouvelle mise à jour, les clients peuvent utiliser n’importe quel port de la plage 1-65535 dans les règles du réseau et de l’application.

Prochaines étapes

Pour plus d’informations sur tout ce que nous avons abordé plus haut, consultez les billets de blog, la documentation et les vidéos ci-dessous.

Partenaires pour la gestion centralisée du Pare-feu Azure :