Mise à la disposition générale du filtrage des noms de domaine complets SQL et du tunneling forcé Pare-feu Azure

Publié le 10 juin, 2020

Principal Program Manager, Azure Networking

Deux nouvelles fonctionnalités clés sont à présent disponibles dans le Pare-feu Azure : le tunneling forcé et le filtrage des noms de domaine complets SQL. En outre, nous avons augmenté la limite d’adresses IP publiques multiples de 100 à 250 pour la traduction d’adresses réseau de destination (DNAT) et la traduction d’adresses réseau source (SNAT).

Le Pare-feu Azure est une offre de pare-feu en tant que service (FWaaS) cloud native qui vous permet de gérer et de journaliser tous vos flux de trafic à l’aide d’une approche DevOps. Le service prend en charge les règles de filtrage au niveau de l’application et du réseau et est intégré au flux Microsoft Threat Intelligence pour filtrer les adresses IP et les domaines malveillants connus. Le Pare-feu Azure est hautement disponible grâce à la mise à l’échelle automatique intégrée.

Mise à disposition générale de la prise en charge du tunneling forcé

Le tunneling forcé vous permet de rediriger tout le trafic Internet lié du Pare-feu Azure vers votre pare-feu local ou de le chaîner à une appliance virtuelle réseau à proximité pour une inspection supplémentaire. Vous activez un pare-feu pour le tunneling forcé lorsque vous créez un pare-feu. À l’heure actuelle, il n’est pas possible de migrer un déploiement de pare-feu existant vers un mode de tunneling forcé.

Pour prendre en charge le tunneling forcé, le trafic de gestion des services est séparé du trafic client. Un sous-réseau dédié supplémentaire nommé AzureFirewallManagementSubnet est requis avec sa propre adresse IP publique associée. Le seul itinéraire autorisé sur ce sous-réseau est un itinéraire par défaut vers Internet, et la propagation de route BGP (Border Gateway Protocol) doit être désactivée.

Dans cette configuration, AzureFirewallSubnet peut à présent inclure des itinéraires vers n’importe quel pare-feu local ou n’importe quelle appliance virtuelle réseau pour traiter le trafic avant qu’il ne soit dirigé vers Internet. Vous pouvez également publier ces itinéraires via BGP vers AzureFirewallSubnet si la propagation de route BGP est activée sur ce sous-réseau.

VNnetFirewall en mode de tunneling forcé.

Figure 1. Pare-feu Azure en mode de tunneling forcé.

Éviter la traduction d’adresses réseau source (SNAT) avec le tunneling forcé

Le Pare-feu Azure assure automatiquement la traduction SNAT pour l’ensemble du trafic sortant à destination d’adresses IP publiques. Le Pare-feu Azure ne fournit pas de traduction d’adresses réseau source (SNAT) lorsque l’adresse IP de destination est une plage d’adresses IP privées, tel que spécifié par la norme IANA RFC 1918. Cette logique fonctionne parfaitement lorsque la sortie du trafic s’effectue directement vers Internet. Cependant, si vous avez activé le tunneling forcé, le trafic Internet utilise la traduction d’adresses réseau source (SNAT) vers l’une des adresses IP privées du pare-feu dans AzureFirewallSubnet, ce qui a pour effet de masquer la source à votre pare-feu local. Vous pouvez configurer le Pare-feu Azure afin qu’il n’utilise pas la traduction d’adresses réseau source (SNAT) en ajoutant « 0.0.0.0/0 » comme plage d’adresses IP privées. Notez qu’avec cette configuration, le Pare-feu Azure ne peut jamais router en sortie le trafic directement vers Internet. Pour plus d’informations, consultez la page sur les plages d’adresses IP privées SNAT du Pare-feu Azure.

Pare-feu Azure configuré pour ne pas utiliser la traduction d’adresses réseau source (SNAT), quelle que soit l’adresse IP de destination, en ajoutant 0.0.0.0/0 comme plage d’adresses IP privées.

Figure 2. Le Pare-feu Azure n’utilise pas la traduction d’adresses réseau source pour la configuration des préfixes IP privés SNAT.

Routage vers le PaaS public et Office 365

Bien que le tunneling forcé du Pare-feu Azure vous permette de diriger tout le trafic Internet vers votre pare-feu local ou une appliance virtuelle réseau proche, ce n’est pas toujours souhaitable. Par exemple, il est probablement préférable d’effectuer une sortie directe vers une plateforme PaaS publique ou Office 365. Pour ce faire, il est possible d’ajouter des itinéraires définis par l’utilisateur au AzureFirewallSubnet avec le type de tronçon suivant « Internet » pour des destinations spécifiques. Étant donné que cette définition est plus spécifique que l’itinéraire par défaut, elle est prioritaire. Pour plus d’informations, consultez Plages d’adresses IP et balises de service Azure et Adresses IP Office 365.

L’autre approche pour router le trafic sortant directement vers un PaaS public consiste à activer des points de terminaison de service de réseau virtuel sur AzureFirewallSubnet. Ces points de terminaison étendent votre espace d’adressage privé de réseau virtuel et l’identité aux services PaaS Azure, par le biais d’une connexion directe. Lorsque cette option est activée, des itinéraires spécifiques vers les services PaaS correspondants sont automatiquement créés. Les points de terminaison de service vous permettent de sécuriser vos ressources critiques du service Azure vers votre réseau virtuel uniquement. Le trafic de votre réseau virtuel vers le service Azure reste toujours sur le réseau principal de Microsoft Azure.

Il est important de noter qu’avec cette configuration, vous ne pouvez pas ajouter « 0.0.0.0/0 » comme préfixe d’adresse IP privée comme indiqué précédemment. Vous pouvez toutefois continuer à ajouter des plages personnalisées qui n’utilisent pas la traduction d’adresses réseau source (SNAT).

Enfin, il est également possible d’utiliser un point de terminaison privé Azure pour se connecter de façon sécurisée et privée à des services PaaS publics alimentés par Azure Private Link. Toutefois, ces connexions contournent votre itinéraire par défaut vers le Pare-feu Azure, comme décrit dans cette documentation. Si vous avez besoin que tout le trafic passe par votre pare-feu, vous pouvez pallier cela en ajoutant un itinéraire défini par l’utilisateur sur tous les sous-réseaux clients avec l’adresse IP du point de terminaison privé et un suffixe /32 comme destination et le Pare-feu Azure comme tronçon suivant. Remarque : pour que cette configuration fonctionne et que le trafic renvoyé à partir de votre point de terminaison privé passe par votre pare-feu, vous devez toujours utiliser la traduction d’adresses réseau source (SNAT) en utilisant 255.255.255.255/32 comme plage d’adresses IP privées.

Itinéraire défini par l’utilisateur ajouté à un point de terminaison privé de stockage qui pointe vers le pare-feu en tant que tronçon suivant pour exiger que tout le trafic passe par le pare-feu.

Figure 3. Itinéraire défini par l’utilisateur à un point de terminaison privé de stockage qui pointe vers le pare-feu en tant que tronçon suivant.

Mise à la disposition générale du filtrage de noms de domaine complets SQL

Vous pouvez maintenant configurer des noms de domaine complets SQL dans des règles d’application du Pare-feu Azure. Cela vous permet de limiter l’accès à partir de votre réseau virtuel aux seules instances de serveur SQL spécifiées. Vous pouvez filtrer le trafic de vos réseaux virtuels vers des instances Azure SQL Database, Azure SQL Data Warehouse, Azure SQL Managed Instance ou SQL IaaS déployées dans vos réseaux virtuels.

Le filtrage des noms de domaine complets SQL est actuellement pris en charge uniquement en mode proxy (port 1433). Si vous utilisez des ports qui ne sont pas par défaut pour le trafic IaaS SQL, vous pouvez configurer ces ports dans les règles d’application du Pare-feu.

Si vous utilisez SQL dans le mode de redirection par défaut, vous pouvez filtrer les accès à l’aide de la balise de service SQL dans le cadre des règles de réseau. L’ajout de la prise en charge du mode de redirection aux règles d’application est prévu dans notre feuille de route.

Règles d’application de Pare-feu Azure pour le filtrage des noms de domaine complets SQL.

Figure 4. Filtrage des noms de domaine complets SQL dans les règles d’application du Pare-feu Azure.

Augmentation de la limite d’adresses IP publiques multiples

Vous pouvez à présent utiliser jusqu’à 250 adresses IP publiques avec votre Pare-feu Azure à la fois pour la traduction d’adresses réseau de destination (DNAT) et source (SNAT).

  • DNAT : vous pouvez traduire plusieurs instances de ports standard vers vos serveurs backend. Par exemple, si vous avez deux adresses IP publiques, vous pouvez traduire le port TCP 3389 (RDP) pour ces deux adresses IP.
  • SNAT : des ports supplémentaires sont disponibles pour les connexions SNAT sortantes, réduisant ainsi le risque de pénurie de ports SNAT. Actuellement, le Pare-feu Azure sélectionne aléatoirement l’adresse IP publique source à utiliser pour une connexion. Si votre réseau est doté d’un filtrage en aval, vous devez autoriser toutes les adresses IP publiques associées à votre pare-feu. Envisagez d’utiliser un préfixe d’adresse IP publique pour simplifier cette configuration.

Pour plus d’informations, consultez Déployer un Pare-feu Azure avec plusieurs adresses IP publiques.

Prochaines étapes

Pour plus d’informations sur tout ce que nous avons abordé ici, consultez les ressources suivantes :