Scénario de région unique : Private Link et DNS dans Azure Virtual WAN

Cet article montre comment exposer une ressource PaaS sur un point de terminaison privé à une charge de travail spécifique dans une seule région. Dans le scénario, la topologie réseau est hub-spoke et le hub est un hub Azure Virtual WAN.

Scénario

Figure 1 : Scénario à région unique pour Virtual WAN avec Private Link et Azure DNS : le défi

Téléchargez un fichier Visio de cette architecture. Cette section définit le scénario et redéfinit le défi pour ce scénario (le défi est identique à l’exemple non fonctionnel dans la page Vue d’ensemble). L’architecture du scénario initial s’appuie sur la topologie de réseau de départ définie dans le guide de vue d’ensemble. Voici les ajouts et les modifications :

• Il n’existe qu’une seule région avec un hub virtuel.
• Il existe un compte Stockage Azure dans la région dont l’accès au réseau public est désactivé. L’hypothèse dans ce scénario est qu’une seule charge de travail accède au compte de stockage.
• Un seul réseau virtuel est initialement connecté au hub virtuel.
• Le réseau virtuel comporte un sous-réseau de charge de travail qui contient un client de machine virtuelle.
• Le réseau virtuel contient un sous-réseau de point de terminaison privé qui contient un point de terminaison privé pour le compte de stockage.

Réussite

Le client de machine virtuelle Azure peut se connecter au compte Stockage Azure via le point de terminaison privé du compte de stockage qui se trouve dans le même réseau virtuel, et tous les autres accès au compte de stockage sont bloqués.

Obstacle

Vous avez besoin d’un enregistrement DNS dans le flux DNS capable de résoudre le nom de domaine complet (FQDN) du compte de stockage à l’adresse IP privée du point de terminaison privé. Comme indiqué dans la vue d’ensemble, le défi du scénario est double :

1. Il n’est pas possible de lier une zone DNS privée qui gère les enregistrements DNS nécessaires aux comptes de stockage sur un hub virtuel.
2. Vous pouvez lier une zone DNS privée au réseau de charge de travail. Vous pouvez donc penser que cela fonctionne. Malheureusement, l’architecture de base stipule que chaque réseau virtuel connecté a des serveurs DNS configurés pour pointer pour utiliser le proxy DNS de Pare-feu Azure.

Étant donné que vous ne pouvez pas lier une zone DNS privée à un hub virtuel et que le réseau virtuel est configuré pour utiliser le proxy DNS Pare-feu Azure, les serveurs Azure DNS ne disposent d’aucun mécanisme pour résoudre le nom de domaine complet (FQDN) du compte de stockage à l’adresse IP privée du point de terminaison privé. Le résultat est que le client reçoit une réponse DNS erronée.

Flux DNS et HTTP

Examinons le DNS et les flux de requêtes HTTP qui en résultent pour cette charge de travail. La révision nous aide à visualiser l’obstacle décrit précédemment.

Figure 2 : Scénario à région unique pour Virtual WAN avec Private Link et Azure DNS : le défi

Téléchargez un fichier Visio de cette architecture.

Flux DNS

1. La requête DNS pour stgworkload00.blob.core.windows.net à partir du client est envoyée au serveur DNS configuré, qui est le Pare-feu Azure dans le hub régional appairé.
2. Le Pare-feu Azure transmet la requête à Azure DNS via proxy. Étant donné qu’il n’est pas possible de lier une zone DNS privée à un hub virtuel, Azure DNS ne sait pas comment résoudre le nom de domaine complet à l’adresse IP privée du point de terminaison privé. Il sait comment résoudre le nom de domaine complet pour obtenir l’adresse IP publique du compte de stockage, de sorte qu’il retourne l’adresse IP publique du compte de stockage.

Flux HTTP

1. Avec le résultat DNS en main, l’adresse IP publique du compte de stockage, le client envoie une requête HTTP à stgworkload00.blob.core.windows.net.
2. La demande est envoyée à l’adresse IP publique du compte de stockage. Cette demande échoue pour de nombreuses raisons :
   • Le groupe de sécurité réseau sur le sous-réseau de charge de travail peut ne pas autoriser ce trafic internet.
   • Le Pare-feu Azure qui filtre le trafic de sortie Internet n’a probablement pas de règle d’application pour prendre en charge ce flux.
   • Même si le groupe de sécurité réseau et le Pare-feu Azure avaient des allocations pour ce flux de requête, le compte de stockage est configuré pour bloquer tout accès au réseau public. En définitive, la tentative enfreint notre objectif d’autoriser uniquement l’accès au compte de stockage via le point de terminaison privé.

Solution : établir une extension de hub virtuel pour DNS

Une solution à ce défi consiste pour l’équipe réseau d’entreprise à implémenter une extension de hub virtuel pour DNS. L’extension de hub virtuel DNS est uniquement chargée d’autoriser les équipes de charge de travail qui doivent utiliser des zones DNS privées dans leur architecture dans cette topologie de hub Virtual WAN de départ.

L’extension DNS est implémentée en tant que spoke de réseau virtuel appairé à son hub virtuel régional. Il est possible de lier des zones DNS privées à ce réseau virtuel. Le réseau virtuel contient également un Azure DNS Private Resolver qui permet aux services en dehors de ce réseau virtuel, comme le Pare-feu Azure, d’interroger et de recevoir des valeurs de toutes les zones DNS privées liées. Voici les composants d’une extension de hub virtuel classique pour DNS, ainsi que certaines modifications de configuration requises :

• Un nouveau réseau virtuel spoke appairé avec le hub virtuel de la région. Ce spoke est configuré comme n’importe quel autre spoke, ce qui signifie que le serveur DNS par défaut et les règles d’acheminement forcent l’utilisation du Pare-feu Azure dans le hub régional.
• Une ressource DNS Private Resolver est déployée avec un point de terminaison entrant dans le réseau virtuel spoke.
• Une ressource de zone DNS privée nommée privatelink.blob.core.windows.net est créée.
  • Cette zone contient un enregistrement A qui mappe le nom de domaine complet du compte de stockage à l’adresse IP privée du point de terminaison privé pour le compte de stockage.
  • La zone DNS privée est liée au réseau virtuel spoke.
  • Si le contrôle d’accès en fonction du rôle (RBAC) le permet, vous pouvez utiliser l’inscription automatique ou les entrées gérées par le service pour gérer ces enregistrements DNS. Si ce n’est pas le cas, vous pouvez les gérer manuellement.
• Dans le hub régional, le serveur DNS du Pare-feu Azure est modifié pour pointer vers le point de terminaison entrant de DNS Private Resolver.

Le diagramme suivant illustre l’architecture, ainsi que les flux DNS et HTTP.

Figure 3 : Solution fonctionnelle pour un scénario de région unique pour Virtual WAN avec Private Link et DNS

Téléchargez un fichier Visio de cette architecture.

Flux DNS pour établir une extension de hub virtuel pour DNS

1. La requête DNS pour stgworkload00.blob.core.windows.net à partir du client est envoyée au serveur DNS configuré, qui est le Pare-feu Azure dans le hub régional appairé – 10.100.0.132 dans ce cas.

   Figure 4 : Configuration des serveurs DNS pour le réseau virtuel de charge de travail

2. Le Pare-feu Azure transmet la requête via proxy au Azure DNS Private Resolver régional dans l’extension hub – 10.200.1.4 dans ce cas, qui est l’adresse IP privée du point de terminaison entrant du DNS Private Resolver.

   

   Capture d’écran de la stratégie Pare-feu Azure où le proxy DNS est activé et les serveurs DNS sont définis sur Personnalisé. L’entrée pointe vers l’adresse IP privée du point de terminaison d’entrée DNS Private Resolver.

   Figure 5 : Configuration DNS dans la stratégie du Pare-feu Azure

3. DNS Private Resolver transmet la requête vers Azure DNS via proxy. Étant donné qu’une zone DNS privée est liée au réseau virtuel contenant le point de terminaison entrant, Azure DNS peut utiliser des enregistrements dans ces zones DNS privées liées.

   Figure 6 : Liens de réseau virtuel de zone DNS privée

4. Azure DNS consulte la zone DNS privée liée et résout le nom de domaine complet de stgworkload00.blob.core.windows.net en 10.1.2.4, qui est l’adresse IP du point de terminaison privé pour le compte de stockage. Cette réponse est fournie au DNS du Pare-feu Azure, qui retourne ensuite l’adresse IP privée du compte de stockage au client.

   Figure 7 : Zone DNS privée avec l’enregistrement A pour le point de terminaison privé de compte de stockage

Flux HTTP

1. Avec le résultat DNS en main, l’adresse IP privée du compte de stockage, le client émet une requête HTTP à stgworkload00.blob.core.windows.net.
2. La demande est envoyée à l’adresse IP privée (10.1.2.4) du compte de stockage. Cette demande achemine correctement, en supposant qu’il n’y a pas de restrictions conflictuelles sur les groupes de sécurité réseau locaux sur le sous-réseau client ou de point de terminaison privé. Il est important de comprendre que, même si le Pare-feu Azure sécurise le trafic privé, la demande n’est pas acheminée via le Pare-feu Azure, car le point de terminaison privé se trouve dans le même réseau virtuel que le client. Cela signifie qu’aucune allocation de Pare-feu Azure ne doit être prise pour ce scénario.
3. Une connexion privée au compte de stockage est établie par le biais du service Private Link. Le compte de stockage autorise uniquement l’accès réseau privé et accepte la requête HTTP.

Considérations relatives à l’extension de hub virtuel pour DNS

Lorsque vous implémentez l’extension pour votre entreprise, tenez compte des conseils suivants.

• Le déploiement de l’extension DNS n’est pas une tâche pour l’équipe de charge de travail. Cette tâche est une fonction de mise en réseau d’entreprise et doit être une décision d’implémentation prise avec ces personnes.
• L’extension DNS et les zones DNS privées doivent exister avant d’ajouter un service PaaS pour lequel vous souhaitez configurer des enregistrements DNS de point de terminaison privé.
• L’extension de hub virtuel est une ressource régionale, évitez le trafic interrégion et établissez une extension de hub par hub régional où la résolution DNS de point de terminaison privé est attendue.

Réseau virtuel Spoke

• Conformément au principe de responsabilité unique, le réseau virtuel de l’extension DNS ne doit contenir que les ressources requises pour la résolution DNS et ne doit pas être partagé avec d’autres ressources.
• Le réseau virtuel de l’extension DNS doit suivre les mêmes instructions de configuration sous Ajout de réseaux spoke.

Programme de résolution privé Azure DNS

• Chaque région doit avoir une extension DNS de hub virtuel avec un DNS Private Resolver.

• Le DNS Private Resolver nécessite uniquement un point de terminaison entrant et aucun point de terminaison sortant pour ce scénario. L’adresse IP privée du point de terminaison entrant est définie pour le service DNS personnalisé dans la stratégie de Pare-feu Azure (voir la figure 5).

• Pour une plus grande résilience et une gestion accrue de la charge, vous pouvez déployer plusieurs instances DNS Private Resolver par région, avec un proxy Azure DNS configuré avec plusieurs adresses IP pour la résolution par proxy.

  Figure 8 : Points de terminaison entrants pour le DNS Private Resolver

• Suivez les restrictions de réseau virtuel pour le DNS Private Resolver.

• Le groupe de sécurité réseau dans le sous-réseau pour le point de terminaison entrant du DNS Private Resolver doit uniquement autoriser le trafic UDP de son hub régional vers le port 53. Vous devez bloquer tout autre trafic entrant et sortant.

Zone DNS privée

Étant donné que l’Azure DNS Private Resolver résout le DNS via Azure DNS, Azure DNS peut récupérer toutes les zones DNS privées liées au réseau virtuel de son sous-réseau entrant.

• Liez la zone DNS privée à l’extension de hub virtuel pour le réseau virtuel DNS.
• Suivez les instructions sur la gestion des zones DNS privées pour les points de terminaison privés.
• Si vous vous attendez à ce que les propriétaires de ressources PaaS gèrent leurs propres entrées, configurez RBAC en conséquence ou implémentez une solution telle que celle de Private Link et l’intégration DNS à grande échelle.

Considérations relatives au scénario

Avec une extension DNS de hub virtuel bien gérée en place, revenons à la charge de travail et examinons quelques points supplémentaires pour aider à atteindre les objectifs de réussite dans ce scénario.

Compte de stockage

• Définissez l’Accès au réseau public sur Désactivé sous Connectivité réseau pour vous assurer que le compte de stockage est accessible uniquement via des points de terminaison privés.
• Ajoutez un point de terminaison privé à un sous-réseau de point de terminaison privé dédié dans le réseau virtuel de la charge de travail.
• Envoyez Diagnostics Azure à l’espace de travail Log Analytics de charge de travail. Vous pouvez utiliser les journaux d’accès pour résoudre les problèmes de configuration.

Sécurité du point de terminaison privé

Une exigence de cette solution est de limiter l’exposition de ce compte de stockage. Une fois que vous avez supprimé l’accès Internet public à votre ressource PaaS, vous devez aborder la sécurité des réseaux privés.

Lorsque le Pare-feu Azure sécurise le trafic privé dans une topologie hub-and-spoke Virtual WAN, le Pare-feu Azure refuse par défaut la connectivité spoke-to-spoke. Ce paramètre par défaut empêche les charges de travail dans d’autres réseaux spoke d’accéder aux points de terminaison privés (et à d’autres ressources) dans le réseau virtuel de charge de travail. Le trafic complet au sein d’un réseau virtuel n’est pas acheminé via le Pare-feu Azure. Pour contrôler l’accès au sein du réseau virtuel et ajouter une protection plus granulaire, tenez compte des recommandations de groupe de sécurité réseau (NSG, Network Security Group) suivantes.

• Créez un groupe de sécurité d’application (ASG, Application Security Group) pour regrouper les ressources qui ont des besoins d’accès entrant ou sortant similaires. Dans ce scénario, utilisez un ASG pour les machines virtuelles clientes qui doivent accéder au stockage et un autre pour les comptes de stockage accessibles. Consultez Configurer un groupe de sécurité d’application (ASG) avec un point de terminaison privé.
• Vérifiez que le sous-réseau contenant la machine virtuelle de charge de travail présente un groupe de sécurité réseau.
• Vérifiez que le sous-réseau contenant les points de terminaison privés présente un groupe de sécurité réseau.

Règles de groupe de sécurité réseau pour le sous-réseau contenant une machine virtuelle de charge de travail

Outre les autres règles réseau requises par votre charge de travail, configurez les règles suivantes.

• Règles de trafic sortant :
  • Autorisez l’ASG de calcul à accéder à l’ASG du compte de stockage.
  • Autorisez l’ASG de calcul sur l’adresse IP privée du hub régional du Pare-feu Azure pour UDP sur le port 53.

*Figure 9 : Règles NSG pour le sous-réseau de charge de travail

Règles NSG pour le sous-réseau contenant des points de terminaison privés

Il est considéré comme une bonne pratique d’exposer les points de terminaison privés sur un petit sous-réseau dédié au sein du réseau virtuel consommateur. L’une des raisons est que vous pouvez appliquer des itinéraires définis par l’utilisateur et des stratégies réseau de groupe de sécurité réseau pour les points de terminaison privés pour renforcer la sécurité et le contrôle du trafic.

Ce scénario permet l’application d’un groupe de sécurité réseau très restrictif.

• Règles de trafic entrant :
  • Autoriser l’ASG de calcul à accéder à l’ASG du compte de stockage
  • Refuser tout autre trafic
• Règles de trafic sortant :
  • Refuser tout le trafic

*Figure 10 : Règles NSG pour le sous-réseau de point de terminaison privé

La sécurité du point de terminaison privé en action

L’image suivante montre comment suivre les considérations décrites peut fournir une sécurité de défense en profondeur. Le diagramme montre un deuxième réseau virtuel spoke avec une deuxième machine virtuelle. Cette charge de travail n’est pas en mesure d’accéder au point de terminaison privé.

Figure 11 : Solution fonctionnelle pour un scénario à région unique pour Virtual WAN avec Private Link et DNS

Téléchargez un fichier Visio de cette architecture.

Flux DNS

Le flux DNS est exactement le même que dans le flux de solution.

Ce qu’il est important de souligner, c’est que le nom de domaine complet est résolu en adresse IP privée, et non en adresse IP publique. Cette résolution signifie que tous les spokes reçoivent toujours l’adresse IP privée de ce service. Un autre scénario explique comment utiliser cette approche pour partager un service PaaS entre plusieurs charges de travail consommatrices. Pour ce scénario à charge de travail unique, il ne s’agit pas d’un problème.

Flux HTTP

1. Avec le résultat DNS en main, l’adresse IP privée du compte de stockage, le client émet une requête HTTP à stgworkload00.blob.core.windows.net.
2. La demande est envoyée à l’adresse IP privée du compte de stockage. Cette demande échoue, comme attendu, pour de nombreuses raisons :
   • Le Pare-feu Azure est configuré pour sécuriser le trafic privé, de sorte qu’il gère la requête. Sauf si le Pare-feu Azure dispose d’une règle de réseau ou d’application pour autoriser le flux, le Pare-feu Azure bloque la requête.
   • Vous n’avez pas besoin d’utiliser le Pare-feu Azure dans le hub pour sécuriser le trafic privé. Par exemple, si votre réseau prend en charge le trafic privé entre régions, le groupe de sécurité réseau sur le sous-réseau du point de terminaison privé est toujours configuré pour bloquer tout le trafic autre que les sources ASG de calcul au sein du réseau virtuel qui héberge la charge de travail.

Récapitulatif

Cet article présente un scénario dans lequel un client de machine virtuelle se connecte au compte de stockage Azure via le point de terminaison privé du compte de stockage. Le point de terminaison se trouve dans le même réseau virtuel que le client. Tous les autres accès au compte de stockage sont bloqués. Ce scénario nécessite un enregistrement DNS dans le flux DNS capable de résoudre le nom de domaine complet (FQDN) du compte de stockage à l’adresse IP privée du point de terminaison privé.

La topologie de réseau de départ pour ce scénario présente deux défis :

• Il n’est pas possible de lier une zone DNS privée avec les enregistrements DNS requis pour le compte de stockage au hub virtuel.
• La liaison d’une zone DNS privée au sous-réseau de charge de travail ne fonctionne pas. La topologie de réseau de départ nécessite que le serveur DNS par défaut et les règles d’acheminement forcent l’utilisation du Pare-feu Azure dans le hub régional.

La solution proposée est que l’équipe réseau d’entreprise implémente une extension de hub virtuel pour DNS. Cette extension permet à l’équipe réseau d’entreprise d’exposer des services DNS partagés aux spokes de charge de travail qui en ont besoin.

Ressources associées

• Qu’est-ce qu’un point de terminaison privé ?
• Configuration DNS des points de terminaison privés Azure
• Private Link et intégration DNS à grande échelle
• Azure Private Link dans un réseau hub-and-spoke
• DNS pour les ressources locales et Azure
• Connectivité à la zone d’atterrissage des données sur une seule région
• Utiliser Azure Private Link pour connecter des réseaux à Azure Monitor
• Programme de résolution privé Azure DNS
• Accès avec sécurité améliorée pour les applications web multilocataires depuis des environnements locaux
• Application web redondante interzone de base hautement disponible
• Tutoriel : Créer une infrastructure DNS de point de terminaison privé avec Azure Private Resolver pour une charge de travail locale