Architecture cloud en mutation
L’une des choses les plus intéressantes de l’informatique est à quel point elle peut être cyclique, notamment en ce qui concerne l’architecture. À l’instar de la mode, ce qui était autrefois considéré comme démodé ou obsolète semble toujours revenir au goût du jour sous une forme ou une autre, généralement avec une nouvelle méthode, un nouveau processus ou une nouvelle procédure.
Prenons l’exemple de l’architecture WAN. Historiquement, les réseaux ont été construits avec un seul objectif : acheminer le trafic des utilisateurs vers le data center (où étaient hébergées les applications d’entreprise). Pour ce faire, nous utilisions des réseaux en étoile dans lesquels le ou les data center(s) devenaient le site hub. De même, le trafic provenant des sites en étoile faisait l’objet d’un backhauling vers ce hub afin d’atteindre la destination voulue, qu’il s’agisse d’Internet ou d’une application interne.
Quelques années plus tard, cette architecture a été jugée totalement inefficace. Avec l’essor des fournisseurs de logiciels et d’infrastructures en tant que services, davantage de trafic était destiné à Internet. Le détournement de ce trafic via un site hub avait donc un impact négatif sur l’expérience utilisateur et les performances des applications. La notion d’une architecture WAN directe vers Internet (réseau WAN défini par logiciel) a alors été introduite, dans laquelle le trafic Internet pourrait s’échapper localement, au lieu de passer par un site hub. Bien que cela ait considérablement amélioré la latence des applications et l’expérience globale, la sécurité a été quelque peu reléguée au second plan, car le trafic n’avait plus de point d’étranglement facile à contrôler ou à surveiller. Au lieu de cela, les entreprises ont été contraintes de sécuriser des dizaines, des centaines, voire des milliers de connexions Internet en étoile.
Face à l’augmentation des incidents de sécurité, les entreprises ont cherché à revenir à un modèle architectural centré sur le hub dans lequel le trafic passe par un point d’étranglement afin de faciliter l’application de politiques de sécurité, mais (espérons-le) sans pénaliser le temps de latence ou l’expérience.
Aujourd’hui, avec l’introduction des installations de colocation, nous revenons à un modèle en étoile, mais avec une redirection plus efficace. Grâce aux installations de colocation, les clients peuvent épingler le trafic Internet vers des sites de colocation proches qui offrent des interconnexions à haut débit avec les principaux fournisseurs IaaS et SaaS. On pourrait considérer cette nouvelle architecture mixte comme une approche multi-étoile. Bien que le trafic Internet doive subir une légère pénalité de détournement pour passer par la colocation la plus proche, nous pouvons compenser cette pénalité grâce à une sécurité plus robuste, des hubs plus proches et des connexions à haut débit vers la destination voulue.
Quel est donc le lien avec une architecture cloud en pleine mutation ? Il est amusant de constater que les architectures cloud ont connu les mêmes types de transitions architecturales et, à bien des égards, ont reproduit les mêmes épreuves que les architectures WAN traditionnelles, même si c’est un peu à l’envers. Il y a plusieurs années, si votre entreprise avait choisi d’entreprendre une migration vers le cloud, vous vous seriez probablement retrouvé à construire plusieurs VNet ou VPC et à desservir chaque VNet ou VPC avec son propre ensemble de ressources dédiées, telles que des pare-feu, des proxys, des équilibreurs de charge, etc. Chaque VNet/VPC était une « île en soi », à l’instar d’une filiale ou d’un site de type « spoke ».
Cependant, les administrateurs ont rapidement compris que ce modèle était coûteux sur le plan opérationnel et qu’il était difficile de le faire évoluer au fur et à mesure que la migration vers le cloud prenait de l’ampleur C’est donc tout naturellement que le concept de réseau en étoile a été introduit pour permettre aux entreprises de centraliser les ressources partagées (comme les pare-feu) dans un hub VNet/VPC, réduisant ainsi la charge opérationnelle et la complexité. Mais même ce concept présentait des difficultés, car les appairages « spoke vers hub » s’accompagnaient souvent de limitations de la bande passante et ajoutaient des coûts ou une certaine complexité, en particulier lorsque les entreprises s’étendaient sur plusieurs régions de cloud
Les fournisseurs de cloud ont cependant vu ce défi comme une opportunité de s’améliorer. C’est ainsi qu’est né le concept de services de réseau de hub dédiés, tels qu’AWS Transit Gateway et Microsoft Azure vWAN. Vous remarquerez peut-être que le concept de ces services ressemble étrangement à l’architecture WAN multi-étoile évoquée précédemment. Dans le modèle cloud, les clients peuvent instancier des hubs virtuels régionalement proches des charges de travail qu’ils desserviront. Chaque hub est ensuite interconnecté à d’autres hubs ainsi qu’au réseau backbone mondial du fournisseur de cloud, ce qui facilite la fourniture d’un transport à haut débit dans le monde entier et la mise en œuvre de la sécurité de manière évolutive.
À l’heure actuelle, de nombreux clients de Zscaler optent pour de tels modèles à mesure qu’ils poursuivent leur migration vers le cloud. Mais comment mettre en œuvre une sécurité Zero Trust évolutive dans cette architecture ?
Mise en œuvre du modèle Zero Trust avec Zscaler Workload Communications
Zscaler Workload Communications est mis en œuvre sous la forme d’appliances de connecteur pour le cloud et les filiales. Ces appliances sont des machines virtuelles légères qui existent dans le cloud ou sur le réseau sur site et fournissent un service de transport hautement fiable vers Zscaler Zero Trust Exchange. Elles sont faciles à déployer, évolutives, performantes et fournissent un transfert de trafic intelligent pour toutes les charges de travail qui les utilisent comme passerelle. Elles peuvent être déployées n’importe où au sein du réseau cloud, mais le sont très souvent dans un modèle de services partagés (en étoile), car celui-ci offre généralement le meilleur rapport qualité-prix.
De même, pour les clients qui débutent leur parcours avec des empreintes plus petites ou des cas d’utilisation plus spécifiques, les Cloud Connector distribués sont également pris en charge :
Dans les deux modèles, les connecteurs cloud/filiale établissent des tunnels dynamiques UDP/443 (DTLS) vers Zero Trust Exchange. Le trafic dirigé vers les appliances sera chiffré avec l’algorithme AES-256, encapsulé et envoyé au point de présence Zscaler le plus proche pour traitement. Bien que cet article se concentre principalement sur le trafic lié à Internet, les appliances de connexion au cloud et aux filiales sont également largement utilisées pour prendre en charge le trafic est-ouest (déplacement latéral). Dans ce scénario, le trafic se déplaçant entre les charges de travail dans le cloud ou la filiale est canalisé par les appliances de connexion au cloud/à la filiale au lieu d’être acheminé directement. Dans un prochain article de blog, nous verrons comment la solution d’accès privé, Zscaler Private Access (ZPA), associée au connecteur cloud et filiale, peut être configurée pour fournir une sécurité de bout en bout, hautement segmentée et pilotée par des politiques pour ce trafic.
Mise en œuvre de Zscaler Workload Communications dans Microsoft vWAN
Récemment, Microsoft a poussé bon nombre de ses clients vers le vWAN, car celui-ci a désormais atteint un niveau de maturité et de fonctionnalités qui justifie une utilisation en production. Pour la plupart des clients, cela signifie généralement instancier le service vWAN et créer des vHubs dans chacune des régions dans lesquelles résident leurs charges de travail cloud. À partir de là, les VNet du spoke sont ensuite appairés avec leur vHub régional respectif.
Il existe alors deux approches pour mettre en œuvre Zscaler Workload Communications dans cette architecture. Dans les deux modèles, les appliances Cloud Connector existent à partir d’un appairage VNet et ne sont pas instanciées directement dans le vHub.
Dans le premier modèle (qui ressemble vaguement au modèle WAN distribué décrit précédemment), les appliances Cloud Connector sont placées à côté des charges de travail qu’elles desserviront au sein du même réseau virtuel :
Ce modèle peut être envisagé lorsqu’un contrôle granulaire est nécessaire pour chaque réseau virtuel, par exemple pour contrôler le trafic se déplaçant latéralement ou pour mettre en place une politique d’accès granulaire à Internet. Vous pourrez également vous renseigner sur les options qui s’offrent à vous lors de la mise en œuvre de l’appairage VNet afin de tenir compte de la manière dont les charges de travail cloud exploiteront (ou non) Cloud Connector lorsqu’elles contacteront d’autres ressources VNet. En outre, il est important de planifier et de prendre en compte la croissance de ce modèle, car les ressources de calcul et natives (telles que l’équilibreur de charge standard, la passerelle NAT, etc.) peuvent rapidement devenir fastidieuses lorsqu’elles sont mises en œuvre sur des dizaines, voire des centaines de VNet.
Ce modèle nécessitera également probablement deux tables de routage distinctes : une pour la ou les charges de travail, dont la route par défaut pointe vers l’équilibreur de charge, et une pour le Cloud Connector, dont la route par défaut pointe vers « Internet » (passerelle NAT) :
Le second modèle est un modèle de services partagés (en étoile). Il s’agit du modèle de déploiement le plus courant auprès des clients, car il est plus efficace sur le plan opérationnel, plus évolutif et permet de maintenir les coûts à un niveau minimum :
Ici, les VNet du spoke envoient le trafic au vHub, qui dirige ensuite le trafic vers le VNet de service (Cloud Connector) pour traitement. Dans ce modèle, nous nous appuyons généralement sur la table de routage vHub pour influencer le trafic depuis les emplacements du spoke vers les appliances Cloud Connector en propageant une route par défaut. Cependant, contrairement au premier modèle, les tables de routage ne sont pas requises dans le VNet du spoke ou dans le VNet du hub/des services partagés Le VNet du spoke héritera simplement de sa route par défaut via la propagation vHub et le VNet du hub/des services partagés utilisera la route Internet « par défaut » que Microsoft installe directement. Gardez toutefois à l’esprit que vous devez désactiver la propagation de la route par défaut sur le VNet du hub/des services partagés. Faute de quoi, la route par défaut du vHub remplacera la route par défaut installée par Microsoft et créera une asymétrie de route.
Vous souhaiterez peut-être également adopter une approche mixte de ces architectures (qui est d’ailleurs entièrement prise en charge). Dans ce cas, certaines appliances Cloud Connector sont placées dans le VNet de la charge de travail (pour répondre à un cas d’utilisation ou à une nuance spécifique), tandis que d’autres appliances Cloud Connector sont placées dans le VNet du hub/des services partagés :
REMARQUE : l’ancienne solution « Secure vHub » de Zscaler est obsolète et n’est plus prise en charge. Nous vous recommandons désormais de continuer avec Cloud Connector. Bien que Cloud Connector ne corresponde pas techniquement à la définition de « Secure vHub » de Microsoft, il offre des performances supérieures et une meilleure résilience que la solution traditionnelle.
Ce qu’il faut garder à l’esprit :
Quelle que soit l’architecture Microsoft vWAN que vous souhaitez déployer, certains éléments ont tendance à causer des problèmes si vous n’y faites pas attention :
- Tables de routage : dans un modèle colocalisé, des tables de routage sont requises dans les VNet du spoke afin de diriger le trafic via les appliances Cloud Connector locales. Dans le deuxième modèle (en étoile), les tables de routage définies par l’utilisateur ne sont pas obligatoires, mais facultatives. Si vous souhaitez définir vos propres tables de routage, soyez prudent lors de l’installation de routes, car les routes définies par l’utilisateur remplaceront les routes propagées par vHub.
- Propagation de la route : dans un modèle en étoile, lors de la configuration de la route par défaut sur vHub, soyez sélectif quant à l’endroit où propager cette route. La propagation de la route sur le VNet de Cloud Connector (hub/services partagés) pourrait provoquer une boucle de route.
- Sélection de la région : assurez-vous que votre vHub se trouve dans la même région que l’équilibreur de charge standard et les appliances Cloud Connector vers lesquels il transmettra le trafic. Microsoft n’empêche pas un utilisateur d’appairer des régions disparates, mais la route par défaut ne transmettra plus correctement le trafic vers l’équilibreur de charge (interrompant la connexion Internet sortante).
- Groupes de sécurité réseau : par défaut, les groupes de sécurité réseau (NSG) du Cloud Connector restreignent le trafic entrant des VNet distants, autorisant uniquement le trafic du VNet local. Bien que cela soit acceptable dans un modèle colocalisé (dans lequel les appliances Cloud Connector se trouvent dans le même VNet que les charges de travail), cela créera des problèmes dans un modèle en étoile. Par conséquent, il sera nécessaire d’ajuster les groupes de sécurité réseau pour autoriser le trafic provenant des VNet du spoke.
- Système de noms de domaine (DNS) : réfléchissez à la manière dont les requêtes DNS sortantes seront traitées. Zscaler Private Access exploite largement le DNS pour influencer le trafic de charge de travail à charge de travail via le Cloud Connector. Pour ce faire, le Cloud Connector doit disposer d’une visibilité sur la requête DNS d’origine de la charge de travail. Dans un modèle colocalisé, cela peut se produire naturellement lorsque la requête DNS passe par le Cloud Connector pour atteindre le serveur DNS du cloud. Dans un modèle en étoile, cela peut s’avérer délicat et nécessiter la mise en œuvre d’outils natifs tels que Azure DNS Private Resolver.
Conclusion
Dans cet article, nous avons exploré certaines des architectures cloud les plus courantes déployées par nos clients dans leurs environnements cloud. En ce qui concerne le vWAN de Microsoft Azure, nous recommandons deux (trois, si vous comptez l’option mixte) architectures principales : les appliances Cloud Connector colocalisées et les appliances Cloud Connector centralisées. Le choix de l’option dépend fortement des cas d’utilisation et des exigences de sécurité du client. Regardez certaines de nos vidéos éducatives et testez Cloud Connector dans le cadre de nos sessions de laboratoire pratiques. Cliquez ici pour plus de détails.
