Mise en réseau pour les charges de travail SaaS sur Azure
Votre réseau fournit l’épine dorsale de la façon dont les clients accèdent à votre application SaaS et permettent la communication entre les composants de votre solution. La façon dont vous concevez votre réseau a un effet direct sur la sécurité, les opérations, les coûts, les performances et la fiabilité de votre solution. Une approche structurée de votre stratégie de mise en réseau devient encore plus importante à mesure que votre environnement cloud augmente.
Choisir une stratégie de déploiement de réseau et une topologie
Les solutions SaaS ont des exigences réseau uniques. À mesure que vous intégrez davantage de clients et que leur utilisation augmente, les exigences réseau changent. La gestion de la croissance peut être difficile en raison de ressources limitées, telles que les plages d’adresses IP. Votre conception réseau a un impact sur la sécurité et l’isolation des clients. La planification de votre stratégie réseau permet de gérer la croissance, d’améliorer la sécurité et de réduire la complexité opérationnelle.
Considérations sur la conception
Planifiez votre stratégie de déploiement réseau en fonction de votre modèle de location. Déterminez si vos ressources réseau seront partagées entre les clients, dédiées à un seul client ou à une combinaison. Ce choix affecte les fonctionnalités, la sécurité et l’isolation des clients de votre application.
Il est courant de partager des ressources réseau, telles que des réseaux virtuels et des profils Azure Front Door, parmi plusieurs clients. Cette approche réduit les coûts et la surcharge opérationnelle. Il simplifie également la connectivité. Vous pouvez facilement connecter les ressources d’un client avec des ressources partagées, telles que des comptes de stockage partagés ou un plan de contrôle.
Toutefois, des ressources réseau dédiées pour chaque client peuvent être nécessaires pour établir une sécurité et une conformité élevées. Par exemple, pour prendre en charge un degré élevé de segmentation réseau entre les clients, vous utilisez des réseaux virtuels comme limite. Les ressources dédiées peuvent être nécessaires lorsque le nombre de ressources réseau sur tous les clients dépasse la capacité d’un seul réseau partagé.
Planifiez le nombre de ressources réseau dont chaque client aura besoin en tenant compte des exigences immédiates et futures. Les exigences des clients et les limites de ressources Azure peuvent forcer des résultats spécifiques. Différentes ressources peuvent nécessiter différentes stratégies de déploiement, telles que l’utilisation de réseaux distincts pour le peering de réseaux virtuels avec des réseaux virtuels Azure appartenant au client.
Pour plus d’informations sur le partage de ressources dans une solution SaaS, consultez l’organisation des ressources pour les charges de travail SaaS.
Comprendre les topologies réseau. Les topologies réseau appartiennent généralement à trois catégories :
Réseau plat : un seul réseau isolé avec des sous-réseaux pour la segmentation. Convient quand vous disposez d’une application multilocataire unique avec une disposition réseau simple. Les réseaux plats peuvent atteindre les limites des ressources et exiger davantage de réseaux à mesure que vous effectuez une mise à l’échelle, ce qui augmente la surcharge et les coûts. Si vous envisagez d’héberger plusieurs applications ou d’utiliser des tampons de déploiement dédiés au sein du même réseau virtuel, vous devrez peut-être disposer d’une disposition réseau complexe.
Hub-and-spoke : réseau hub centralisé avec peering aux réseaux spoke isolés. Adapté à une extensibilité élevée et à l’isolation du client, car chaque client ou application a son propre spoke, en communiquant uniquement avec le hub. Vous pouvez déployer rapidement davantage de spokes si nécessaire afin que les ressources du hub puissent être utilisées par tous les spokes. La communication transitive ou spoke-à-spoke via le hub est désactivée par défaut, ce qui permet de maintenir l’isolation des clients dans les solutions SaaS.
Aucun réseau : utilisé pour les services PaaS Azure, où vous pouvez héberger des charges de travail complexes sans déployer de réseaux virtuels. Par exemple, Azure App Service permet une intégration directe avec d’autres services PaaS sur le réseau principal Azure. Bien que cette approche simplifie la gestion, elle limite la flexibilité du déploiement des contrôles de sécurité et la possibilité d’optimiser les performances. Cette approche peut fonctionner correctement pour les applications natives cloud. À mesure que votre solution évolue, prévoyez de passer à une topologie hub-and-spoke au fil du temps.
Compromis : Complexité et sécurité. Le démarrage sans limite de réseau définie peut réduire la charge opérationnelle de la gestion des composants réseau tels que les groupes de sécurité, l’espace d’adressage IP et les pare-feu. Toutefois, un périmètre réseau est essentiel pour la plupart des charges de travail. En l’absence de contrôles de sécurité réseau, reposez sur une gestion forte des identités et des accès pour protéger votre charge de travail contre le trafic malveillant.
Découvrez comment l’architecture multirégion affecte les topologies réseau. Dans une architecture multirégion utilisant des réseaux virtuels, la plupart des ressources réseau sont déployées séparément dans chaque région, car les pare-feu, les passerelles de réseau virtuel et les groupes de sécurité réseau ne peuvent pas être partagés entre les régions.
Recommandations de conception
| Recommandation | Avantage |
|---|---|
| Décidez quels composants réseau sont partagés et quels composants sont dédiés au client. Partagez des ressources facturées par instance, telles que Pare-feu Azure, Azure Bastion et Azure Front Door. |
Prenez en charge l’équilibre entre vos exigences de sécurité et d’isolation tout en réduisant votre coût et votre charge opérationnelle. |
| Commencez par une topologie plate ou aucune approche réseau. Passez toujours en revue les exigences de sécurité en premier, car ces approches offrent une isolation limitée et des contrôles de trafic. |
Vous pouvez réduire la complexité et le coût de votre solution à l’aide de topologies réseau plus simples. |
| Prenez en compte les topologies hub-and-spoke pour des besoins complexes ou lors du déploiement de réseaux virtuels dédiés par client. Utilisez le hub pour héberger des ressources réseau partagées entre les réseaux clients. | Vous pouvez mettre à l’échelle plus facilement et améliorer votre rentabilité en partageant des ressources via votre réseau hub. |
Concevoir un périmètre réseau sécurisé
Votre périmètre réseau établit la limite de sécurité entre votre application et d’autres réseaux, y compris Internet. En documentant votre périmètre réseau, vous pouvez faire la distinction entre différents types de flux de trafic :
- Trafic d’entrée, qui arrive dans le réseau à partir d’une source externe.
- Trafic interne, qui passe entre les composants au sein de votre réseau.
- Trafic sortant, qui quitte le réseau.
Chaque flux implique différents risques et contrôles. Par exemple, plusieurs contrôles de sécurité sont nécessaires pour inspecter et traiter le trafic d’entrée.
Important
En guise de bonne pratique générale, suivez toujours une approche de confiance zéro. Vérifiez que tout le trafic est contrôlé et inspecté, y compris le trafic interne.
Vos clients peuvent également avoir des exigences de conformité spécifiques qui influencent votre architecture. Par exemple, s’ils ont besoin d’une conformité SOC 2, ils doivent implémenter différents contrôles réseau, notamment un pare-feu, un pare-feu d’applications web et des groupes de sécurité réseau, pour répondre aux exigences de sécurité. Même si vous n’avez pas besoin de vous conformer immédiatement, tenez compte de ces facteurs d’extensibilité lors de la conception de votre architecture.
Reportez-vous aux recommandations SE :06 pour la mise en réseau et la connectivité
Considérations sur la conception
Protégez et gérez le trafic d’entrée. Inspectez ce trafic pour les menaces entrantes.
Les pare-feu vous permettent de bloquer les adresses IP malveillantes et d’effectuer des analyses avancées pour vous protéger contre les tentatives d’intrusion. Toutefois, les pare-feu peuvent être coûteux. Évaluez vos exigences de sécurité pour déterminer si un pare-feu est requis.
Les applications web sont vulnérables aux attaques courantes, telles que l’injection SQL, les scripts intersites et d’autres vulnérabilités OWASP principales. Le pare-feu d’applications web Azure protège contre ces attaques et est intégré à Application Gateway et Azure Front Door. Passez en revue les niveaux de ces services pour comprendre les fonctionnalités WAF dans lesquelles se trouvent les produits.
Les attaques DDoS sont un risque pour les applications accessibles sur Internet. Azure fournit un niveau de protection de base sans coût. Azure DDoS Protection offre une protection avancée en apprenant vos modèles de trafic et en ajustant les protections en conséquence, bien qu’elles soient coûteuses. Si vous utilisez Front Door, tirez parti des fonctionnalités DDoS intégrées.
Au-delà de la sécurité, vous pouvez également manipuler le trafic d’entrée pour améliorer les performances de votre application en utilisant la mise en cache et l’équilibrage de charge.
Envisagez d’utiliser un service proxy inverse comme Azure Front Door pour la gestion globale du trafic HTTP(S). Vous pouvez également utiliser Application Gateway ou d’autres services Azure pour le contrôle du trafic entrant. Pour en savoir plus sur les options d’équilibrage de charge dans Azure, consultez les options d’équilibrage de charge.
Protégez le trafic interne. Vérifiez que le trafic entre votre application et ses composants est sécurisé pour empêcher l’accès malveillant. Protégez ces ressources et améliorez les performances à l’aide du trafic interne au lieu du routage sur Internet. Azure Private Link est couramment utilisé pour se connecter aux ressources Azure via une adresse IP interne au sein de votre réseau. Pour certains types de ressources, les points de terminaison de service peuvent être une alternative plus rentable. Si vous activez la connectivité Internet publique pour vos ressources, découvrez comment restreindre le trafic à l’aide d’adresses IP et d’identités d’application, telles que des identités managées.
Protégez le trafic de sortie. Dans certaines solutions, inspectez le trafic sortant pour empêcher l’exfiltration des données, en particulier pour la conformité réglementaire et les clients d’entreprise. Utilisez des pare-feu pour gérer et examiner le trafic de sortie, bloquant les connexions à des emplacements non autorisés.
Planifiez la mise à l’échelle de la connectivité sortante et de la SNAT. L’épuisement des ports de traduction d’adresses réseau source (SNAT) peut affecter les applications mutualisées. Ces applications ont souvent besoin de connexions réseau distinctes pour chaque locataire et le partage de ressources entre les clients augmente le risque d’épuisement SNAT à mesure que votre base de clients augmente. Vous pouvez atténuer l’épuisement SNAT à l’aide de la passerelle NAT Azure, des pare-feu comme Pare-feu Azure ou une combinaison des deux approches.
Recommandations de conception
| Recommandation | Avantage |
|---|---|
| Conservez un catalogue des points de terminaison réseau exposés à Internet. Capturez des détails tels que l’adresse IP (si statique), le nom d’hôte, les ports, les protocoles utilisés et la justification des connexions. Documentez la façon dont vous prévoyez de protéger chaque point de terminaison. |
Cette liste constitue la base de votre définition de périmètre, ce qui vous permet de prendre des décisions explicites sur la gestion du trafic via votre solution. |
| Comprendre les fonctionnalités du service Azure pour limiter l’accès et améliorer la protection. Par exemple, l’exposition de points de terminaison de compte de stockage aux clients nécessite des contrôles supplémentaires tels que des signatures d’accès partagé, des pare-feu de compte de stockage et l’utilisation de comptes de stockage distincts pour une utilisation interne et externe. |
Vous pouvez sélectionner des contrôles qui répondent à vos besoins en matière de sécurité, de coût et de performances. |
| Pour les applications HTTP(S), utilisez un proxy inverse, comme Azure Front Door ou Application Gateway. | Les proxys inverses offrent un large éventail de fonctionnalités pour améliorer les performances, la résilience, la sécurité et réduire la complexité opérationnelle. |
| Inspectez le trafic d’entrée à l’aide d’un pare-feu d’applications web. Évitez d’exposer des ressources web telles qu’un App Service ou Azure Kubernetes Service (AKS) directement sur Internet. |
Vous pouvez mieux protéger vos applications web contre les menaces courantes et réduire l’exposition globale de votre solution. |
| Protégez votre application contre les attaques par déni de service. Utilisez Azure Front Door ou Azure DDoS Protection en fonction des protocoles utilisés par vos points de terminaison publics. |
Protégez votre solution contre un type d’attaque courant. |
| Si votre application nécessite une connectivité de sortie à grande échelle, utilisez la passerelle NAT ou un pare-feu pour fournir des ports SNAT supplémentaires. | Vous pouvez prendre en charge des niveaux de mise à l’échelle plus élevés. |
Connectivité interréseau
Pour certains scénarios, vous devrez peut-être vous connecter à des ressources externes à Azure, telles que des données au sein du réseau privé ou des ressources d’un client sur un autre fournisseur de cloud dans une configuration multicloud. Ces besoins peuvent compliquer la conception de votre réseau, nécessitant différentes approches pour implémenter la connectivité entre réseaux en fonction de vos besoins spécifiques.
Considérations sur la conception
Identifiez les points de terminaison auxquels l’application a besoin de connexion. L’application peut avoir besoin de communiquer avec d’autres services, tels que les services de stockage et les bases de données. Documentez leur propriétaire, leur emplacement et leur type de connectivité. Vous pouvez ensuite choisir la méthode appropriée pour vous connecter à ces points de terminaison. Les approches courantes sont les suivantes :
Emplacement de la ressource Owner Options de connectivité à prendre en compte Azure Client - Point de terminaison privé (sur les locataires Microsoft Entra ID)
- Peering de réseaux virtuels (entre locataires Microsoft Entra ID)
- Point de terminaison de service (sur les locataires Microsoft Entra ID)
Autre fournisseur de cloud Éditeur de logiciels indépendants ou client - VPN site à site
- ExpressRoute
- Internet
Sur site Éditeur de logiciels indépendants ou client - VPN site à site
- ExpressRoute
- Internet
Private Link et point de terminaison privé. Fournissez une connectivité sécurisée à différentes ressources Azure, notamment des équilibreurs de charge internes pour les machines virtuelles. Ils permettent l’accès privé à votre solution SaaS pour les clients, même s’ils présentent des considérations sur les coûts.
Compromis : sécurité et coût. La liaison privée garantit que votre trafic reste au sein de votre réseau privé et est recommandé pour la connectivité réseau entre les locataires Microsoft Entra. Toutefois, chaque point de terminaison privé entraîne des coûts, ce qui peut s’ajouter en fonction de vos besoins de sécurité. Les points de terminaison de service peuvent être une alternative économique, en conservant le trafic sur le réseau principal Microsoft tout en fournissant un niveau de connectivité privée.Point de terminaison de service. Route le trafic vers les ressources PaaS via le réseau principal de Microsoft, en sécurisant la communication de service à service. Ils peuvent être rentables pour les applications à bande passante élevée, mais nécessitent la configuration et la maintenance des listes de contrôle d’accès pour la sécurité. La prise en charge des points de terminaison de service sur les locataires Microsoft Entra ID varie selon le service Azure. Consultez la documentation du produit pour chaque service que vous utilisez.
Le peering de réseaux virtuels connecte deux réseaux virtuels, ce qui permet aux ressources d’un réseau d’accéder aux adresses IP dans l’autre. Il facilite la connectivité aux ressources privées dans un réseau virtuel Azure. L’accès peut être géré à l’aide de groupes de sécurité réseau, mais l’application de l’isolation peut être difficile. Par conséquent, il est important de planifier la topologie de votre réseau en fonction des besoins spécifiques des clients.
Les réseaux privés virtuels (VPN) créent un tunnel sécurisé via Internet entre deux réseaux, notamment entre les fournisseurs de cloud et les emplacements locaux. Les VPN de site à site utilisent des appliances réseau dans chaque réseau pour la configuration. Ils offrent une option de connectivité à faible coût, mais nécessitent une configuration et ne garantissent pas le débit prévisible.
ExpressRoute fournit une connexion privée dédiée, hautes performances, entre Azure et d’autres fournisseurs de cloud ou réseaux locaux. Il garantit des performances prévisibles et évite le trafic Internet, mais est fourni avec des coûts plus élevés et nécessite une configuration plus complexe.
Planifiez en fonction de la destination. Vous devrez peut-être vous connecter à des ressources dans différents locataires Microsoft Entra ID, en particulier si la ressource cible se trouve dans l’abonnement Azure d’un client. Envisagez d’utiliser des points de terminaison privés, un VPN de site à site ou en appairant des réseaux virtuels. Pour plus d’informations, consultez Peering virtual networks in different Microsoft Entra ID tenants.
Pour vous connecter aux ressources hébergées dans un autre fournisseur de cloud, il est courant d’utiliser la connectivité Internet publique, un VPN de site à site ou ExpressRoute. Pour plus d’informations, consultez Connectivité à d’autres fournisseurs de cloud.
Comprendre les effets de la connectivité sur votre topologie de réseau. Un réseau virtuel Azure ne peut avoir qu’une seule passerelle de réseau virtuel, qui peut se connecter à plusieurs emplacements via un VPN de site à site ou ExpressRoute. Toutefois, il existe des limites sur le nombre de connexions via une passerelle et l’isolation du trafic client peut être difficile. Pour plusieurs connexions à différents emplacements, planifiez votre topologie de réseau en conséquence, éventuellement en déployant un réseau virtuel distinct pour chaque client.
Comprendre les implications de la planification des adresses IP. Certaines approches de connectivité fournissent automatiquement une traduction d’adresses réseau (NAT), ce qui évite les problèmes liés aux adresses IP qui se chevauchent. Toutefois, le peering de réseaux virtuels et ExpressRoute n’effectuent pas de nat. Lorsque vous utilisez ces méthodes, planifiez soigneusement vos ressources réseau et les allocations d’adresses IP pour éviter les chevauchements de plages d’adresses IP et garantir une croissance future. La planification des adresses IP peut être complexe, en particulier lors de la connexion à des tiers tels que des clients, de sorte que vous envisagez des conflits potentiels avec leurs plages d’adresses IP.
Comprendre la facturation de sortie réseau. Azure facture généralement le trafic réseau sortant lorsqu’il quitte le réseau Microsoft ou se déplace entre les régions Azure. Lors de la conception de solutions multirégions ou multiclouds, il est important de comprendre les implications des coûts. Les choix architecturaux, tels que l’utilisation d’Azure Front Door ou d’ExpressRoute, peuvent affecter la façon dont vous êtes facturé pour le trafic réseau.
Recommandations de conception
| Recommandation | Avantage |
|---|---|
| Préférez les approches de mise en réseau privée pour la connexion entre réseaux afin de hiérarchiser la sécurité. Envisagez uniquement le routage sur Internet après avoir évalué les implications de sécurité et de performances associées. |
Le trafic privé traverse un chemin réseau sécurisé, ce qui permet de réduire de nombreux types de risques de sécurité. |
| Lors de la connexion aux ressources client hébergées dans leurs environnements Azure, utilisez Private Link, des points de terminaison de service ou des peerings de réseaux virtuels. | Vous pouvez conserver le trafic sur le réseau Microsoft, ce qui permet de réduire les coûts et la complexité opérationnelle par rapport à d’autres approches. |
| Lors de la connexion entre les fournisseurs de cloud ou vers des réseaux locaux, utilisez des VPN de site à site ou ExpressRoute. | Ces technologies fournissent des connexions sécurisées entre les fournisseurs. |
Déployer sur des environnements appartenant à des clients
Votre modèle métier peut vous obliger à héberger l’application ou ses composants dans l’environnement Azure d’un client. Le client gère son propre abonnement Azure et paie directement le coût des ressources requises pour exécuter l’application. En tant que fournisseur de solutions, vous êtes responsable de la gestion de la solution, comme le déploiement initial, l’application de la configuration et le déploiement de mises à jour sur l’application.
Dans de telles situations, les clients apportent souvent leur propre réseau et déploient votre application dans un espace réseau qu’ils définissent. Les applications managées Azure offrent des fonctionnalités pour faciliter ce processus. Pour plus d’informations, consultez Utiliser un réseau virtuel existant avec des applications managées Azure.
Considérations sur la conception
Plages d’adresses IP et conflits. Lorsque les clients déploient et gèrent des réseaux virtuels, ils sont responsables de la gestion des conflits et de la mise à l’échelle du réseau. Toutefois, vous devez anticiper différents scénarios d’utilisation des clients. Planifiez les déploiements dans des environnements avec un espace d’adressage IP minimal à l’aide d’adresses IP efficacement et évitez les plages d’adresses IP codées en dur pour éviter les chevauchements avec les plages de clients.
Vous pouvez également déployer un réseau virtuel dédié pour votre solution. Vous pouvez utiliser private Link ou le peering de réseaux virtuels pour permettre aux clients de se connecter aux ressources. Ces approches sont décrites dans la connectivité entre réseaux. Si vous avez défini des points d’entrée et de sortie, évaluez NAT comme une approche pour éliminer les problèmes causés par les chevauchements d’adresses IP.
Fournir un accès réseau à des fins de gestion. Passez en revue les ressources que vous déployez dans des environnements clients et planifiez la façon dont vous y accéderez pour surveiller, gérer ou reconfigurer ces ressources. Lorsque des ressources sont déployées avec des adresses IP privées dans un environnement appartenant au client, assurez-vous que vous disposez d’un chemin réseau pour les atteindre à partir de votre propre réseau. Réfléchissez à la façon dont vous facilitez les modifications d’application et de ressources, telles que l’envoi (push) d’une nouvelle version de l’application ou la mise à jour d’une configuration de ressource Azure.
Dans certaines solutions, vous pouvez utiliser des fonctionnalités fournies par des applications managées Azure, telles que l’accès juste-à-temps et le déploiement de mises à jour sur des applications. Si vous avez besoin d’un contrôle supplémentaire, vous pouvez héberger un point de terminaison au sein du réseau du client auquel votre plan de contrôle peut se connecter, en fournissant l’accès à vos ressources. Cette méthode nécessite des ressources et un développement Azure supplémentaires pour répondre aux exigences de sécurité, opérationnelles et de performances. Pour obtenir un exemple d’implémentation de cette approche, consultez l’exemple de mise à jour des applications managées Azure.
Recommandations de conception
| Recommandation | Avantage |
|---|---|
| Utilisez des applications managées Azure pour déployer et gérer des ressources déployées par le client. | Les applications managées Azure offrent une gamme de fonctionnalités qui vous permettent de déployer et de gérer des ressources au sein de l’abonnement Azure d’un client. |
| Réduisez le nombre d’adresses IP que vous consommez dans l’espace réseau virtuel du client. | Les clients ont souvent une disponibilité d’adresse IP restreinte. En minimisant votre empreinte et en découplant votre mise à l’échelle de l’utilisation de leur adresse IP, vous pouvez élargir le nombre de clients qui peuvent utiliser votre solution et activer des niveaux de croissance plus élevés. |
| Planifiez comment obtenir un accès réseau pour gérer les ressources dans les environnements clients, en tenant compte de la surveillance, des modifications de configuration des ressources et des mises à jour d’application. | Vous pouvez configurer directement les ressources que vous gérez. |
| Déterminez si vous souhaitez déployer un réseau virtuel dédié ou l’intégrer au réseau virtuel existant d’un client. | En planifiant à l’avance, vous vous assurez que vous pouvez répondre aux exigences de vos clients en matière d’isolation, de sécurité et d’intégration avec leurs autres systèmes. |
| Désactivez l’accès public sur les ressources Azure par défaut. Préférez l’entrée privée si possible. | Vous réduisez l’étendue des ressources réseau que vous et vos clients devez protéger. |
Ressources supplémentaires
L’architecture multilocataire est une méthodologie métier de base pour la conception de charges de travail SaaS. Ces articles fournissent plus d’informations sur la conception du réseau :
- Approches architecturales pour la mise en réseau dans les solutions multilocataires
- Modèles de location
- Topologie de mise en réseau hub-and-spoke
- Considérations relatives à Azure NAT Gateway pour l’architecture mutualisée
- Approches architecturales pour l’intégration des locataires et l’accès aux données
Étape suivante
Découvrez les considérations relatives à la plateforme de données pour l’intégrité et les performances des données pour les charges de travail SaaS sur Azure.