Sécuriser les charges de travail dans des environnements multiclouds avec Zscaler Zero Trust Exchange

Le cloud est devenu le nouveau data center pour la plupart des entreprises, les environnements multi-cloud devenant de plus en plus la norme. Les charges de travail du cloud doivent pouvoir communiquer entre elles et avec Internet en toute sécurité. Hélas, les solutions disponibles permettant de bâtir une connectivité sécurisée de cloud à cloud et de cloud à Internet à l’aide de pare-feu et de VPN afin d’étendre le WAN de l’entreprise au cloud, génèrent des risques de sécurité, des problèmes de performance et compliquent les opérations.

Difficultés liées à l’extension du réseau d’entreprise vers le cloud

Traditionnellement, deux environnements différents sont connectés à l’aide de routeurs. Comme ces routeurs sont utilisés pour faire aboutir les tunnels VPN ou IPSec et échanger des routes, chacun de ces environnements a accès à toutes les adresses IP des autres environnements. Pour contrôler l’accès entre ces environnements, des pare-feu fournissent un contrôle d’accès statique afin de garantir que seules des adresses IP spécifiques d’un environnement ont accès à des adresses IP spécifiques d’autres environnements. Il s’agit de l’approche IP et pare-feu traditionnelle que la plupart des entreprises n’ont eu d’autre choix que d’adopter. 

 

L’approche IP et pare-feu engendre des risques de sécurité, car la connectivité IP plate à maillage complet expose les réseaux aux déplacements latéraux des menaces.

Cette approche est également synonyme de complexité opérationnelle avec des charges de travail éphémères dans le cloud. Lorsque les IP vont et viennent, chaque nouvelle IP doit être propagée par les routeurs. Toute nouvelle IP doit être programmée dans le pare-feu, et si ces IP se chevauchent, il convient de résoudre ce problème avant qu’elles puissent se connecter à ces réseaux.

Enfin, cette approche présente des problèmes d’échelle et de performance tels que la mise à l’échelle des routes, des congestions de débit et une plus grande latence.

Ces inconvénients se multiplient avec l’augmentation du nombre d’applications distribuées sur plusieurs clouds et l’adoption de services cloud natifs, tels que les conteneurs, les PaaS et les services sans serveur.

Avec une approche traditionnelle, tout le trafic lié à Internet ou à d’autres charges de travail dans un autre cloud doit passer par un hub centralisé, et ce hub dispose de pare-feu, de proxys Squid, de routeurs, etc. , comme une architecture cloisonnée dans un data center. Les limitations spécifiques sont notamment :

 

 

1. Posture de sécurité limitée :

Des capacités supplémentaires telles qu’un proxy et la protection des données sont indispensables pour une posture de sécurité complète, car l’inspection SSL à grande échelle n’est pas possible avec des pare-feu virtuels. Cela se traduit par des appliances virtuelles supplémentaires pour les proxys Squid, le sandboxing, etc.

2. Risques liés à un réseau maillé complet :

Pour permettre la communication de la charge de travail dans un environnement multi-cloud, l’architecture IP traditionnelle distribue les routes et partage les informations relatives aux IP et aux sous-réseaux entre les différents environnements, créant ainsi un réseau plat et des règles de pare-feu statiques faciles à contourner avec un risque de déplacement latéral des menaces.

3. Limitation au niveau des performances des appliances :

Le débit est limité par le maillon le plus faible, en l'occurrence, l’échelle et les performances du pare-feu. Plus vous activez de services de sécurité sur les pare-feu, tels que l’inspection SSL du contenu, plus les performances ralentissent.

4. Frais généraux d’orchestration et de gestion :

Les pare-feu traditionnels nécessitent des machines virtuelles supplémentaires pour l’orchestration, la politique, les opérations et la gestion des licences, et ajoutent ainsi un niveau supplémentaire de complexité et de coût. La reproduction de cette configuration pour chaque fournisseur de cloud ajoute une charge supplémentaire pour les opérations multi-cloud.

5. Angles morts liés aux sauts multiples vers une destination :

Les approches traditionnelles basées sur les IP requièrent de nombreux outils tels que des pare-feu, des routeurs SD-WAN, des NACL et des groupes de sécurité. Chacun d’entre eux nécessite sa propre journalisation, et une corrélation incorrecte des journaux crée des angles morts supplémentaires pour les équipes de mise en réseau et de sécurité.

Étendre la stratégie Zero Trust aux charges de travail dans le cloud

Heureusement, nous avons déjà observé les défis que pose le WAN d’entreprise pour l’accès des employés au cours des dernières années. Pour surmonter les lacunes en matière de sécurité et de performances de l’approche IP et pare-feu, un pourcentage croissant d’entreprises a adopté une stratégie Zero Trust. Ces mêmes principes de Zero Trust, réinventés pour les besoins spécifiques des charges de travail dans le cloud, sont la solution pour les réseaux multi-cloud.

Avec la stratégie Zero Trust, les réseaux ne sont jamais considérés comme fiables, de sorte que les informations d’IP et de routage ne sont jamais échangées. La connectivité est activée à un niveau granulaire pour les charges de travail en fonction de l’identité et du contexte; il n’est donc pas nécessaire de créer des règles de pare-feu statiques pour restreindre l’accès IP entre les environnements.

 

Zscaler Internet Access (ZIA) et Zscaler Private Access (ZPA) sont les leaders du marché en matière de sécurisation de l’accès des utilisateurs finaux à Internet et aux applications privées. La solution Workload Communications de Zscaler, soutenue par Cloud Connector, étend ces solutions pour sécuriser l’accès des charges de travail à Internet (ZIA pour les charges de travail) et sécuriser l’accès privé aux charges de travail privées distantes (avec ZPA pour les charges de travail).Cette nouvelle approche révolutionnaire permet simultanément d’améliorer la sécurité, de réduire la complexité opérationnelle et d’améliorer les performances des applications.

 

Cas d’utilisation 1 : instaurer Zero Trust pour la communication des charges de travail vers Internet

Cloud Connector permet aux charges de travail de se connecter directement au cloud Zscaler pour accéder à Internet. Tous les services de sécurité, tels que le proxy SSL, la protection des données et la protection avancée contre les menaces, s’exécutent en mode natif dans Zero Trust Exchange. Avec cette architecture, vous pouvez appliquer la même politique de sécurité à toutes les charges de travail accédant à Internet depuis n’importe quel cloud. Cette configuration contraste fortement avec les architectures traditionnelles où vous devez construire une architecture cloisonnée avec des pare-feu et des proxys Squid dans chaque cloud.

 

Cas d’utilisation 2 : instaurer Zero Trust pour la communication de charge de travail à charge de travail dans un environnement multi-cloud

Cloud Connector permet aux charges de travail de se connecter directement au cloud Zscaler. Les charges de travail provenant de n’importe quel cloud (AWS, Azure, data center) peuvent communiquer entre elles via Zero Trust Exchange. Zero Trust Exchange s’appuie sur l’identité et le contexte pour vérifier la fiabilité, et établit ensuite la connexion. Cette configuration contraste fortement avec les architectures traditionnelles où un routage IP est indispensable entre ces environnements cloud.

 

Cas d’utilisation 3 : instaurer Zero Trust pour les communications de charge de travail à charge de travail au sein d’un VPC/VNET

Zscaler Workload Segmentation élève la segmentation à un niveau granulaire, à l’intérieur d’une machine virtuelle, au niveau d’une application ou d’un processus individuel. Un agent de segmentation de la charge de travail fournit une identité logicielle en générant des empreintes digitales au niveau du processus. L’apprentissage automatique détecte tous les chemins disponibles vers un processus ou une application particulière et formule une recommandation sur les chemins autorisés, en écartant tous les chemins inutiles qui augmentent le risque de déplacement latéral des menaces. Cette configuration contraste avec les architectures traditionnelles qui utilisent des ACL (listes de contrôle d’accès) et des SG (groupes de sécurité) statiques qu’un attaquant peut facilement contourner en se greffant sur une règle existante.

Comment Zero Trust résout les limitations de l’IP et du pare-feu

 

 

Lorsque nous avons examiné les architectures traditionnelles, le problème sous-jacent commun s’est révélé être la connectivité IP. La mise en réseau et la sécurité sont traditionnellement considérées comme des fonctionnalités distinctes. La connectivité (routage IP) est activée en premier lieu, puis la sécurité (filtrage par pare-feu) est activée par-dessus. Certains fournisseurs ont intégré les deux dans une seule appliance, mais l’approche et l’architecture restent les mêmes.

Zero Trust Exchange de Zscaler adopte une approche totalement différente : la sécurité d’abord, la connectivité ensuite. Pourquoi créer une connectivité inutile qu’il vous faudra bloquer plus tard ?

Dans la stratégie Zero Trust de Zscaler, nous ne faisons confiance à personne. La seule connectivité par défaut de la source est Zero Trust Exchange, et non l’application de destination. Tout le trafic des charges de travail est transmis à Cloud Connector qui connecte ensuite ces charges de travail à Zero Trust Exchange.

Avant de connecter la source et la destination, Zero Trust Exchange passe par les étapes suivantes :