Partager via

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

  • Article

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.

Notes

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 comprendre les détails pour concevoir votre propre solution, vous pouvez en savoir plus sur la façon dont Azure isole le trafic de votre réseau virtuel du trafic 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 reposer exclusivement sur les contrôles de 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 utiliser des points de terminaison privés ou des ressources intégrées au réseau virtuel, 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 des réseaux virtuels pour les services de plateforme est basée 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 de la mise en 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, des serveurs de bases de données ou d’autres ressources spécifiques du client, veillez à créer des sous-réseaux suffisamment grands pour la croissance de vos locataires et la mise à l’échelle automatique horizontale 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 est basé sur des facteurs tels que le nombre de nœuds, 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 de plan.

Passez en revue les recommandations 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 n’avez pas besoin d’envoyer des données aux points de terminaison des locataires, tenez compte des approches courantes suivantes :

  • Initiez des connexions à partir de votre solution aux points de terminaison locataires via 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 propres au locataire avec les adresses IP sélectionnées 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 d’associer le réseaux virtuels en fonction de vos propres besoins, par exemple, si vous devez établir une topologie Hub-and-spoke pour 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.

Toutefois, cette approche signifie qu’il est peu probable que vous puissiez homologuer les réseaux virtuels de vos locataires ou adopter une topologie Hub-and-spoke, car il existe probablement des plages d’adresses IP qui se chevauchent entre les réseaux virtuels de différents locataires.

Topologie hub-and-spoke

La topologie de réseau virtuel Hub-and-spoke vous permet d’utiliser un réseau virtuel hub centralisé avec plusieurs réseaux virtuels spoke. 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 Hub-and-spoke, veillez à prévoir des limites, telles que le nombre maximal de réseaux virtuels appairés, et vérifiez que vous n’utilisez pas 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 pour 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 locataire 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 couche 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 demandes vers les serveurs principaux ou les tampons de déploiement spécifiques du locataire.
  • 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 est mis à l’échelle pour prendre en charge 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 le traitement du contenu web à partir d’un service de stockage cloud natif et l’utilisation d’un réseau de distribution de contenu (CDN) pour mettre en cache le contenu.

Vous pouvez utiliser Azure Front Door ou un autre CDN pour les composants statiques de votre solution, tels que les applications JavaScript monopage, et pour le contenu statique comme les fichiers image et les 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 multilocataires à 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 autoriser le nombre de ressources ou d’instances de ressources que vous allez déployer, particulièrement lorsque vous mettez à l’échelle. 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 service pour l’authentification Mutual TLS et les stratégies de réseau pour contrôler le trafic Est-Ouest. Dans App Service, envisagez 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