Exploiter le langage naturel pour définir et simplifier les politiques de microsegmentation

Parmi les trois ressources de base de tout centre de données ou cloud (calcul, stockage, réseau), le réseau a été la plus lente à évoluer vers le monde moderne de virtualisation et d'abstraction des ressources. C'est en grande partie intentionnel. On peut affirmer que la structure du réseau est la ressource la plus critique de tout centre de données ou architecture cloud. Sans réseau, le calcul et le stockage sont des îlots inaccessibles. Le réseau permet l'accès et la communication entre toutes les ressources de calcul et de stockage, entre elles et avec les utilisateurs finaux de ces ressources. Sans le réseau qui sous-tend une architecture, toutes les conversations dans le cloud n'ont aucun sens. Quel que soit le degré d'abstraction des conversations dans le cloud autour des ressources informatiques, qu'il s'agisse de conversations sans serveur ou sans serveur, s'il y a un paquet IP n'importe où sur l'image, le réseau est essentiel.

La sécurité du réseau est désormais définie en langage naturel et non en langage réseau.

Cela relève du bon sens, et le réseau possède ses propres formes de virtualisation des ressources destinées à résoudre des problèmes de réseau spécifiques. Néanmoins, il est mentionné ici pour le simple fait que la sécurité des centres de données ou des déploiements dans le cloud est traditionnellement mise en œuvre sur le réseau. Afin de bloquer ou d'activer le trafic réseau en transit entre les ressources cloud, un pare-feu est déployé quelque part dans la structure du réseau. Les logiciels des terminaux peuvent être déployés sur des ressources informatiques, qui sont généralement des outils basés sur des signatures qui recherchent les malwares connus ou les mauvais comportements, mais ils inspectent généralement le trafic, sans le bloquer ni l'autoriser. La plupart des charges de travail disposent de fonctionnalités de pare-feu intégrées, telles que iptables sous Linux, mais l'orchestration de ces outils à grande échelle est souvent difficile à gérer et, par conséquent, non utilisée. Donc, sécurité du réseau et l'application du trafic se fait traditionnellement à l'aide de pare-feux réseau.

La sécurité est souvent définie dans une langue différente

Les pare-feux étant généralement gérés par des équipes réseau, la politique de sécurité est le plus souvent définie à l'aide de termes familiers aux équipes réseau. Les pare-feux existent depuis des décennies et leur configuration a très peu évolué au fil des ans. Les règles de politique sont généralement écrites à l'aide d'adresses IP, de ports TCP/UDP, de VLAN et de zones. Les pare-feux ne sont généralement pas conçus pour examiner plus en profondeur la charge utile des paquets afin d'inspecter le contenu ou les applications contenus, car ils souhaitent éviter de devenir un goulot d'étranglement du trafic réseau.

Il existe ce que l'on appelle pare-feux de nouvelle génération (NGFW) qui ont la capacité d'inspecter les paquets de manière beaucoup plus approfondie à la vitesse du fil et peuvent définir une politique en fonction de ce qui est réellement contenu dans la charge utile de données d'un paquet, et pas seulement de ses en-têtes réseau. Mais comme les vieilles habitudes ont la vie dure, la réalité est que ces pare-feux sont souvent configurés à l'ancienne, les options de nouvelle génération restant inutilisées. Le résultat est un appareil qui utilise la terminologie réseau pour définir sécurité du réseau, ce qui n'est pas la façon dont les utilisateurs de ressources hébergées dans un centre de données ou dans le cloud perçoivent ces ressources. Souvent, les utilisateurs ne savent pas, ou s'en fichent, sur quel segment de réseau une ressource est hébergée. Ils s'intéressent à la ressource elle-même.

La politique du réseau doit refléter la façon dont les utilisateurs perçoivent les ressources à protéger

Lorsqu'un utilisateur ou un développeur signale un problème, par exemple l'impossibilité d'accéder à une ressource hébergée dans un centre de données ou dans le cloud, il fait généralement référence à la charge de travail ou à l'application spécifique inaccessible. Ils ne signalent généralement pas qu'une adresse IP spécifique n'est pas accessible via un port spécifique. Toutefois, la mise en réseau ou opérations de sécurité les équipes demanderont ces informations. Et c'est là que le problème se pose : Le problème signalé est dans une langue différente de celle des appareils qui appliquent la politique réseau. Le langage des applications n'équivaut généralement pas au langage du réseau.

L'un des détails importants de la quête visant à automatiser autant de ressources que possible dans les architectures cloud est la possibilité de définir la politique réseau en utilisant les mêmes termes que ceux que les utilisateurs perçoivent pour les ressources protégées. Si un pare-feu applique une politique entre les applications X, Y et Z, il doit être en mesure de définir une politique spécifique à ces applications, et non à la ressource réseau sur laquelle elles sont hébergées.

Cela est particulièrement pertinent dans les infrastructures modernes hébergées dans le cloud public, telles que les microservices, dans lesquelles les adresses IP sont éphémères. Les charges de travail et les applications sont souvent migrées de manière dynamique sur différents segments de réseau, de sorte qu'une adresse IP n'est plus un moyen fiable d'identifier une charge de travail spécifique pendant le cycle de vie de cette ressource. Si vous devez modifier un pare-feu chaque fois qu'une adresse IP change, cela n'est pas évolutif.

Il en résulte que, très souvent, les pare-feux ne sont tout simplement pas déployés dans les architectures cloud modernes. Au lieu de cela, ils sont relégués à la périphérie d'un tissu nuageux, ne contrôlant que le trafic nord-sud, sans tenir compte de la majeure partie du trafic est-ouest.

Définissez la sécurité à l'aide de métadonnées, et non d'adresses IP

La plupart des contrôleurs SDN modernes peuvent créer ce qui équivaut à une base de données locale d'adresses IP et de métadonnées de charge de travail appliquée à chaque charge de travail. Par exemple, si cinq charges de travail de production sont des serveurs SQL et que cinq autres charges de travail sont des serveurs SQL de développement, le contrôleur créera un enregistrement local répertoriant ces serveurs en deux catégories, les cinq premières adresses IP de charge de travail étant attribuées à une balise de métadonnées « SQL-Prod » et les cinq secondes adresses IP de charge de travail étant attribuées à une balise de métadonnées « SQL-Dev ». Le contrôleur surveillera ces charges de travail, et si une charge de travail modifie son adresse IP pour une raison quelconque, ou si elle est réduite, il mettra à jour ses enregistrements locaux de mappages de métadonnées vers IP.

De cette façon, le contrôleur peut suivre le cycle de vie complet de la charge de travail en fonction des métadonnées qui lui sont attribuées, quelle que soit l'adresse IP qu'il lui a attribuée. Le transfert de paquets vers et depuis les charges de travail est toujours effectué à l'aide de recherches IP, en utilisant l'adresse IP actuellement attribuée. Mais l'identité de cette charge de travail est maintenue par les métadonnées qui lui sont attribuées, indépendamment du segment de réseau auquel elle est affectée.

L'identification d'une charge de travail à l'aide de métadonnées permet de dissocier entièrement l'identité de cette charge de travail de tout détail réseau. C'est ainsi que la sécurité moderne doit être définie. Définir une politique qui se lit comme suit : « Aucun serveur SQL en développement ne peut entrer en contact avec des serveurs SQL en production » est beaucoup plus proche de la façon dont les utilisateurs perçoivent ces ressources que quelque chose comme définir une politique à lire comme « 192.168.10.0/24 Autorisation TCP 1024-2000 10.10.0.0/16 ». Les termes de métadonnées sont beaucoup plus lisibles par l'homme que les termes de réseau.

L'utilisation de métadonnées pour identifier les ressources est généralement appelée « balises » ou « étiquettes ». Et ce concept est utilisé par d'autres contrôleurs que le SDN. Avec Illumio ASP, vous pouvez attribuer une étiquette à chaque charge de travail, et chaque étiquette comporte quatre « dimensions » : rôle, application, environnement et emplacement. Chaque charge de travail peut se voir attribuer une étiquette qui l'identifie par rapport à l'une ou à l'ensemble de ces dimensions, et la politique peut ensuite être définie à l'aide de ces étiquettes. Ainsi, un ensemble de règles Illumio ne fait pas référence à des ports ou à des adresses IP ; il fait référence à des étiquettes.

La valeur des étiquettes Illumio

Le concept d'étiquettes peut sembler un détail mineur, mais il convient de le souligner. À l'aide d'étiquettes, vous pouvez définir une politique en utilisant les mêmes termes que la façon dont les utilisateurs perçoivent les ressources protégées. Il s'agit d'un changement significatif par rapport à la définition traditionnelle de la sécurité des réseaux. Pendant des décennies, la sécurité des réseaux a été définie en fonction des structures réseau : adresses IP, VLAN et ports. Les pare-feux envisagent la sécurité à travers le prisme de ces structures réseau, et si l'une de ces structures change, la configuration du pare-feu doit être modifiée.

Mais si la politique est définie à l'aide d'étiquettes et que ces étiquettes entraînent la configuration des fonctionnalités de pare-feu intégrées de la charge de travail pour appliquer cette définition en arrière-plan, la politique correspond désormais à la manière dont les ressources sont réellement utilisées. La sécurité du réseau est désormais définie à l'aide du langage naturel, et non du langage réseau. De plus, cette politique de langage naturel est définie une seule fois et reste silencieuse même lorsque les charges de travail migrent entre les structures réseau, sont réduites ou augmentées, ou étendues à des déploiements de grande envergure.

La sécurité ne doit pas constituer un obstacle aux exigences d'évolutivité de la charge de travail. L'utilisation du langage naturel pour définir les politiques, à l'aide d'étiquettes, permet l'évolution de la charge de travail sans que la sécurité ne ralentisse le processus DevOps.

J'utilise donc des étiquettes : et maintenant ?

Même si les équipes de mise en réseau s'habituent à définir les politiques à l'aide d'étiquettes en langage naturel, afin de créer un langage plus lisible par l'homme, l'état d'esprit qui sous-tend la définition des politiques est encore souvent centré sur le réseau. Bien que les étiquettes fassent référence aux charges de travail et aux applications, les équipes réseau considèrent toujours les limites de confiance comme des limites du réseau. Mais, à mesure que de plus en plus d'entreprises adoptent Confiance zéro état d'esprit, une caractéristique importante oblige les organisations à repousser les limites de confiance en s'éloignant du réseau et en les orientant directement vers les ressources auxquelles les étiquettes font référence. Si vous avez cinq charges de travail SQL, chacune de ces charges de travail constitue sa propre limite de confiance. La limite de confiance n'est pas un segment de réseau commun qu'ils peuvent tous partager.

Illumio déploie des agents, appelés FOURs, sur chaque charge de travail surveillée, et ces agents traduisent la politique basée sur des étiquettes en règles sur le pare-feu intégré à chaque charge de travail. Ainsi, la première étape de la vie d'un paquet, à sa naissance, est la politique. Une autre façon de penser à Zero Trust est la suivante : « aucun paquet ne doit atteindre le plan de transfert du réseau tant qu'il n'a pas été inspecté ». Avec Illumio, au moment où un paquet atteint le plan de transfert du réseau, la sécurité est déjà appliquée.

Ceci est particulièrement important lorsque vous essayez de résoudre le problème de mouvement latéral, qui permet à des acteurs malveillants ou à des programmes malveillants de traverser un réseau sans être détectés. Lorsque vous discutez des directives de sécurité avec des utilisateurs distants, par exemple, le besoin de sécurité est généralement reconnu, mais la réponse courante est « Je n'ai rien à cacher », ce qui est utilisé pour justifier le fait de ne pas prendre la peine de sécuriser une charge de travail. Cet utilisateur n'a peut-être rien à cacher, mais quelqu'un d'autre pourrait le faire. Les malwares contournent souvent une charge de travail dans le but précis de passer de cette charge de travail à d'autres charges de travail, la destination étant une ressource plus précieuse. Il s'agit d'un mouvement latéral, qui utilise une charge de travail comme rampe de lancement pour une autre charge de travail.

Si une limite de confiance est un segment de réseau et qu'un logiciel malveillant enfreint l'une des nombreuses charges de travail présentes sur ce segment de réseau, il peut se déplacer latéralement entre les charges de travail qui partagent un segment sans que le pare-feu réseau ne s'en aperçoive. Les mouvements latéraux doivent être évités à chaque charge de travail, et non dans la structure du réseau.

Les étiquettes sont utiles pour faciliter la compréhension des politiques et pour garder l'objectif ultime en ligne de mire : adapter la solution de sécurité à ce que vous essayez de sécuriser. Ne vous fiez pas à une couche d'une architecture cloud pour sécuriser une autre couche. Vos limites de confiance se situent quel que soit l'endroit où se trouvent vos charges de travail. Zero Trust signifie que chaque charge de travail est un segment, et si vous sécurisez chaque charge de travail, vous réduirez considérablement le risque de mouvement latéral.

Pour en savoir plus sur Illumio ASP et sur notre conception de l'étiquetage, consultez :

• Nouvelle vidéo sur le le pouvoir des étiquettes
• Le Guide de conception Illumio ASP