5 conseils pour simplifier l'étiquetage des charges de travail pour la microsegmentation

La propriété intellectuelle possède une structure que tout le monde et chaque machine peuvent comprendre. Si vous montrez à quelqu'un un ensemble de nombres en 4 dimensions comme 192.168.1.254, beaucoup le reconnaîtront immédiatement. La structure simple rend l'information facile à utiliser et à comprendre. C'est ce qui permet à Internet d'évoluer et de fonctionner. Et pour ceux qui travaillent avec elle, sa hiérarchie fournit des informations immédiates.

Imaginez l'alternative : un monde où les gens définissent des structures arbitraires. Et si une minute vous voyiez 192.179.134.56.245.23 et la minute suivante vous voyiez 24,87 ? Comment pouvons-nous déterminer comment ils sont liés les uns aux autres ?

Bien que nous considérions la flexibilité et le libre arbitre comme des éléments positifs, dans le monde de l'adressage réseau, tout comme en ce qui concerne l'étiquetage de la charge de travail (en particulier dans microsegmentation) — cela peut entraîner de la confusion et de la complexité. En fin de compte, cela entraîne des politiques incohérentes et des problèmes similaires à ceux rencontrés avec les politiques de pare-feu traditionnelles.

Depuis quelques années, nous étiquetons des objets dotés d'un large éventail d'attributs afin d'identifier et de regrouper les actifs, ce qui n'a cessé de poser des problèmes d'échelle et de gérabilité. Sans structure, la création d'une architecture durable devient de plus en plus un problème au fil du temps. Chez Illumio, nous l'avons identifié très tôt et avons décidé que la structure et la simplicité offraient d'énormes avantages opérationnels par rapport au balisage arbitraire d'objets.

En termes simples, les étiquettes doivent être faciles à utiliser, répétables, prévisibles et simples à comprendre ultérieurement.

Dans cette optique, voici 5 conseils pour simplifier l'étiquetage des charges de travail :

1. Respectez un schéma d'étiquetage en 4 dimensions

Cela fonctionne en classant les charges de travail à l'aide de paramètres dimensionnels simples et évidents. Par exemple :

1. Lieu : Où se situe la charge de travail ? Il peut s'agir d'un pays, d'une ville, d'un fournisseur de cloud, etc.
2. Environnement : Cet objet est-il en cours de production, de développement ou de test ?
3. Candidature : Sert-il à une application de finance, de ressources humaines ou de CRM ?
4. Rôle : S'agit-il d'un serveur d'applications, d'un serveur Web ou d'une base de données ?

En nous en tenant aux quatre groupes simples que sont le rôle, l'application, l'environnement et la localisation (RAEL), nous pouvons créer un modèle d'étiquetage qui soit non seulement facile à comprendre, mais également portable et extensible.

Cette structure permet aux utilisateurs de basculer sur l'une des quatre étiquettes et d'utiliser une seule section pour simplifier le contrôle et réduire le temps de calcul. Si nos étiquettes étaient destinées à des véhicules et prenaient la forme « Type | Marque | Modèle | Couleur », identifier uniquement les BMW ou les véhicules rouges rendrait l'exercice très simple et rapide.

Et n'oubliez pas que l'étiquetage d'un objet est tout simplement utilisé pour définir l'objet et son objectif principal, et non ses relations. S'en tenir à ce principe et utiliser la politique pour définir les relations, c'est le chemin du bonheur — croyez-moi là-dessus.

2. Standardisez sur un format

Bien que nous puissions observer des choses similaires pour les réseaux et l'informatique, il existe une grande différence entre « Production », « Prod » et « Prod ». Il y aura toujours des erreurs d'orthographe et, dans un modèle structuré en 4 dimensions, il est facile de les résoudre.

Cependant, dans un environnement de freestyle souple, essayer de trouver l'erreur dans « Prod.Fin.Win.Uk.Crm.Web.BldG1.10 » sera long.

3. Soyez prudent lorsque vous raccourcissez le nom des étiquettes

Par exemple, vous raccourcissez une étiquette, telle que « Production » en « Produit », mais vous ne raccourcissez pas « Base de données ». Le raccourcissement incohérent des noms d'étiquettes peut entraîner la duplication des étiquettes, ce qui peut à son tour entraîner une application des politiques incohérente ou des problèmes de prise en charge.

Nous vous recommandons d'utiliser les noms complets (Production, Développement et Test) à moins qu'une version abrégée ou un acronyme ne soit la nomenclature couramment utilisée dans votre organisation (comme UAT). Un exemple classique où cela peut poser problème est la création à la fois d'une étiquette « Prod » et d'une étiquette « Production ». Si certaines charges de travail sont étiquetées « Production », les règles créées pour la « Production » ne leur seront pas appliquées.

La définition d'une norme de dénomination n'est pas un concept nouveau, et il y a une bonne raison à cela.

4. Restez cohérent sur tous les systèmes

Outre la cohérence de votre schéma d'étiquetage pour la microsegmentation, nous vous recommandons de maintenir la cohérence avec les sources externes de métadonnées.

Si vous avez défini des conventions de dénomination des métadonnées, par exemple dans votre base de données de gestion des configurations (CMDB), des conventions de dénomination des hôtes ou si vous utilisez des blocs d'adresses IP, ne créez pas de conventions alternatives pour votre schéma d'étiquetage. Au cours de votre projet de déploiement, si vous découvrez que votre source de données standard présente également des incohérences, c'est l'occasion d'y remédier et d'améliorer la qualité de cette source de données. C'est extrêmement bénéfique pour de nombreuses raisons, et votre organisation en bénéficiera.

Votre cas d'utilisation de déploiement initial peut être limité à un environnement ou à une application spécifique. Cependant, le fait de structurer la conception de votre étiquette en tenant compte de l'ensemble de votre organisation vous permettra d'économiser du travail si le déploiement s'étend. Les schémas d'étiquettes plus simples sont plus évolutifs et plus faciles à prendre en charge.

5. Utilisez des étiquettes pour permettre la différenciation entre les objets

Lorsque vous devez différencier les règles entre les objets, utilisez des libellés différents. Dans certains cas, il peut être tentant d'utiliser des étiquettes distinctes, mais en réalité, il n'y a aucune différenciation politique, ce n'est donc pas nécessaire. Et n'oubliez pas que la politique à cet égard inclut la politique de sécurité, mais aussi RBAC, les rapports, le contrôle des modifications et d'autres types de politiques.

Dans cette optique, utilisez des noms courants pour vos étiquettes dans la mesure du possible. Par exemple, Apache, Nginx et IIS utilisent des ports de service et des protocoles similaires, tels que 80/TCP ou 443/TCP. Par conséquent, nous vous recommandons d'utiliser un nom d'étiquette courant, tel que « Serveur Web ». Dans la plupart des cas, vous n'aurez probablement pas besoin de rédiger des politiques différentes pour celles-ci.

Ne modifiez les noms des étiquettes que lorsque les charges de travail nécessitent une politique de sécurité différente. Par exemple, Oracle, IBM DB2 et MS SQL Server utilisent des ports de service et des protocoles différents, et chacun possède des éléments de politique de sécurité uniques, tels que des flux de trafic de cluster. Par conséquent, nous vous recommandons de leur attribuer trois étiquettes de rôle différentes aux charges de travail qui exécutent ces applications. Par exemple, cela vous permettra de rédiger une politique spécifique pour autoriser vos serveurs Oracle Enterprise Manager à accéder uniquement à vos serveurs de base de données Oracle, et non à vos serveurs Sybase.

Comment Illumio peut vous aider

Noyau Illumio utilise une conception multidimensionnelle, avec une combinaison de quatre étiquettes identifiant les objets de politique. D'autres produits utilisant le balisage peuvent vous permettre de créer n'importe quel nombre de tags. Bien que cela puisse sembler rendre l'étiquetage plus flexible, cela entraîne des défis qui s'aggravent au fil du temps.

Si vous continuez à ajouter différentes dimensions d'étiquette, vous vous retrouvez très rapidement avec un modèle unidimensionnel dans lequel une étiquette donnée indique une application de politique unique. Une bonne analogie avec cela est un service d'annuaire, dans lequel un nouveau groupe (tag) peut être créé pour chaque nouvelle exigence et appliqué aux utilisateurs. Le nombre de ces groupes augmente rapidement et sont souvent associés aux mêmes objets, ce qui entraîne une duplication. Il n'est pas rare qu'il existe un scénario dans lequel il y a plus de groupes que d'utilisateurs. De même, dans une solution basée sur des balises, vous risquez de vous retrouver avec plus de balises que d'objets, chaque objet étant associé à un grand nombre de balises.

Il incombe ensuite aux administrateurs d'associer tous les objets à toutes les balises dont ils ont besoin. Il en résulte que chaque fois qu'un nouvel objet est créé, il doit être étiqueté avec une collection croissante de balises pour obtenir l'accès requis. Dans ce scénario, l'évolutivité devient difficile et la cohérence commence à échouer.

Beaucoup d'entre nous se sont retrouvés dans une situation où notre accès n'était pas tout à fait le même que celui d'un autre membre de notre équipe, et il s'avère qu'il nous manque un groupe (ou un tag). En utilisant un modèle simple en 4 dimensions, l'étiquetage de nouveaux objets est simple, prévisible, reproductible et supportable, et l'héritage dans la conception des politiques améliore considérablement la gérabilité.

La définition d'un système d'étiquetage évolutif et cohérent nécessite un changement de conception des politiques, mais une fois compris, sa simplicité rendra la gestion des politiques plus efficace.

Pour plus d'informations sur la façon dont nous envisageons l'étiquetage chez Illumio, consultez cette superbe vidéo de notre évangéliste en chef, Nathanaël Iversen.