Pare-feu Azure et inspection du trafic

Pare-feu Azure est un service de sécurité réseau natif cloud managé qui fournit une inspection et un filtrage centralisés du trafic pour vos réseaux virtuels Azure. Contrairement aux groupes de sécurité réseau qui fonctionnent au niveau de la couche 4, Pare-feu Azure inspecte le trafic au niveau des couches 3 à 7. Cette fonctionnalité permet le filtrage complet du nom de domaine (FQDN), le renseignement sur les menaces, la détection et la prévention des intrusions (IDPS) et l’inspection TLS. Vous déployez Pare-feu Azure dans un sous-réseau dédié au sein de votre réseau virtuel hub et routez le trafic à partir de charges de travail spoke via le pare-feu pour inspection avant qu’il n’atteigne sa destination.

Cet article explique comment sélectionner la référence SKU Pare-feu Azure appropriée, positionner le pare-feu dans une topologie hub-spoke, configurer des types de règles et s’intégrer à des services complémentaires tels que la passerelle NAT et le serveur de routage. Pare-feu Azure est l’un des trois services principaux de sécurité réseau Azure, aux côtés d’Azure DDoS Protection et Azure Web Application Firewall.

Présentation de cet article

Cet article traite de l’inspection centralisée du trafic réseau en utilisant Pare-feu Azure. Vous apprendrez à propos de :

• Sélection du niveau de référence SKU en fonction des exigences de sécurité et de la sensibilité de la charge de travail.
• Les modèles de positionnement de hub et d’itinéraire défini par l’utilisateur (UDR) qui forcent le trafic via le pare-feu.
• Logique de traitement des règles pour les règles DNAT, réseau et application.
• Tunnel forcé pour les environnements nécessitant une inspection sur site.
• Capacités d’inspection TLS et d’IDPS dans l’offre Premium.
• Intégration avec la passerelle NAT pour la mise à l’échelle des ports SNAT et Route Server pour le routage basé sur BGP.

Qui a besoin de cet article

Déployez Pare-feu Azure lorsque vos charges de travail nécessitent une ou plusieurs des fonctionnalités suivantes :

• Contrôle de sortie centralisé : vous devez limiter les noms de domaine complets externes et les URL que vos charges de travail peuvent atteindre, au-delà de ce que fournissent les règles IP NSG.
• Inspection est-ouest : le trafic entre les réseaux virtuels spoke doit passer par un point d'inspection avec état avant que le pare-feu ne l'autorise.
• Journalisation obligatoire de conformité : les infrastructures réglementaires nécessitent une visibilité complète de couche 7 sur les connexions autorisées et refusées avec une granularité au niveau du nom de domaine complet.
• Protection contre les menaces : vous avez besoin de la détection et de la prévention des intrusions basées sur des signatures pour identifier les modèles de trafic malveillants, notamment les rappels de commande et de contrôle, les tentatives d’exploitation et le mouvement latéral.
• Inspection du trafic TLS : vous devez déchiffrer et inspecter le trafic chiffré (HTTPS) afin d’y détecter des menaces avant qu’il n’atteigne les charges de travail ou ne quitte le réseau.

Les organisations qui n’ont besoin que d’un filtrage de paquets de couche 4 sans prise en charge des FQDN peuvent envisager les NSG et les ASG comme une alternative plus simple et moins coûteuse.

Niveaux SKU d'Pare-feu Azure

Pare-feu Azure est disponible dans trois niveaux de référence SKU. Chaque niveau s’appuie sur les fonctionnalités du niveau précédent.

Comment choisir votre référence SKU

Utilisez les critères de décision suivants :

• Choisissez Basic lorsque vous avez des environnements de développement/test ou de petites charges de travail qui ont besoin d’un filtrage de sortie basé sur un nom de domaine complet sans filtrage d’informations sur les menaces (mode refus) ou une inspection avancée. La référence SKU de base inclut le renseignement sur les menaces en mode alerte uniquement, mais ne prend pas en charge le mode de refus, le proxy DNS ou les catégories web. Le SKU de base nécessite un AzureFirewallManagementSubnet dédié (/26 minimum) en plus du AzureFirewallSubnet et n’est disponible que dans certaines régions.
• Choisissez Standard pour les charges de travail de production qui ont besoin d’un filtrage basé sur le renseignement sur les menaces, d’un proxy DNS pour la résolution de règles FQDN, de filtrage de catégories web et de gestion centralisée des stratégies via Azure Firewall Manager. Standard fournit le moteur complet d'inspection avec état avec des flux de renseignements sur les menaces qui bloquent les connexions vers des adresses IP et des domaines connus comme malveillants.
• Choisissez Premium lorsque des exigences réglementaires ou de sécurité imposent l’inspection TLS du trafic chiffré, un IDPS fondé sur des signatures avec des règles continuellement mises à jour (plus de 67 000 signatures dans plus de 50 catégories, mises à jour en temps réel), ou un filtrage complet du chemin d’URL au-delà du nom de domaine pleinement qualifié (FQDN). La prime est requise pour les secteurs tels que les services financiers, les soins de santé et le gouvernement où l’inspection chiffrée du trafic est obligatoire.

Modèle de positionnement du hub et de routage UDR

Déployez Pare-feu Azure dans un sous-réseau dédié nommé exactement AzureFirewallSubnet au sein de votre réseau virtuel hub. Ce sous-réseau nécessite une taille minimale de /26 (59 adresses IP utilisables).

Routage d’architecture

Dans une topologie hub-spoke, les sous-réseaux de charge de travail spoke n’acheminent pas le trafic directement vers Internet ou vers d’autres spokes. Au lieu de cela, les UDR sur chaque sous-réseau spoke définissent l’itinéraire par défaut (0.0.0.0/0) sur l’adresse IP privée Pare-feu Azure. Ce modèle garantit que tout le trafic, qu’il soit nord-sud (à destination d’Internet) ou est-ouest (d’un spoke à l’autre), passe par le pare-feu pour inspection.

Modèle de configuration UDR :

Le AzureFirewallSubnet lui-même ne nécessite pas d’UDR dans la plupart des scénarios, car le pare-feu utilise les itinéraires système pour atteindre les réseaux spoke via le peering de réseaux virtuels. Lorsque vous intégrez à Serveur de routes Azure, le sous-réseau de pare-feu apprend des itinéraires via BGP. Cette approche supprime le besoin de maintenance manuelle des itinéraires à mesure que votre réseau augmente.

Configuration requise du sous-réseau

Pour plus d’informations sur la conception du réseau virtuel hub et la planification du sous-réseau, consultez topologie hub-spoke.

Types de règles et logique de traitement

Pare-feu Azure traite les règles via Pare-feu Azure Stratégie. Les règles sont organisées en collections de règles, qui sont regroupées en groupes de regroupements de règles. Le pare-feu évalue les règles dans l’ordre de priorité suivant :

1. Règles DNAT (traduction d’adresses réseau de destination) : traitées en premier. Traduisez le trafic entrant d’une adresse IP publique en adresse IP privée derrière le pare-feu.
2. Règles réseau : traitées en second. Autorisez ou refusez le trafic en fonction de l’adresse IP source, de l’adresse IP de destination, du port et du protocole (couche 3/4).
3. Règles d’application : traitées en dernier. Autoriser ou refuser le trafic sortant en fonction du nom de domaine complet, de l’URL ou de la catégorie web (couche 7).

Dans chaque type de règle, les groupes de regroupements de règles sont évalués par priorité (nombre le plus bas = priorité la plus élevée). Dans un groupe, les regroupements de règles sont évalués par priorité. La première règle de correspondance détermine l’action (Autoriser ou Refuser) et arrête une évaluation supplémentaire.

Règles DNAT

Utilisez des règles DNAT pour publier des services internes via l’adresse IP publique du pare-feu. Le pare-feu convertit l’adresse de destination de son adresse IP publique en adresse IP privée du service principal. Les scénarios courants sont les suivants :

• Exposition d’un serveur web interne via l’adresse IP publique du pare-feu sur le port 443
• Fourniture d’un accès RDP ou SSH contrôlé à une zone de rebond sans affecter une adresse IP publique à la machine virtuelle
• Publication de services non HTTP/S qui nécessitent un accès entrant à partir d’Internet

Example: Translate inbound TCP 443 on firewall public IP → 10.1.2.4:443 (internal web server)

Les règles DNAT ajoutent implicitement une règle de réseau correspondante pour autoriser le trafic traduit. Une fois qu’une règle DNAT correspond, le trafic est traduit et autorisé sans traitement de règle réseau supplémentaire. Pour la sécurité, limitez l’adresse IP source dans vos règles DNAT à des sources Internet spécifiques plutôt que d’utiliser des caractères génériques.

Règles de réseau

Les règles réseau filtrent le trafic au niveau de la couche 3 et de la couche 4. Utilisez des règles réseau lorsque vous devez autoriser ou refuser le trafic en fonction de l’adresse IP source, de l’adresse IP de destination, du port de destination et du protocole. Les règles de réseau n’effectuent pas de résolution FQDN. Ils fonctionnent strictement sur les adresses IP. Les cas d’utilisation courants sont les suivants :

• Autorisation de la communication entre spokes pour des ports spécifiques (par exemple, SQL Server sur TCP 1433).
• Autoriser le trafic NTP (UDP 123) vers des serveurs de temps spécifiques.
• Blocage du trafic vers des plages d’adresses IP malveillantes connues à l’aide de règles de refus.
• Autoriser ICMP pour les diagnostics réseau entre des sous-réseaux spécifiques.

Les règles réseau prennent en charge les types de protocole TCP, UDP, ICMP et Any. Vous pouvez spécifier des adresses IP, des plages d’adresses IP, des balises de service et des groupes IP en tant que source et destination.

Règles d’application

Les règles d’application filtrent le trafic HTTP/S sortant et MSSQL en fonction des noms de domaine complets, des URL et des catégories web. Les règles d’application exigent la fonction de proxy DNS pour la résolution des FQDN. Utilisez des règles d’application quand :

• Vous devez autoriser l’accès à des noms de domaine complets spécifiques (par exemple, *.microsoft.com ou storage.blob.core.windows.net).
• Vous souhaitez filtrer par chemin d’URL (référence SKU Premium uniquement), par exemple autoriser github.com/myorg/* mais bloquer d’autres chemins d’accès GitHub.
• Vous devez autoriser ou bloquer des catégories web entières (par exemple, autoriser « Outils de développement » et bloquer « Jeu »).

Les règles d’application fournissent des balises de nom de domaine complet pour les services de Azure courants (tels que Windows Update, Sauvegarde Azure et HDInsight) qui simplifient la création de règles en regroupant les noms de domaine complets requis en une seule balise.

Comportement du SNAT

Par défaut, Pare-feu Azure applique SNAT (traduction d’adresses réseau sources) au trafic sortant destiné aux adresses IP publiques. Le pare-feu n’effectue pas de trafic SNAT lorsque la destination est une plage d’adresses IP privée (RFC 1918) ou un espace d’adressage partagé (RFC 6598). Le pare-feu convertit l’adresse IP source des connexions liées à Internet en une de ses adresses IP publiques. Chaque adresse IP publique fournit 2 496 ports SNAT par instance principale.

Pour les charges de travail avec des taux de connexion sortant élevés, intégrez la passerelle NAT pour effectuer une mise à l’échelle vers 64 512 ports par adresse IP publique (jusqu’à 16 adresses IP publiques, environ un million de ports SNAT au total).

Lorsque vous associez la passerelle NAT au AzureFirewallSubnet, tout le trafic Internet sortant passe automatiquement par les adresses IP publiques de la passerelle NAT. Le pare-feu continue d’inspecter le trafic, mais la passerelle NAT gère la traduction SNAT. Aucun double NAT ne se produit.

Gestionnaire de pare-feu et héritage de stratégie

Azure Firewall Manager fournit une stratégie de sécurité centralisée et une gestion des itinéraires sur plusieurs instances de Pare-feu Azure. Les fonctionnalités clés sont les suivantes :

• Hiérarchie de stratégie : créez une stratégie de base (parent) avec des règles à l’échelle de l’organisation et autorisez les équipes enfants à créer des stratégies enfants qui héritent du parent. Les règles parentes ont toujours priorité, quelles que soient les valeurs de priorité des règles enfants.
• Gestion interrégion : une stratégie de pare-feu est une ressource globale que vous pouvez associer aux pare-feu dans n’importe quelle région ou abonnement.
• Gouvernance multi-pare-feu : appliquez une posture de sécurité cohérente entre les pare-feu hubs dans différentes régions ou entre les hubs de Virtual WAN sécurisés.

Les règles NAT sont spécifiques au pare-feu et ne sont pas héritées des stratégies parentes. Le mode de renseignement sur les menaces est hérité, mais ne peut être remplacé dans les stratégies enfants que par un mode plus strict. Une stratégie associée à zéro ou une seule instance de pare-feu est incluse sans coût supplémentaire. Les associations supplémentaires sont facturées.

Tunnel forcé

Dans certains environnements réglementaires, tout le trafic lié à Internet doit d’abord transiter par un point d’inspection local avant d’atteindre Internet. Pare-feu Azure prend en charge le tunneling forcé pour répondre à cette exigence.

Lorsque vous activez le tunneling forcé :

• Le AzureFirewallManagementSubnet trafic de gestion du pare-feu est dirigé directement vers Internet. Ce sous-réseau doit disposer d'un itinéraire vers 0.0.0.0/0 avec Internet comme saut suivant. Vous ne pouvez pas forcer la gestion du trafic via l’inspection locale.
• Le AzureFirewallSubnet achemine le trafic de charge de travail à destination d’Internet vers un pare-feu local ou une appliance réseau virtuelle tierce (NVA) via ExpressRoute ou passerelle VPN.
• Les règles DNAT ne sont pas prises en charge en mode tunneling forcé, car le trafic entrant ne peut pas atteindre directement l’adresse IP publique du pare-feu.
• Le pare-feu ne nécessite pas d’adresse IP publique sur le AzureFirewallSubnet lorsque vous configurez le tunneling forcé, car tout le trafic sortant passe par le chemin local.

Utilisez le tunneling forcé lorsque les mandats de conformité nécessitent une visibilité locale de tout le trafic lié à Internet, ou lorsque vous devez chaîner des Pare-feu Azure avec une pile de sécurité locale existante. Les scénarios courants incluent les environnements de services financiers soumis aux réglementations relatives à la résidence des données et aux réseaux gouvernementaux avec des exigences centralisées en matière de rupture d’Internet.

Inspection TLS (Premium)

Pare-feu Azure Premium intercepte les connexions HTTPS sortantes, déchiffre le trafic, l’inspecte par rapport aux signatures IDPS et aux règles d’application, puis le chiffre à nouveau et le transfère. Ce processus nécessite un certificat d’autorité de certification intermédiaire stocké dans Azure Key Vault.

Exigences relatives aux certificats

Le pare-feu utilise le certificat d’autorité de certification intermédiaire pour générer dynamiquement des certificats de serveur pour les connexions interceptées. Les navigateurs et applications des utilisateurs finaux doivent faire confiance à l’autorité de certification racine ou à l’autorité de certification intermédiaire de l’organisation, présentes dans leur magasin de certificats, pour éviter les avertissements de confiance.

Système de Détection et de Prévention d'Intrusion (IDPS)

La référence SKU Premium inclut un moteur IDPS entièrement managé avec plus de 67 000 règles sur 50 catégories. Les signatures sont mises à jour en continu avec 20 à 40 nouvelles règles publiées quotidiennement. IDPS fonctionne en deux modes :

• Mode d’alerte : journalise les correspondances de signature sans bloquer le trafic. Utiliser pendant le déploiement et le réglage initiaux.
• Mode alerte et refus : journalise et bloque le trafic correspondant aux signatures IDPS. Utiliser en production après le réglage.

Les catégories IDPS couvrent les protocoles de commande et de contrôle des programmes malveillants, le hameçonnage, les Troie, les botnets, les kits d’exploitation, les vulnérabilités et les protocoles SCADA/ICS.

Filtrage de sortie AKS

Lorsque les clusters Azure Kubernetes Service (AKS) nécessitent un trafic de sortie contrôlé, Pare-feu Azure fournit un filtrage sortant basé sur les noms de domaine complets (FQDN) pour les nœuds du cluster. Sans filtrage de sortie, les nœuds AKS peuvent atteindre n’importe quel point de terminaison Internet, ce qui augmente la surface d’attaque pour les attaques de chaîne logistique et d’exfiltration de données.

Pour implémenter ce modèle :

1. Déployez AKS avec outboundType défini sur userDefinedRouting et une table de routage personnalisée sur le sous-réseau de nœud.
2. Définissez l’itinéraire par défaut (0.0.0.0/0) sur l’adresse IP privée Pare-feu Azure.
3. Créez des règles d’application dans la stratégie de pare-feu qui autorisent les FQDN requis pour AKS (registres de conteneurs, points de terminaison du serveur d’API, dépôts de packages Microsoft).
4. Créez des règles réseau pour les points de terminaison non HTTP/S requis (NTP, DNS, connectivité de tunnel).

Ce modèle donne aux équipes de sécurité une visibilité et un contrôle sur les points de terminaison externes que les nœuds AKS peuvent atteindre, tout en permettant au cluster de fonctionner correctement. Les noms de domaine complets obligatoires varient selon l’ensemble de fonctionnalités AKS. Les clusters qui utilisent des nœuds GPU, Azure Monitor ou Azure Policy nécessitent des entrées de liste approuvées supplémentaires.

Pour obtenir des exemples détaillés de spécifications de nom de domaine complet et de règle, consultez Utiliser Pare-feu Azure pour protéger les déploiements AKS.

Considérations relatives à la conception

Prerequisites

Avant de déployer Pare-feu Azure :

• AzureFirewallSubnet : votre réseau virtuel hub doit inclure un sous-réseau dédié nommé AzureFirewallSubnet avec une taille minimale de /26. Consultez la conception du réseau virtuel et du sous-réseau pour obtenir des conseils de planification de sous-réseau.
• Topologie hub-spoke ou Virtual WAN : déployez Pare-feu Azure dans un hub central qui route le trafic à partir de réseaux spoke. Consultez la topologie hub-spoke ou Virtual WAN pour connaître les options de topologie.
• Plan d’adresse IP : réservez de l’espace d’adressage pour le sous-réseau de pare-feu, le sous-réseau de gestion (si vous utilisez le tunneling forcé) et toutes les adresses IP publiques. Consultez la planification des adresses IP.
• Azure Firewall Manager : utilisez Azure Firewall Manager si vous avez besoin d’une hiérarchie de stratégie qui partage des règles de base sur plusieurs instances de pare-feu.
• Espace de travail Log Analytics : créez un espace de travail pour les journaux de diagnostic du pare-feu avant le déploiement afin de surveiller le trafic et de résoudre les problèmes liés aux règles dès le premier jour.

Considérations relatives à la sécurité

• Journalisation : activez les paramètres de diagnostic pour envoyer les journaux d’Pare-feu Azure à un espace de travail Log Analytics. Les journaux structurés offrent une visibilité au niveau du FQDN sur chaque connexion autorisée ou refusée, à des fins d’audit et d’analyse forensique.
• Disponibilité : déployez Pare-feu Azure entre les zones de disponibilité pour optimiser son contrat SLA de disponibilité. Pour connaître les pourcentages de contrat SLA actuels, consultez le contrat SLA pour Pare-feu Azure.
• Défense en couches : Pare-feu Azure complète, mais ne remplace pas les groupes de sécurité réseau. Appliquez des NSG au niveau du sous-réseau et de la carte réseau virtuelle (NIC) afin d’assurer la microsegmentation. Utilisez le pare-feu pour l’inspection centralisée de la stratégie, des informations sur les menaces et de la couche 7.
• Dimensionnez correctement ce que vous inspectez : forcer tous les flux à passer par le pare-feu, y compris entre les différents niveaux d'une même application, tels que web-vers-application et application-vers-base de données, augmente la latence et le coût de traitement par gigaoctet. Utilisez les groupes de sécurité réseau et les groupes de sécurité des applications pour le trafic est-ouest entre niveaux approuvés, et réservez l'inspection par pare-feu au trafic qui franchit une frontière de confiance : trafic à destination d'Internet, entre spokes, hybride ou intercloud. Cette approche permet au pare-feu de se concentrer sur le trafic qui bénéficie de l’inspection et évite les coûts inutiles.
• Protection DDoS : Protégez les adresses IP publiques associées à Pare-feu Azure à l’aide de Azure protection DDoS. Consultez la protection DDoS.
• Trafic ExpressRoute : lorsque vous utilisez ExpressRoute, configurez les UDR pour diriger le trafic de peering privé via Pare-feu Azure pour l’inspection des flux de trafic hybride.

Articles connexes

• Topologie de réseau hub-spoke : réseau virtuel hub où vous déployez Pare-feu Azure.
• Accès Internet sortant : modèles de contrôle de sortie avec Pare-feu Azure et passerelle NAT.
• Web Application Firewall : protection HTTP/S de couche 7 qui complète l’inspection au niveau du réseau Pare-feu Azure.
• Sécurité DNS et résolution de noms privés : configuration du proxy DNS qui active les règles basées sur un nom de domaine complet.
• Qu’est-ce que Azure Network Security ? : Hub d’aperçu qui compare Pare-feu Azure, DDoS Protection et Web Application Firewall.

Learn more

• Documentation du Pare-feu Azure
• Fonctionnalités du Pare-feu Azure
• Fonctionnalités du Pare-feu Azure Premium
• Vue d’ensemble de Azure Firewall Manager
• Déployer et configurer Pare-feu Azure
• Tarification d'Pare-feu Azure

Étapes suivantes