Scénarios du pare-feu Azure pour inspecter le trafic destiné à un point de terminaison privé
Remarque
Si vous voulez sécuriser le trafic vers des points de terminaison privés dans Azure Virtual WAN en utilisant un hub virtuel sécurisé, consultez Sécuriser le trafic destiné aux points de terminaison privés dans Azure Virtual WAN.
Le point de terminaison privé Azure est le composant fondamental d’Azure Private Link. Les points de terminaison privés permettent aux ressources Azure déployées dans un réseau virtuel de communiquer en privé avec des ressources de liaisons privées.
Les points de terminaison privés permettent aux ressources d’accéder au service de liaison privée déployé dans un réseau virtuel. L’accès au point de terminaison privé via l’appairage de réseaux virtuels et les connexions réseau locales permettent d’étendre la connectivité.
Vous devrez peut-être inspecter ou bloquer le trafic des clients vers les services exposés via des points de terminaison privés. Effectuez cette inspection à l’aide de Pare-feu Azure ou d’une appliance virtuelle réseau tierce.
Les limites suivantes s'appliquent :
Le trafic des groupes de sécurité réseau (NSG) est contourné à partir des points de terminaison privés en raison de la désactivation par défaut des stratégies réseau pour un sous-réseau d’un réseau virtuel. Pour utiliser des stratégies réseau telles que les routes définies par les utilisateurs et le support de groupe de sécurité réseau, la prise en charge de la stratégie réseau doit être activée pour le sous-réseau. Ce paramètre s’applique uniquement aux points de terminaison privés au sein du sous-réseau. Ce paramètre affecte tous les points de terminaison privés du sous-réseau. Pour les autres ressources du sous-réseau, l’accès est contrôlé en fonction des règles de sécurité du groupe de sécurité réseau.
Le trafic des routes définies par l’utilisateur (UDR) est ignoré des points de terminaison privés. Les routes définies par l’utilisateur peuvent être utilisées pour forcer le trafic destiné au point de terminaison privé.
Une table de routage unique peut être attachée à un sous-réseau
Une table de routage prend en charge jusqu’à 400 itinéraires
Pare-feu Azure filtre le trafic à l’aide des éléments suivants :
Nom de domaine complet dans les règles de réseau pour les protocoles TCP et UDP
Nom de domaine complet dans les règles d’application pour HTTP, HTTPS et MSSQL.
Important
L’utilisation de règles d’application plutôt que de règles de réseau est recommandée lors de l’inspection du trafic destiné à des points de terminaison privés afin de maintenir la symétrie du flux. Les règles d’application sont préférées aux règles réseau pour inspecter le trafic destiné aux points de terminaison privés, car le Pare-feu Azure achemine toujours le trafic SNAT avec des règles d’application. Si des règles de réseau sont utilisées ou si une NVA est utilisée à la place de Pare-feu Azure, la SNAT doit être configurée pour le trafic destiné aux points de terminaison privés afin de préserver la symétrie du flux.
Notes
Le filtrage FQDN SQL est pris en charge uniquement en mode proxy (port 1433). Le mode proxy peut entraîner une plus grande latence par rapport au mode de redirection. Si vous souhaitez continuer à utiliser le mode de redirection, qui est le mode par défaut pour les clients se connectant dans Azure, vous pouvez filtrer l’accès en utilisant le nom de domaine complet dans les règles de réseau du pare-feu.
Scénario 1 : Architecture hub-and-spoke – Réseau virtuel dédié pour les points de terminaison privés
Ce scénario est l’architecture la plus extensible pour se connecter en privé à plusieurs services Azure à l’aide de points de terminaison privés. Un itinéraire pointant vers l’espace d’adressage du réseau où sont déployés les points de terminaison privés est créé. Cette configuration réduit les frais administratifs et évite d’atteindre la limite des 400 itinéraires.
Si les réseaux virtuels sont appairés, les connexions d’un réseau virtuel client au pare-feu Azure dans un réseau virtuel hub sont facturées. Les connexions de Pare-feu Azure dans un réseau virtuel hub vers des points de terminaison privés dans un réseau virtuel appairé ne sont pas facturées.
Pour plus d’informations sur les frais liés aux connexions à l’aide de réseaux virtuels appairés, consultez la section FAQ de la page Tarification.
Scénario 2 : Architecture hub-and-spoke – Réseau virtuel partagé pour les points de terminaison privés et les machines virtuelles
Ce scénario est implémenté dans les cas suivants :
Il est impossible d’avoir un réseau virtuel dédié pour les points de terminaison privés
Seuls quelques services sont exposés dans le réseau virtuel à l’aide de points de terminaison privés
Les machines virtuelles ont des itinéraires système /32 qui pointent vers chaque point de terminaison privé. Un itinéraire par point de terminaison privé est configuré pour acheminer le trafic via Pare-feu Azure.
Les frais administratifs liés au maintien de la table de routage augmentent à mesure que les services sont exposés dans le réseau virtuel. La possibilité d’atteindre la limite d’itinéraires augmente également.
Selon votre architecture globale, il est possible d’atteindre la limite des 400 itinéraires. Nous vous recommandons d’utiliser le scénario 1 dans la mesure du possible.
Si les réseaux virtuels sont appairés, les connexions d’un réseau virtuel client au pare-feu Azure dans un réseau virtuel hub sont facturées. Les connexions de Pare-feu Azure dans un réseau virtuel hub vers des points de terminaison privés dans un réseau virtuel appairé ne sont pas facturées.
Pour plus d’informations sur les frais liés aux connexions à l’aide de réseaux virtuels appairés, consultez la section FAQ de la page Tarification.
Scénario 3 : Réseau virtuel unique
Utilisez ce modèle lorsqu’il n’est pas possible d’effectuer une migration vers une architecture hub-and-spoke. Les mêmes considérations que celles du scénario 2 s’appliquent. Dans ce scénario, les frais d’appairage de réseaux virtuels ne s’appliquent pas.
Scénario 4 : Trafic local vers des points de terminaison privés
Vous pouvez implémenter cette architecture si vous avez configuré la connectivité avec votre réseau local à l’aide de l’une des deux méthodes suivantes :
Si vos besoins en matière de sécurité exigent que le trafic client vers les services exposés via des points de terminaison privés soit acheminé par une appliance de sécurité, déployez ce scénario.
Les mêmes considérations que celles du scénario 2 ci-dessus s’appliquent. Dans ce scénario, il n’y a pas de frais d’appairage de réseaux virtuels. Pour plus d’informations sur la manière de configurer vos serveurs DNS afin de permettre aux charges de travail locales d’accéder à des points de terminaison privés, consultez Charges de travail locales à l’aide d’un redirecteur DNS.
Étapes suivantes
Dans cet article, vous avez exploré différents scénarios que vous pouvez utiliser pour limiter le trafic entre une machine virtuelle et un point de terminaison privé à l’aide de Pare-feu Azure.
Pour obtenir un tutoriel sur la configuration du Pare-feu Azure pour inspecter le trafic destiné à un point de terminaison privé, consultez la page Tutoriel : Inspecter le trafic du point de terminaison privé avec le Pare-feu Azure.
Pour plus d’informations sur les points de terminaison privés, consultez Qu’est-ce qu’un point de terminaison privé Azure ?.