Meilleures pratiques en matière de segmentation de la charge de travail : allégée et rationalisée ou lourde et complexe ?

La « cybersécurité » couvre un large éventail de sujets, notamment les priorités du réseau, les priorités des hôtes, l'authentification, l'identité, l'automatisation, la conformité, etc. Microsegmentation n'est qu'un élément de ce principe plus large, mais nombreux sont ceux qui pensent encore que sa mise en œuvre à grande échelle constitue un défi.

Toutes les charges de travail modernes contiennent un pare-feu et un filtre de port intégrés, comme iptables sous Linux. La configuration de cette configuration sur des charges de travail individuelles est relativement simple, mais le faire à grande échelle constitue souvent un défi. Et ce, dans le cadre de la migration croissante des charges de travail monolithiques vers les microservices, rend ce défi encore plus difficile à mettre en œuvre. Il en résulte que la segmentation au niveau de la couche de charge de travail de l'architecture n'est souvent pas effectuée, laissant simplement cette tâche à la structure réseau sous-jacente à implémenter. Cette approche crée un conflit de priorités car la segmentation du réseau est souvent mise en œuvre pour des raisons différentes de celles requises par la segmentation de la charge de travail.

Deux exigences clés pour la segmentation de la couche de charge de travail dans les architectures de cloud hybride et de microservices sont l'automatisation et la prise en charge d'architectures à grande échelle. L'automatisation consiste à supprimer autant que possible l'élément humain, car plus un humain est impliqué dans le processus opérationnel, plus il est probable que des erreurs de configuration et des erreurs se produisent. Et la prise en charge d'architectures à grande échelle implique de permettre l'automatisation de la segmentation de manière à éviter les obstacles à l'architecture globale une fois qu'une certaine échelle est atteinte.

Ces exigences peuvent être mises en œuvre de deux manières : une approche « lourde » ou une approche « légère ». Comparons ces deux approches afin de déterminer celle qui est la plus appropriée pour vous et votre organisation.

L'histoire de deux approches de la microsegmentation

Discutons d'abord de ce que nous considérons comme une approche « lourde ». Les approches plus lourdes, comme Cisco Tetration par exemple, visent à capturer chaque paquet de chaque charge de travail, à effectuer des analyses du réseau sur l'ensemble de la structure du réseau et à nécessiter une intervention humaine importante pour mettre en œuvre une politique de segmentation à grande échelle. L'opérationnalisation de tels outils est assez complexe et peut donc être décrite comme une approche « lourde » de mise en œuvre de la microsegmentation.

En revanche, les approches « légères », comme Illumio, étaient spécialement conçu pour la microsegmentation. Ils ne sont pas nés en tant que produit unique et ont ensuite été modifiés en un produit différent. Ils se concentrent exclusivement sur la segmentation au niveau de la charge de travail et sont délibérément indépendants de la manière dont le réseau sous-jacent est mis en œuvre, laissant la tâche de l'analyse du réseau aux outils réseau. Grâce à cette approche, la mise en œuvre de la politique de segmentation est rationalisée, en mettant l'accent sur l'automatisation, qui ne nécessite que peu ou pas d'intervention humaine.

Quand est-ce que la segmentation va détruire mon architecture ?

C'est un truisme, mais il convient de le répéter : plus la solution est complexe, plus elle atteindra rapidement une limite opérationnelle maximale. À un moment donné, une solution complexe se heurtera à un obstacle à l'évolutivité de l'architecture globale de segmentation de la charge de travail.

Les solutions plus lourdes et complexes de microsegmentation fonctionneront sur des cas d'utilisation plus restreints, mais à mesure que ces cas d'utilisation se développeront, elles finiront par alourdir les frais opérationnels et atteindront une limite stricte. À ce stade, les charges de travail supplémentaires ne sont souvent pas protégées et l'automatisation commence à s'arrêter. Au fur et à mesure que la solution exécute de plus en plus de tâches, la complexité finit par devenir une charge opérationnelle.

Les fournisseurs de microsegmentation publient fréquemment des chiffres qui reflètent leur limite supérieure de charges de travail gérées, et ces chiffres semblent suffisamment importants pour répondre à la croissance attendue. Mais à mesure que de plus en plus d'organisations adoptent des architectures cloud hybrides, la virtualisation crée beaucoup plus de charges de travail que les hôtes bare metal traditionnels. De plus, les architectures de microservices créent un nombre supplémentaire significatif d'entités adressables IP au sein d'un hôte, ce qui entraîne une augmentation rapide du nombre total de charges de travail. Le nombre de charges de travail gérées ne doit pas être déterminé par les outils utilisés pour opérationnaliser la segmentation. Afin de garantir un cycle de croissance ininterrompu de la charge de travail, ne partez jamais du principe qu'un nombre plus faible sera suffisant.

Afin d'automatiser la micro-segmentation dans toute architecture de cloud hybride en évolution, la solution ne doit pas tomber en panne une fois qu'un certain nombre est atteint.

Automatisation ≠ Humains

L'automatisation nécessite une architecture allégée et rationalisée. Une grande partie des failles de sécurité dans tout environnement cloud sont dues à des erreurs de bonne foi commises par les administrateurs. À mesure que les cycles de vie des charges de travail deviennent plus dynamiques et que leur localisation sur les segments du réseau devient de plus en plus éphémère, il est de plus en plus essentiel d'automatiser les processus de sécurité et de supprimer le risque important introduit par l'intervention humaine dans le processus opérationnel.

Illumio, à titre d'exemple d'approche légère, utilise le concept de étiquettes en quatre dimensions et le ringfencing des applications pour simplifier et automatiser le processus d'application de la segmentation à une charge de travail au moment de sa création. Il permet de suggérer automatiquement des limites de segmentation ou de permettre à l'administrateur de définir ces limites. Cela réduit considérablement le risque qu'une intervention humaine introduise une erreur par inadvertance.

La plupart des solutions lourdes, comme Tetration, incluent des options permettant d'appliquer des balises aux charges de travail afin de les suivre indépendamment de l'adressage IP. Cela dit, le processus est « lourd », complexe et nécessite une quantité importante d'interactions humaines initiales et d'expertise pour être mis en œuvre. Et comme vous pouvez le deviner, plus un processus nécessite une intervention humaine et une expertise, plus le risque d'erreur involontaire augmente.

Lorsque vous planifiez l'automatisation de la segmentation de la charge de travail, gardez cette règle à l'esprit : plus le processus est complexe, plus le risque est élevé.

Introduisez des microservices, attendez-vous à davantage de charges de travail

La migration du développement d'applications des charges de travail monolithiques vers les microservices entraîne une augmentation significative du nombre de charges de travail à gérer. Avec l'avènement de la virtualisation, un seul hôte bare-metal pouvait gérer de nombreuses machines virtuelles, chacune ayant sa propre adresse IP. Et maintenant, avec l'avènement des microservices, chacune de ces machines virtuelles peut héberger de nombreuses constructions conteneurisées, ce qui se traduit par encore plus d'adresses IP.

Si chaque entité d'un réseau possédant une adresse IP est définie comme une charge de travail, un environnement de microservices peut faire exploser le nombre de charges de travail. Le grand nombre de charges de travail qui doivent être surveillées nécessite une solution capable échelle à de très grands nombres.

La visualisation est primordiale

La surveillance d'une charge de travail implique deux choses fondamentales : l'application d'une politique et la visualisation. Mais comment visualiser les interactions entre les applications sur un grand nombre de charges de travail ? La visualisation de la communication de la charge de travail ne peut pas dépendre de segmentation du réseau. Dans le cas des microservices, le besoin de visualisation va au-delà du trafic VM à VM et doit inclure la communication entre les pods, les nœuds et les services lors de l'utilisation de Kubernetes ou OpenShift pour orchestrer les cycles de vie des conteneurs.

Les solutions lourdes, telles que Tetration, peuvent appliquer des politiques dans un environnement conteneurisé, mais la visualisation du trafic des applications au sein de ces structures est limitée. Ces solutions permettent souvent de créer une carte visuelle du trafic entre les hôtes, mais la vue s'arrête là et le trafic entre les constructions conteneurisées au sein d'un hôte est absent. D'autre part, une solution légère étend la visibilité sur tous les plans, depuis les hôtes « bare-metal » jusqu'aux machines virtuelles et à toutes les constructions conteneurisées de n'importe quel hôte. Toutes les charges de travail, qu'elles soient monolithiques ou conteneurisées, sont entièrement visibles lorsqu'Illumio, par exemple, construit son carte de dépendance des applications.

La visualisation de l'ensemble du trafic et du comportement des applications, quel que soit leur mode d'hébergement, est essentielle à mesure que vos charges de travail évoluent dans le cloud hybride et les différentes ressources de calcul, à la fois dans les centres de données sur site et dans les structures de cloud public. La visualisation prend de l'importance à mesure que ces détails deviennent plus complexes et dynamiques, afin de créer et d'appliquer politique déclarative lisible par l'homme.

L'essentiel

Au moment de décider de la manière de mettre en œuvre la segmentation de la charge de travail à grande échelle et de manière automatisée, une approche allégée et rationalisée est la seule option viable. De la même manière que le déploiement d'un hors-bord est parfois un meilleur choix que le déploiement d'un cuirassé si l'objectif est la vitesse et l'agilité sur l'eau, il en va de même pour la manière dont la microsegmentation est déployée dans les clouds hybrides modernes et les structures de calcul. Réduisez la complexité et faites en sorte que la solution soit « légère » et non « lourde ».