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

Des trois ressources de base d'un centre de données ou d'un nuage (calcul, stockage, réseau), le réseau a été le plus lent à évoluer dans le monde moderne de la virtualisation et de l'abstraction des ressources. C'est en grande partie à dessein. On peut affirmer que la structure du réseau est la ressource la plus critique dans tout centre de données ou architecture en nuage. Sans réseau, l'informatique 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 sous-jacent à toute architecture, toutes les conversations sur le nuage n'ont aucun sens. Quel que soit le degré d'abstraction des conversations sur le cloud autour des ressources informatiques, du bare-metal au serverless, s'il y a un paquet IP n'importe où dans l'image, le réseau est critique.

La sécurité des réseaux est désormais définie en langage naturel, et non plus en langage de réseau.

C'est une question de bon sens, et les réseaux ont leurs 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é dans les centres de données ou les déploiements en nuage a traditionnellement été mise en œuvre dans le réseau. Afin de bloquer ou d'autoriser le trafic réseau en transit entre les ressources en nuage, un pare-feu est déployé quelque part dans le réseau. Les logiciels pour terminaux peuvent être déployés sur des ressources informatiques, qui sont généralement des outils basés sur des signatures qui recherchent des logiciels malveillants connus ou un mauvais comportement, mais qui inspectent généralement le trafic, sans le bloquer ou l'autoriser. La plupart des charges de travail disposent de capacité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, n'est pas utilisée. Ainsi, la sécurité du réseau et le contrôle du trafic sont traditionnellement assurés par des pare-feux.

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

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

Il existe des pare-feu dits de nouvelle génération (NGFW) qui ont la capacité d'inspecter les paquets beaucoup plus profondément à la vitesse du fil et qui peuvent définir une politique en fonction de ce qui est réellement contenu dans la charge utile d'un paquet, et pas seulement dans ses en-têtes de réseau. Mais comme les vieilles habitudes ont la vie dure, la réalité est que ces pare-feu sont souvent configurés à l'ancienne, sans que les options de la nouvelle génération soient utilisées. Il en résulte un dispositif qui utilise la terminologie des réseaux pour définir la sécurité du réseau, ce qui n'est pas la façon dont les utilisateurs des ressources hébergées dans un centre de données ou dans un nuage perçoivent ces ressources. Souvent, les utilisateurs ne savent pas, ou ne se soucient pas, de savoir 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 manière dont les utilisateurs perçoivent les ressources protégées.

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

Un détail important dans la quête de l'automatisation du plus grand nombre de ressources possible dans les architectures en nuage est la capacité de définir une politique de réseau en utilisant les mêmes termes que ceux perçus par les utilisateurs pour les ressources à protéger. Si un pare-feu applique une politique entre les applications X, Y et Z, il doit pouvoir définir une politique spécifique à ces applications, et non à la ressource réseau sur laquelle elles sont hébergées.

Ceci est particulièrement pertinent dans les infrastructures modernes hébergées dans le nuage public, telles que les microservices, dans lesquelles les adresses IP sont éphémères. Les charges de travail et les applications sont souvent déplacé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, cette solution n'est pas extensible.

Il en résulte que, très souvent, les pare-feu ne sont tout simplement pas déployés dans les architectures modernes d'informatique en nuage. Au lieu de cela, ils sont relégués à la périphérie d'une structure en nuage, n'appliquant que le trafic nord-sud, sans tenir compte de la majorité du trafic est-ouest.

Définir 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 de charges de travail et de métadonnées appliquées à 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 de développement SQL, le contrôleur créera un enregistrement local qui répertorie ces serveurs en deux catégories, les cinq premières IP de charge de travail étant affectées à une balise de métadonnées "SQL-Prod" et les cinq secondes IP de charge de travail étant affectées à une balise de métadonnées "SQL-Dev". Le contrôleur surveillera ces charges de travail et, si une charge de travail change d'adresse IP pour une raison quelconque ou si elle est désactivée, il mettra à jour ses enregistrements locaux de correspondances entre les métadonnées et l'adresse IP.

De cette manière, le contrôleur peut suivre le cycle de vie complet de la charge de travail sur la base des métadonnées qui lui sont attribuées, quelle que soit l'adresse IP qui lui a été 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 qui lui a été 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 faire abstraction de l'identité de cette charge de travail et de tous les détails du réseau - c'est ainsi que la sécurité moderne doit être définie. La définition d'une politique du type "Aucun serveur SQL en développement ne peut entrer en contact avec des serveurs SQL en production" est beaucoup plus proche de la manière dont les utilisateurs perçoivent ces ressources que la définition d'une politique du type "192.168.10.0/24". TCP 1024-2000 10.10.0.0/16 permis". Les termes des métadonnées sont beaucoup plus lisibles par l'homme que les termes de la mise en réseau.

L'utilisation des métadonnées pour identifier les ressources est généralement désignée par les termes "étiquettes" ou "tags". 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 alors ê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 IP, mais à des étiquettes.

La valeur des étiquettes Illumio

La notion d'étiquette peut sembler un détail mineur, mais elle mérite d'être soulignée. En utilisant des étiquettes, vous pouvez définir une politique en utilisant les mêmes termes que ceux utilisés par les utilisateurs pour percevoir les ressources protégées. Il s'agit d'un changement important 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 autour de concepts de réseau : IP, VLAN et ports. Les pare-feux considèrent la sécurité à travers l'objectif de ces constructions de réseau, et si l'une de ces constructions change, la configuration du pare-feux doit être modifiée.

Mais si la politique est définie à l'aide d'étiquettes et que ces étiquettes entraînent la configuration des capacités du pare-feu intégré 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é des réseaux est désormais définie en langage naturel, et non plus en langage de réseau. Cette politique en langage naturel n'est définie qu'une seule fois et reste silencieuse même lorsque les charges de travail migrent à travers les réseaux, sont réduites ou augmentées, ou mises à l'échelle pour des déploiements de grande envergure.

La sécurité ne doit pas être un obstacle aux exigences d'évolutivité de la charge de travail. L'utilisation du langage naturel pour définir la politique - en utilisant des é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 des politiques en utilisant des é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 de la politique est encore souvent centré sur le réseau. Si les étiquettes font référence aux charges de travail et aux applications, les équipes chargées de la mise en réseau considèrent toujours les limites de confiance comme des limites de réseau. Mais comme de plus en plus d'entreprises adoptent un état d'esprit de confiance zéro, une caractéristique importante exige que les organisations repoussent les limites de la confiance hors du réseau et directement vers les ressources auxquelles les étiquettes se réfèrent. Si vous avez cinq charges de travail SQL, chacune d'entre elles 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, connus sous le nom de VEN, sur chaque charge de travail surveillée, et ces agents traduisent la politique basée sur les étiquettes en règles sur le pare-feu intégré de chaque charge de travail. La première étape de la vie d'un paquet, à sa naissance, est donc la politique. Une autre façon de concevoir la confiance zéro est la suivante : "aucun paquet ne doit atteindre le plan d'acheminement du réseau avant d'avoir été inspecté". Avec Illumio, lorsqu'un paquet atteint le plan d'acheminement du réseau, la sécurité a déjà été appliquée.

Cela est particulièrement important lorsque l'on tente de résoudre le problème du mouvement latéral, qui permet à des acteurs malveillants ou à des logiciels malveillants de traverser un réseau sans être détectés. Lorsque vous discutez des lignes directrices en matière de sécurité avec des utilisateurs distants, par exemple, la nécessité de la sécurité est généralement reconnue, mais une réponse fréquente est "je n'ai rien à cacher", ce qui sert de justification pour ne pas prendre la peine de sécuriser une charge de travail. Si cet utilisateur n'a peut-être rien à cacher, quelqu'un d'autre pourrait le faire. Les logiciels malveillants s'introduisent souvent dans une charge de travail dans le but spécifique 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 consiste à utiliser une charge de travail comme rampe de lancement pour une autre charge de travail.

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

Les étiquettes sont utiles pour faciliter la compréhension de la politique et pour ne pas perdre de vue l'objectif final : pousser la solution de sécurité vers ce que vous essayez de sécuriser. Ne comptez pas sur une couche de l'architecture en nuage pour sécuriser une autre couche. Vos limites de confiance se situent là où se trouvent vos charges de travail. La confiance zéro 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 l'ASP d'Illumio et sur la façon dont nous concevons l'étiquetage, consultez le site :

• Nouvelle vidéo sur le pouvoir des étiquettes
• Le guide de conception ASP d'Illumio