Qu’est-ce qu’un pare-feu Azure ?

Le Pare-feu Azure est un service de sécurité de pare-feu réseau intelligent et natif Cloud qui offre le meilleur de la protection contre les menaces pour vos charges de travail cloud s’exécutant dans Azure. Il s’agit d’un service de pare-feu avec état intégral, doté d’une haute disponibilité intégrée et d’une scalabilité illimitée dans le cloud. Il fournit l’inspection du trafic Est-Ouest et Nord-Sud.

Le Pare-feu Azure est proposé dans trois versions : Standard, Premium et De base.

Pare-feu Azure Standard

Le Pare-feu Azure standard fournit un filtrage L3-L7 et des flux de renseignement sur les menaces directement à partir de la Cybersécurité Microsoft. Le filtrage basé sur le renseignement sur les menaces peut émettre des alertes et refuser le trafic provenant, ou à destination, d’adresses IP et de domaines malveillants connus, qui sont mis à jour en temps réel pour offrir une protection contre les attaques nouvelles et émergentes.

Vue d’ensemble du Pare-feu Standard

Pour en savoir plus sur les fonctionnalités du Pare-feu Standard, consultez Fonctionnalités du Pare-feu Azure Standard.

Pare-feu Azure Premium

Le Pare-feu Azure Premium propose des fonctionnalités avancées incluant un système IDPS basé sur les signatures pour permettre une détection rapide des attaques en recherchant des modèles spécifiques. Ces modèles peuvent inclure des séquences d’octets dans le trafic réseau ou des séquences d’instructions malveillantes connues utilisées par un programme malveillant. Il existe plus de 58 000 signatures dans plus de 50 catégories, qui sont mises à jour en temps réel pour offrir une protection contre les codes malveillants nouveaux et émergents exploitant une faille de sécurité. Les catégories de codes malveillants exploitant une faille de sécurité incluent les programmes malveillants, le hameçonnage, le minage de monnaie et les chevaux de Troie.

Vue d’ensemble du Pare-feu Premium

Pour plus d’informations sur les fonctionnalités du Pare-feu Premium, consultez Fonctionnalités du Pare-feu Azure Premium.

Pare-feu Azure De base (préversion)

Important

Le Pare-feu Azure De base est actuellement en préversion. Pour connaître les conditions juridiques qui s’appliquent aux fonctionnalités Azure en version bêta, en préversion ou plus généralement non encore en disponibilité générale, consultez l’Avenant aux conditions d’utilisation des préversions de Microsoft Azure.

Le Pare-feu Azure De base est destiné aux clients de petite et moyenne taille (PME) pour sécuriser leur environnement cloud Azure. Il offre la protection essentielle dont les PME ont besoin à un prix abordable.

Schéma montrant le pare-feu De base.

Le Pare-feu Azure De base est similaire au Pare-feu Standard, mais présente les limitations suivantes :

  • Prend uniquement en charge le mode d’alerte.
  • Unité d’échelle fixe pour exécuter le service sur deux instances principales de machine virtuelle.
  • Recommandé pour les environnements avec un débit maximal de 250 Mbits/s. Le débit peut augmenter pour la disponibilité générale des fonctionnalités (GA).

Régions prises en charge

Le Pare-feu Azure De base est disponible dans les régions suivantes pendant la préversion :

  • USA Est
  • USA Est 2
  • USA Ouest
  • USA Ouest 2
  • USA Ouest 3
  • USA Centre
  • Centre-Nord des États-Unis
  • États-Unis - partie centrale méridionale
  • Centre-USA Ouest
  • USA Est 2 (EUAP)
  • EUAP USA Centre
  • Europe Nord
  • Europe Ouest
  • Asie Est
  • Asie Sud-Est
  • Japon Est
  • OuJapon Est
  • Australie Est
  • Sud-Australie Est
  • Centre de l’Australie
  • Brésil Sud
  • Inde Sud
  • Inde centrale
  • Inde Ouest
  • Centre du Canada
  • Est du Canada
  • Sud du Royaume-Uni
  • Ouest du Royaume-Uni
  • Centre de la Corée
  • Corée du Sud
  • France Centre
  • Afrique du Sud Nord
  • Émirats arabes unis Nord
  • Suisse Nord
  • Allemagne Centre-Ouest
  • Norvège Est
  • Inde Ouest Jio
  • Suède Centre
  • Qatar Central

Pour déployer un pare-feu de base, consultez Déployer et configurer le Pare-feu Azure De base (préversion) et la stratégie à l’aide du Portail Azure.

Azure Firewall Manager

Vous pouvez utiliser Azure Firewall Manager pour gérer de manière centralisée les Pare-feu Azure sur plusieurs abonnements. Firewall Manager utilise la stratégie de pare-feu pour appliquer un ensemble commun de règles de réseau/d’application et de configuration aux pare-feu de votre locataire.

Firewall Manager prend en charge les pare-feu à la fois dans les environnements de réseau virtuel et de réseau étendu virtuel (hub virtuel sécurisé). Les hubs virtuels sécurisés utilisent la solution d’automatisation de route Virtual WAN pour simplifier le routage du trafic vers le pare-feu en quelques clics.

Pour en savoir plus sur Azure Firewall Manager, consultez Azure Firewall Manager.

Tarifs et contrat SLA

Pour plus d’informations sur les tarifs du Pare-feu Azure, consultez Tarifs du Pare-feu Azure.

Pour plus d’informations sur le contrat de niveau de service du Pare-feu Azure, consultez Contrat SLA du Pare-feu Azure.

Régions prises en charge

Pour connaître les régions prises en charge par Pare-feu Azure, consultez Disponibilité des produits Azure par région.

Nouveautés

Pour découvrir les nouveautés du Pare-feu Azure, consultez Mises à jour Azure.

Problèmes connus

Pare-feu Azure Standard

Les problèmes connus de Pare-feu Azure Standard sont les suivants :

Notes

Tout problème qui s’applique à Standard s’applique également à Premium.

Problème Description Limitation des risques
Les règles de filtrage réseau pour les protocoles autres que TCP/UDP (par exemple ICMP) ne fonctionnent pas pour le trafic lié à Internet. Les règles de filtrage réseau des protocoles autres que TCP/UDP ne fonctionnent pas avec SNAT pour votre adresse IP publique. Les protocoles autres que TCP/UDP sont pris en charge entre les sous-réseaux du rayon et les réseaux virtuels. Le service Pare-feu Azure utilise Standard Load Balancer, qui ne prend pas en charge SNAT pour les protocoles IP pour le moment. Nous étudions les possibilités de prendre en charge ce scénario dans une prochaine version.
Protocole ICMP non pris en charge par PowerShell et l’interface de ligne de commande Azure PowerShell et l’interface CLI ne prennent pas en charge le protocole ICMP en tant que protocole valide dans les règles de réseau. Il est toujours possible d’utiliser le protocole ICMP par le biais du portail et de l’API REST. Nous travaillons actuellement à ajouter à PowerShell et à l’interface de ligne de commande la prise en charge du protocole ICMP.
Les balises FQDN requièrent une définition protocole : port Les règles d’application avec des balises FQDN requièrent une définition port : protocole. Vous pouvez utiliser https en tant que valeur port : protocole. Nous travaillons actuellement à rendre ce champ facultatif lorsque des balises FQDN sont utilisées.
Le déplacement d’un pare-feu vers un autre groupe de ressources ou un autre abonnement n’est pas pris en charge Le déplacement d’un pare-feu vers un autre groupe de ressources ou un autre abonnement n’est pas pris en charge. La prise en charge de cette fonctionnalité figure sur notre feuille de route. Pour déplacer un pare-feu vers un autre groupe de ressources ou un autre abonnement, vous devez supprimer l’instance actuelle et la recréer dans le nouveau groupe de ressources ou le nouvel abonnement.
Les alertes Threat intelligence peuvent être masquées Les règles de réseau avec la destination 80/443 pour le filtrage sortant masque les alertes intelligentes de menaces lorsqu’elles sont configurées pour en mode alerte uniquement. Créez un filtrage sortant pour 80/443 à l’aide de règles d’application. Ou modifiez le mode d’intelligence contre les menaces pour alerter et rejeter.
La fonction DNAT du Pare-feu Azure ne fonctionne pas pour les destinations IP privées La prise en charge de la fonction DNAT du Pare-feu Azure est limitée aux sorties/entrées Internet. Actuellement, DNAT ne fonctionne pas pour les destinations IP privées. Par exemple, spoke-à-spoke. Il s’agit d’une limitation actuelle.
Impossible de supprimer la première configuration IP publique Chaque adresse IP publique du Pare-feu Azure est affectée à une configuration IP. La première configuration IP est affectée pendant le déploiement du pare-feu. En général, elle contient une référence au sous-réseau du pare-feu (sauf si elle est configurée autrement de manière explicite via un déploiement de modèle). Vous ne pouvez pas supprimer cette configuration IP, car cela aurait pour effet de désallouer le pare-feu. Vous pouvez toujours changer ou supprimer l’adresse IP publique qui est associée à cette configuration IP si le pare-feu comprend au moins une autre adresse IP publique disponible. C'est la procédure normale.
Les zones de disponibilité ne peuvent être configurées que pendant le déploiement. Les zones de disponibilité ne peuvent être configurées que pendant le déploiement. Vous ne pouvez pas configurer les Zones de disponibilité après le déploiement d’un pare-feu. C'est la procédure normale.
SNAT sur les connexions entrantes En plus de DNAT, les connexions via l’adresse IP publique du pare-feu (entrante) sont traduites vers l’une des adresses IP privées du pare-feu. Cette exigence actuelle (également pour les appliances virtuelles réseau Active/Active) permet d’assurer la symétrie du routage. Pour préserver la source originale pour HTTP/S, pensez à utiliser les en-têtes XFF. Par exemple, utilisez un service tel que Azure Front Door ou Azure Application Gateway devant le pare-feu. Vous pouvez également ajouter le pare-feu d’applications web en tant qu’Azure Front Door et l’associer au pare-feu.
Prise en charge du filtrage FQDN SQL uniquement en mode proxy (port 1433) Pour Azure SQL Database, Azure Synapse Analytics et Azure SQL Managed Instance :

Le filtrage FQDN SQL est pris en charge uniquement en mode proxy (port 1433).

Pour Azure SQL IaaS :

Si vous utilisez des ports non standard, vous pouvez spécifier ces ports dans les règles de l’application.
Pour SQL en mode de redirection (l’option par défaut si vous vous connectez à partir d’Azure), vous pouvez à la place filtrer l’accès par le biais de l’étiquette du service SQL, dans le cadre des règles de réseau du Pare-feu Azure.
Le trafic SMTP sortant sur le port TCP 25 est bloqué Les e-mails sortants envoyés directement à des domaines externes (comme outlook.com et gmail.com) sur le port TCP 25 peuvent être bloqués par la plateforme Azure. Il s’agit du comportement par défaut de la plateforme dans Azure. Le Pare-feu Azure n’introduit aucune restriction spécifique supplémentaire. Utilisez des services de relais SMTP authentifiés, qui se connectent généralement via le port TCP 587, mais prennent également en charge d’autres ports. Pour plus d’informations, consultez Résoudre les problèmes de connectivité SMTP sortante dans Azure. Même si le Pare-feu Azure peut actuellement communiquer avec les adresses IP publiques via le port TCP 25 sortant, il n’est pas garanti que cela soit toujours possible et pris en charge pour tous les types d’abonnements. Pour les adresses IP privées, telles que les réseaux virtuels, les réseaux privés virtuels et Azure ExpressRoute, le Pare-feu Azure prend en charge une connexion sortante du port TCP 25.
Insuffisance de ports SNAT Actuellement, le Pare-feu Azure prend en charge 2496 ports par adresse IP publique par instance de groupe de machines virtuelles identiques back-end. Par défaut, il existe deux instances de groupe de machines virtuelles identiques. Il existe donc 4992 ports par flux (adresse IP de destination, port de destination et protocole (TCP ou UDP)). Le pare-feu peut évoluer jusqu’à 20 instances maximum. Il s’agit d’une limitation de plateforme. Vous pouvez contourner les limites en configurant les déploiements de Pare-feu Azure avec un minimum de cinq adresses IP publiques pour les déploiements sujets à une insuffisance de ports SNAT. Ceci multiplie par cinq le nombre de ports SNAT disponibles. Effectuez l’allocation à partir d’un préfixe d’adresse IP pour simplifier les autorisations en aval. Pour une solution plus permanente, vous pouvez déployer une passerelle NAT pour surmonter les limites du port SNAT. Cette approche est prise en charge pour les déploiements de réseaux virtuels.

Pour plus d’informations, consultez Mettre à l’échelle les ports SNAT avec la table NAT de réseau virtuel Azure.
DNAT n’est pas pris en charge avec l’option Tunneling forcé activée Les pare-feu déployés, dont l’option Tunneling forcé est activée, ne peuvent pas prendre en charge l’accès entrant depuis Internet compte tenu du routage asymétrique. Ils ont ce comportement par défaut en raison du routage asymétrique. Le chemin de retour des connexions entrantes passe par le pare-feu local, qui n’a pas vu la connexion établie.
Le FTP passif sortant est susceptible de ne pas fonctionner pour les pare-feu ayant plusieurs adresses IP publiques ; cela dépend de la configuration de votre serveur FTP. Le mode FTP passif établit des connexions différentes pour les canaux de contrôle et ceux de données. Lorsqu’un pare-feu disposant de plusieurs adresses IP publiques envoie des données sortantes, il sélectionne de manière aléatoire une de ses adresses IP publiques comme adresse IP source. FTP peut échouer lorsque les canaux de données et de contrôle utilisent des adresses IP sources différentes ; cela dépend de la configuration de votre serveur FTP. Une configuration SNAT explicite est prévue. En attendant, vous pouvez configurer votre serveur FTP pour accepter des canaux de données et de contrôle à partir d’adresses IP sources différentes (consultez cet exemple pour IIS). En guise d’alternative, utilisez une seule adresse IP dans ce cas de figure.
Le FTP passif entrant est susceptible de ne pas fonctionner ; cela dépend de la configuration de votre serveur FTP. Le mode FTP passif établit des connexions différentes pour les canaux de contrôle et ceux de données. Les connexions entrantes sur le Pare-feu Azure font l’objet d’une traduction SNAT en une des adresses IP privées du pare-feu afin de garantir un routage symétrique. FTP peut échouer lorsque les canaux de données et de contrôle utilisent des adresses IP sources différentes ; cela dépend de la configuration de votre serveur FTP. La conservation de l’adresse IP source d’origine est en cours d’examen. En attendant, vous pouvez configurer votre serveur FTP pour accepter des canaux de données et de contrôle à partir d’adresses IP sources différentes.
Le FTP actif ne fonctionne pas quand le client FTP doit atteindre un serveur FTP sur Internet. Le FTP actif utilise une commande PORT du client FTP qui indique au serveur FTP l’IP et le port à utiliser pour le canal de données. Cette commande PORT utilise l’IP privée du client, que vous ne pouvez pas changer. Le trafic côté client qui traverse le Pare-feu Azure est un trafic NAT pour les communications basées sur Internet, de sorte que la commande PORT est considérée comme non valide par le serveur FTP. Il s’agit d’une limitation générale du FTP actif quand il est utilisé avec NAT côté client.
Il manque une dimension de protocole à la métrique NetworkRuleHit La métrique ApplicationRuleHit autorise le protocole basé sur le filtrage, mais cette fonctionnalité est absente de la métrique NetworkRuleHit correspondante. Un correctif est en cours d’étude.
Les règles NAT avec des ports entre 64000 et 65535 ne sont pas prises en charge Le Pare-feu Azure autorise tous les ports de la plage 1-65535 dans les règles de réseau et d’application. Toutefois, les règles NAT prennent uniquement en charge les ports de la plage 1-63999. Il s’agit d’une limitation actuelle.
Les mises à jour de configuration peuvent prendre cinq minutes en moyenne Une mise à jour de configuration du Pare-feu Azure peut prendre trois à cinq minutes en moyenne ; les mises à jour parallèles ne sont pas prises en charge. Un correctif est en cours d’étude.
Le pare-feu Azure utilise des en-têtes SNI TLS pour filtrer le trafic HTTPS et MSSQL Si le logiciel du navigateur ou du serveur ne prend pas en charge l’extension SNI, vous ne pouvez pas vous connecter via le Pare-feu Azure. Si le logiciel du navigateur ou du serveur ne prend pas en charge SNI, il est possible que vous puissiez contrôler la connexion en utilisant une règle de réseau au lieu d’une règle d’application. Consultez Indication du nom du serveur (SNI) pour découvrir les logiciels qui prennent en charge SNI.
Impossible d’ajouter des étiquettes de stratégie de pare-feu à l’aide du portail ou des modèles Azure Resource Manager (ARM) La stratégie de Pare-feu Azure a une limite de prise en charge des correctifs qui vous empêche d’ajouter une étiquette à l’aide du portail Azure ou des modèles ARM. L’erreur suivante est générée : Impossible d’enregistrer les étiquettes de la ressource. Un correctif est en cours d’étude. Vous pouvez aussi utiliser l’applet de commande Azure PowerShell Set-AzFirewallPolicy pour mettre à jour les balises.
IPv6 n’est pas pris en charge actuellement Si vous ajoutez une adresse IPv6 à une règle, le pare-feu échoue. Utilisez uniquement des adresses IPv4. La prise en charge d’IPv6 est en cours d’examen.
La mise à jour de plusieurs groupes d'adresses IP échoue en générant une erreur de conflit. Quand vous mettez à jour au moins deux groupes IP joints au même pare-feu, l’une des ressources passe en état d’échec. Il s'agit d'un problème/d'une limitation connu(e).

Quand vous mettez à jour un groupe IP, une mise à jour est déclenchée sur tous les pare-feux auxquels ce groupe IP est joint. Si la mise à jour d’un deuxième groupe IP est lancée alors que le pare-feu est toujours à l’état Mise à jour, la mise à jour du groupe IP échoue.

Pour éviter l’échec, les groupes IP joints au même pare-feu doivent être mis à jour un par un. Prévoyez suffisamment de temps entre les mises à jour pour permettre au pare-feu de sortir de l'état Mise à jour.
La suppression de RuleCollectionGroups à l’aide de modèles ARM n’est pas prise en charge. La suppression d’un RuleCollectionGroup à l’aide de modèles ARM n’est pas prise en charge et entraîne un échec. Cette opération n’est pas prise en charge.
La règle DNAT permettant de tout (*) autoriser renvoie le trafic SNAT. Si une règle DNAT autorise tout (*) en tant qu’adresse IP source, une règle de réseau implicite met en correspondance le traffic VNet-VNet et soumet systématiquement le trafic à cette règle SNAT. Il s’agit d’une limitation actuelle.
L’ajout d’une règle DNAT à un hub virtuel sécurisé à l’aide d’un fournisseur de sécurité n’est pas pris en charge. Cela se traduit par un itinéraire asynchrone pour le trafic DNAT de retour, qui accède au fournisseur de sécurité. Non pris en charge.
Une erreur s’est produite lors de la création de plus de 2000 collections de règles. Le nombre maximal de collections de règles NAT/Application ou Réseau est de 2000 (limite de Resource Manager). Il s’agit d’une limitation actuelle.
Impossible de voir le nom de la règle réseau dans les journaux du Pare-feu Azure Les données du journal des règles réseau du Pare-feu Azure ne montrent pas le nom de la règle pour le trafic réseau. La fonctionnalité de journalisation des noms de règles réseau est en préversion. Pour plus d’informations, consultez Fonctionnalités du Pare-feu Azure en préversion.
En-tête XFF dans HTTP/S Les en-têtes XFF sont remplacés par l’adresse IP source d’origine, telle que la voit le pare-feu. Cela s’applique aux cas d’usage suivants :
- Requêtes HTTP
- Requêtes HTTPs avec terminaison TLS
Un correctif est en cours d’étude.
Impossible d’effectuer la mise à niveau vers Premium avec des zones de disponibilité dans la région Asie Sud-Est. Actuellement, vous ne pouvez pas effectuer la mise à niveau vers le Pare-feu Azure Premium avec des zones de disponibilité dans la région Asie Sud-Est. Déployez un nouveau Pare-feu Premium en Asie du Sud-Est sans zones de disponibilité ou déployez dans une région qui prend en charge les zones de disponibilité.
Impossible de déployer un pare-feu avec des zones de disponibilité avec une adresse IP publique nouvellement créée Quand vous déployez un pare-feu avec des zones de disponibilité, vous ne pouvez pas utiliser une adresse IP publique nouvellement créée. Commencez par créer une nouvelle adresse IP publique redondante dans une zone, puis affectez cette adresse IP créée précédemment lors du déploiement du pare-feu.
La zone DNS privée Azure n’est pas prise en charge avec Pare-feu Azure La zone DNS privée Azure ne fonctionne pas avec Pare-feu Azure indépendamment de Pare-feu Azure paramètres DNS. Pour obtenir l’état souhaité de l’utilisation d’un serveur DNS privé, utilisez Pare-feu Azure proxy DNS au lieu d’une zone DNS privée Azure.

Pare-feu Azure Premium

Les problèmes connus du Pare-feu Azure Premium sont les suivants :

Problème Description Limitation des risques
Prise en charge ESNI pour la résolution de nom de domaine complet dans HTTPS Le chiffrement SNI n’est pas pris en charge dans l’établissement d'une liaison HTTPS. Aujourd’hui, seul Firefox prend en charge ESNI via une configuration personnalisée. La solution de contournement recommandée consiste à désactiver cette fonctionnalité.
L’authentification de la certification du client n’est pas prise en charge Les certificats clients sont utilisés pour créer une approbation d’identité mutuelle entre le client et le serveur. Les certificats clients sont utilisés lors d’une négociation TLS. Le Pare-feu Azure renégocie une connexion avec le serveur et n’a pas accès à la clé privée des certificats clients. Aucun
QUIC/HTTP3 QUIC est la nouvelle version majeure de HTTP. Il s’agit d’un protocole basé sur UDP sur 80 (PLAN) et 443 (SSL). L’inspection FQDN/URL/TLS n’est pas prise en charge. Configurez le passage UDP 80/443 en tant que règles de réseau.
Certificats signés par le client non approuvés Les certificats signés par le client ne sont pas approuvés par le pare-feu lorsqu’ils proviennent d’un serveur web intranet. Un correctif est en cours d’étude.
Adresse IP source erronée dans les alertes avec système IDPS pour HTTP (sans inspection TLS). Lorsque le trafic HTTP en texte brut est utilisé, que le système IDPS émet une nouvelle alerte et que la destination est une adresse IP publique, l’adresse IP source affichée est incorrecte (l’adresse IP interne est affichée à la place de l’adresse IP d’origine). Un correctif est en cours d’étude.
Propagation du certificat Après l’application d’un certificat d’autorité de certification sur le pare-feu, la prise en compte du certificat peut prendre de 5 à 10 minutes. Un correctif est en cours d’étude.
Prise en charge du protocole TLS 1.3 Le protocole TLS 1.3 est partiellement pris en charge. Le tunnel TLS entre le client et le pare-feu est basé sur le protocole TLS 1.2, et celui entre le pare-feu et le serveur web externe est basé sur le protocole TLS 1.3. Des mises à jour sont à l’étude.
Zones de disponibilité pour le Pare-feu Premium dans la région Asie Sud-Est Actuellement, vous ne pouvez pas déployer le Pare-feu Azure Premium avec des zones de disponibilité dans la région Asie Sud-Est. Déployez le Pare-feu en Asie du Sud-Est sans zones de disponibilité ou déployez dans une région qui prend en charge les zones de disponibilité.

Étapes suivantes