FAQ Pare-feu Azure

Généralités

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

Pare-feu Azure est un service de sécurité réseau informatique géré qui protège vos ressources Réseau virtuel Azure. Il s’agit d’un service de pare-feu entièrement avec état, pourvu d’une haute disponibilité intégrée et de l’extensibilité sans limites du cloud. Vous pouvez créer, appliquer et consigner des stratégies de connectivité réseau et d’application de façon centralisée entre les abonnements et les réseaux virtuels.

Quelles sont les fonctionnalités prises en charge par le Pare-feu Azure ?

Pour obtenir la liste détaillée des fonctionnalités du Pare-feu Azure, consultez les fonctionnalités du Pare-feu Azure.

Qu’est le modèle de déploiement type de Pare-feu Azure ?

Le Pare-feu Azure peut être déployé sur n’importe quel réseau virtuel. Toutefois, il est généralement déployé sur un réseau virtuel central dans un modèle hub-and-spoke, avec d’autres réseaux virtuels appairés à celui-ci. L’itinéraire par défaut des réseaux virtuels appairés est défini pour pointer vers ce réseau virtuel de pare-feu central. Bien que le peering de réseaux virtuels globaux soit pris en charge, il n’est pas recommandé en raison de problèmes potentiels de performances et de latence entre les régions. Pour des performances optimales, déployez un pare-feu par région.

Ce modèle permet un contrôle centralisé sur plusieurs réseaux virtuels spoke sur différents abonnements et offre des économies en évitant la nécessité de déployer un pare-feu dans chaque réseau virtuel. Les économies de coûts doivent être évaluées par rapport aux coûts de peering associés en fonction des modèles de trafic.

Comment puis-je déployer le Pare-feu Azure ?

Le Pare-feu Azure peut être déployé à l’aide du portail Azure, de PowerShell, de l’API REST ou des modèles. Pour obtenir des instructions pas à pas, consultez Tutoriel : Déployer et configurer le Pare-feu Azure à l’aide du portail Azure.

Quels sont les principaux concepts du Pare-feu Azure ?

Le Pare-feu Azure utilise des règles et des regroupements de règles. Une collection de règles est un ensemble de règles avec le même ordre et la même priorité. Les collections de règles sont exécutées dans l’ordre de priorité. Les collections de règles DNAT ont une priorité plus élevée que les regroupements de règles réseau, qui à leur tour ont une priorité plus élevée que les regroupements de règles d’application. Toutes les règles se terminent.

Il existe trois types de regroupement de règles :

• Règles d’application : Configurez des noms de domaine complets (FQDN) accessibles à partir d’un réseau virtuel.
• Règles réseau : configurez des règles avec des adresses sources, des protocoles, des ports de destination et des adresses de destination.
• Règles NAT : Configurez les règles DNAT pour autoriser les connexions entrantes Internet ou intranet (preview).

Pour plus d’informations, consultez Configurer les règles du pare-feu Azure.

Quels services de journalisation et d’analyse le Pare-feu Azure prend-il en charge ?

Le Pare-feu Azure s’intègre à Azure Monitor pour afficher et analyser les journaux. Les journaux peuvent être envoyés à Log Analytics, stockage Azure ou Event Hubs et analysés à l’aide d’outils tels que Log Analytics, Excel ou Power BI. Pour plus d’informations, consultez Didacticiel : Surveiller les journaux d’activité de pare-feu Azure.

Comment le Pare-feu Azure diffère-t-il des appliances virtuelles réseau dans la Place de marché ?

Le Pare-feu Azure est un service de sécurité réseau managé basé sur le cloud qui protège les ressources de réseau virtuel. Il s’agit d’un service de pare-feu entièrement avec état, pourvu d’une haute disponibilité intégrée et de l’extensibilité sans limites du cloud. Il est préintégré avec des fournisseurs de sécurité en tant que service (SECaaS) tiers pour améliorer la sécurité des connexions Internet de réseau virtuel et de branche. Pour plus d’informations, voir Sécurité du réseau Azure.

Quelle est la différence entre Application Gateway WAF et Pare-feu Azure ?

Application Gateway WAF fournit une protection entrante centralisée pour les applications web contre les attaques et vulnérabilités courantes. Pare-feu Azure assure une protection en entrée pour les protocoles non-HTTP/S (par exemple, RDP, SSH et FTP), une protection en sortie au niveau du réseau pour tous les ports et protocoles, ainsi qu’une protection au niveau de l’application pour le trafic HTTP/S sortant.

Quelle est la différence entre les groupes de sécurité réseau (NSG) et Pare-feu Azure ?

Le Pare-feu Azure complète les groupes de sécurité réseau pour fournir une meilleure sécurité réseau « de défense en profondeur ». Les groupes de sécurité réseau offrent un filtrage de trafic de couche réseau distribué pour limiter le trafic au sein des réseaux virtuels de chaque abonnement. Le Pare-feu Azure fournit une protection centralisée, entièrement avec état et au niveau de l’application sur les abonnements et les réseaux virtuels.

Les groupes de sécurité réseau sont-ils pris en charge dans AzureFirewallSubnet ?

Le Pare-feu Azure est un service géré avec plusieurs couches de protection, notamment la protection de la plateforme avec des groupes de sécurité réseau au niveau de la carte réseau (non visibles). Les groupes de sécurité réseau au niveau du sous-réseau ne sont pas obligatoires sur AzureFirewallSubnet et sont désactivés pour empêcher les interruptions de service.

Quelle est la valeur ajoutée du Pare-feu Azure avec des points de terminaison privés ?

Les points de terminaison privés sont un composant de Private Link, une technologie qui permet d’interagir avec les services PaaS Azure à l’aide d’adresses IP privées plutôt que publiques. Le Pare-feu Azure peut être utilisé pour empêcher l’accès aux adresses IP publiques, ce qui évite d’exfiltration de données aux services Azure ne tirant pas parti de Private Link, ainsi que pour implémenter des stratégies de confiance zéro en définissant qui dans votre organisation doit accéder à ces services PaaS Azure, car Private Link ouvre par défaut l’accès réseau pour l’ensemble de votre réseau d’entreprise.

La conception appropriée pour inspecter le trafic vers des points de terminaison privés avec le Pare-feu Azure dépend de votre architecture réseau, vous trouverez plus de détails dans l’article Scénarios de pare-feu Azure pour inspecter le trafic destiné à un point de terminaison privé.

Quelle est la valeur ajoutée du Pare-feu Azure avec des points de terminaison de service de réseau virtuel ?

Les points de terminaison de service de réseau virtuel sont une alternative à Private Link pour contrôler l’accès réseau aux services PaaS Azure. Même si le client utilise toujours des adresses IP publiques pour accéder au service PaaS, le sous-réseau source est rendu visible afin que le service PaaS de destination puisse implémenter des règles de filtre et restreindre l’accès par sous-réseau. Vous trouverez une comparaison détaillée entre les deux mécanismes dans Comparer les points de terminaison privés et les points de terminaison de service.

Les règles d’application du Pare-feu Azure peuvent être utilisées pour s’assurer qu’aucune exfiltration de données aux services non autorisés n’a lieu et pour implémenter des stratégies d’accès avec une granularité accrue au-delà du niveau du sous-réseau. En règle générale, les points de terminaison de service de réseau virtuel doivent être activés dans le sous-réseau du client qui se connectera à un service Azure. Toutefois, lors de l’inspection du trafic vers les points de terminaison de service avec le pare-feu Azure, vous devez activer le point de terminaison de service correspondant dans le sous-réseau du pare-feu Azure et les désactiver sur le sous-réseau du client réel (généralement un réseau virtuel spoke). De cette façon, vous pouvez utiliser des règles d’application dans le Pare-feu Azure pour contrôler les services Azure auxquels vos charges de travail Azure auront accès.

Quels sont les tarifs de Pare-feu Azure ?

Pour plus d’informations sur la tarification, consultez Tarification du Pare-feu Azure.

Quelles sont les limites de service connues pour le Pare-feu Azure ?

Pour connaître les limites de service, consultez les limites, quotas et contraintes d’abonnement Azure et de service.

Où le Pare-feu Azure stocke-t-il les données client ?

Le Pare-feu Azure ne déplace pas ou ne stocke pas les données client en dehors de la région où elle est déployée.

Le Pare-feu Azure est-il pris en charge dans les hubs virtuels sécurisés (vWAN) au Qatar ?

Non, le Pare-feu Azure dans les hubs virtuels sécurisés (vWAN) n’est actuellement pas pris en charge au Qatar.

Fonctionnalités et fonctionnalités prises en charge

Pare-feu Azure prend-il en charge le filtrage du trafic entrant ?

Oui, le Pare-feu Azure prend en charge le filtrage du trafic entrant et sortant. Le filtrage entrant est généralement utilisé pour les protocoles non HTTP tels que RDP, SSH et FTP. Pour le trafic HTTP entrant et HTTPS, envisagez d’utiliser un pare-feu d’applications web comme le pare-feu d’applications web Azure (WAF) ou les fonctionnalités d’inspection approfondie des paquets du Pare-feu Azure Premium.

Azure Firewall De base prend-il en charge le tunneling forcé ?

Oui, le Pare-feu Azure De base prend en charge le tunneling forcé.

Pourquoi un test ping TCP ou un outil similaire semble-t-il se connecter à un nom de domaine complet cible, même quand aucune règle n’autorise le trafic ?

Un test ping TCP ne se connecte pas réellement au nom de domaine complet cible. Le Pare-feu Azure bloque les connexions à n’importe quelle adresse IP cible ou nom de domaine complet, sauf si une règle est explicitement autorisée.

Dans le cas d’un test ping TCP, si aucune règle n’autorise le trafic, le pare-feu lui-même répond à la requête ping TCP du client. Cette réponse n’atteint pas l’adresse IP cible ou le nom de domaine complet et n’est pas journalisée. Si une règle réseau autorise explicitement l’accès à l’adresse IP cible ou au nom de domaine complet, la requête ping atteint le serveur cible et sa réponse est relayée au client. Cet événement est consigné dans le journal des règles de réseau.

Le Pare-feu Azure prend-il en charge le peering BGP ?

Non, le Pare-feu Azure ne prend pas en charge le peering BGP en mode natif. Toutefois, la fonctionnalité d’itinéraires SNAT Autolearn utilise indirectement BGP via Azure Route Server.

Gestion et configuration

Comment arrêter et démarrer le Pare-feu Azure ?

Vous pouvez utiliser Azure PowerShell pour libérer et allouer le Pare-feu Azure. Le processus varie en fonction de la configuration.

Pour un pare-feu sans carte réseau de gestion :

# Stop the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw

# Start the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
$publicip1 = Get-AzPublicIpAddress -Name "Public IP1 Name" -ResourceGroupName "RG Name"
$publicip2 = Get-AzPublicIpAddress -Name "Public IP2 Name" -ResourceGroupName "RG Name"
$azfw.Allocate($vnet, @($publicip1, $publicip2))
Set-AzFirewall -AzureFirewall $azfw

Pour un pare-feu avec une carte réseau de gestion :

# Stop the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw

# Start the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
$pip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "azfwpublicip"
$mgmtPip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "mgmtpip"
$azfw.Allocate($vnet, $pip, $mgmtPip)
Set-AzFirewall -AzureFirewall $azfw

Pour un pare-feu dans un hub virtuel sécurisé :

# Stop the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw

# Start the firewall
$virtualhub = Get-AzVirtualHub -ResourceGroupName "vHUB RG Name" -Name "vHUB Name"
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "Firewall RG Name"
$azfw.Allocate($virtualhub.Id)
Set-AzFirewall -AzureFirewall $azfw

Notes

Lors de l’arrêt et du démarrage du pare-feu, la facturation s’arrête et démarre en conséquence. Toutefois, l’adresse IP privée peut changer, ce qui peut affecter la connectivité si les tables de routage sont configurées.

Comment configurer des zones de disponibilité après le déploiement ?

Il est recommandé de configurer des zones de disponibilité pendant le déploiement initial. Toutefois, vous pouvez les reconfigurer après le déploiement si :

• Le pare-feu est déployé dans un réseau virtuel (non pris en charge dans les hubs virtuels sécurisés).
• La région prend en charge les zones de disponibilité.
• Toutes les adresses IP publiques attachées sont configurées avec les mêmes zones.

Pour reconfigurer les zones de disponibilité :

1. Libérer le pare-feu :

   $azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
   $azfw.Deallocate()
   Set-AzFirewall -AzureFirewall $azfw
   

2. Mettez à jour la configuration de la zone et allouez le pare-feu :

   $azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
   $vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
   $pip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "azfwpublicip"
   $mgmtPip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "mgmtpip"
   $azfw.Allocate($vnet, $pip, $mgmtPip)
   $azfw.Zones = 1, 2, 3
   Set-AzFirewall -AzureFirewall $azfw
   

Existe-t-il des restrictions de groupe de ressources de pare-feu Azure ?

Oui:

• Le Pare-feu Azure et le réseau virtuel doivent se trouver dans le même groupe de ressources.
• L’adresse IP publique peut se trouver dans un autre groupe de ressources.
• Toutes les ressources (pare-feu Azure, réseau virtuel, adresse IP publique) doivent se trouver dans le même abonnement.

Que signifie l’état d’approvisionnement **Échec** ?

Un état d’approvisionnement ayant échoué indique qu’une mise à jour de configuration a échoué sur une ou plusieurs instances principales. Le Pare-feu Azure reste opérationnel, mais la configuration peut être incohérente. Réessayez la mise à jour jusqu’à ce que l’état d’approvisionnement passe à Réussi.

Comment le pare-feu Azure gère la maintenance planifiée et les défaillances non planifiées ?

Le Pare-feu Azure utilise une configuration active-active avec plusieurs nœuds principaux. Pendant la maintenance planifiée, le drainage des connexions garantit des mises à jour normales. Pour les défaillances non planifiées, un nouveau nœud remplace l’échec, et la connectivité est généralement restaurée dans les 10 secondes.

Une limite de caractères s'applique-t-elle aux noms des pare-feu ?

Oui, les noms de pare-feu sont limités à 50 caractères.

Pourquoi le service Pare-feu Azure impose-t-il une taille de sous-réseau de /26 ?

Un sous-réseau /26 garantit des adresses IP suffisantes pour la mise à l’échelle, car le Pare-feu Azure provisionne des instances de machines virtuelles supplémentaires.

La taille du sous-réseau du pare-feu doit-elle changer au fil de la mise à l'échelle du service ?

Non, un sous-réseau /26 est suffisant pour tous les scénarios de mise à l’échelle.

Comment puis-je augmenter le débit de mon pare-feu ?

Le pare-feu Azure est mis à l’échelle automatiquement en fonction de l’utilisation du processeur, du débit et du nombre de connexions. La capacité de débit varie de 2,5 à 3 Gbits/s initialement à 30 Gbits/s (référence SKU Standard) ou 100 Gbits/s (référence SKU Premium).

Le nombre d’adresses IP prises en charge par les groupes IP est-il limité ?

Oui. Pour plus d’informations, consultez les limites, quotas et contraintes d’abonnement Azure et de service.

Puis-je déplacer un groupe IP vers un autre groupe de ressources ?

Non, le déplacement d’un groupe IP vers un autre groupe de ressources n’est pas pris en charge actuellement.

Quel est le délai d’inactivité TCP pour le pare-feu Azure ?

Le comportement standard d’un pare-feu réseau consiste à garantir que les connexions TCP restent actives et à les fermer rapidement en l’absence d’activité. Le délai d’inactivité TCP du pare-feu Azure est de quatre minutes. Ce paramètre n’est pas configurable par l’utilisateur, mais vous pouvez contacter le Support Azure pour augmenter le délai d’inactivité des connexions entrantes et sortantes jusqu’à 15 minutes. Le délai d’inactivité du trafic est-ouest ne peut pas être changé.

Si une période d’inactivité est supérieure à la valeur de délai d’expiration, le maintien de la session TCP ou HTTP n’est pas garanti. Une pratique courante consiste à utiliser TCP keep-alive. Cela permet de maintenir la connexion active pendant une période plus longue. Pour plus d’informations, consultez ces exemples .NET.

Puis-je déployer un pare-feu Azure sans adresse IP publique ?

Oui, mais vous devez configurer le pare-feu en mode Tunneling forcé. Cette configuration crée une interface de gestion avec une adresse IP publique utilisée par Pare-feu Azure pour ses opérations. Cette adresse IP publique est destinée au trafic de gestion. Il est utilisé exclusivement par la plateforme Azure et ne peut être utilisé à aucune autre fin. Le réseau de chemin d’accès aux données du locataire peut être configuré sans adresse IP publique et le trafic Internet peut être transféré en mode Tunnel forcé vers un autre pare-feu ou être complètement bloqué.

Existe-t-il un moyen de sauvegarder automatiquement le Pare-feu Azure et ses stratégies ?

Oui. Pour plus d’informations, consultez Sauvegarder le Pare-feu Azure et la Stratégie de pare-feu Azure avec Logic Apps.

Connectivité et routage

Comment faire pour configurer Pare-feu Azure avec mes points de terminaison de service ?

Pour bénéficier d’un accès sécurisé aux services PaaS, nous vous recommandons des points de terminaison de service. Vous pouvez choisir d’activer des points de terminaison de service dans le sous-réseau de Pare-feu Azure et les désactiver dans les réseaux virtuels spoke connectés. De cette façon, vous bénéficiez des deux fonctionnalités : sécurité de point de terminaison de service et journalisation centralisée pour tout le trafic.

Dans un réseau virtuel de hub, le pare-feu Azure peut-il envoyer et filtrer le trafic réseau entre plusieurs réseaux virtuels spoke ?

Oui, vous pouvez utiliser le pare-feu Azure dans un réseau virtuel de hub pour acheminer et filtrer le trafic entre plusieurs réseaux virtuels spoke. Afin de fonctionner correctement, les sous-réseaux de chaque réseau virtuel spoke doivent disposer d’un UDR pointant vers Pare-feu Azure en tant que passerelle par défaut pour ce scénario.

Pare-feu Azure peut-il envoyer et filtrer le trafic réseau entre des sous-réseaux d’un même réseau virtuel ou réseau virtuel appairé ?

Oui. Toutefois, la configuration des UDR pour rediriger le trafic entre les sous-réseaux du même réseau virtuel nécessite davantage d’attention. Tout en utilisant la plage d’adresses de réseau virtuel comme préfixe cible pour l’UDR est suffisant, cela achemine également tout le trafic d’une machine à un autre dans le même sous-réseau via l’instance du Pare-feu Azure. Pour éviter cela, incluez un itinéraire pour le sous-réseau dans l’UDR avec un type de tronçon suivant de réseau virtuel. La gestion de ces itinéraires peut être lourde et sujette à erreur. La méthode recommandée pour la segmentation interne du réseau consiste à utiliser des groupes de sécurité réseau, qui ne requièrent pas d’UDR.

La sortie de Pare-feu Azure traduit-elle l’adresse réseau source (SNAT) entre réseaux privés ?

Pare-feu Azure ne traduit pas l’adresse réseau source lorsque l’adresse IP de destination est une plage d’adresses IP privées selon la norme IANA RFC 1918 ou IANA RFC 6598 pour les réseaux privés. Si votre organisation utilise une plage d’adresses IP publiques pour les réseaux privés, Pare-feu Azure traduit l’adresse réseau source du trafic en une des adresses IP privées du pare-feu dans AzureFirewallSubnet. Vous pouvez configurer le pare-feu Azure pour ne pas traduire l’adresse réseau source (SNAT) de votre plage d’adresses IP publiques. Pour plus d’informations, consultez Plages d’adresses IP privées SNAT du Pare-feu Azure.

En outre, le trafic traité par les règles d’application fait toujours l’objet d’une SNAT. Si vous souhaitez voir l’adresse IP source d’origine dans vos journaux pour le trafic FQDN, vous pouvez utiliser des règles de réseau avec le FQDN de destination.

Le tunneling/chaînage forcé à une appliance virtuelle réseau est-il pris en charge ?

Le tunneling forcé est pris en charge lorsque vous créez un nouveau pare-feu. Vous ne pouvez pas configurer un pare-feu existant pour le tunneling forcé. Pour plus d’informations, consultez la page Tunneling forcé du Pare-feu Azure.

Le Pare-feu Azure doit avoir une connectivité Internet directe. Si votre AzureFirewallSubnet prend connaissance d’un itinéraire par défaut pour votre réseau local via le protocole BGP, vous devez le remplacer par un UDR 0.0.0.0/0 avec la valeur NextHopType définie sur Internet pour garantir une connectivité Internet directe.

Si votre configuration nécessite un tunneling forcé vers un réseau local et que vous pouvez déterminer les préfixes IP cibles pour vos destinations Internet, vous pouvez configurer ces plages en faisant du réseau local le tronçon suivant avec une route définie par l’utilisateur sur le sous-réseau AzureFirewallSubnet. Vous pouvez aussi utiliser le protocole BGP pour définir ces routes.

Comment les caractères génériques fonctionnent-ils dans les URL et FQDN cibles dans les règles d’application ?

• URL : un astérisque fonctionne quand il est placé sur le côté le plus à droite ou le plus à gauche. S’il est à gauche, il ne peut pas faire partie du FQDN.
• FQDN : un astérisque fonctionne quand il est placé sur le côté le plus à gauche.
• GÉNÉRAL – Les astérisques à l'extrême gauche signifient littéralement tout ce qui correspond à la gauche, ce qui signifie que plusieurs sous-domaines et/ou variantes de nom de domaine potentiellement indésirables correspondent – voir les exemples suivants.

Exemples :

Catégorie	Règle	Pris en charge ?	Exemples positifs
TargetURL	www.contoso.com	Oui	www.contoso.com www.contoso.com/
TargetURL	*.contoso.com	Oui	any.contoso.com/ sub1.any.contoso.com
TargetURL	*contoso.com	Oui	example.anycontoso.com sub1.example.contoso.com contoso.com Avertissement : Cette utilisation du caractère générique autorise également des variantes potentiellement indésirables/risquées telles que th3re4lcontoso.com. Agissez donc avec précaution.
TargetURL	www.contoso.com/test	Oui	www.contoso.com/test www.contoso.com/test/ www.contoso.com/test?with_query=1
TargetURL	www.contoso.com/test/*	Oui	www.contoso.com/test/anything Remarque : www.contoso.com/testne correspond pas (dernière barre oblique)
TargetURL	www.contoso.*/test/*	Non
TargetURL	www.contoso.com/test?example=1	Non
TargetURL	www.contoso.*	Non
TargetURL	www.*contoso.com	Non
TargetURL	www.contoso.com:8080	Non
TargetURL	*.contoso.*	Non
TargetFQDN	www.contoso.com	Oui	www.contoso.com
TargetFQDN	*.contoso.com	Oui	any.contoso.com Remarque : Si vous voulez autoriser spécifiquement contoso.com, vous devez inclure contoso.com dans la règle. Sinon, la connexion est supprimée par défaut, car la requête ne correspond à aucune règle.
TargetFQDN	*contoso.com	Oui	example.anycontoso.com contoso.com
TargetFQDN	www.contoso.*	Non
TargetFQDN	*.contoso.*	Non

Le Pare-feu Azure autorise-t-il l’accès à Active Directory par défaut ?

Non. Le Pare-feu Azure bloque l’accès à Active Directory par défaut. Pour autoriser l’accès, configurez l’étiquette du service Azure Active Directory. Pour plus d’informations, consultez Étiquettes du service Pare-feu Azure.

Puis-je exclure un nom de domaine complet (FSDN) ou une adresse IP du filtrage basé sur les renseignements sur les menaces du Pare-feu Azure ?

Oui, vous pouvez utiliser Azure PowerShell pour le faire :

# Add a Threat Intelligence allowlist to an Existing Azure Firewall.

# Create the allowlist with both FQDN and IPAddresses
$fw = Get-AzFirewall -Name "Name_of_Firewall" -ResourceGroupName "Name_of_ResourceGroup"
$fw.ThreatIntelWhitelist = New-AzFirewallThreatIntelWhitelist `
   -FQDN @("fqdn1", "fqdn2", …) -IpAddress @("ip1", "ip2", …)

# Or Update FQDNs and IpAddresses separately
$fw = Get-AzFirewall -Name $firewallname -ResourceGroupName $RG
$fw.ThreatIntelWhitelist.IpAddresses = @($fw.ThreatIntelWhitelist.IpAddresses + $ipaddresses)
$fw.ThreatIntelWhitelist.fqdns = @($fw.ThreatIntelWhitelist.fqdns + $fqdns)


Set-AzFirewall -AzureFirewall $fw

Pourquoi un test Ping TCP et des outils similaires peuvent-ils se connecter à un nom de domaine complet cible même si aucune règle n’autorise ce trafic sur le Pare-feu Azure ?

Un test Ping TCP ne se connecte pas réellement au nom de domaine complet cible. Le Pare-feu Azure n’autorise aucune connexion à une adresse IP/un FQDN cible, sauf si une règle explicite l’autorise.

Le test ping TCP est un cas d’usage unique. Si aucune règle n’est autorisée, le Pare-feu répond à la requête ping TCP du client même si le test ping TCP n’atteint pas l’adresse IP ou le FQDN cible. Dans ce cas, l’événement n’est pas consigné. Si une règle réseau autorise l’accès à l’adresse IP ou au FQDN cible, alors la requête ping atteint le serveur cible et sa réponse est renvoyée au client. Cet événement est consigné dans le journal des règles de réseau.

Le nombre d’adresses IP prises en charge par les groupes IP est-il limité ?

Oui. Pour plus d’informations, consultez Abonnement Azure et limites, quotas et contraintes de service

Puis-je déplacer un groupe IP vers un autre groupe de ressources ?

Non, le déplacement d’un groupe IP vers un autre groupe de ressources n’est pas pris en charge actuellement.

Quel est le délai d’inactivité TCP pour le pare-feu Azure ?

Le comportement standard d’un pare-feu réseau consiste à garantir que les connexions TCP restent actives et à les fermer rapidement en l’absence d’activité. Le délai d’inactivité TCP du pare-feu Azure est de quatre minutes. Ce paramètre n’est pas configurable par l’utilisateur, mais vous pouvez contacter le Support Azure pour augmenter le délai d’inactivité des connexions entrantes et sortantes jusqu’à 15 minutes. Le délai d’inactivité du trafic est-ouest ne peut pas être changé.

Si une période d’inactivité est supérieure à la valeur de délai d’expiration, le maintien de la session TCP ou HTTP n’est pas garanti. Une pratique courante consiste à utiliser TCP keep-alive. Cela permet de maintenir la connexion active pendant une période plus longue. Pour plus d’informations, consultez ces exemples .NET.

Puis-je déployer un pare-feu Azure sans adresse IP publique ?

Oui, mais vous devez configurer le pare-feu en mode Tunneling forcé. Cette configuration crée une interface de gestion avec une adresse IP publique utilisée par Pare-feu Azure pour ses opérations. Cette adresse IP publique est destinée au trafic de gestion. Il est utilisé exclusivement par la plateforme Azure et ne peut être utilisé à aucune autre fin. Le réseau de chemin d’accès aux données du locataire peut être configuré sans adresse IP publique et le trafic Internet peut être transféré en mode Tunnel forcé vers un autre pare-feu ou être complètement bloqué.

Où le Pare-feu Azure stocke-t-il les données client ?

Le Pare-feu Azure ne déplace pas ni ne stocke les données client en dehors de la région dans laquelle il est déployé.

Existe-t-il un moyen de sauvegarder automatiquement le Pare-feu Azure et ses stratégies ?

Oui. Pour plus d’informations, consultez Sauvegarder le Pare-feu Azure et la Stratégie de pare-feu Azure avec Logic Apps.

Le Pare-feu Azure est-il pris en charge dans les hubs virtuels sécurisés (vWAN) au Qatar ?

Non, le Pare-feu Azure n’est actuellement pas pris en charge dans les hubs virtuels sécurisés (vWAN) au Qatar.

Combien de connexions parallèles peut prendre en charge Pare-feu Azure ?

Le Pare-feu Azure utilise les Machines virtuelles Azure sous-jacentes ayant un strict nombre limite de connexions. Chaque machine virtuelle compte 250 000 connexions actives au total.

La limite totale par pare-feu est la limite de connexion de chaque machine virtuelle (250 000) x le nombre de machines virtuelles dans le pool principal du pare-feu. Le Pare-feu Azure commence par deux machines virtuelles et effectue un scale-out selon l’utilisation du processeur et le débit.

Quel est le comportement de réutilisation des ports SNAT TCP/UDP dans le Pare-feu Azure ?

Le Pare-feu Azure utilise actuellement des ports sources TCP/UDP pour le trafic SNAT sortant, sans temps d'attente d'inactivité. Lorsqu'une connexion TCP/UDP est fermée, le port TCP utilisé est immédiatement considéré comme disponible pour les connexions à venir.

Comme solution de contournement pour certaines architectures, vous pouvez déployer et mettre à l'échelle avec la passerelle NAT avec le pare-feu Azure pour fournir un pool plus large de ports SNAT pour plus de variabilité et de disponibilité.

Que sont les comportements NAT dans le Pare-feu Azure ?

Les comportements NAT spécifiques dépendent de la configuration du pare-feu et du type de NAT configuré. Par exemple, le pare-feu dispose de règles DNAT pour le trafic entrant, ainsi que de règles réseau et d’application pour le trafic sortant via le pare-feu.

Pour plus d’informations, consultez Comportements NAT du Pare-feu Azure.

Délais d’expiration et mise à l’échelle

Comment fonctionne ce drainage des connexions ?

Pour toute activité de maintenance planifiée, la logique de drainage des connexions met à jour les nœuds principaux de manière appropriée. Pare-feu Azure attend 90 secondes que les connexions existantes se ferment. Pendant les 45 premières secondes, le nœud back-end n’accepte pas de nouvelles connexions et, pendant le temps restant, il répond par RST à tous les paquets entrants. Si nécessaire, les clients peuvent automatiquement rétablir la connectivité à un autre nœud principal.

Comment le Pare-feu Azure gère-t-il les arrêts d’instance de machine virtuelle pendant le scale-in (scale-down) d’un groupe de machines virtuelles identiques ou les mises à niveau logicielles de la flotte ?

Un arrêt d’instance de machine virtuelle de Pare-feu Azure peut se produire pendant le scale-in (scale-down) d’un groupe de machines virtuelles identiques ou la mise à niveau logicielle de la flotte. Dans ce cas, les nouvelles connexions entrantes font l’objet d’un équilibrage de charge et sont acheminées vers les instances de pare-feu restantes au lieu d’être transférées à l’instance de pare-feu arrêtée. Après 45 secondes, le pare-feu commence à rejeter les connexions existantes en envoyant des paquets TCP RST. Au bout de 45 secondes supplémentaires, la machine virtuelle du pare-feu s’arrête. Pour plus d’informations, consultez Réinitialisation TCP de l’équilibreur de charge et délai d’inactivité.

Combien de temps le scale-out du Pare-feu Azure prend-il ?

Le Pare-feu Azure se met progressivement à l’échelle lorsque le débit moyen ou la consommation du processeur est de 60 %, ou que le nombre de connexions utilisées est de 80 %. Par exemple, il commence à effectuer un scale-out lorsqu’il atteint 60 % de son débit maximal. Les nombres de débit maximal varient en fonction de la référence SKU du Pare-feu Azure et des fonctionnalités activées. Pour plus d’informations, consultez Performances du Pare-feu Azure.

Cette opération prend de cinq à sept minutes. Lorsque vous testez les performances, veillez à tester au moins 10 à 15 minutes et à démarrer de nouvelles connexions pour tirer parti des nœuds de pare-feu Azure nouvellement créés.

Comment le Pare-feu Azure gère-t-il les délais d’inactivité ?

Quand une connexion est sujette à un délai d’inactivité (quatre minutes d’absence d’activité), le pare-feu Azure arrête la connexion proprement en envoyant un paquet TCP RST.

Maintenance contrôlée par le client

Quel type de maintenance prend-il en charge la maintenance contrôlée par le client ?

Les services Azure subissent des mises à jour de maintenance régulières pour améliorer les fonctionnalités, la fiabilité, les performances et la sécurité. Avec une période de maintenance configurée, la maintenance du système d’exploitation invité et la maintenance du service sont effectuées pendant cette fenêtre. Toutefois, la maintenance contrôlée par le client n’inclut pas les mises à jour de l’hôte ou les mises à jour de sécurité critiques.

Puis-je recevoir une notification avancée de l’événement de maintenance ?

Les notifications avancées pour la maintenance du Pare-feu Azure ne sont pas disponibles.

Puis-je configurer une fenêtre de maintenance inférieure à cinq heures ?

Non, une fenêtre de maintenance minimale de cinq heures est requise.

Puis-je configurer une fenêtre de maintenance autre qu’une planification quotidienne ?

Non, les fenêtres de maintenance sont actuellement configurées pour se répéter quotidiennement.

Existe-t-il des cas où je ne peux pas contrôler certaines mises à jour ?

La maintenance contrôlée par le client prend en charge les mises à jour du système d’exploitation invité et du service, qui comptent pour la plupart des éléments de maintenance qui concernent les clients. Toutefois, certaines mises à jour, telles que les mises à jour de l’hôte, sont en dehors de l’étendue de la maintenance contrôlée par le client. Dans de rares cas, nous pouvons remplacer votre contrôle de la fenêtre de maintenance pour résoudre les problèmes de sécurité de gravité élevée.

Les ressources de configuration de maintenance doivent-elles se trouver dans la même région que le Pare-feu Azure ?

Oui.

Pouvons-nous créer plusieurs configurations de maintenance pour un seul pare-feu Azure ?

Non. Actuellement, une seule configuration de maintenance peut être associée à un pare-feu Azure.

Quelles références SKU du Pare-feu Azure puis-je configurer pour utiliser la maintenance contrôlée par le client ?

Toutes les références SKU du Pare-feu Azure - De base, Standard et Premium prennent en charge la maintenance contrôlée par le client.

Combien de temps faut-il pour qu’une stratégie de configuration de maintenance devienne effective après son affectation au Pare-feu Azure ?

Le pare-feu Azure peut prendre jusqu’à 24 heures après que la stratégie de maintenance soit associée.

J’ai planifié une fenêtre de maintenance pour une date ultérieure pour l’une de mes ressources pare-feu Azure. Les activités de maintenance seront-elles suspendues sur cette ressource jusqu’à ce moment-là ?

Les activités de maintenance sur votre pare-feu Azure ne sont pas suspendues pendant la période précédant la fenêtre de maintenance planifiée. Pendant des jours qui ne sont pas inclus dans votre planification de maintenance, les opérations de maintenance régulières continuent comme d’habitude sur la ressource.

Comment en savoir plus sur la maintenance contrôlée par le client sur le Pare-feu Azure ?

Pour plus d’informations, consultez Configurer la maintenance contrôlée par le client.

Pare-feu Azure est un service de sécurité réseau informatique géré qui protège vos ressources Réseau virtuel Azure. Il s’agit d’un service de pare-feu entièrement avec état, pourvu d’une haute disponibilité intégrée et de l’extensibilité sans limites du cloud. Vous pouvez créer, appliquer et consigner des stratégies de connectivité réseau et d’application de façon centralisée entre les abonnements et les réseaux virtuels.

Pour obtenir la liste détaillée des fonctionnalités du Pare-feu Azure, consultez les fonctionnalités du Pare-feu Azure.

Le Pare-feu Azure peut être déployé sur n’importe quel réseau virtuel. Toutefois, il est généralement déployé sur un réseau virtuel central dans un modèle hub-and-spoke, avec d’autres réseaux virtuels appairés à celui-ci. L’itinéraire par défaut des réseaux virtuels appairés est défini pour pointer vers ce réseau virtuel de pare-feu central. Bien que le peering de réseaux virtuels globaux soit pris en charge, il n’est pas recommandé en raison de problèmes potentiels de performances et de latence entre les régions. Pour des performances optimales, déployez un pare-feu par région.

Ce modèle permet un contrôle centralisé sur plusieurs réseaux virtuels spoke sur différents abonnements et offre des économies en évitant la nécessité de déployer un pare-feu dans chaque réseau virtuel. Les économies de coûts doivent être évaluées par rapport aux coûts de peering associés en fonction des modèles de trafic.

Le Pare-feu Azure peut être déployé à l’aide du portail Azure, de PowerShell, de l’API REST ou des modèles. Pour obtenir des instructions pas à pas, consultez Tutoriel : Déployer et configurer le Pare-feu Azure à l’aide du portail Azure.

Le Pare-feu Azure utilise des règles et des regroupements de règles. Une collection de règles est un ensemble de règles avec le même ordre et la même priorité. Les collections de règles sont exécutées dans l’ordre de priorité. Les collections de règles DNAT ont une priorité plus élevée que les regroupements de règles réseau, qui à leur tour ont une priorité plus élevée que les regroupements de règles d’application. Toutes les règles se terminent.

Il existe trois types de regroupement de règles :

• Règles d’application : Configurez des noms de domaine complets (FQDN) accessibles à partir d’un réseau virtuel.
• Règles réseau : configurez des règles avec des adresses sources, des protocoles, des ports de destination et des adresses de destination.
• Règles NAT : Configurez les règles DNAT pour autoriser les connexions entrantes Internet ou intranet (preview).

Pour plus d’informations, consultez Configurer les règles du pare-feu Azure.

Le Pare-feu Azure s’intègre à Azure Monitor pour afficher et analyser les journaux. Les journaux peuvent être envoyés à Log Analytics, stockage Azure ou Event Hubs et analysés à l’aide d’outils tels que Log Analytics, Excel ou Power BI. Pour plus d’informations, consultez Didacticiel : Surveiller les journaux d’activité de pare-feu Azure.

Le Pare-feu Azure est un service de sécurité réseau managé basé sur le cloud qui protège les ressources de réseau virtuel. Il s’agit d’un service de pare-feu entièrement avec état, pourvu d’une haute disponibilité intégrée et de l’extensibilité sans limites du cloud. Il est préintégré avec des fournisseurs de sécurité en tant que service (SECaaS) tiers pour améliorer la sécurité des connexions Internet de réseau virtuel et de branche. Pour plus d’informations, voir Sécurité du réseau Azure.

Application Gateway WAF fournit une protection entrante centralisée pour les applications web contre les attaques et vulnérabilités courantes. Pare-feu Azure assure une protection en entrée pour les protocoles non-HTTP/S (par exemple, RDP, SSH et FTP), une protection en sortie au niveau du réseau pour tous les ports et protocoles, ainsi qu’une protection au niveau de l’application pour le trafic HTTP/S sortant.

Le Pare-feu Azure complète les groupes de sécurité réseau pour fournir une meilleure sécurité réseau « de défense en profondeur ». Les groupes de sécurité réseau offrent un filtrage de trafic de couche réseau distribué pour limiter le trafic au sein des réseaux virtuels de chaque abonnement. Le Pare-feu Azure fournit une protection centralisée, entièrement avec état et au niveau de l’application sur les abonnements et les réseaux virtuels.

Le Pare-feu Azure est un service géré avec plusieurs couches de protection, notamment la protection de la plateforme avec des groupes de sécurité réseau au niveau de la carte réseau (non visibles). Les groupes de sécurité réseau au niveau du sous-réseau ne sont pas obligatoires sur AzureFirewallSubnet et sont désactivés pour empêcher les interruptions de service.

Les points de terminaison privés sont un composant de Private Link, une technologie qui permet d’interagir avec les services PaaS Azure à l’aide d’adresses IP privées plutôt que publiques. Le Pare-feu Azure peut être utilisé pour empêcher l’accès aux adresses IP publiques, ce qui évite d’exfiltration de données aux services Azure ne tirant pas parti de Private Link, ainsi que pour implémenter des stratégies de confiance zéro en définissant qui dans votre organisation doit accéder à ces services PaaS Azure, car Private Link ouvre par défaut l’accès réseau pour l’ensemble de votre réseau d’entreprise.

La conception appropriée pour inspecter le trafic vers des points de terminaison privés avec le Pare-feu Azure dépend de votre architecture réseau, vous trouverez plus de détails dans l’article Scénarios de pare-feu Azure pour inspecter le trafic destiné à un point de terminaison privé.

Les points de terminaison de service de réseau virtuel sont une alternative à Private Link pour contrôler l’accès réseau aux services PaaS Azure. Même si le client utilise toujours des adresses IP publiques pour accéder au service PaaS, le sous-réseau source est rendu visible afin que le service PaaS de destination puisse implémenter des règles de filtre et restreindre l’accès par sous-réseau. Vous trouverez une comparaison détaillée entre les deux mécanismes dans Comparer les points de terminaison privés et les points de terminaison de service.

Les règles d’application du Pare-feu Azure peuvent être utilisées pour s’assurer qu’aucune exfiltration de données aux services non autorisés n’a lieu et pour implémenter des stratégies d’accès avec une granularité accrue au-delà du niveau du sous-réseau. En règle générale, les points de terminaison de service de réseau virtuel doivent être activés dans le sous-réseau du client qui se connectera à un service Azure. Toutefois, lors de l’inspection du trafic vers les points de terminaison de service avec le pare-feu Azure, vous devez activer le point de terminaison de service correspondant dans le sous-réseau du pare-feu Azure et les désactiver sur le sous-réseau du client réel (généralement un réseau virtuel spoke). De cette façon, vous pouvez utiliser des règles d’application dans le Pare-feu Azure pour contrôler les services Azure auxquels vos charges de travail Azure auront accès.

Pour plus d’informations sur la tarification, consultez Tarification du Pare-feu Azure.

Pour connaître les limites de service, consultez les limites, quotas et contraintes d’abonnement Azure et de service.

Le Pare-feu Azure ne déplace pas ou ne stocke pas les données client en dehors de la région où elle est déployée.

Non, le Pare-feu Azure dans les hubs virtuels sécurisés (vWAN) n’est actuellement pas pris en charge au Qatar.

Oui, le Pare-feu Azure prend en charge le filtrage du trafic entrant et sortant. Le filtrage entrant est généralement utilisé pour les protocoles non HTTP tels que RDP, SSH et FTP. Pour le trafic HTTP entrant et HTTPS, envisagez d’utiliser un pare-feu d’applications web comme le pare-feu d’applications web Azure (WAF) ou les fonctionnalités d’inspection approfondie des paquets du Pare-feu Azure Premium.

Oui, le Pare-feu Azure De base prend en charge le tunneling forcé.

Un test ping TCP ne se connecte pas réellement au nom de domaine complet cible. Le Pare-feu Azure bloque les connexions à n’importe quelle adresse IP cible ou nom de domaine complet, sauf si une règle est explicitement autorisée.

Dans le cas d’un test ping TCP, si aucune règle n’autorise le trafic, le pare-feu lui-même répond à la requête ping TCP du client. Cette réponse n’atteint pas l’adresse IP cible ou le nom de domaine complet et n’est pas journalisée. Si une règle réseau autorise explicitement l’accès à l’adresse IP cible ou au nom de domaine complet, la requête ping atteint le serveur cible et sa réponse est relayée au client. Cet événement est consigné dans le journal des règles de réseau.

Non, le Pare-feu Azure ne prend pas en charge le peering BGP en mode natif. Toutefois, la fonctionnalité d’itinéraires SNAT Autolearn utilise indirectement BGP via Azure Route Server.

Vous pouvez utiliser Azure PowerShell pour libérer et allouer le Pare-feu Azure. Le processus varie en fonction de la configuration.

Pour un pare-feu sans carte réseau de gestion :

# Stop the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw

# Start the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
$publicip1 = Get-AzPublicIpAddress -Name "Public IP1 Name" -ResourceGroupName "RG Name"
$publicip2 = Get-AzPublicIpAddress -Name "Public IP2 Name" -ResourceGroupName "RG Name"
$azfw.Allocate($vnet, @($publicip1, $publicip2))
Set-AzFirewall -AzureFirewall $azfw

Pour un pare-feu avec une carte réseau de gestion :

# Stop the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw

# Start the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
$pip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "azfwpublicip"
$mgmtPip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "mgmtpip"
$azfw.Allocate($vnet, $pip, $mgmtPip)
Set-AzFirewall -AzureFirewall $azfw

Pour un pare-feu dans un hub virtuel sécurisé :

# Stop the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw

# Start the firewall
$virtualhub = Get-AzVirtualHub -ResourceGroupName "vHUB RG Name" -Name "vHUB Name"
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "Firewall RG Name"
$azfw.Allocate($virtualhub.Id)
Set-AzFirewall -AzureFirewall $azfw

Notes

Lors de l’arrêt et du démarrage du pare-feu, la facturation s’arrête et démarre en conséquence. Toutefois, l’adresse IP privée peut changer, ce qui peut affecter la connectivité si les tables de routage sont configurées.

Il est recommandé de configurer des zones de disponibilité pendant le déploiement initial. Toutefois, vous pouvez les reconfigurer après le déploiement si :

• Le pare-feu est déployé dans un réseau virtuel (non pris en charge dans les hubs virtuels sécurisés).
• La région prend en charge les zones de disponibilité.
• Toutes les adresses IP publiques attachées sont configurées avec les mêmes zones.

Pour reconfigurer les zones de disponibilité :

1. Libérer le pare-feu :

   $azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
   $azfw.Deallocate()
   Set-AzFirewall -AzureFirewall $azfw
   

2. Mettez à jour la configuration de la zone et allouez le pare-feu :

   $azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
   $vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
   $pip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "azfwpublicip"
   $mgmtPip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "mgmtpip"
   $azfw.Allocate($vnet, $pip, $mgmtPip)
   $azfw.Zones = 1, 2, 3
   Set-AzFirewall -AzureFirewall $azfw
   

Oui:

• Le Pare-feu Azure et le réseau virtuel doivent se trouver dans le même groupe de ressources.
• L’adresse IP publique peut se trouver dans un autre groupe de ressources.
• Toutes les ressources (pare-feu Azure, réseau virtuel, adresse IP publique) doivent se trouver dans le même abonnement.

Un état d’approvisionnement ayant échoué indique qu’une mise à jour de configuration a échoué sur une ou plusieurs instances principales. Le Pare-feu Azure reste opérationnel, mais la configuration peut être incohérente. Réessayez la mise à jour jusqu’à ce que l’état d’approvisionnement passe à Réussi.

Le Pare-feu Azure utilise une configuration active-active avec plusieurs nœuds principaux. Pendant la maintenance planifiée, le drainage des connexions garantit des mises à jour normales. Pour les défaillances non planifiées, un nouveau nœud remplace l’échec, et la connectivité est généralement restaurée dans les 10 secondes.

Oui, les noms de pare-feu sont limités à 50 caractères.

Un sous-réseau /26 garantit des adresses IP suffisantes pour la mise à l’échelle, car le Pare-feu Azure provisionne des instances de machines virtuelles supplémentaires.

Non, un sous-réseau /26 est suffisant pour tous les scénarios de mise à l’échelle.

Le pare-feu Azure est mis à l’échelle automatiquement en fonction de l’utilisation du processeur, du débit et du nombre de connexions. La capacité de débit varie de 2,5 à 3 Gbits/s initialement à 30 Gbits/s (référence SKU Standard) ou 100 Gbits/s (référence SKU Premium).

Oui. Pour plus d’informations, consultez les limites, quotas et contraintes d’abonnement Azure et de service.

Non, le déplacement d’un groupe IP vers un autre groupe de ressources n’est pas pris en charge actuellement.

Le comportement standard d’un pare-feu réseau consiste à garantir que les connexions TCP restent actives et à les fermer rapidement en l’absence d’activité. Le délai d’inactivité TCP du pare-feu Azure est de quatre minutes. Ce paramètre n’est pas configurable par l’utilisateur, mais vous pouvez contacter le Support Azure pour augmenter le délai d’inactivité des connexions entrantes et sortantes jusqu’à 15 minutes. Le délai d’inactivité du trafic est-ouest ne peut pas être changé.

Si une période d’inactivité est supérieure à la valeur de délai d’expiration, le maintien de la session TCP ou HTTP n’est pas garanti. Une pratique courante consiste à utiliser TCP keep-alive. Cela permet de maintenir la connexion active pendant une période plus longue. Pour plus d’informations, consultez ces exemples .NET.

Oui, mais vous devez configurer le pare-feu en mode Tunneling forcé. Cette configuration crée une interface de gestion avec une adresse IP publique utilisée par Pare-feu Azure pour ses opérations. Cette adresse IP publique est destinée au trafic de gestion. Il est utilisé exclusivement par la plateforme Azure et ne peut être utilisé à aucune autre fin. Le réseau de chemin d’accès aux données du locataire peut être configuré sans adresse IP publique et le trafic Internet peut être transféré en mode Tunnel forcé vers un autre pare-feu ou être complètement bloqué.

Oui. Pour plus d’informations, consultez Sauvegarder le Pare-feu Azure et la Stratégie de pare-feu Azure avec Logic Apps.

Pour bénéficier d’un accès sécurisé aux services PaaS, nous vous recommandons des points de terminaison de service. Vous pouvez choisir d’activer des points de terminaison de service dans le sous-réseau de Pare-feu Azure et les désactiver dans les réseaux virtuels spoke connectés. De cette façon, vous bénéficiez des deux fonctionnalités : sécurité de point de terminaison de service et journalisation centralisée pour tout le trafic.

Oui, vous pouvez utiliser le pare-feu Azure dans un réseau virtuel de hub pour acheminer et filtrer le trafic entre plusieurs réseaux virtuels spoke. Afin de fonctionner correctement, les sous-réseaux de chaque réseau virtuel spoke doivent disposer d’un UDR pointant vers Pare-feu Azure en tant que passerelle par défaut pour ce scénario.

Oui. Toutefois, la configuration des UDR pour rediriger le trafic entre les sous-réseaux du même réseau virtuel nécessite davantage d’attention. Tout en utilisant la plage d’adresses de réseau virtuel comme préfixe cible pour l’UDR est suffisant, cela achemine également tout le trafic d’une machine à un autre dans le même sous-réseau via l’instance du Pare-feu Azure. Pour éviter cela, incluez un itinéraire pour le sous-réseau dans l’UDR avec un type de tronçon suivant de réseau virtuel. La gestion de ces itinéraires peut être lourde et sujette à erreur. La méthode recommandée pour la segmentation interne du réseau consiste à utiliser des groupes de sécurité réseau, qui ne requièrent pas d’UDR.

Pare-feu Azure ne traduit pas l’adresse réseau source lorsque l’adresse IP de destination est une plage d’adresses IP privées selon la norme IANA RFC 1918 ou IANA RFC 6598 pour les réseaux privés. Si votre organisation utilise une plage d’adresses IP publiques pour les réseaux privés, Pare-feu Azure traduit l’adresse réseau source du trafic en une des adresses IP privées du pare-feu dans AzureFirewallSubnet. Vous pouvez configurer le pare-feu Azure pour ne pas traduire l’adresse réseau source (SNAT) de votre plage d’adresses IP publiques. Pour plus d’informations, consultez Plages d’adresses IP privées SNAT du Pare-feu Azure.

En outre, le trafic traité par les règles d’application fait toujours l’objet d’une SNAT. Si vous souhaitez voir l’adresse IP source d’origine dans vos journaux pour le trafic FQDN, vous pouvez utiliser des règles de réseau avec le FQDN de destination.

Le tunneling forcé est pris en charge lorsque vous créez un nouveau pare-feu. Vous ne pouvez pas configurer un pare-feu existant pour le tunneling forcé. Pour plus d’informations, consultez la page Tunneling forcé du Pare-feu Azure.

Le Pare-feu Azure doit avoir une connectivité Internet directe. Si votre AzureFirewallSubnet prend connaissance d’un itinéraire par défaut pour votre réseau local via le protocole BGP, vous devez le remplacer par un UDR 0.0.0.0/0 avec la valeur NextHopType définie sur Internet pour garantir une connectivité Internet directe.

Si votre configuration nécessite un tunneling forcé vers un réseau local et que vous pouvez déterminer les préfixes IP cibles pour vos destinations Internet, vous pouvez configurer ces plages en faisant du réseau local le tronçon suivant avec une route définie par l’utilisateur sur le sous-réseau AzureFirewallSubnet. Vous pouvez aussi utiliser le protocole BGP pour définir ces routes.

• URL : un astérisque fonctionne quand il est placé sur le côté le plus à droite ou le plus à gauche. S’il est à gauche, il ne peut pas faire partie du FQDN.
• FQDN : un astérisque fonctionne quand il est placé sur le côté le plus à gauche.
• GÉNÉRAL – Les astérisques à l'extrême gauche signifient littéralement tout ce qui correspond à la gauche, ce qui signifie que plusieurs sous-domaines et/ou variantes de nom de domaine potentiellement indésirables correspondent – voir les exemples suivants.

Exemples :

Catégorie	Règle	Pris en charge ?	Exemples positifs
TargetURL	www.contoso.com	Oui	www.contoso.com www.contoso.com/
TargetURL	*.contoso.com	Oui	any.contoso.com/ sub1.any.contoso.com
TargetURL	*contoso.com	Oui	example.anycontoso.com sub1.example.contoso.com contoso.com Avertissement : Cette utilisation du caractère générique autorise également des variantes potentiellement indésirables/risquées telles que th3re4lcontoso.com. Agissez donc avec précaution.
TargetURL	www.contoso.com/test	Oui	www.contoso.com/test www.contoso.com/test/ www.contoso.com/test?with_query=1
TargetURL	www.contoso.com/test/*	Oui	www.contoso.com/test/anything Remarque : www.contoso.com/testne correspond pas (dernière barre oblique)
TargetURL	www.contoso.*/test/*	Non
TargetURL	www.contoso.com/test?example=1	Non
TargetURL	www.contoso.*	Non
TargetURL	www.*contoso.com	Non
TargetURL	www.contoso.com:8080	Non
TargetURL	*.contoso.*	Non
TargetFQDN	www.contoso.com	Oui	www.contoso.com
TargetFQDN	*.contoso.com	Oui	any.contoso.com Remarque : Si vous voulez autoriser spécifiquement contoso.com, vous devez inclure contoso.com dans la règle. Sinon, la connexion est supprimée par défaut, car la requête ne correspond à aucune règle.
TargetFQDN	*contoso.com	Oui	example.anycontoso.com contoso.com
TargetFQDN	www.contoso.*	Non
TargetFQDN	*.contoso.*	Non

Non. Le Pare-feu Azure bloque l’accès à Active Directory par défaut. Pour autoriser l’accès, configurez l’étiquette du service Azure Active Directory. Pour plus d’informations, consultez Étiquettes du service Pare-feu Azure.

Oui, vous pouvez utiliser Azure PowerShell pour le faire :

# Add a Threat Intelligence allowlist to an Existing Azure Firewall.

# Create the allowlist with both FQDN and IPAddresses
$fw = Get-AzFirewall -Name "Name_of_Firewall" -ResourceGroupName "Name_of_ResourceGroup"
$fw.ThreatIntelWhitelist = New-AzFirewallThreatIntelWhitelist `
   -FQDN @("fqdn1", "fqdn2", …) -IpAddress @("ip1", "ip2", …)

# Or Update FQDNs and IpAddresses separately
$fw = Get-AzFirewall -Name $firewallname -ResourceGroupName $RG
$fw.ThreatIntelWhitelist.IpAddresses = @($fw.ThreatIntelWhitelist.IpAddresses + $ipaddresses)
$fw.ThreatIntelWhitelist.fqdns = @($fw.ThreatIntelWhitelist.fqdns + $fqdns)


Set-AzFirewall -AzureFirewall $fw

Un test Ping TCP ne se connecte pas réellement au nom de domaine complet cible. Le Pare-feu Azure n’autorise aucune connexion à une adresse IP/un FQDN cible, sauf si une règle explicite l’autorise.

Le test ping TCP est un cas d’usage unique. Si aucune règle n’est autorisée, le Pare-feu répond à la requête ping TCP du client même si le test ping TCP n’atteint pas l’adresse IP ou le FQDN cible. Dans ce cas, l’événement n’est pas consigné. Si une règle réseau autorise l’accès à l’adresse IP ou au FQDN cible, alors la requête ping atteint le serveur cible et sa réponse est renvoyée au client. Cet événement est consigné dans le journal des règles de réseau.

Oui. Pour plus d’informations, consultez Abonnement Azure et limites, quotas et contraintes de service

Non, le déplacement d’un groupe IP vers un autre groupe de ressources n’est pas pris en charge actuellement.

Le comportement standard d’un pare-feu réseau consiste à garantir que les connexions TCP restent actives et à les fermer rapidement en l’absence d’activité. Le délai d’inactivité TCP du pare-feu Azure est de quatre minutes. Ce paramètre n’est pas configurable par l’utilisateur, mais vous pouvez contacter le Support Azure pour augmenter le délai d’inactivité des connexions entrantes et sortantes jusqu’à 15 minutes. Le délai d’inactivité du trafic est-ouest ne peut pas être changé.

Si une période d’inactivité est supérieure à la valeur de délai d’expiration, le maintien de la session TCP ou HTTP n’est pas garanti. Une pratique courante consiste à utiliser TCP keep-alive. Cela permet de maintenir la connexion active pendant une période plus longue. Pour plus d’informations, consultez ces exemples .NET.

Oui, mais vous devez configurer le pare-feu en mode Tunneling forcé. Cette configuration crée une interface de gestion avec une adresse IP publique utilisée par Pare-feu Azure pour ses opérations. Cette adresse IP publique est destinée au trafic de gestion. Il est utilisé exclusivement par la plateforme Azure et ne peut être utilisé à aucune autre fin. Le réseau de chemin d’accès aux données du locataire peut être configuré sans adresse IP publique et le trafic Internet peut être transféré en mode Tunnel forcé vers un autre pare-feu ou être complètement bloqué.

Le Pare-feu Azure ne déplace pas ni ne stocke les données client en dehors de la région dans laquelle il est déployé.

Oui. Pour plus d’informations, consultez Sauvegarder le Pare-feu Azure et la Stratégie de pare-feu Azure avec Logic Apps.

Non, le Pare-feu Azure n’est actuellement pas pris en charge dans les hubs virtuels sécurisés (vWAN) au Qatar.

Le Pare-feu Azure utilise les Machines virtuelles Azure sous-jacentes ayant un strict nombre limite de connexions. Chaque machine virtuelle compte 250 000 connexions actives au total.

La limite totale par pare-feu est la limite de connexion de chaque machine virtuelle (250 000) x le nombre de machines virtuelles dans le pool principal du pare-feu. Le Pare-feu Azure commence par deux machines virtuelles et effectue un scale-out selon l’utilisation du processeur et le débit.

Le Pare-feu Azure utilise actuellement des ports sources TCP/UDP pour le trafic SNAT sortant, sans temps d'attente d'inactivité. Lorsqu'une connexion TCP/UDP est fermée, le port TCP utilisé est immédiatement considéré comme disponible pour les connexions à venir.

Comme solution de contournement pour certaines architectures, vous pouvez déployer et mettre à l'échelle avec la passerelle NAT avec le pare-feu Azure pour fournir un pool plus large de ports SNAT pour plus de variabilité et de disponibilité.

Les comportements NAT spécifiques dépendent de la configuration du pare-feu et du type de NAT configuré. Par exemple, le pare-feu dispose de règles DNAT pour le trafic entrant, ainsi que de règles réseau et d’application pour le trafic sortant via le pare-feu.

Pour plus d’informations, consultez Comportements NAT du Pare-feu Azure.

Pour toute activité de maintenance planifiée, la logique de drainage des connexions met à jour les nœuds principaux de manière appropriée. Pare-feu Azure attend 90 secondes que les connexions existantes se ferment. Pendant les 45 premières secondes, le nœud back-end n’accepte pas de nouvelles connexions et, pendant le temps restant, il répond par RST à tous les paquets entrants. Si nécessaire, les clients peuvent automatiquement rétablir la connectivité à un autre nœud principal.

Un arrêt d’instance de machine virtuelle de Pare-feu Azure peut se produire pendant le scale-in (scale-down) d’un groupe de machines virtuelles identiques ou la mise à niveau logicielle de la flotte. Dans ce cas, les nouvelles connexions entrantes font l’objet d’un équilibrage de charge et sont acheminées vers les instances de pare-feu restantes au lieu d’être transférées à l’instance de pare-feu arrêtée. Après 45 secondes, le pare-feu commence à rejeter les connexions existantes en envoyant des paquets TCP RST. Au bout de 45 secondes supplémentaires, la machine virtuelle du pare-feu s’arrête. Pour plus d’informations, consultez Réinitialisation TCP de l’équilibreur de charge et délai d’inactivité.

Le Pare-feu Azure se met progressivement à l’échelle lorsque le débit moyen ou la consommation du processeur est de 60 %, ou que le nombre de connexions utilisées est de 80 %. Par exemple, il commence à effectuer un scale-out lorsqu’il atteint 60 % de son débit maximal. Les nombres de débit maximal varient en fonction de la référence SKU du Pare-feu Azure et des fonctionnalités activées. Pour plus d’informations, consultez Performances du Pare-feu Azure.

Cette opération prend de cinq à sept minutes. Lorsque vous testez les performances, veillez à tester au moins 10 à 15 minutes et à démarrer de nouvelles connexions pour tirer parti des nœuds de pare-feu Azure nouvellement créés.

Quand une connexion est sujette à un délai d’inactivité (quatre minutes d’absence d’activité), le pare-feu Azure arrête la connexion proprement en envoyant un paquet TCP RST.

Les services Azure subissent des mises à jour de maintenance régulières pour améliorer les fonctionnalités, la fiabilité, les performances et la sécurité. Avec une période de maintenance configurée, la maintenance du système d’exploitation invité et la maintenance du service sont effectuées pendant cette fenêtre. Toutefois, la maintenance contrôlée par le client n’inclut pas les mises à jour de l’hôte ou les mises à jour de sécurité critiques.

Les notifications avancées pour la maintenance du Pare-feu Azure ne sont pas disponibles.

Non, une fenêtre de maintenance minimale de cinq heures est requise.

Non, les fenêtres de maintenance sont actuellement configurées pour se répéter quotidiennement.

La maintenance contrôlée par le client prend en charge les mises à jour du système d’exploitation invité et du service, qui comptent pour la plupart des éléments de maintenance qui concernent les clients. Toutefois, certaines mises à jour, telles que les mises à jour de l’hôte, sont en dehors de l’étendue de la maintenance contrôlée par le client. Dans de rares cas, nous pouvons remplacer votre contrôle de la fenêtre de maintenance pour résoudre les problèmes de sécurité de gravité élevée.

Oui.

Non. Actuellement, une seule configuration de maintenance peut être associée à un pare-feu Azure.

Toutes les références SKU du Pare-feu Azure - De base, Standard et Premium prennent en charge la maintenance contrôlée par le client.

Le pare-feu Azure peut prendre jusqu’à 24 heures après que la stratégie de maintenance soit associée.

Les activités de maintenance sur votre pare-feu Azure ne sont pas suspendues pendant la période précédant la fenêtre de maintenance planifiée. Pendant des jours qui ne sont pas inclus dans votre planification de maintenance, les opérations de maintenance régulières continuent comme d’habitude sur la ressource.

Pour plus d’informations, consultez Configurer la maintenance contrôlée par le client.