Partager via

Approches architecturales pour la mise en réseau dans les solutions multilocataires

Toutes les solutions déployées sur Azure nécessitent une mise en réseau d’un certain type. Selon la conception de votre solution et la charge de travail, la façon dont vous interagissez avec les services de mise en réseau d’Azure peut être différente. Dans cet article, nous fournissons des considérations et des conseils pour les aspects de la mise en réseau des solutions multilocataires sur Azure. Nous incluons des informations allant des composants de mise en réseau de niveau inférieur, tels que les réseaux virtuels, à des approches de niveau d’application et de niveau supérieur.

Remarque

Azure lui-même est un environnement multilocataires, et les composants réseau d’Azure sont conçus pour une architecture multilocataires. Bien qu'il ne soit pas nécessaire de saisir tous les détails pour créer votre propre solution, vous avez la possibilité de découvrir comment Azure sépare le trafic de votre réseau virtuel de celui des autres clients.

Principaux éléments et exigences à prendre en compte

Services de plateforme et d’infrastructure

Les préoccupations de vos composants de mise en réseau diffèrent selon la catégorie des services que vous utilisez.

Services d’infrastructure

Chaque fois que vous utilisez des services d’infrastructure, tels que des machines virtuelles ou Azure Kubernetes Service, vous devez prendre en compte et concevoir les réseaux virtuels, ou VNets, qui étayent la connectivité de vos services. Vous devez également prendre en compte les autres couches de sécurité et d’isolation que vous devez incorporer dans votre conception. Évitez de vous fier exclusivement aux contrôles de la couche réseau.

Services de plateforme

Si vous utilisez les services de plateforme d’Azure, comme App Service, Azure Cosmos DB ou Azure SQL Database, l’architecture spécifique que vous utilisez détermine les services de mise en réseau dont vous avez besoin.

Si vous devez isoler vos services de plateforme d’Internet, vous devez utiliser un réseau virtuel. Selon les services spécifiques que vous utilisez, vous pouvez travailler avec des points de terminaison privés ou des ressources intégrées au VNet, comme Application Gateway. Toutefois, vous pouvez également choisir de rendre vos services de plateforme accessibles par le biais de leurs adresses IP publiques et d’utiliser les propres protections de ces services, telles que les pare-feu et les contrôles d’identité. Dans ces situations, il est possible que vous n’ayez pas besoin d’un réseau virtuel.

La décision d'utiliser ou non des VNets pour les services de plateforme repose sur de nombreuses exigences, notamment les facteurs suivants :

  • Exigences de conformité : vous devrez peut-être répondre à une norme de conformité spécifique. Certaines normes requièrent que votre environnement Azure soit configuré de manière spécifique.
  • Exigences de vos locataires : même si votre propre organisation n’a pas de conditions requises spécifiques pour l’isolation ou les contrôles de la couche réseau, vos locataires en ont peut-être. Assurez-vous de bien comprendre la façon dont vos locataires accèdent à votre solution et s’ils ont des hypothèses sur la conception de leur réseau.
  • Complexité : il peut être plus complexe de comprendre et d’utiliser des réseaux virtuels. Assurez-vous que votre équipe a une compréhension claire des principes impliqués, ou que vous serez susceptible de déployer un environnement non sécurisé.

Assurez-vous que vous comprenez les implications de l’utilisation du réseau privé.

Dimensionnement de sous-réseaux

Lorsque vous devez déployer un réseau virtuel, il est important de prendre en compte soigneusement le dimensionnement et l’espace d’adressage du réseau virtuel entier et des sous-réseaux au sein du réseau virtuel.

Veillez à bien comprendre la façon dont vous allez déployer vos ressources Azure dans des réseaux virtuels, ainsi que le nombre d’adresses IP consommées par chaque ressource. Si vous déployez des nœuds de calcul spécifiques au client, des serveurs de bases de données ou d'autres ressources, veillez à créer des sous-réseaux suffisamment grands pour la croissance attendue des clients et l’autoscaling horizontal des ressources.

De même, lorsque vous travaillez avec des services gérés, il est important de comprendre comment les adresses IP sont consommées. Par exemple, lorsque vous utilisez Azure Kubernetes Service avec l’interface Azure Container Networking Interface (CNI), le nombre d’adresses IP consommées à partir d’un sous-réseau dépend de facteurs tels que le nombre de nœuds, la façon dont vous effectuez la mise à l'échelle horizontale et le processus de déploiement du service que vous utilisez. Lorsque vous utilisez Azure App Service et Azure Functions avec l’intégration au réseau virtuel, le nombre d’adresses IP consommées est basé sur le nombre d’instances du plan.

Passez en revue la directive de segmentation de sous-réseau lors de la planification de vos sous-réseaux.

Accès public ou privé

Déterminez si vos locataires accèdent à vos services via Internet ou par le biais d’adresses IP privées.

Pour l’accès Internet (public), vous pouvez utiliser des règles de pare-feu, l’autorisation ou le refus d’adresses IP, des secrets partagés et des clés, ainsi que des contrôles basés sur l’identité pour sécuriser votre service.

Si vous devez activer la connectivité à votre service à l’aide d’adresses IP privées, envisagez d’utiliser le service Azure Private Link ou l’appairage de réseaux virtuels inter-locataires. Dans certains scénarios limités, vous pouvez également envisager d’utiliser Azure ExpressRoute ou la passerelle VPN Azure pour activer l’accès privé à votre solution. En général, cette approche n'a de sens que si vous avez un petit nombre de locataires et si vous déployez des réseaux virtuels dédiés pour chacun d'entre eux.

Accès aux points de terminaison des locataires

Déterminez si vous devez envoyer des données aux points de terminaison au sein des réseaux des locataires, à l’intérieur ou à l’extérieur d’Azure. Par exemple, devez-vous appeler un webhook fourni par un client, ou avez-vous besoin d’envoyer des messages en temps réel à un locataire ?

Si vous avez besoin d’envoyer des données aux points de terminaison des locataires, tenez compte des approches courantes suivantes :

  • Établissez des connexions depuis votre solution aux points de terminaison des locataires via l'Internet. Déterminez si les connexions doivent provenir d’une adresse IP statique. Selon les services Azure que vous utilisez, vous devrez peut-être déployer une passerelle NAT, un pare-feu ou un équilibreur de charge.
  • Déployez un agent pour activer la connectivité entre vos services hébergés sur Azure et les réseaux de vos clients, quel que soit l’emplacement où ils se trouvent.
  • Pour la messagerie unidirectionnelle, envisagez d’utiliser un service comme Azure Event Grid, potentiellement en conjonction avec des domaines d’événements.

Approches et modèles à prendre en compte

Dans cette section, nous décrivons quelques-unes des principales approches de mise en réseau que vous pouvez prendre en compte dans une solution multilocataires. Nous commençons par décrire les approches de niveau inférieur pour les composants de mise en réseau de base, puis poursuivons avec les approches que vous pouvez prendre en compte pour HTTP et d’autres problèmes liés à la couche application.

Réseaux virtuels spécifiques au locataire avec des adresses IP choisies par le fournisseur de services

Dans certains cas, vous devez exécuter des ressources dédiées connectées à un réseau virtuel dans Azure au nom d’un locataire. Par exemple, vous pouvez exécuter une machine virtuelle pour chaque locataire, ou vous devrez peut-être utiliser des points de terminaison privés pour accéder aux bases de données spécifiques du locataire.

Envisagez de déployer un réseau virtuel pour chaque locataire, à l’aide d’un espace d’adressage IP que vous contrôlez. Cette approche vous permet de connecter les VNets en tant que nœuds homologues selon vos besoins, par exemple si vous devez établir une topologie Hub-and-spoke afin de contrôler de manière centralisée l’entrée et la sortie du trafic.

Toutefois, les adresses IP sélectionnées par le fournisseur de services ne sont pas appropriées si les locataires doivent se connecter directement au réseau virtuel que vous avez créé, par exemple à l’aide de l’appairage de réseaux virtuels. Il est probable que l’espace d’adressage que vous sélectionnez ne soit pas compatible avec leur propre espace d’adressage.

Réseaux virtuels spécifiques du locataire avec des adresses IP sélectionnées par le locataire

Si les locataires doivent homologuer leurs propres réseaux virtuels avec le réseau virtuel que vous gérez en leur nom, envisagez de déployer des réseaux virtuels propres au locataire avec un espace d’adressage IP que le locataire sélectionne. Ce système permet à chaque locataire de s’assurer que les plages d’adresses IP du réseau virtuel de votre système ne se chevauchent pas avec leurs propres réseaux virtuels. En utilisant des plages d’adresses IP qui ne se chevauchent pas, ils peuvent s’assurer de la compatibilité au peering de leurs réseaux.

Cependant, avec cette approche, il est peu probable que vous puissiez connecter les VNets de vos clients en tant que nœuds homologues ou adopter une topologie Hub-and-spoke, car il est probable que les plages d’adresses IP se chevauchent entre les VNets de différents clients.

Topologie hub-and-spoke

La topologie VNet hub and spoke vous permet d'associer un VNet hub centralisé à plusieurs VNets spoke en tant que nœuds homologues. Vous pouvez contrôler de manière centralisée l’entrée et la sortie du trafic pour votre réseaux virtuels, et contrôler si les ressources du réseau virtuel de chaque spoke peuvent communiquer entre elles. Chaque réseau virtuel spoke peut également accéder à des composants partagés, comme le Pare-feu Azure, et il peut être en mesure d’utiliser des services comme Azure DDoS Protection.

Lorsque vous utilisez une topologie en étoile, assurez-vous de planifier en fonction des limites, telles que le nombre maximal de VNets appairés, et assurez-vous de ne pas utiliser d'espaces d'adressage qui se chevauchent pour le réseau virtuel de chaque locataire.

La topologie Hub-and-spoke peut être utile lorsque vous déployez des réseaux virtuels spécifiques du locataire avec des adresses IP que vous sélectionnez. Le réseau virtuel de chaque locataire devient un spoke et peut partager vos ressources communes dans le réseau virtuel hub. Vous pouvez également utiliser la topologie Hub-and-spoke lorsque vous mettez à l’échelle des ressources partagées sur plusieurs réseaux virtuels à des fins de mise à l’échelle, ou lorsque vous utilisez le modèle Tampons de déploiement.

Conseil

Si votre solution s’exécute sur plusieurs régions géographiques, il est généralement recommandé de déployer des hubs et des ressources de hub distincts dans chaque région. Bien que cette pratique entraîne un coût de ressource plus élevé, elle évite que le trafic transite par plusieurs régions Azure, ce qui peut augmenter la latence des demandes et occasionner des frais de peering mondial.

Adresses IP statiques

Déterminez si vos locataires ont besoin que votre service utilise des adresses IP publiques statiques pour le trafic entrant, le trafic sortant, ou les deux. Différents services Azure permettent d’utiliser des adresses IP statiques de différentes façons.

Lorsque vous travaillez avec des machines virtuelles et d’autres composants d’infrastructure, envisagez d’utiliser un équilibreur de charge ou un pare-feu pour l’adressage IP statique entrant et sortant. Envisagez d’utiliser la passerelle NAT pour contrôler l’adresse IP du trafic sortant. Pour plus d’informations sur l’utilisation de la NAT Gateway dans une solution multi-locataire, consultez l’article Considérations relatives à la passerelle NAT Azure pour l’architecture mutualisée.

Lorsque vous travaillez avec des services de plateforme, le service spécifique que vous utilisez détermine si et comment vous pouvez contrôler les adresses IP. Il se peut que vous deviez configurer la ressource d'une manière spécifique, par exemple en déployant une ressource telle qu'une machine virtuelle dans un réseau virtuel, puis en utilisant une passerelle NAT ou un pare-feu. Ou bien, vous pouvez demander l’ensemble actuel d’adresses IP utilisées par le service pour le trafic sortant. Par exemple, App Service fournit une API et une interface web pour obtenir les adresses IP sortantes actuelles de votre application.

Agents

Si vous avez besoin d’autoriser vos locataires à recevoir des messages initiés par votre solution, ou si vous avez besoin d’accéder à des données qui existent dans des réseaux personnels de locataires, envisagez de fournir un agent (parfois appelé passerelle locale) qu’ils peuvent déployer au sein de leur réseau. Cette approche peut fonctionner, que les réseaux de vos locataires se trouvent dans Azure, dans un autre fournisseur de cloud ou en local.

L’agent initie une connexion sortante vers un point de terminaison que vous spécifiez et contrôlez, et soit conserve les connexions de longue durée actives soit effectue des interrogations de façon intermittente. Envisagez d’utiliser Azure Relay pour établir et gérer les connexions entre votre agent et votre service. Lorsque l’agent établit la connexion, il s’authentifie et inclut des informations sur l’identificateur du locataire afin que votre service puisse mapper la connexion au locataire approprié.

En général, les agents simplifient la configuration de la sécurité pour vos locataires. Il peut être complexe et risqué d’ouvrir des ports entrants, en particulier dans un environnement local. Un agent évite la nécessité pour les locataires de prendre ce risque.

Voici des exemples de services Microsoft qui fournissent des agents pour la connectivité aux réseaux des locataires :

Le service Azure Private Link fournit une connectivité privée entre l'environnement Azure d'un client et votre solution. Les locataires peuvent également utiliser le service Private Link avec leur propre réseau virtuel pour accéder à votre service à partir d’un environnement local. Azure route de manière sécurisée le trafic vers le service à l’aide d’adresses IP privées.

Pour plus d’informations sur Private Link et l’architecture multilocataire, consultez Multilocataire et Azure Private Link.

Noms de domaine, sous-domaines et TLS

Lorsque vous travaillez avec des noms de domaine et le protocole TLS dans une solution multilocataires, il y a plusieurs considérations à prendre en compte. Passez en revue les considérations relatives à l’architecture multilocataires et aux noms de domaine.

Modèle de routage de passerelle et de déchargement de passerelle

Le modèle de routage de passerelle et le modèle de déchargement de passerelle impliquent le déploiement d’un proxy inverse de niveau 7 ou d'une passerelle. Les passerelles sont utiles pour fournir des services principaux pour une application multilocataires, notamment les fonctionnalités suivantes :

  • Routage des requêtes vers des backends spécifiques au locataire ou des tampons de déploiement.
  • Gestion des noms de domaine et des certificats TLS propres au locataire.
  • Inspection des demandes de vérification des menaces de sécurité, à l’aide d’un pare-feu d’applications web (WAF).
  • Mise en cache des réponses pour améliorer les performances.

Azure fournit plusieurs services qui peuvent être utilisés pour atteindre tout ou partie de ces objectifs, notamment Azure Front Door, Azure Application Gateway et Gestion des API Azure. Vous pouvez également déployer votre propre solution personnalisée, à l’aide d’un logiciel tel que NGINX ou HAProxy.

Si vous envisagez de déployer une passerelle pour votre solution, nous vous recommandons de commencer par créer un prototype complet qui inclut toutes les fonctionnalités dont vous avez besoin, et de vérifier que les composants de votre application continuent de fonctionner comme prévu. Vous devez également comprendre comment le composant de passerelle sera capable de s'adapter pour soutenir la croissance de votre trafic et de vos locataires.

Modèle d’hébergement de contenu statique

Le modèle d’hébergement de contenu statique implique la fourniture du contenu web à partir d’un service de stockage cloud natif et l’utilisation d’un réseau de distribution de contenu (CDN) pour la mise en cache du contenu.

Vous pouvez utiliser Azure Front Door ou un autre CDN pour les composants statiques de votre solution, comme les applications JavaScript à page unique, ainsi que pour le contenu statique tel que des fichiers image et des documents.

Selon la conception de votre solution, vous pouvez également mettre en cache des fichiers ou des données spécifiques au locataire au sein d’un CDN, comme les réponses d’API au format JSON. Cette pratique peut vous aider à améliorer les performances et l’évolutivité de votre solution, mais il est important de déterminer si les données spécifiques au locataire sont suffisamment isolées pour éviter toute fuite de données entre les locataires. Pensez à la façon dont vous envisagez de vider le contenu propre au locataire de votre cache, par exemple lorsque les données sont mises à jour ou qu’une nouvelle version de l’application est déployée. En incluant l’identificateur de locataire dans le chemin d’URL, vous pouvez contrôler si vous videz un fichier spécifique, tous les fichiers qui sont en rapport avec un locataire spécifique ou tous les fichiers pour tous les locataires.

Antimodèles à éviter

Échec de la planification de la connectivité au réseau virtuel

En déployant des ressources dans des réseaux virtuels, vous avez un grand contrôle sur la façon dont le trafic transite par les composants de votre solution. Toutefois, l’intégration au réseau virtuel introduit également une complexité, un coût et d’autres facteurs supplémentaires que vous devez prendre en compte. Cet effet est particulièrement vrai avec les composants PaaS (Platform at a service).

Il est important de tester et de planifier votre stratégie réseau, afin que vous découvriez les problèmes avant de les implémenter dans un environnement de production.

Ne pas planifier de limites

Azure applique un certain nombre de limites qui affectent les ressources de mise en réseau. Ces limites incluent les limites de ressources Azure et les limites de protocole et de plateforme principales. Par exemple, lorsque vous créez une solution multi-locataires à grande échelle sur les services de plateforme, comme Azure App Service et Azure Functions, vous devrez peut-être prendre en compte le nombre de connexions TCP et de ports SNAT. Lorsque vous travaillez avec des machines virtuelles et des équilibrages de charge, vous devez également tenir compte des limitations relatives aux règles de trafic sortant et aux ports SNAT.

Petits sous-réseaux

Il est important de tenir compte de la taille de chaque sous-réseau pour permettre le nombre de ressources ou d’instances de ressources que vous allez déployer, surtout à mesure que vous faites évoluer votre infrastructure. Lorsque vous utilisez des ressources PaaS (Platform as a service), assurez-vous que la configuration et la mise à l’échelle de votre ressource ont une incidence sur le nombre d’adresses IP requises dans son sous-réseau.

Segmentation de réseau incorrecte

Si votre solution nécessite des réseaux virtuels, réfléchissez à la façon dont vous configurez la segmentation de réseau pour vous permettre de contrôler les flux de trafic entrants et sortants (Nord-Sud) et les flux au sein de votre solution (Est-Ouest). Décidez si les locataires doivent avoir leurs propres réseaux virtuels ou si vous allez déployer des ressources partagées dans des réseaux virtuels partagés. Changer d’approche peut être difficile. Vous devez donc prendre en compte toutes vos exigences, puis sélectionner une approche qui fonctionnera pour vos objectifs de croissance futurs.

S’appuyer uniquement sur les contrôles de sécurité de la couche réseau

Dans les solutions modernes, il est important de combiner la sécurité de la couche réseau à d’autres contrôles de sécurité et vous ne devez pas vous appuyer uniquement sur les pare-feu ou la segmentation du réseau. C’est ce que l’on appelle parfois la mise en réseau de confiance zéro. Utilisez des contrôles basés sur l’identité pour vérifier le client, l’appelant ou l’utilisateur, à chaque couche de votre solution. Envisagez d’utiliser des services qui vous permettent d’ajouter des couches de protection supplémentaires. Les options disponibles dépendent des services Azure que vous utilisez. Dans AKS, envisagez d’utiliser un maillage de services pour l’authentification TLS mutuelle et les stratégies de réseau pour contrôler le trafic est-ouest. Dans App Service, considérez d’utiliser la prise en charge intégrée de l’authentification et de l’autorisation ainsi que les restrictions d’accès.

Réécriture des en-têtes d’hôte sans test

Lorsque vous utilisez le modèle de déchargement de passerelle, vous pouvez envisager de réécrire l’en-tête Host des requêtes HTTP. Cette pratique peut simplifier la configuration de votre service d’application web principal en déchargeant le domaine personnalisé et la gestion TLS sur la passerelle.

Toutefois, les réécritures d’en-tête Host peuvent entraîner des problèmes pour certains services backend. Si votre application émet des cookies ou des redirections HTTP, l’incompatibilité des noms d’hôtes peut perturber les fonctionnalités de l’application. En particulier, ce problème peut survenir lorsque vous utilisez des services principaux qui sont eux-mêmes multi-locataires, comme Azure App Service, Azure Functions et Azure Spring Apps. Pour plus d’informations, consultez la meilleure pratique de préservation du nom d’hôte.

Veillez à tester le comportement de votre application avec la configuration de passerelle que vous prévoyez d’utiliser.

Contributeurs

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

Auteur principal :

Autres contributeurs :

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

Étapes suivantes