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

L'IP a une structure que tout le monde et toutes les machines peuvent comprendre. Si vous montrez à quelqu'un un ensemble de nombres en 4 dimensions comme 192.168.1.254, Nombreux sont ceux qui le reconnaîtront immédiatement. La structure simple rend l'information facile à consommer et à comprendre. C'est ce qui permet à l'internet de s'étendre 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. Que se passerait-il si une minute vous voyiez 192.179.134.56.245.23 et la suivante 24.87 ? Comment déterminer les liens entre ces éléments ?

Bien que nous considérions la flexibilité et le libre arbitre comme des éléments positifs, dans le monde de l'adressage réseau - et également dans l'étiquetage de la charge de travail (en particulier dans la microsegmentation) - ils peuvent être source de confusion et de complexité. En fin de compte, cela conduit à des politiques incohérentes et à des problèmes similaires à ceux rencontrés avec les politiques de pare-feu traditionnelles.

Depuis quelques années, nous avons étiqueté les objets avec un large éventail d'attributs pour identifier et regrouper les biens, ce qui a toujours posé des problèmes d'échelle et de gestion. Sans structure, la création d'une architecture durable devient de plus en plus problématique au fil du temps. Chez Illumio, nous avons identifié ce problème très tôt et avons décidé que la structure et la simplicité offraient d'énormes avantages opérationnels par rapport à l'étiquetage arbitraire des objets.

En d'autres termes, les étiquettes doivent être faciles à utiliser, reproductibles, prévisibles et simples à comprendre par la suite.

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

1. S'en tenir à un système d'étiquetage à 4 dimensions

Il s'agit de classer les charges de travail en fonction de paramètres dimensionnels simples et évidents. Par exemple :

1. Localisation : Où se situe la charge de travail ? Il peut s'agir d'un pays, d'une ville, d'un fournisseur de services en nuage, etc.
2. Environnement : Cet objet se trouve-t-il en production, en développement ou en test ?
3. Application : S'agit-il d'une application financière, de ressources humaines ou de gestion de la relation client (CRM) ?
4. Rôle : s'agit-il d'un serveur d'application, 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 l'emplacement (RAEL), nous pouvons créer un modèle d'étiquetage qui est non seulement facile à comprendre, mais aussi portable et extensible.

Cette structure permet aux utilisateurs de pivoter sur n'importe laquelle des quatre étiquettes et d'utiliser une seule section pour simplifier le contrôle et réduire le temps de calcul. Si nos étiquettes concernaient des véhicules et prenaient la forme de "Type | Marque | Modèle | Couleur", l'identification des seules BMW ou des véhicules rouges rendrait l'exercice très simple et rapide.

N'oubliez pas que l'étiquetage des objets sert tout simplement à 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 sur ce point.

2. Standardiser un format

Bien que nous puissions voir des choses similaires pour la mise en réseau et l'informatique, il y a une grande différence entre "Production", "Prod" et "prod". Il y aura toujours des erreurs d'orthographe et, dans un modèle structuré à quatre dimensions, il est facile de les résoudre.

Cependant, dans un environnement libre, j'essaie de trouver l'erreur dans "prod.fin.win.UK.CRM.web.bldg1.10" sera un long processus.

3. Soyez prudent lorsque vous raccourcissez les noms des étiquettes

Par exemple, vous abrégez une étiquette, telle que "Production" en "Prod", mais vous n'abrégez pas "Base de données". Le fait de raccourcir les noms des étiquettes de manière incohérente peut entraîner la duplication des étiquettes, ce qui peut à son tour conduire à une application incohérente des politiques ou à des problèmes de compatibilité.

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 de problème est la création d'une étiquette "Prod" et d'une étiquette "Production". Si certaines charges de travail sont étiquetées comme "Prod", les règles créées pour "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. Rester cohérent dans tous les systèmes

Outre la cohérence de votre système d'étiquetage pour la micro-segmentation, nous vous recommandons de maintenir la cohérence avec les sources externes de métadonnées.

Si vous avez établi des conventions de dénomination des métadonnées, par exemple dans votre base de données de gestion de la configuration (CMDB), des conventions de dénomination des hôtes ou l'utilisation de blocs d'adresses IP, ne créez pas d'autres conventions pour votre système 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. Cela est extrêmement bénéfique pour une multitude de raisons, et votre organisation en bénéficiera.

Le cas d'utilisation de votre déploiement initial peut être limité à un environnement ou à une application spécifique. Cependant, si vous concevez votre étiquette en pensant à l'ensemble de votre organisation, vous économiserez du travail si le déploiement s'étend. Les schémas d'étiquetage plus simples sont plus évolutifs et plus faciles à prendre en charge.

5. Utilisez des étiquettes pour différencier les objets

Lorsque vous devez différencier les politiques entre les objets, utilisez des étiquettes différentes. Dans certains cas, il peut être tentant d'utiliser des étiquettes distinctes, mais en réalité il n'y a pas de différenciation politique, et cela n'est donc pas nécessaire. N'oubliez pas que la politique à cet égard comprend la politique de sécurité, mais aussi le RBAC, le reporting, le contrôle des changements et d'autres types de politique.

En gardant cela à l'esprit, utilisez des noms communs 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 commun, tel que "Serveur Web". Dans la plupart des cas, vous n'aurez probablement pas besoin de rédiger des polices différentes pour ceux-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 et des protocoles de service différents, et chacun possède des éléments de politique de sécurité uniques, tels que les flux de trafic en grappe. Par conséquent, nous vous recommandons d'attribuer trois étiquettes de rôle différentes aux charges de travail qui exécutent ces applications. Par exemple, cela vous permettra d'écrire une politique spécifique pour permettre à vos serveurs Oracle Enterprise Manager d'accéder uniquement à vos serveurs de bases de données Oracle, et non à vos serveurs Sybase.

Comment Illumio peut vous aider

Illumio Core utilise une conception multidimensionnelle, avec une combinaison de quatre étiquettes identifiant les objets de la politique. D'autres produits utilisant le balisage peuvent vous permettre de créer un nombre illimité de balises. Bien que cela puisse sembler rendre l'étiquetage plus flexible, il en résulte des difficultés qui s'accentuent au fil du temps.

Si vous continuez à ajouter différentes dimensions d'étiquettes, vous aboutissez très rapidement à un modèle unidimensionnel où toute étiquette donnée indique une application unique de la politique. L'analogie avec un service d'annuaire est parfaite : un nouveau groupe (étiquette) peut être créé pour chaque nouveau besoin et appliqué aux utilisateurs. Ces groupes se multiplient rapidement et sont souvent associés aux mêmes objets, ce qui entraîne des doublons. Il n'est pas rare qu'il y ait plus de groupes que d'utilisateurs. De même, dans une solution basée sur les balises, vous risquez de vous retrouver avec plus de balises que d'objets, chaque objet étant associé à un grand nombre de balises.

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

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'est avéré qu'il nous manquait un groupe (ou une étiquette). Grâce à l'utilisation d'un modèle simple à quatre dimensions, l'étiquetage de nouveaux objets est simple, prévisible, reproductible et supportable, et l'héritage dans la conception de la politique améliore considérablement la facilité de gestion.

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

Pour en savoir plus sur la façon dont nous concevons l'étiquetage chez Illumio, consultez cette excellente vidéo de notre évangéliste en chef, Nathanael Iversen.