FAQ sur Azure Firewall

Azure Firewall est un service de sécurité réseau managé basé sur le cloud qui protège vos ressources Azure Virtual Network. 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 Azure Firewall, consultez Azure Firewall fonctionnalités.

Azure Firewall pouvez ê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. 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 l’appairage 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 dans 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.

Azure Firewall pouvez ê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 Tutorial : Déployer et configurer des Azure Firewall à l’aide du portail Azure.

Azure Firewall 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 ont un caractère terminatif.

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 des règles DNAT pour autoriser les connexions Internet ou intranet entrantes (préversion).

Pour plus d’informations, consultez Configuration des règles d'Azure Firewall.

Azure Firewall s’intègre à Azure Monitor pour afficher et analyser les logs. Les journaux peuvent être envoyés à Log Analytics, Azure Storage ou Event Hubs et analysés à l’aide d’outils tels que Log Analytics, Excel ou Power BI. Pour plus d’informations, consultez Tutorial : Monitor Azure Firewall logs.

Azure Firewall 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 tiers de sécurité en tant que service (SECaaS) pour améliorer la sécurité des connexions Internet de réseaux virtuels et de liaisons de branche. Pour plus d’informations, consultez Azure sécurité réseau.

Application Gateway WAF fournit une protection entrante centralisée pour les applications web contre les attaques et vulnérabilités courantes. Azure Firewall fournit une protection entrante pour les protocoles non HTTP/S (par exemple, RDP, SSH, FTP), la protection au niveau du réseau sortant pour tous les ports et protocoles et la protection au niveau de l’application pour le http/S sortant.

Azure Firewall 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 assurent un filtrage du trafic distribué au niveau de la couche réseau pour limiter le trafic au sein des réseaux virtuels de chaque abonnement. Le Pare-feu Azure offre une protection centralisée, entièrement avec état et au niveau de l’application, pour les abonnements et les réseaux virtuels.

Azure Firewall est un service géré avec plusieurs couches de protection, y compris la protection de la plateforme avec des NSG au niveau de l'interface 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 Azure services PaaS à l’aide d’adresses IP privées au lieu de celles publiques. Azure Firewall peut être utilisé pour empêcher l’accès aux adresses IP publiques, par conséquent, éviter l’exfiltration des données vers les services Azure ne tirant pas parti de Private Link, ainsi que pour implémenter des stratégies de confiance zéro afin de définir qui, dans votre organisation, doit accéder à ces services Azure PaaS, depuis que Private Link ouvre par défaut l’accès réseau à l’ensemble de votre réseau d’entreprise.

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

Virtual Network points de terminaison de service constituent 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.

Azure Firewall règles d’application peuvent être utilisées pour vous 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 de 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 Azure Firewall, vous devez activer le point de terminaison de service correspondant dans le sous-réseau Azure Firewall à la place 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 Azure Firewall pour contrôler les Azure services auxquels vos charges de travail Azure auront accès.

Pour plus d’informations sur la tarification, consultez Azure Firewall Tarification.

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

Azure Firewall 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, Azure Firewall dans les hubs virtuels sécurisés (vWAN) n'est actuellement pas pris en charge au Qatar.

Oui, Azure Firewall 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 et HTTPS entrant, envisagez d’utiliser un pare-feu d’applications web comme Azure Web Application Firewall (WAF) ou les fonctionnalités d’inspection approfondie des paquets de Azure Firewall Premium.

Oui, Azure Firewall Basic prend en charge le tunneling forcé.

Un test Ping TCP ne se connecte pas réellement au nom de domaine complet cible. Azure Firewall bloque les connexions à n’importe quelle adresse IP cible ou nom de domaine complet, sauf autorisation explicite d’une règle.

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, Azure Firewall 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.

Azure Firewall ne prend pas en charge en mode natif ESP (Encapsulating Security Payload), mais vous pouvez autoriser le trafic ESP en configurant une règle de réseau comme suit :

configuration Azure Firewall (règle réseau) :

• Protocole : n’importe quel
• Port source : * (Aucun)
• Port de destination : * (Tout)
• Source/Destination : spécifiez les adresses IP selon les besoins

Cette configuration permet aux paquets ESP (numéro de protocole IP 50) et au trafic non TCP/UDP de correspondre à la règle. Toutefois, notez que Azure Firewall n’inspecte pas les charges utiles ESP.

Reference : si vous utilisez un groupe de sécurité réseau (NSG) au lieu de Azure Firewall : NSG ne fournit pas d’option directe pour spécifier ESP (numéro de protocole IP 50), mais les paquets ESP peuvent être autorisés à l’aide des paramètres suivants :

• Protocole : n’importe quel
• Port : * (Any)
• Source/Destination : spécifiez les adresses IP selon les besoins

Recommendations:

• Pour les configurations VPN IPsec, l’utilisation de Azure VPN Gateway est recommandée.
• Envisagez d’utiliser un modèle NVA (Appliance virtuelle réseau) en fonction de vos besoins.

Vous pouvez utiliser Azure PowerShell pour libérer et allouer le Azure Firewall. 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

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 Azure Firewall 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 (Azure pare-feu, 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. La Azure Firewall reste opérationnelle, mais la configuration peut être incohérente. Réessayez la mise à jour jusqu’à ce que l’état d’approvisionnement passe à Réussi.

Azure Firewall utilise une configuration active-active avec plusieurs nœuds principaux. Pendant la maintenance planifiée, le drainage de connexion 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 la Azure Firewall 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.

Azure Firewall s’adapte 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 Azure les limites d’abonnement et de service, les quotas et les contraintes.

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é. Azure Firewall délai d’inactivité TCP est de quatre minutes. Ce paramètre n'est pas configurable par l'utilisateur, mais vous pouvez contacter Azure support 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 les 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 Azure Firewall 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 pas être utilisé à d'autres fins. 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 Backup Azure Firewall et Azure Firewall Policy 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 les points de terminaison de service dans le sous-réseau Azure Firewall et de les désactiver sur 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 Pare-feu Azure dans un réseau virtuel de hub pour acheminer et filtrer le trafic entre plusieurs réseaux virtuels spoke. Les sous-réseaux de chacun des réseaux virtuels spoke doivent disposer d’un UDR pointant vers l’Azure Firewall comme passerelle par défaut pour que ce scénario fonctionne correctement.

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. Bien que l’utilisation de la plage d’adresses de réseau virtuel comme préfixe cible pour l’UDR soit suffisante, cela achemine également tout le trafic d’une machine à une autre dans le même sous-réseau via Azure Firewall. Pour éviter cela, ajoutez une route pour le sous-réseau dans l’UDR avec un type de tronçon suivant défini sur 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.

Azure Firewall ne fait pas de SNAT lorsque l'adresse IP de destination appartient à une plage d'adresses IP privées selon 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, Azure Firewall SNATs le trafic vers l’une des adresses IP privées du pare-feu dans AzureFirewallSubnet. Vous pouvez configurer Azure Firewall pour ne pas faire de SNAT avec votre plage d’adresses IP publiques. Pour plus d’informations, consultez plages d'adresses IP privées SNAT d'Azure Firewall.

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 lors de la création d’un pare-feu, et il est également pris en charge pour les pare-feu existants en ajoutant une carte réseau de gestion pour le tunneling forcé. Pour plus d’informations sur les nouveaux déploiements, consultez Tunneling forcé du Pare-feu Azure. Pour les pare-feu existants, consultez Azure Firewall NIC de gestion.

Azure Firewall devez disposer d’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 : les astérisques fonctionnent quand ils sont placés sur le côté le plus à droite ou à gauche. S’il est à gauche, il ne peut pas faire partie du FQDN.
• FQDN - les astérisques fonctionnent lorsqu’ils sont placés à l'extrémité gauche.
• GÉNÉRAL - Les astérisques sur le côté gauche signifient littéralement tout ce qui se trouve à gauche correspond, ce qui signifie que plusieurs sous-domaines et/ou variantes de noms de domaine potentiellement indésirables sont mis en correspondance . Consultez les exemples suivants.

Exemples :

Non. Azure Firewall 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 Azure Firewall balises de service.

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 ping TCP ne se connecte pas réellement à la FQDN cible. Azure Firewall n'autorise pas de connexion à une adresse IP cible/nom de domaine complet, sauf s'il existe une règle explicite qui 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 Azure les limites d’abonnement et de service, les quotas et les contraintes

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é. Azure Firewall délai d’inactivité TCP est de quatre minutes. Ce paramètre n'est pas configurable par l'utilisateur, mais vous pouvez contacter Azure support 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 les 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 Azure Firewall 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 pas être utilisé à d'autres fins. 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é.

Azure Firewall ne déplace pas ou ne stocke pas les données client hors de la région dans laquelle elle est déployée.

Oui. Pour plus d’informations, consultez Backup Azure Firewall et Azure Firewall Policy avec Logic Apps.

Non, actuellement Azure Firewall dans des hubs virtuels sécurisés (vWAN) n'est pas pris en charge au Qatar.

Azure Firewall utilise des machines virtuelles Azure sous-jacentes qui ont un nombre limité 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. Azure Firewall commence par deux machines virtuelles et effectue un scale-out en fonction de l’utilisation et du débit du processeur.

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

Pour contourner certaines architectures, vous pouvez déployer et mettre à l’échelle avec NAT Gateway avec Azure Firewall pour fournir un pool plus large de ports SNAT pour la variabilité et la 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 Azure Firewall Comportements NAT.

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

Une instance de machine virtuelle de Pare-feu Azure peut être arrêtée pendant le scale-in (scale-down) d’un Virtual Machine Scale Set ou pendant la mise à niveau logicielle de la flotte. Dans ces cas, les nouvelles connexions entrantes sont équilibrées de charge sur les instances de pare-feu restantes et ne sont pas transférées vers l'instance de pare-feu en panne. 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 et délai d'inactivité de l'équilibreur de charge.

Azure Firewall augmente progressivement sa capacité lorsque le débit moyen ou la consommation du processeur atteignent 60 % et que l'utilisation des connexions atteint 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 Azure Firewall et des fonctionnalités activées. Pour plus d’informations, consultez Azure Firewall performances.

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 nouvellement créés Azure Firewall.

Lorsqu’une connexion a un délai d’inactivité (quatre minutes d’absence d’activité), Azure Firewall termine normalement la connexion en envoyant un paquet TCP RST.

Azure services 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 Azure Firewall maintenance 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 représentent la majorité des éléments de maintenance préoccupants pour 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 des cas rares, nous pouvons passer outre votre fenêtre de maintenance personnalisée pour corriger des problèmes de sécurité graves.

Oui.

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

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

L’application du programme de maintenance par le Pare-feu Azure peut prendre jusqu’à 24 heures après l’association de la politique de maintenance.

Les activités de maintenance sur votre Azure Firewall 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.