Meilleures pratiques pour la segmentation de la charge de travail : Lean et rationalisé ou lourd et complexe ?

La "cybersécurité" couvre un large éventail de sujets, parmi lesquels les priorités du réseau, les priorités de l'hôte, l'authentification, l'identité, l'automatisation, la conformité, etc. La micro-segmentation est l'un des éléments de ce principe plus large, mais beaucoup pensent encore qu'il est difficile de la mettre en œuvre à grande échelle.

Toutes les charges de travail modernes contiennent un pare-feu intégré et un filtre de port, comme iptables sous Linux. Il est relativement simple de configurer cela pour des charges de travail individuelles, mais cela s'avère souvent difficile à réaliser à grande échelle. Ce défi est d'autant plus difficile à relever qu'il s'inscrit dans le cadre d'une migration évolutive des charges de travail monolithiques vers les microservices. 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 du réseau sous-jacent. 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 qui sont requises pour la segmentation de la charge de travail.

L'automatisation et la prise en charge d'architectures à grande échelle sont deux exigences clés de la segmentation au niveau de la charge de travail dans les architectures de cloud hybride et de microservices. L'automatisation consiste à supprimer autant que possible l'élément humain, car plus l'homme est impliqué dans le processus opérationnel, plus il y a de risques de mauvaises configurations et d'erreurs. La prise en charge d'architectures à grande échelle implique de permettre l'automatisation de la segmentation de manière à éviter les blocages de 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 pour voir laquelle est la plus judicieuse pour vous et votre organisation.

Deux approches de la microsegmentation

Examinons d'abord ce que nous considérons comme une approche "lourde". Les approches plus lourdes, comme Cisco Tetration par exemple, sont axées sur la capture de chaque paquet de chaque charge de travail, l'analyse du réseau à travers la structure du réseau, et nécessitent une intervention humaine importante dans la mise en œuvre de la politique de segmentation à l'échelle. L'opérationnalisation de ces outils est assez complexe et peut donc être décrite comme une approche "lourde" de la mise en œuvre de la micro-segmentation.

En revanche, les approches "légères", comme Illumio, ont été conçues pour la micro-segmentation. Ils ne sont pas nés comme un produit et n'ont pas été modifiés par la suite 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 indifférents à 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 de mise en réseau. Cette approche permet de rationaliser la mise en œuvre de la politique de segmentation, en mettant l'accent sur l'automatisation et en ne nécessitant que peu, voire pas du tout, d'intervention humaine.

Quand la segmentation brisera-t-elle mon architecture ?

C'est un truisme, mais il vaut la peine de le répéter : plus la solution est complexe, plus vite elle atteindra une limite supérieure opérationnelle. À un moment donné, une solution complexe se heurte à un obstacle qui limite l'évolutivité de l'architecture globale de segmentation de la charge de travail.

Des solutions plus lourdes et complexes pour la micro-segmentation fonctionneront pour des cas d'utilisation plus restreints, mais au fur et à mesure que ces cas d'utilisation se multiplieront, elles finiront par peser sur les frais généraux opérationnels et atteindront une limite difficile à franchir. À ce stade, d'autres charges de travail sont souvent laissées sans protection et l'automatisation commence à s'effondrer. Au fur et à mesure que la solution exécute davantage de tâches, la complexité finit par devenir un fardeau opérationnel.

Les fournisseurs de micro-segmentation publient fréquemment des chiffres qui reflètent leur limite supérieure de charges de travail gérées, et ces chiffres semblent être suffisamment importants pour faire face à la croissance attendue. Mais comme de plus en plus d'entreprises adoptent des architectures de nuages hybrides, la virtualisation crée beaucoup plus de charges de travail que dans le cas des hôtes traditionnels à base de métal nu. De plus, les architectures microservices créent un nombre supplémentaire important d'entités adressables par 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 inférieur sera suffisant.

Pour automatiser la micro-segmentation dans une architecture de cloud hybride évolutive, la solution ne doit pas s'effondrer une fois qu'un nombre supérieur est atteint.

Automatisation ≠ Humains

L'automatisation nécessite une architecture allégée et rationalisée. Un grand pourcentage des failles de sécurité dans un environnement en nuage est dû à des erreurs honnêtes commises par les administrateurs. Le cycle de vie des charges de travail devenant plus dynamique et l'endroit où elles résident sur les segments du réseau devenant de plus en plus éphémère, il est plus critique d'automatiser les processus de sécurité et d'éliminer le risque significatif introduit par l'intervention humaine dans le processus opérationnel.

Illumio, qui est un exemple d'approche légère, utilise le concept d'étiquettes quadridimensionnelles et de délimitation 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 puisse introduire une erreur par inadvertance.

La plupart des solutions lourdes, comme Tetration, comprennent des options permettant d'appliquer des étiquettes 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 opérationnel. Et comme vous pouvez le deviner, plus un processus nécessite une intervention humaine et de l'expertise, plus le risque d'erreur involontaire est élevé.

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 les microservices, attendez-vous à davantage de charges de travail

La migration du développement d'applications des charges de travail monolithiques vers les microservices a pour effet d'augmenter considérablement le nombre de charges de travail à gérer. Avec l'avènement de la virtualisation, une seule machine nue 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 un nombre encore plus élevé d'adresses IP.

Si chaque entité sur un réseau avec une adresse IP est définie comme une charge de travail, un environnement microservices peut faire exploser le nombre de charges de travail. Le nombre de charges de travail à surveiller nécessite une solution capable de s'adapter à un très grand nombre d'utilisateurs.

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 ce que les applications font entre elles dans un grand nombre de charges de travail ? La visualisation de la communication de la charge de travail ne peut pas dépendre de la segmentation du réseau. Dans le cas des microservices, le besoin de visualisation va au-delà du trafic VM-to-VM et doit inclure la communication entre les pods, les nœuds et les services lorsque vous utilisez Kubernetes ou OpenShift pour orchestrer les cycles de vie des conteneurs.

Les solutions lourdes, comme Tetration, peuvent appliquer une politique dans un environnement conteneurisé, mais la visualisation du trafic des applications dans ces constructions est limitée. Ces solutions peuvent souvent 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 n'est pas pris en compte. D'autre part, une solution légère étend la visibilité depuis les hôtes nus jusqu'aux VM et à toutes les constructions conteneurisées au sein d'un hôte. Toutes les charges de travail, qu'elles soient monolithiques ou conteneurisées, sont entièrement visibles lorsqu'Illumio, par exemple, construit sa carte des dépendances applicatives.

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 nuage hybride et les différentes ressources de calcul, à la fois dans les centres de données sur site et dans les nuages publics. La visualisation devient plus importante à mesure que ces détails deviennent plus complexes et dynamiques, afin de créer et d'appliquer une politique déclarative lisible par l'homme.

Le bilan

Lorsqu'il s'agit de décider comment 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 même que le déploiement d'un hors-bord est parfois préférable à celui 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 micro-segmentation est déployée dans les nuages hybrides et les structures informatiques modernes. Réduisez la complexité et faites en sorte que la solution soit "légère" et non "lourde".