FAQ 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.

Pour découvrir les fonctionnalités du Pare-feu Azure, consultez Fonctionnalités du Pare-feu Azure.

Vous pouvez déployer Pare-feu Azure sur n’importe quel réseau virtuel, mais en général, les clients le déploient sur un réseau virtuel central et appairent les autres réseaux virtuels à celui-ci dans un modèle hub-and-spoke. Vous pouvez ensuite définir l’itinéraire par défaut des réseaux virtuels appairés pour qu’il pointe vers ce réseau virtuel de pare-feu central. Global VNET Peering est pris en charge, mais n’est pas recommandé en raison de problèmes potentiels de performances et de latence sur les régions. Pour de meilleures performances, déployez un pare-feu par région.

L'avantage de ce modèle est qu'il permet d'exercer un contrôle centralisé sur plusieurs réseaux virtuels spoke pour différents abonnements. Il permet également de réaliser des économies de coûts puisqu'il n'est pas nécessaire de déployer un pare-feu au sein de chaque réseau virtuel. Les économies doivent être mesurées par rapport aux coûts de peering associés en fonction des modèles de trafic du client.

Vous pouvez installer Pare-feu Azure via le Portail Microsoft Azure, PowerShell, les API REST ou à l’aide de modèles. Voir le tutoriel : Déployer et configurer Pare-feu Azure avec le portail Azure pour obtenir des instructions pas à pas.

Pare-feu Azure prend en charge les règles et les regroupements de règles. Un regroupement de règles est un ensemble de règles qui partagent le même ordre et la même priorité. Les regroupements de règles sont exécutés dans l’ordre de leur priorité. Les regroupements de règles DNAT sont des regroupements de règles de réseau prioritaires, avec une priorité supérieure à celle des collections de règles d’application, et 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) qui sont accessibles depuis un réseau virtuel.
• Règles de réseau : Configurez des règles contenant les adresses sources, les protocoles, les ports de destination et les adresses de destination.
• Règles NAT : Configurez des règles DNAT pour autoriser les connexions Internet entrantes.

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

Pare-feu Azure prend en charge le filtrage du trafic entrant et sortant. La protection entrante est généralement utilisée pour les protocoles non HTTP comme les protocoles RDP, SSH et FTP. Pour la protection HTTP et HTTPS entrante, utilisez un pare-feu d’applications web comme Azure Web Application Firewall (WAF), ou les fonctionnalités de déchargement TLS et d’inspection approfondie des paquets du Pare-feu Azure Premium.

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

Pare-feu Azure est intégré à Azure Monitor pour la consultation et l’analyse des journaux d’activité de Pare-feu. Les journaux d’activité peuvent être envoyés à Log Analytics, Stockage Azure ou Event Hubs. Ils peuvent être analysés dans Log Analytics ou par d’autres outils comme Excel et 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 cloud managé qui protège vos ressources de réseau virtuel. Il s’agit d’un service de pare-feu avec état intégral, doté d’une haute disponibilité intégrée et d’une scalabilité illimitée dans le cloud. Il est préintégré aux fournisseurs SECaaS (Security as a service) tiers pour offrir une sécurité avancée à vos connexions Internet de réseau virtuel et de succursale. Pour en savoir plus sur la sécurité réseau Azure, consultez Sécurité réseau Azure.

Le pare-feu d’applications web (WAF, Web Application Firewall) est une fonctionnalité d’Application Gateway qui protège en entrée vos applications web de manière centralisée contre les vulnérabilités et les exploits courants. 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 service Pare-feu Azure complète les fonctionnalités de groupe de sécurité réseau. Ensemble, ils fournissent une meilleure sécurité réseau grâce à une défense approfondie. Les groupes de sécurité réseau assurent un filtrage du trafic distribué au niveau de la couche réseau pour limiter le trafic aux ressources au sein de réseaux virtuels de chaque abonnement. Pare-feu Azure est un service de pare-feu entièrement centralisé et avec état qui offre une protection au niveau du réseau et de l’application entre les différents abonnements et réseaux virtuels.

Pare-feu Azure est un service géré avec plusieurs couches de protection, y compris la protection de plateforme avec des groupes de sécurité réseau au niveau de la carte réseau (non visible). Les groupes de sécurité réseau au niveau du sous-réseau ne sont pas nécessaires sur AzureFirewallSubnet, et sont désactivés pour empêcher toute interruption du 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.

Consultez Tarification de Pare-feu Azure.

Vous pouvez utiliser les méthodes désallouer et allouer d’Azure PowerShell. Si le pare-feu est configuré pour le tunneling forcé, la procédure est légèrement différente.

Par exemple, pour un pare-feu NON configuré pour le tunneling forcé :

# Stop an existing 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 configuré pour le tunneling forcé, la procédure d’arrêt est la même. Toutefois, au démarrage, l’adresse IP publique de gestion doit être réassociée au pare-feu :

# Stop an existing 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"
$mgmtPip2 = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "mgmtpip"
$azfw.Allocate($vnet, $pip, $mgmtPip2)
$azfw | Set-AzFirewall

Pour un pare-feu dans une architecture de hub virtuel sécurisé, l’arrêt est le même, mais le démarrage doit utiliser l’ID de hub virtuel :

# Stop and existing firewall

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

# Start the firewall

$virtualhub = get-azvirtualhub -ResourceGroupName "RG name of vHUB" -name "vHUB name"
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "Azfw RG Name"
$azfw.Allocate($virtualhub.Id)
$azfw | Set-AzFirewall

Lorsque vous allouez et libérez, la facturation du pare-feu démarre et s’arrête en conséquence.

Il est recommandé de configurer des zones de disponibilité pendant le déploiement initial du pare-feu. Toutefois, dans certains cas, il est possible de modifier les zones de disponibilité après le déploiement. Les prérequis sont les suivants :

• Le pare-feu est déployé dans un réseau virtuel. Il n’est pas pris en charge avec les pare-feu déployés dans un hub virtuel sécurisé.
• La région du pare-feu prend en charge les zones de disponibilité.
• Toutes les adresses IP publiques jointes sont déployées avec des zones de disponibilité. Dans la page de propriétés de chaque adresse IP publique, vérifiez que le champ Zones de disponibilité existe et qu’il est configuré avec les mêmes zones que celles que vous avez configurées pour le pare-feu.

La reconfiguration des zones de disponibilité ne peut être effectuée que lorsque vous redémarrez le pare-feu. Après avoir alloué le pare-feu et juste avant de démarrer le pare-feu avec Set-AzFirewall, utilisez l’Azure PowerShell suivant pour modifier la propriété Zones du 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"
$mgmtPip2 = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "mgmtpip"
$azfw.Allocate($vnet, $pip, $mgmtPip2)
$azFw.Zones=1,2,3
$azfw | Set-AzFirewall

Pour connaître les limites du service Pare-feu Azure, voir Limites, quotas et contraintes applicables aux services et abonnements Azure.

Oui, vous pouvez utiliser Pare-feu Azure dans un réseau virtuel de hub pour acheminer et filtrer le trafic entre deux 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 d’un même réseau virtuel nécessite davantage d’attention. Bien que l'utilisation de la plage d'adresses du réseau virtuel comme préfixe cible pour l'UDR soit suffisante, celle-ci achemine également tout le trafic d'une machine vers une autre au sein du même sous-réseau via l'instance du Pare-feu Azure. Pour éviter cela, incluez l'itinéraire du sous-réseau dans l'UDR, avec VNET comme type de tronçon suivant. 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. 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.

Oui. Le pare-feu, le réseau virtuel et l’IP publique doivent tous être dans le même groupe de ressources.

• 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 :

Chaque fois qu’une modification de configuration est appliquée, Pare-feu Azure tente de mettre à jour toutes ses instances de serveur principal sous-jacentes. Dans de rares cas, il se peut qu’une de ces instances back-end ne soit pas mise à jour avec la nouvelle configuration et que le processus de mise à jour s’arrête avec un état de provisionnement ayant échoué. Votre Pare-feu Azure est toujours opérationnel, mais l’état de la configuration appliquée peut être incohérent : certaines instances ont toujours la configuration précédente tandis que d’autres ont l’ensemble de règles mis à jour. Si cela se produit, essayez de mettre à jour votre configuration une fois de plus jusqu’à la réussite de l’opération que votre Pare-feu aie l’état d’approvisionnement Réussite.

Le pare-feu Azure est constitué de plusieurs nœuds back-end dans une configuration active-active. Pour toute activité de maintenance planifiée, notre logique de drainage des connexions permet de mettre à jour les nœuds de manière appropriée. Pour limiter le risque d’interruption, les mises à jour sont planifiées en dehors des heures d’ouverture, et ce pour chaque région Azure. Pour les problèmes non planifiés, nous instancions un nouveau nœud pour remplacer le nœud défaillant. La connectivité avec le nouveau nœud est généralement rétablie dans les 10 secondes suivant la défaillance.

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.

Oui. Le nom d’un pare-feu est limité à 50 caractères.

Le Pare-feu Azure doit approvisionner davantage de machines virtuelles au fil de sa mise à l'échelle. Avec un espace d'adressage de /26, le pare-feu dispose de suffisamment d'adresses IP pour prendre en charge la mise à l'échelle.

Non. Un sous-réseau de /26 suffit au Pare-feu Azure.

La capacité de débit initiale du Pare-feu Azure va de 2,5 à 3 Gbits/s et peut aller jusqu’à 30 Gbits/s pour la référence SKU Standard et 100 Gbits/s pour la référence SKU Premium. Il effectue un scale-out automatiquement en fonction de l’utilisation du processeur, du débit et du nombre de connexions.

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. Le nombre maximal de débit varie en fonction de la référence SKU du pare-feu et des fonctionnalités activées. Pour plus d’informations, consultez Performances du Pare-feu Azure.

Cette opération prend de cinq à sept minutes.

Lors des tests de performances, veillez à tester pendant au moins 10 à 15 minutes et à initier de nouvelles connexions pour profiter des nœuds de pare-feu 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.

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é.

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.