Partager via

Conseils pour l’utilisation d’Azure Private Link dans une solution mutualisée

Azure Private Link fournit une adressage IP privée pour les services de plateforme Azure et pour vos propres applications hébergées sur des machines virtuelles Azure. Vous pouvez utiliser Private Link pour activer la connectivité privée à partir des environnements Azure de vos locataires. Les locataires peuvent également utiliser Private Link pour accéder à votre solution à partir de leurs environnements locaux, lorsqu’ils sont connectés via des passerelles de réseau privé virtuel (passerelle VPN) ou ExpressRoute.

Azure Private Link est utilisé par de nombreux grands fournisseurs SaaS, notamment Snowflake, Confluent Cloud et MongoDB Atlas.

Dans cet article, nous allons examiner comment configurer Private Link pour une solution mutualisée hébergée par Azure.

Considérations clés

Espaces d’adressage IP superposés

Private Link fournit des fonctionnalités puissantes pour les solutions mutualisées, où les locataires peuvent accéder au service via des espaces d’adressage privés.

Différents locataires utilisent fréquemment les mêmes espaces d'adresses IP privées ou des espaces qui se chevauchent. Par exemple, votre solution mutualisée peut utiliser l’espace d’adressage IP de 10.1.0.0/16. Supposons que le locataire A utilise son propre réseau local avec le même espace d’adressage IP, et que le locataire B utilise également le même espace d’adressage IP. Vous ne pouvez pas connecter ou appairer directement vos réseaux, car les plages d’adresses IP se chevauchent.

Lorsque vous utilisez Private Link pour activer la connectivité de chaque locataire à la solution multitenant, le trafic de chaque locataire se voit automatiquement appliquer la traduction d'adresses réseau (NAT). Chaque locataire peut utiliser une adresse IP privée au sein de son propre réseau respectif, et le trafic transite de manière transparente vers la solution mutualisée. Private Link effectue une traduction d’adresses réseau sur le trafic, même lorsque les locataires et le fournisseur de services utilisent tous des plages d’adresses IP qui se chevauchent :

Diagramme montrant la connectivité entre deux locataires et un service multilocataire, qui utilisent tous le même espace d’adressage IP.

Lorsque le trafic arrive dans la solution multi-tenant, il a déjà été traduit. Cela signifie que le trafic semble provenir de l’espace d’adressage IP du réseau virtuel du service multilocataire. Private Link fournit la fonctionnalité TCP Proxy Protocol v2 , qui permet à un service mutualisé de connaître le locataire qui a envoyé la requête, et même l’adresse IP d’origine du réseau source.

Sélection du service

Lorsque vous utilisez Private Link, il est important de prendre en compte le service auquel vous souhaitez autoriser la connectivité entrante.

Le service Azure Private Link est utilisé avec des machines virtuelles derrière un équilibreur de charge standard.

Vous pouvez également utiliser Private Link avec d’autres services Azure. Ces services incluent des plateformes d’hébergement d’applications comme Azure App Service. Ils incluent également Azure Application Gateway ou Gestion des API Azure, qui sont des passerelles réseau et API.

La plateforme d’application que vous utilisez détermine de nombreux aspects de votre configuration Private Link et les limites qui s’appliquent. En outre, certains services ne prennent pas en charge Private Link pour le trafic entrant. Passez en revue la documentation des services Azure que vous utilisez pour comprendre leur prise en charge de Private Link.

Limites

Examinez attentivement le nombre de points de terminaison privés que vous pouvez créer, en fonction de l’architecture de votre solution. Si vous utilisez une plateforme d’application PaaS (Platform as a Service), il est important de connaître le nombre maximal de points de terminaison privés qu’une seule ressource peut prendre en charge. Si vous exécutez des machines virtuelles, vous pouvez attacher une instance de service Private Link à un équilibreur de charge standard (SLB). Dans cette configuration, vous pouvez généralement connecter un nombre plus élevé de points de terminaison privés, mais les limites s’appliquent toujours. Ces limites peuvent déterminer le nombre de locataires que vous pouvez connecter à vos ressources à l’aide de Private Link. Passez en revue les limites, quotas et contraintes d’abonnement Azure pour comprendre les limites du nombre de points de terminaison et de connexions.

En outre, certains services nécessitent une configuration réseau spécialisée pour utiliser Private Link. Par exemple, si vous utilisez Private Link avec Azure Application Gateway, vous devez provisionner un sous-réseau dédié, en plus du sous-réseau standard pour la ressource Application Gateway.

Testez soigneusement votre solution, notamment votre déploiement et votre configuration de diagnostic, avec votre configuration Private Link activée. Lorsque des points de terminaison privés sont activés sur certains services Azure, le trafic Internet public est bloqué. Ce comportement peut nécessiter que vous modifiez vos processus de déploiement et de gestion.

Vous pouvez choisir de déployer votre solution pour qu’elle soit accessible sur Internet et qu’elle soit également exposée via des points de terminaison privés. Par exemple, certains de vos locataires peuvent nécessiter une connectivité privée, tandis que d’autres s’appuient sur la connectivité Internet publique. Considérez votre topologie réseau globale et les chemins d’accès que suit le trafic de chaque locataire.

Lorsque votre solution est basée sur des machines virtuelles derrière un équilibreur de charge standard, vous pouvez exposer votre point de terminaison via le service Private Link. Dans ce cas, un pare-feu d’applications web et le routage des applications font probablement déjà partie de votre charge de travail basée sur des machines virtuelles.

De nombreux services PaaS Azure prennent en charge Private Link pour la connectivité entrante, même entre différents abonnements Azure et locataires Microsoft Entra. Vous pouvez utiliser les fonctionnalités Private Link de ce service pour exposer votre point de terminaison.

Lorsque vous utilisez d’autres services accessibles sur Internet, comme Azure Front Door, il est important de déterminer s’ils prennent en charge Private Link pour le trafic entrant. Si ce n’est pas le cas, réfléchissez à la façon dont votre trafic transite par chaque chemin d’accès à votre solution.

Par exemple, supposons que vous développez une application accessible sur Internet qui s'exécute sur un ensemble de machines virtuelles à échelle variable. Vous utilisez Azure Front Door, y compris son pare-feu d’applications web (WAF), pour la sécurité et l’accélération du trafic, et vous configurez Front Door pour envoyer son trafic via un point de terminaison privé à votre service back-end (origine). Le locataire A se connecte à votre solution à l’aide d’un point de terminaison public et le locataire B se connecte à l’aide d’un point de terminaison privé. Étant donné que Front Door ne prend pas en charge Private Link pour les connexions entrantes, le trafic du locataire B contourne votre Front Door et son WAF :

Diagramme montrant les requêtes provenant d’Azure Front Door, ainsi qu’un point de terminaison privé, qui contourne Front Door.

Modèles d’isolation

Private Link est conçu pour prendre en charge des scénarios dans lesquels un niveau d’application unique peut être utilisé par plusieurs clients distincts, tels que vos locataires. Lorsque vous envisagez l’isolation pour Private Link, le principal problème concerne le nombre de ressources qui doivent être déployées pour prendre en charge vos besoins. Les modèles d’isolation de locataire que vous pouvez utiliser pour Private Link dépendent du service que vous utilisez.

Si vous utilisez le service Private Link avec des machines virtuelles derrière un équilibreur de charge standard, il existe plusieurs modèles d’isolation que vous pouvez prendre en compte.

Considération Service Private Link partagé et équilibreur de charge partagé Service Private Link dédié et équilibreur de charge dédié Service Private Link dédié et équilibreur de charge partagé
Complexité du déploiement Faible Moyenne-élevée, en fonction du nombre de locataires Moyenne-élevée, en fonction du nombre de locataires
Complexité opérationnelle Faible Moyenne-élevée, en fonction du nombre de ressources Moyenne-élevée, en fonction du nombre de ressources
Limites à prendre en compte Nombre de points de terminaison privés sur le même service Private Link Nombre de services Private Link par abonnement Nombre de services Private Link par équilibreur de charge standard
Exemple de scénario Solution multilocataire volumineuse avec une couche Application partagée Tampons de déploiement distincts pour chaque locataire Couche Application partagée dans un tampon unique, avec un grand nombre de locataires

Dans les trois modèles, le niveau d’isolation et de performances des données dépend des autres éléments de votre solution, et le déploiement du service Private Link n’affecte pas ces facteurs de manière matérielle.

Vous pouvez envisager de déployer un service Private Link partagé, qui est connecté à un équilibreur de charge standard. Chacun de vos locataires peut créer un point de terminaison privé et l’utiliser pour se connecter à votre solution.

Une seule instance de service Private Link prend en charge un grand nombre de points de terminaison privés. Si vous épuisez la limite, vous pouvez déployer davantage d’instances de service Private Link, bien qu’il existe également des limites au nombre de services Private Link que vous pouvez déployer sur un seul équilibreur de charge. Si vous prévoyez d’aborder ces limites, envisagez d’utiliser une approche basée sur les tampons de déploiement et de déployer des équilibreurs de charge partagés et des instances de service Private Link dans chaque tampon.

Vous pouvez déployer un service Private Link dédié et un équilibreur de charge dédié pour chaque locataire. Cette approche est logique lorsque vous disposez d’un ensemble dédié de machines virtuelles pour chaque locataire, par exemple lorsque vos locataires ont des exigences de conformité strictes.

Vous pouvez également déployer des instances de service Private Link dédiées pour chaque locataire, avec un équilibreur de charge standard partagé. Toutefois, ce modèle est peu susceptible d’offrir beaucoup d’avantages. En outre, étant donné qu’il existe une limite au nombre de services Private Link que vous pouvez déployer sur un seul équilibreur de charge standard, ce modèle n’est probablement pas susceptible d’être mis à l’échelle au-delà d’une petite solution multilocataire.

Plus souvent, vous pouvez déployer plusieurs services Private Link partagés. Cette approche vous permet d’étendre le nombre de points de terminaison privés que votre solution peut prendre en charge sur un équilibreur de charge partagé.

Modèles d’isolation pour les services PaaS Azure avec des points de terminaison privés

Lorsque vous déployez des services PaaS (Platform as a Service) Azure et que vous souhaitez permettre aux locataires d’accéder à ces services avec des points de terminaison privés, tenez compte des fonctionnalités et des contraintes du service spécifique. En outre, déterminez si vos ressources de la couche Application sont dédiées à un locataire spécifique ou si elles sont partagées entre des locataires.

Si vous déployez un ensemble dédié de ressources de la couche Application pour chaque locataire, il est probable que vous puissiez déployer un point de terminaison privé pour ce locataire afin d’accéder à ses ressources. Il est peu probable que vous épuisez les limites de service liées à private Link, car chaque locataire dispose de ses propres ressources dédiées.

Lorsque vous partagez des ressources de la couche application entre des locataires, vous pouvez envisager de déployer un point de terminaison privé pour chaque locataire. Il existe des limites sur le nombre de points de terminaison privés qui peuvent être attachés à une seule ressource, et ces limites sont différentes pour chaque service.

Private Link a plusieurs fonctionnalités utiles dans un environnement multilocataire. Toutefois, les fonctionnalités spécifiques disponibles dépendent du service que vous utilisez. Le service Azure Private Link de base, pour les machines virtuelles et les équilibreurs de charge, prend en charge toutes les fonctionnalités décrites ci-dessous. D’autres services avec prise en charge de Private Link peuvent fournir uniquement un sous-ensemble de ces fonctionnalités.

Alias de service

Lorsqu’un locataire configure l’accès à votre service à l’aide de Private Link, il doit être en mesure d’identifier votre service afin qu’Azure puisse établir la connexion.

Le service Private Link et certains autres services Azure compatibles Private Link vous permettent de configurer un alias que vous fournissez à vos locataires. En utilisant un alias, vous évitez de divulguer vos ID d’abonnement Azure et les noms des groupes de ressources.

Visibilité du service

Le service Private Link vous permet de contrôler la visibilité de votre point de terminaison privé. Vous pouvez autoriser tous les clients Azure à se connecter à votre service, s’ils connaissent son alias ou son ID de ressource. Vous pouvez également restreindre l’accès à un ensemble de clients Azure connus.

Vous pouvez également spécifier un ensemble d’ID d’abonnement Azure pré-approuvés qui peuvent se connecter à votre point de terminaison privé. Si vous choisissez d’utiliser cette approche, réfléchissez à la façon dont vous collecterez et autoriserez les ID d’abonnement. Par exemple, vous pouvez fournir une interface utilisateur d’administration dans votre application pour collecter l’ID d’abonnement d’un locataire. Ensuite, vous pouvez reconfigurer dynamiquement votre instance de service Private Link pour pré-approuver cet ID d’abonnement pour les connexions.

Approbations de connexion

Une fois qu’une connexion a été demandée entre un client (comme un locataire) et un point de terminaison privé, Private Link exige que la connexion soit approuvée. Tant que la connexion n’est pas approuvée, le trafic ne peut pas transiter par la connexion de point de terminaison privé.

Le service Private Link prend en charge plusieurs types de flux d’approbation, notamment :

  • Approbation manuelle, où votre équipe approuve explicitement chaque connexion. Cette approche est viable lorsque vous n’avez que quelques locataires qui utilisent votre service via Private Link.
  • Approbation basée sur l’API, où le service Private Link traite la connexion comme nécessitant une approbation manuelle, et votre application utilise l’API Mettre à jour une connexion de point de terminaison privé, Azure CLI ou Azure PowerShell pour approuver une connexion. Cette approche peut être utile lorsque vous avez une liste de locataires autorisés à utiliser des points de terminaison privés.
  • Approbation automatique, où le service Private Link lui-même gère la liste des ID d’abonnement qui doivent avoir leurs connexions automatiquement approuvées.

Pour plus d’informations, consultez Contrôle de l’accès au service.

Protocole proxy v2

Lorsque vous utilisez le service Private Link, par défaut, votre application dispose uniquement d’une visibilité d’une adresse IP qui a été via la traduction d’adresses réseau (NAT). Ce comportement signifie que le trafic semble circuler à partir de votre propre réseau virtuel.

Private Link vous permet d’accéder à l’adresse IP du client d’origine, dans le réseau virtuel du locataire. Cette fonctionnalité utilise le protocole tcp proxy v2.

Par exemple, supposons que les administrateurs de vos locataires doivent ajouter des restrictions d’accès basées sur des adresses IP, telles que l’hôte 10.0.0.10 peuvent accéder au service, mais que l’hôte 10.0.0.20 ne peut pas. Lorsque vous utilisez le protocole proxy v2, vous pouvez autoriser vos locataires à configurer ces types de restrictions d’accès dans votre application. Toutefois, votre code d’application doit inspecter l’adresse IP d’origine du client et appliquer les restrictions.

  • Explication et démonstrations du service Azure Private Link du point de vue des fournisseurs (ISV SaaS) et des consommateurs : une vidéo qui se penche sur la fonctionnalité du service Azure Private Link, permettant aux fournisseurs de services multitenants (tels que les fournisseurs de logiciels indépendants créant des produits SaaS). Cette solution permet aux consommateurs d’accéder au service du fournisseur à l’aide d’adresses IP privées à partir des propres réseaux virtuels Azure du consommateur.
  • Tcp Proxy Protocol v2 avec Azure Private Link Service : vidéo qui présente une présentation approfondie du protocole TCP Proxy Protocol v2, qui est une fonctionnalité avancée du service Azure Private Link. Il est utile dans les scénarios multi-entité et SaaS (Software as a Service). La vidéo vous montre comment activer le protocole proxy v2 dans le service Azure Private Link. Il vous montre également comment configurer un service NGINX pour lire l’adresse IP privée source du client d’origine, plutôt que l’adresse IP NAT, pour accéder au service via le point de terminaison privé.
  • Utilisation de NGINX Plus pour décoder le protocole TLV linkIdentifier du protocole proxy à partir du service Azure Private Link : vidéo qui explique comment utiliser NGINX Plus pour obtenir le protocole TLV du protocole PROXY TCP v2 à partir du service Azure Private Link. La vidéo montre comment vous pouvez ensuite extraire et décoder la valeur numérique linkIdentifier, également appelée LINKID, de la connexion de point d'accès privé. Cette solution est utile pour les fournisseurs multilocataires qui doivent identifier le locataire consommateur spécifique à partir duquel la connexion a été établie.
  • Modèle de connectivité privée SaaS : exemple de solution qui illustre une approche permettant d’automatiser l’approbation des connexions de point de terminaison privé à l’aide d’applications managées Azure.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteurs principaux :

Autre contributeur :

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes

Passez en revue les approches de mise en réseau de l’architecture mutualisée.