Ne laissez pas votre réseau constituer un obstacle à la segmentation de la charge de travail

La sécurité et la mise en réseau sont depuis longtemps une source de priorités contradictoires. Lors de la conception d'un centre de données traditionnel ou d'une structure cloud hybride, la priorité de l'architecture réseau est la fourniture fiable et résiliente du trafic. Le réseau est peut-être la ressource la plus critique de tout centre de données ou architecture cloud. Après tout, les charges de travail, les clients et les bases de données ne peuvent communiquer entre eux que s'il existe un réseau entre eux. Et tous les réseaux fonctionnent en prenant des décisions de transfert sur la base de l'analyse des en-têtes des paquets et de diverses autres mesures. De plus, les routeurs et les commutateurs échangent des informations sur les concepts de couche 2 et de couche 3, qui sont tous deux largement indépendants des détails spécifiques à l'application contenus au plus profond de la charge utile des données des paquets. Les réseaux sont principalement axés sur la transmission fiable et rapide du trafic, plutôt que sur les données d'application contenues dans ce trafic.

Alors, lorsqu'il s'agit de sécuriser ces applications, et leurs charges de travail, pourquoi continuons-nous à envisager des approches liées au réseau ? Explorons comment faire évoluer votre approche afin que le réseau ne soit plus un obstacle à la fourniture agile des charges de travail, à l'automatisation et à la sécurité.

Fonctionnement interne des charges de travail modernes

Les charges de travail, qui communiquent sur n'importe quel réseau, sont conçues pour le faire en fonction des priorités spécifiques à l'application. L'activité d'une charge de travail est plus importante que l'apparence de la structure réseau sous-jacente. Les clients communiquent avec les charges de travail, et les charges de travail communiquent avec les bases de données sur la base de concepts qui ne dépendent généralement pas des détails contenus dans les en-têtes de paquets réseau.

Contrairement aux charges de travail classiques, les charges de travail modernes sont largement abstraites au-dessus des ressources du réseau ou du serveur sous-jacents. Il est supposé que la présence d'une charge de travail sur n'importe quelle ressource sous-jacente est transitoire et peut être migrée dynamiquement en direct entre les hôtes, les centres de données et les clouds. Ces migrations se produisent généralement de manière dynamique, sans direction humaine manuelle. En raison de cette abstraction des charges de travail au-dessus des ressources sous-jacentes, il n'est plus réaliste de considérer l'adresse IP d'une charge de travail comme une forme d'identité utile pendant toute la durée de vie de cette charge de travail. Une charge de travail peut avoir de nombreuses adresses IP différentes au cours de son cycle de vie, ce qui affecte directement la manière dont les limites de sécurité sont définies sur les réseaux modernes.

Segmentation du réseau et pare-feux traditionnels

L'évolution des réseaux est traditionnellement lente, de par leur conception, en raison de la nature critique des structures de réseaux. De nombreux réseaux de centres de données sont en grande partie plats, et de nombreuses structures de réseaux de cloud public ne contiennent que des niveaux de segmentation grossiers. Lorsque les réseaux sont segmentés dans n'importe quel environnement, cela est généralement fait pour répondre à des priorités spécifiques au réseau, par exemple pour isoler de larges catégories de ressources, comme une zone démilitarisée, un segment WAN, un segment de campus ou les segments Web/App/Dev traditionnels. La segmentation d'un réseau est également motivée par l'optimisation des performances du réseau, l'augmentation du débit, la mise en œuvre de la redondance des chemins ou l'amélioration de l'efficacité de tâches telles que la synthèse des itinéraires, Spanning Tree et ECMP.

Les segments de réseau sont généralement mis en œuvre en créant des VLAN et des sous-réseaux, soit sur des réseaux « sous-jacents » existants, soit sur des réseaux « superposés », mis en œuvre à l'aide de contrôleurs SDN et de tunnels tels que VXLAN. Que la topologie soit sous-jacente ou superposée, tous ces segments de réseau se terminent sur des routeurs ou des commutateurs, qu'ils soient matériels ou virtuels. Et la mise en œuvre de la sécurité sur ces segments se fait généralement à l'aide de pare-feux réseau.

Les pare-feux considèrent généralement n'importe quel segment comme un groupe de plages IP avec les ports TCP/UDP associés ou comme des zones, qui sont un ensemble de segments, ainsi que les ports à bloquer ou à autoriser entre les plages IP pertinentes. Les pare-feux réseau n'implémentent pas de sécurité basée sur le contenu spécifique à l'application de la charge utile de données d'un paquet. Les pare-feux considèrent l'adresse IP et le port de destination ou source d'un paquet comme l'identité de la charge de travail. Même avec le moderne pare-feux « nouvelle génération », qui sont capables de prendre des décisions en fonction des données d'application contenues au plus profond du paquet, la majorité des règles de pare-feu sont toujours configurées selon des plages d'adresses IP et de ports traditionnelles. Les vieilles habitudes ont la vie dure.

Rompre avec les traditions

La philosophie DevOps met fortement l'accent sur la rapidité de déploiement et sur l'automatisation. Et, comme mentionné, les modifications apportées aux segments de réseau et les pare-feux sont généralement lents et manuels. L'automatisation des modifications apportées aux réseaux et à la sécurité se heurte souvent à des obstacles opérationnels, qui peuvent être difficiles à modifier. Il en résulte que la sécurité est souvent reléguée au second plan, car elle ne fait que ralentir les processus. En général, les charges de travail sont déployées rapidement et avec agilité, et la sécurité ne redevient une priorité qu'en cas de violation et de litige. Personne ne veut être la personne qui expliquera au PDG pourquoi la sécurité n'était pas une priorité et pourquoi son entreprise est aujourd'hui poursuivie en justice.

Amazon a exprimé ce conflit de priorités entre l'agilité de la charge de travail et les changements du réseau en 2012 en disant : « Le réseau me gêne ». Le réseau et l'évolution de ses segments constituent des obstacles aux déploiements agiles des charges de travail. Donc, segmentation du réseau n'est souvent pas fait, ou cela est fait de manière très grossière par des équipes de mise en réseau.

Et si la segmentation et la sécurité du réseau pouvaient être mises en œuvre directement depuis la charge de travail ? Plus besoin d'attendre que les opérations réseau mettent en œuvre la segmentation dans la structure réseau sous-jacente.

Et si vous pouviez implémenter les segments requis directement à partir du même processus agile que le déploiement d'une charge de travail via le processus DevOps ?

Et, plus important encore, et si la sécurité entre ces segments pourrait-elle être définie à l'aide d'une politique de langage naturel, plutôt que de s'appuyer sur des règles de pare-feu IP/port obsolètes ? Il n'y a plus de politique définie à l'encontre de l'adresse IP source et des ports pointant vers l'IP et les ports de destination, car ceux-ci ne sont plus liés aux charges de travail tout au long de leur cycle de vie.

Et si vous pouviez rédiger une politique qui reflète la façon dont les utilisateurs perçoivent les ressources, telle que « Seuls les serveurs Web déployés à New York peuvent communiquer avec les serveurs de base de données à Londres ? »

Et si tu pouvais définir cela selon une approche granulaire, en obtenant une véritable approche Zero Trust « microsegmentée », telle que « Seul le serveur Web-1 peut communiquer avec le serveur Web-2 au même endroit » ?

Une architecture réseau comporte quatre grandes couches dans lesquelles la politique peut être appliquée, comme illustré dans ce schéma :

Au fur et à mesure que vous montez les couches, la politique est exprimée dans un langage plus naturel, indépendant des couches inférieures. L'application d'une politique de charge de travail directement aux charges de travail permet aux couches inférieures de se concentrer sur les priorités du réseau.

En permettant aux outils de couche de travail de définir la segmentation et l'application entre les charges de travail, de manière abstraite au-dessus de la structure du réseau sous-jacent, les équipes chargées des opérations réseau ne sont pas obligées de voir les exigences des applications influencer la conception du réseau. L'extension de la segmentation et de l'application des applications à la couche de charge de travail permet aux équipes chargées des opérations réseau de concevoir des structures réseau en fonction des priorités du réseau.

Les pare-feux seront toujours utilisés pour créer de larges segments au sein de la structure, comme cela a toujours été fait, mais il n'est plus nécessaire de créer un nombre important de VLAN ou de sous-réseaux pour répondre aux exigences de segmentation des applications. Les architectes réseau peuvent plutôt se concentrer sur les priorités du réseau lors de la conception segmentation du réseau, tels que le débit, la redondance, la synthèse des itinéraires, Spanning Tree et ECMP. La segmentation des applications ne doit plus compliquer la conception du réseau. Le fait que les charges de travail créent et appliquent des limites de segmentation permet également au réseau d'être le premier à rechercher les causes lors de la résolution des problèmes de sécurité.

Une segmentation moderne pour des charges de travail modernes

ceux d'Illumio Plateforme de sécurité adaptative (ASP) permet la microsegmentation entre les charges de travail, essentielle pour créer un véritable Architecture Zero Trust, et utilise des expressions en langage naturel pour définir la politique entre ces charges de travail. Cela vous donne une carte des dépendances des applications qui fournit une image claire des charges de travail qui communiquent entre elles et des personnes qui établissent des connexions avec qui, sur l'ensemble de votre structure de cloud hybride. Bien que vous ayez une visibilité complète sur l'adressage IP utilisé par les charges de travail, aucune politique ne doit être définie en fonction de l'adressage IP, car l'association entre l'adressage réseau et les applications est transitoire.

Illumio utilise des étiquettes pour identifier les charges de travail par rapport à des critères qui sont résumés au-dessus du segment du réseau cloud hybride sous-jacent sur lequel elles sont hébergées :

• Ces étiquettes incluent des métadonnées associées aux charges de travail, quelle que soit leur adresse IP actuelle.
• Les libellés sont Rôle, Application, Environnement et Emplacement (« RAEL »).
• Ils sont utilisés pour définir des segments entre les charges de travail, et l'application entre ces charges de travail étiquetées est définie à l'aide d'expressions en langage naturel, telles que les charges de travail Web peuvent communiquer avec les charges de travail des applications, mais seules les charges de travail des applications peuvent communiquer avec les charges de travail de la base de données. La politique n'est pas spécifique à l'adressage IP.
• Illumio traduit ensuite ces règles de politique basées sur des étiquettes en configurations spécifiques aux capacités de filtrage réseau du système d'exploitation qui exécute actuellement ces charges de travail : Linux iptables et ipsets, Windows Filtering Platform (WFP) ou la table d'état IPFilter pour les charges de travail Solaris et AIX.

Comme Illumio vous permet de définir une politique d'une manière totalement abstraite, indépendamment de la manière et de l'endroit où une charge de travail est hébergée, les priorités réseau et les priorités des applications ne sont plus en conflit.

En résumé

Dans les architectures de réseau de centres de données et de cloud hybrides modernes, le périmètre est simplement défini comme l'endroit où votre charge de travail est actuellement hébergée, et cette charge de travail peut être déplacée de manière dynamique sur n'importe quel segment du cloud. L'ancienne définition du périmètre, qui se situait entre le centre de données et Internet, n'est plus pertinente, et il est difficile d'adapter l'architecture du réseau pour permettre la microsegmentation au-delà des limites des applications. Les solutions SDN utilisant des contrôleurs et des réseaux superposés qui se terminent par des hyperviseurs déplacent efficacement la frontière entre le réseau et les charges de travail jusqu'à l'hôte, mais elles reposent toujours sur la définition de segments « de bas en haut » : depuis la couche réseau pour résoudre un problème dans la couche de charge de travail.

Une approche beaucoup plus évolutive dans les structures cloud modernes consiste à accéder à la charge de travail pour créer des microsegments et appliquer des politiques adaptées aux charges de travail, libérant ainsi la segmentation du réseau à définir en fonction de priorités pertinentes pour la conception du réseau. Le réseau n'est plus un obstacle charge de travail des applications agilité et sécurité. Et le réseau n'est plus en première ligne lorsque sécurité des applications le dépannage se produit, ce qui réduit le risque d'être pointé du doigt lors des réponses aux incidents.

Consultez ceci vidéo pour un aperçu rapide de l'évolution de la segmentation et pour en savoir plus sur notre solution ici.