Ne laissez pas votre réseau faire 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 conflictuelles. Lors de la conception d'un centre de données traditionnel ou d'une structure de nuage hybride, la priorité de l'architecture du réseau est la livraison fiable et résiliente du trafic. Le réseau est sans doute la ressource la plus critique de tout centre de données ou de toute architecture en nuage. En effet, les charges de travail, les clients et les bases de données ne peuvent pas communiquer entre eux s'il n'y a pas de réseau. Tous les réseaux fonctionnent en prenant des décisions de transfert basées sur 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 la couche 2 et de la couche 3, qui sont tous deux largement indépendants des détails spécifiques à l'application contenus dans les données utiles des paquets. Les réseaux sont principalement axés sur la fiabilité et la rapidité du trafic, plutôt que sur les données d'application contenues dans ce trafic.

Dès lors, 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 ? Voyons comment faire évoluer votre approche pour que le réseau ne soit plus un obstacle à la fourniture agile de charges de travail, à l'automatisation et à la sécurité.

Fonctionnement interne des charges de travail modernes

Les charges de travail, qui communiquent à travers n'importe quel réseau, sont conçues pour le faire sur la base de priorités spécifiques à l'application. Ce que fait une charge de travail est plus important que l'aspect du réseau sous-jacent. 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 des paquets du réseau.

Contrairement aux charges de travail traditionnelles, les charges de travail modernes sont largement abstraites par rapport aux ressources sous-jacentes du réseau ou du serveur. On part du principe que la présence d'une charge de travail sur une ressource sous-jacente est transitoire et qu'elle peut être déplacée de manière dynamique entre les hôtes, les centres de données et les nuages. Ces migrations se produisent généralement de manière dynamique, sans intervention humaine manuelle. En raison de cette abstraction des charges de travail par rapport aux 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 pour 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 a une incidence directe sur la manière dont les limites de sécurité sont définies dans les réseaux modernes.

Segmentation traditionnelle du réseau et pare-feu

Les changements apportés aux réseaux sont traditionnellement lents, de par leur conception, en raison de la nature critique des tissus des réseaux. De nombreux réseaux de centres de données sont largement plats, et de nombreux réseaux de clouds publics ne contiennent que des niveaux de segmentation grossiers. Lorsque les réseaux sont segmentés, quel que soit l'environnement, c'est généralement pour répondre à des priorités propres au réseau, par exemple pour créer une isolation entre de grandes catégories de ressources, comme une zone démilitarisée (DMZ), un segment de réseau étendu (WAN), un segment de campus ou les segments traditionnels Web/App/Dev. D'autres raisons de segmenter un réseau sont l'optimisation des performances du réseau, l'augmentation du débit, la mise en œuvre d'une redondance des chemins ou l'amélioration de l'efficacité de tâches telles que le résumé des routes, le Spanning Tree et l'ECMP.

Les segments de réseau sont traditionnellement mis en œuvre en créant des VLAN et des sous-réseaux, soit à travers des réseaux "sous-jacents" traditionnels, soit à travers des réseaux "superposés", mis en œuvre à l'aide de contrôleurs SDN et de tunnels tels que VXLAN. Que la topologie soit superposée ou non, tous ces segments de réseau aboutissent à des routeurs ou à des commutateurs, matériels ou virtuels. La mise en œuvre de la sécurité dans ces segments se fait généralement à l'aide de pare-feu de réseau.

Les pare-feu considèrent traditionnellement tout segment comme un groupe de plages IP avec les ports TCP/UDP associés ou comme des zones, qui sont une collection de segments, avec les ports à bloquer ou à autoriser entre les plages IP concernées. Les pare-feu de réseau ne mettent pas en œuvre une sécurité basée sur le contenu spécifique à l'application de la charge utile des données d'un paquet. Les pare-feu considèrent l'adresse IP de destination ou de source et le port d'un paquet comme l'identité d'une charge de travail. Même avec les pare-feu modernes de"nouvelle génération", qui sont capables de prendre des décisions basées sur les données d'application contenues dans les paquets, la majorité des règles des pare-feu sont encore configurées selon les plages traditionnelles d'adresses IP et de ports. 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. De plus, comme nous l'avons mentionné, les modifications des segments de réseau et des pare-feux sont généralement lentes et manuelles. L'automatisation des modifications apportées aux réseaux et à la sécurité se heurte souvent à des barrières opérationnelles, qu'il peut être difficile de modifier. Il en résulte que la sécurité est souvent négligée, car elle ne fait que ralentir les processus. En général, les charges de travail sont déployées rapidement et avec souplesse, et la sécurité ne redevient une priorité qu'une fois qu'une brèche s'est produite et que l'entreprise est confrontée à un litige. Personne ne veut être la personne qui doit expliquer au PDG pourquoi la sécurité n'était pas une priorité et pourquoi son entreprise est aujourd'hui poursuivie en justice.

En 2012, Amazon a exprimé de manière célèbre ce conflit de priorités entre l'agilité de la charge de travail et les changements de réseau en disant : "Le réseau est sur mon chemin". Le réseau, et les segments de réseau changeants, sont des obstacles aux déploiements agiles de charges de travail. Ainsi, la segmentation du réseau n'est souvent pas réalisée, ou alors de manière très grossière par les équipes chargées de la mise en réseau.

Mais que se passerait-il si la segmentation et la sécurité du réseau pouvaient être mises en œuvre directement à partir de la charge de travail ? Il n'est plus nécessaire d'attendre que les opérations réseau mettent en œuvre la segmentation dans le réseau sous-jacent.

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

Et surtout, que se passerait-il si la sécurité entre ces segments pouvait être définie à l'aide d'une politique en 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 contre les IP et les ports sources pointant vers les IP et les ports de destination, puisque 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 manière dont les utilisateurs perçoivent les ressources, par exemple "Seuls les serveurs Web déployés à New York peuvent communiquer avec les serveurs de base de données situés à Londres" ?

Et si vous pouviez définir cela de manière granulaire, en adoptant une véritable approche de confiance zéro "microsegmentée", telle que "Seul le serveur Web-1 peut communiquer avec le serveur Web-2 au sein d'un même lieu" ?

L'architecture d'un réseau comporte quatre grandes couches où la politique peut être appliquée, comme l'illustre ce diagramme :

Au fur et à mesure que l'on monte dans les couches, la politique est exprimée dans un langage plus naturel, sans tenir compte des couches inférieures. L'application d'une politique de charge de travail directement au niveau des charges de travail permet aux couches inférieures de se concentrer sur les priorités du réseau.

En permettant aux outils de la couche de charge de travail de définir la segmentation et l'application entre les charges de travail, d'une manière abstraite par rapport à la structure sous-jacente du réseau, les équipes chargées de l'exploitation du réseau sont libérées de l'influence des exigences des applications sur la conception du réseau. Le fait de faire remonter la segmentation et l'application des applications jusqu'à la couche de charge de travail permet aux équipes d'exploitation du réseau de concevoir des structures de réseau en fonction des priorités du réseau.

Les pare-feu seront toujours utilisés pour créer de larges segments à travers la structure, comme cela a toujours été le cas, mais il n'est plus nécessaire de créer un nombre considérable de VLAN ou de sous-réseaux pour répondre aux exigences de segmentation des applications. Les architectes de réseau peuvent plutôt se concentrer sur les priorités du réseau lors de la conception de la segmentation du réseau, telles que le débit, la redondance, le résumé des routes, le Spanning Tree et l'ECMP. La segmentation des applications ne doit plus être un casse-tête pour 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 de ne pas être le premier à être recherché lors de la résolution des problèmes de sécurité.

Une segmentation moderne pour des charges de travail modernes

L'Adaptive Security Platform (ASP) d'Illumio permet la microsegmentation entre les charges de travail, essentielle à la construction d'une véritable architecture de confiance zéro, et utilise des expressions en langage naturel pour définir des politiques entre ces charges de travail. Il vous donne une carte des dépendances applic atives qui fournit une image claire des charges de travail qui communiquent entre elles et des personnes qui établissent des connexions avec d'autres, dans l'ensemble de votre infrastructure de cloud hybride. Et si vous avez une visibilité totale sur l'adressage IP utilisé par les charges de travail, la politique n'est pas - et ne doit pas être - définie en fonction de l'adressage IP, car l'association entre l'adressage réseau et les applications est éphémère.

Illumio utilise des étiquettes pour identifier les charges de travail en fonction de critères qui sont abstraits au-dessus de n'importe quel segment du réseau hybride sous-jacent sur lequel elles sont hébergées :

• Ces étiquettes comprennent des métadonnées associées aux charges de travail, indépendamment de leur adresse IP actuelle.
• Les étiquettes sont Role, Application, Environment, and Location ("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 App, mais seules les charges de travail App peuvent communiquer avec les charges de travail 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 les étiquettes en configurations spécifiques aux capacités de filtrage de réseau du système d'exploitation qui exécute actuellement ces charges de travail - soit Linux iptables et ipsets, Windows Filtering Platform (WFP), ou la table d'état IPFilter pour les charges de travail Solaris et AIX.

Étant donné qu'Illumio vous permet de définir une politique d'une manière totalement abstraite par rapport à la façon dont une charge de travail est hébergée et à l'endroit où elle est hébergée, il en résulte que les priorités en matière de réseau et les priorités en matière d'application ne sont plus en conflit.

En résumé

Dans les architectures modernes de centres de données et de réseaux de nuages hybrides, 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 se déplacer de manière dynamique à travers n'importe quel segment du nuage. L'ancienne définition du périmètre comme étant situé entre le centre de données et l'Internet n'est plus pertinente, et essayer d'architecturer le réseau pour permettre une microsegmentation à travers les frontières des applications est un défi à l'échelle. Les solutions SDN utilisant des contrôleurs et des réseaux superposés qui se terminent dans des hyperviseurs déplacent effectivement la frontière entre le réseau et les charges de travail vers l'hôte, mais elles s'appuient toujours sur la définition de segments "de bas en haut" : de la couche réseau pour résoudre un problème dans la couche charge de travail.

Une approche beaucoup plus évolutive dans les infrastructures modernes en nuage consiste à aller jusqu'à la charge de travail pour créer des microsegments et appliquer des politiques pertinentes pour les charges de travail, libérant ainsi la segmentation du réseau pour qu'elle soit définie en fonction des priorités pertinentes pour la conception du réseau. Le réseau n'est plus un obstacle à l'agilité et à la sécurité des charges de travail des applications. En outre, le réseau n'est plus le premier concerné par le dépannage de la sécurité des applications, ce qui réduit les accusations lors des interventions en cas d'incident.

Regardez cette vidéo pour un voyage rapide qui explique l'évolution de la segmentation et apprenez-en plus sur notre solution ici.