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 :
Étape 1 : qui êtes-vous ?
Zero Trust Exchange vérifie la provenance des charges de travail, par exemple un Cloud Connector authentifié et enregistré, ou un VPC ou VNET client.
Étape 2 : où allez-vous ?
Vous pouvez définir une politique basée sur la destination : Zero Trust Exchange peut vérifier si la destination est une application approuvée ou non.
Étape 3 : quel est votre niveau de risque ?
Vous pouvez recourir à une politique basée sur une source VPC/VNET. Seuls les VPC d’entreprise sont autorisés à accéder à certaines destinations; toutefois, les VPC/VNET partenaires, qui sont considérés comme risqués, ne peuvent pas y accéder.
Étape 4 : transportez-vous des éléments nuisibles ?
Pour les destinations Internet non fiables, vous pouvez activer le proxy SSL intégral et inspecter la totalité des données en provenance de la source vers la destination et vice-versa.
Étape 5 : établir la connexion
Pour les destinations Internet, nous établissons une connexion par proxy avec la destination. Pour l’accès aux applications privées, nous établissons une connexion de l’intérieur vers l’extérieur à partir de l’application Connector à la destination. Zero Trust Exchange est le point de rendez-vous et établit cette connexion.
Principaux avantages de la mise en œuvre de Zero Trust pour les charges de travail dans le cloud
1. Protection contre les cybermenaces pour toutes les charges de travail :
Prévenir les compromissions des charges de travail :
Une cyber inspection est effectuée pour toutes les communications des charges de travail vers Internet, ce qui protège les charges de travail contre les menaces telles que les botnets, le contenu actif malveillant et la fraude.
Empêcher le déplacement latéral des menaces à travers les clouds :
Avec la connectivité Zero Trust, chaque environnement (data center, régions de cloud, etc.) est isolé et toute destination dans d’autres environnements ne peut pas être routée. Ceci empêche tout déplacement latéral des menaces entre les environnements.
Empêcher le mouvement latéral des menaces à l’intérieur d’un data center ou d’une région de cloud :
La microsegmentation basée sur l’identité au niveau des processus empêche tout déplacement latéral des menaces à l’intérieur d’un data center ou d’une région de cloud.
2. Sécurisation des données dans les clouds SaaS et publics :
Sécuriser les données dans les clouds publics :
Assurez un accès basé sur le moindre privilège aux charges de travail en minimisant les droits (CIEM) et réduisez le risque de compromission en corrigeant les mauvaises configurations (CSPM).
Sécuriser les données SaaS :
Obtenez une visibilité sur les opérations d’informatique fantôme pour empêcher l’utilisation d’applications non approuvées et prévenir le partage excessif (API CASB).
DLP inline :
Prévenez les violations ou l’exfiltration de données en assurant une inspection par DLP de tout le trafic des charges de travail transitant par Internet.
3. Performance et évolutivité à très grande échelle :
Zscaler dispose de plus de 150 points de présence de service Zero Trust Exchange. Ces POP sont appariés avec tous les principaux fournisseurs de cloud et chacun d’entre eux dispose d’une capacité de fonctionnement de plusieurs téraoctets. Par défaut, Cloud Connector se connecte au POP qui dispose de la meilleure disponibilité et qui est le plus proche.
4. Prêt pour DevOps et entièrement automatisé :
La gestion et la politique sont gérées de manière centralisée et fournies par le cloud ; toutes les mises à niveau des Cloud Connector sont gérées par Zscaler. L’orchestration compatible avec Terraform peut être facilement intégrée au pipeline DevOps CI/CD. Les automatisations natives de la plateforme, telles que les modèles Cloudformation et Azure Resource Manager (ARM), sont également fournies d’emblée.
5. Journalisation complète et flux de journaux :
Tout le trafic sortant de n’importe quel Cloud Connector, y compris le trafic en direction de Zero Trust Exchange, est consigné et peut être diffusé vers un SIEM/agrégateur de journaux de votre choix. Un filtrage plus sophistiqué est disponible pour la diffusion vers des emplacements critiques.
Déployer Cloud Connector
Cloud Connector peut soit être déployé dans chaque VPC/VNET si l’isolation d’un VPC/VNET est requise, soit être déployé dans un emplacement central si l’isolation est requise pour un groupe de VPC/VNET. Les modèles de déploiement disposent de la flexibilité nécessaire pour prendre en charge aussi bien les déploiements centralisés que distribués.
En résumé, les charges de travail sont considérées comme des images en miroir des utilisateurs. En adoptant une architecture Zero Trust pour les communications des charges de travail, vous pouvez protéger vos données et charges de travail, éliminer les surfaces d’attaque et stopper le déplacement latéral des menaces. Nous vous invitons à nous rejoindre dans ce voyage Zero Trust qui transformera votre connectivité dans le cloud. Pour planifier une démonstration, vous pouvez nous contacter à [email protected].
