La racine du mal

Choisir une convention de nommage des machines est, le plus souvent, une étape dont se saisissent les administrateurs système et/ou réseau, assez tôt dans la vie d'une société.
Seulement, lorsque l'entreprise grandit, les bouts de ficelle, mis en place au début, ne suffisent plus (si vous nommez vos serveurs comme les chevaliers du Zodiaque, vous allez avoir du mal passé 30 machines).
C'est généralement à ce moment qu'on va opter pour une politique de nommage mieux dimensionnée mais encore informelle.
Puis l'entreprise grandit encore, elle a plusieurs bâtiments, les administrateurs n'étaient pas tous là au démarrage de l'entreprise (ils ne connaissent pas l'historique). Plusieurs conventions de nommage cohabitent (parfois différentes entre les services). Savoir à qui appartient une machine et à quoi elle sert devient un casse tête.

Face à cela, l'entreprise va mettre en place un outil de CMDB. Malheureusement, dans les faits il y en a souvent plusieurs qui cohabitent et personne ne s'accorde sur celui qui doit primer. Ils sont incomplets, peu mis à jour, lourds, tout le monde les détestent et doit se débrouiller avec de la magie noire pour trouver l'info.

"Mal nommer les choses c'est ajouter au malheur du monde" disait Camus

Chez Astar, nous aimons bien les solutions simples, légères et qui épargnent les usines à gaz. Une bonne politique de nommage peut repousser le moment où vous aurez besoin d'outillage (CMDB) et même après, cela vous épagnera bien du travail d'archéologie du SI. Voici quelques bénéfices simples:

• Un mainteneur qui voit qu'une machine ne répond plus peut directement qualifier la gravité (savoir si c'est une machine de production ou de dev, si c'est de l'usage interne ou du B2C, etc.) et savoir où elle se trouve si il veut agir physiquement dessus
• Un opérateur du SOC peut rapidement savoir où se trouve une machine qui génèrent des alertes et à quoi elle sert. Ceci peut permettre de confirmer/infirmer d'un coup d'oeil si un événement de sécurité est suspect (un équipement réseau qui se met à faire du HTTPS c'est pas la même soupe qu'un poste de travail)
• Si une vulnérabilité publique affecte un certain type de système, une première estimation des machines concernées dans l'entreprise, peut rapidement être menée
• En cas de contrôle RGPD, un Data officer peut rapidement fournir une liste macroscopique des machines qui hébergent des données personnelles
• On peut s'assurer que le déploiement d'une machine est bien passé par toutes les étapes voulues (chacune fournissant un élément du nommage)
• Vous pouvez scripter des comportements en vous basant sur le nom d'une machine (si le nom m'indique que c'est une machine Linux, je me connecte en SSH, si c'est du Windows en WinRM, ...)
• etc.

Mais avant de rentrer dans le vif du sujet, il faut préciser quelque chose d'important :

Si nous vous proposons cet article, c'est parce qu'il y a un intérêt énorme à faire une bonne politque de nommage du premier coup et le plus tôt possible. Cela améliore considérablement la connaissance et la maintenabilité d'un SI (ce qui est l'étape primordiale à la sécurité: on ne sécurise que ce que l'on connait). Cela lutte contre le shadow IT, les angles morts, les surfaces d'attaque inutilement exposées (les serveurs toujours branchés mais que plus personne n'utilise), etc.

Si vous partez sur une convention temporaire que vous prévoyez d'améliorer avec le temps, vous aurez une cohabitation de plusieurs conventions et donc ce sera nul.
Une politique de nommage doit être homogène. Dès qu'on commence à avoir plusieurs conventions qui cohabitent, il vaut mieux perdre un peu de temps à tout remettre à plat que laisser perdurer. C'est beaucoup plus facile à faire que contrôler que toutes les machines sont bien renseignées dans la CMDB. Mais le plus tôt on introduit une poltique de nommage, le plus tard on rencontrera ce genre de problème.

Allons-y

Que nommer ?

Qu'est-ce qui pourrait nous intéresser de connaître "d'un coup d'oeil" en lisant le nom d'une machine ? En vrac on peut citer :

• Sa localisation physique (pays, ville, bâtiment, ...)
• Sa localisation logique (Edge, DMZ, Lan, hébergeur, AWS, ...)
• Son type (serveur, workstation, équipement réseau, IoT, ...)
• Son OS (Linux, Windows, BSD, FortiOS, Android, ...)
• Sa criticité opérationnelle (production, pré-production, dev, ...)
• Sa criticité métier (B2C, B2B, interne, ...)
• Le service fourni (Mail, Router, ERP, ...)
• Le responsable (la personne a contacter si on a une question dessus (genre "est-ce que cette machine est toujours utilisée ?"))

Cependant, vous devez aussi limiter la quantité d'information car tout cela sera accessible à un attaquant ayant pu pénétrer dans le réseau (s'il peut trouver d'un coup d'oeil tous les windows XP vulnérables, ou localiser directement le serveur de backup, ce n'est pas à votre avantage).
Tout est affaire de jugement selon la criticité de votre système d'information.

Comment nommer ?

En général, il y a deux alternatives :

• soit on utilise une lettre pour chaque info
• soit on utilise un trigramme

Aucune n'est satisfaisante.

Avec le trigramme, les noms peuvent être très longs (ce qui est chiant à taper au clavier quand on en a besoin). Et les risques de collision (deux trucs différents qui ont le même trigramme) ne sont pas nuls. Avec les initiales, il y a un risque important de collision et c'est moins facile de retenir les correspondances. Pour traiter les collisions, vous aurez besoin d'un séparateur (un "-" ou un ":" par exemple) ce qui va allonger considérablement le nom aussi. Si des collisions apparaissent, que vous décidez d'ajouter des caractères pour lever l'ambiguité et que vous n'avez pas de séparateurs, vous perdez la faculté de facilement scripter des comportements basés sur les noms.

Le meilleur compromis semble être de n'utiliser que le minimum de caractères pour décrire sans ambiguité et de mettre des séparateurs.
Si des valeurs sont peu susceptibles de se diversifier dans l'avenir (par exemple une échelle de criticité: l:low m:medium h:high c:critical ou le type de data stockée: p:personal s:strategic o:operational h:health), le séparateur peut être omis entre celles-ci.

Dans quel ordre le nommer ?

L'ordre n'est pas vraiment déterminant. La plupart du temps, l'habitude de lecture de la convention de nommage est rapidement adoptée.

Voici tout de même deux propositions :

• Aller du plus tangible au plus abstrait : de la localisation physique à la donnée stockée par exemple.
• Aller du champ le plus obligatoire au champ le plus optionnel (ceci permet de facilement omettre certains champs optionnels pour gagner de la place).

Où nommer ?

Le mieux c'est le serveur DNS interne évidemment. Cela permet d'avoir une gestion centralisée: si on me demande toutes les machines Windows du parc, je peux faire un transfert de zone et trier celles qui correspondent. De la même manière, si une adresse IP n'a pas de résolution DNS associée, on saura que c'est suspect (soit un intrus, soit une machine qui n'a pas suivi le process normal de recette).
C'est en revanche complexe d'utiliser un nommage de toutes les machines avec une partie du réseau en DHCP. L'adressage fixe sera le plus adéquat.
Concernant le fait de nommer des équipements qui ne sont pas connectés au réseau (un PC en standalone par exemple), un enregistrement TXT (simple texte) peut être utilisé au lieu d'un A (association nom <-> IP).

Le nom doit être répliqué en tant que hostname de la machine pour assurer la cohérence. Cependant le hostname est parfois limité en taille (notamment sur les équipements réseau) et risquera donc de devoir être tronqué au dela de 10-12 caractères.

La formule

Nous y voilà. Le schéma de nommage global, proposé par Astar, est :

CRITICITE-TYPE-OS-LIEU-RESEAU-USAGE-DATA

Et voici tout de suite une série d'exemples qui recouvrent différents usages possibles :

• prd:e:fo:tls:dmz:fw: : Un équipement réseau (e) de type pare-feu (fw) de production (prd) tournant avec l'OS FortiOS (fo) situé dans la DMZ (dmz) de Toulouse (tls) et n'hébergeant aucune donnée importante (nul)
• 3-s-w-fp-ovh-axelor-pso : Un serveur (s) windows (w) servant d'ERP (axelor) hébergé dans l'infrastructure d'OVH (ovh) du Datacenter de Paris en France (fp) ayant une criticité de 3/4 (3) et traitant des données personnelles, stratégiques et opérationnelles (pso)
• mslg23_bi_p : Un serveur (s) Linux (l) de criticité mineure (m) situé dans le VLan 23 (23) du site Gaudi de Barcelone (g) utilisé pour la business intelligence (bi) et habritant des données personnelles (p)

Plus en détail

Criticité

On le met en premier car on veut savoir tout de suite si la machine à laquelle on s'intéresse est importante pour l'entreprise. Si on me dit "y a la machine crit-n-b-p-dmz-fw--res qui vient de tomber" je vais un peu plus me presser que si c'est low-s-l-p-ovh-marketing-bi-mcom.

On peut utiliser une dénomination dont le lecteur pourra déduire la criticité :

‍

Ou bien utiliser une échelle de criticité textuelle :

‍

Ou encore numérique (1-2-3-4). Mais la version numérique pose toujours le problème que tout le monde n'a pas les mêmes réflexes quant à la criticité maximale (est-ce que c'est 1 ou est-ce que c'est 4 ?), donc nous recommandons la textuelle.

Type

En suivant on indique le type de machine car ça donne tout de suite un début de contexte quant au fait qu'il se passe ceci ou cela.
Une caméra IP qui consomme beaucoup de bande passante ça m'étonne tout de suite moins que si c'est une badgeuse.

On peut partir sur une dénomination légère :

‍

Ou bien donner plus de détails, notamment pour les types d'équipements et d'objets connectés mais ça demandera d'utiliser plusieurs lettres : r:router - sw:switch - f:firewall - ... cm:camera - th:thermostat - r:raspberry - ...
Ce n'est pas forcément utile d'aller à ce niveau de précision car le champ usage donnera aussi des précisions

OS

Connaitre l'OS peut rapidement permettre de savoir si une machine est concernée par un problème. Par exemple si une vulnérabilité affecte SSH, en se basant sur les noms on peut estimer le nombre de machines concernées (les Linux, les équipements réseau sont probablement concernés mais pas les windows, les android, etc.).

Une dénomination à une seule lettre suffit à couvrir les grandes familles ce qui est, le plus souvent, suffisant :

‍

La pluaprt des équipements réseau sont des surcouches du système BSD et peuvent donc y être associés. La catégorie "firmware" est un fourre-tout dans lequel on peut mettre les imprimantes, les téléphones sur IP, les caméras IP, etc.
Cependant, on peut être tenté d'aller plus loin dans la précision pour distinguer les différents OS des équipements frontaux afin de réagir plus vite en cas de vulnrabilité publique : FortiOS, Cisco IOS, Junos OS, Gaia, ... mais là aussi cela nécessitera probablement plus d'une seule lettre.

Lieu

Connaitre le lieu est intéressant quand l'entreprise est grande et qu'elle dispose de plusieurs locaux, hébergements, datacenters, etc.
Si l'on voit qu'un serveur AD a planté et qu'il faut le rebooter, savoir rapidement qu'il est à Meudon (c-s-w-meu-srv-ad-p) et pas à San Francisco permet de passer son coup de fil plus vite.

Cette info est difficile à normaliser. Si vous commencez par seulement donner des noms de bâtiments mais que, plus tard, vous en avez des milliers dans le monde, on ne pourra plus décrypter l'information "d'un coup d'oeil". Inversement, si vous donnez seulement le nom de la ville ou du pays mais qu'il y a des dizaines de sous-lieux, vous perdez en utilité.
Un compromis peut être d'utiliser un trigramme PAYS-VILLE-BATIMENT (fla: France-Labège-ACTYS) mais il peut y avoir des collisions assez vite entre les noms des pays (France, Finlande, ...) ou ceux des batiments (ACTYS 1, ACTYS 2, ...).

Le plus commun est d'utiliser le nom d'un "site". Une unique ville ou un unique pays peut comporter plusieurs sites et un site peut comporter plusieurs bâtiments. C'est un bon compromis entre la rapidité d'interprétation et l'utilité de l'information.
Par exemple, pour le siège d'Astar, situé dans le quartier Terre-Cabade de Toulouse, un "tca" est suffisamment court et les collisions seront vraisemblablement évitables quand nous aurons des bureaux partout dans le monde.

Réseau

Cette information n'est pas aussi figée que le type d'équipement ou l'OS. Elle peut prendre de nombreuses formes selon la façon dont vous avez segmenté votre réseau : par lieu géographique, par usage, par criticité, etc. Et selon cette façon, ce champ peut avoir des intersections avec les champs "criticité", "lieu" et "usage".
Si vous avez nommé un VLan "VLAN_TOULOUSE_DMZ" par exemple, vous pouvez vous contenter de mentionner "dmz" car Toulouse est déjà indiqué par le champ lieu.

On peut imaginer beaucoup d'approches différentes pour le nommage de ce champ: vlan23, dmz, admin, zone_rouge, .... Je déconseille cependant d'y mettre des subnets (type 172.16.0.0_16), ce serait trop redondant avec l'information portée par l'adresse IP.
Le mieux est d'opter soit pour l'identifiant unique du réseau (un numéro ou un nom) soit pour un mot qui décrit son usage.

Usage

Ce champ est, en quelque sorte, l'espace commentaire du nom, le joker. On peut y mettre la fonction générale de l'équipement (erp), être plus précis en donnant le nom de l'outil (axelor) ou au contraire plus général en donnant le service qui en est responsable(compta).

Indiquer un responsable (au sens RACI du terme) n'est pas une chose simple à renseigner. D'un côté, c'est une information très utile si elle est précise : ça dit directement à qui il faut s'adresser si on a une question sur cette machine, ce qui est inestimable.
Mais d'un autre côté, plus c'est précis, plus c'est susceptible d'être obsolète rapidement : si vous avez mis le nom du responsable (mettons "dofer") et qu'il est viré par la suite, ça va être pénible de changer tous les noms DNS des machines qu'il gérait. D'ailleurs, en plus d'être pénible, ce serait même risqué puisque des noms DNS sont vraisemblablement utilisés dans des fichiers de configuration.
On veut donc indiquer une information aussi immuable que possible : le nom d'un service/métier (admsys: administration des systèmes) ou d'un poste (rmarket : responsable maketing).

Il faut faire attention à ne pas être trop verbeux non plus et quand on ne sait pas quoi mettre, on peut aussi laisser simplement le champ vide.
Par exemple, pour une caméra IP dont le nom du réseau explicite déjà clairement l'usage, on omet le champ : mif-dsd-cam- -p (un objet connecté (i) de criticité moyenne (m) basé sur un firmware (f) sur le site de Dresde (dsd) et dans le réseau des caméras (cam) et traitant des données personnelles (p)). On pourrait préciser parking pour indiquer où la caméra filme mais l'intérêt d'une telle info est probablement trop faible pour mériter de figurer dans le nom.
C'est affaire de jugement.

Data

Ce champ mérite sa place notamment pour les contraintes RGPD. On peut simplement l'utiliser en mode booléen : est-ce que oui ou non des données personnelles sont présentes ? Bien entendu, il faut considérer les données personnelles non internes (sinon n'importe quelle machine stocke des noms d'utilisateurs donc des infos personnelles).

On peut aussi rendre ce champ plus riche en utilisant des initiales pour les principaux types de données :

‍

Les données "opérationnelles" sont à considérer comme celles nécessaires à l'accomplissement des tâches auprès des clients. Les données "stratégiques" sont les secrets industriels, les savoir-faires de l'entreprise. Les autres sont assez transparentes.

Si l'on adopte cette approche, ce champ devra toujours être entouré de séparateurs car le nombre de lettres peut varier. Un serveur de paiement hébergera des données personnelles et bancaire (pb). Un serveur de partage de fichier hébergera des données opérationnelles, stratégiques et personnelles (pos).

Cependant, ce niveau de précision va avoir des intersections importantes avec le champ criticité (qui lui est plus large car il prend aussi en compte les besoins de disponibilité du service). Or il faut toujours essayer de réduire la redondance si l'on veut que les usagers adoptent la convention de nommage. Si les administrateurs système ont l'impression de remplir des données compliquées à récolter et redondantes entre elles, ça ne marchera pas très bien.
Donc on peut se contenter d'une simple valeur booléenne ("-p-" si ça contient des données personnelles ou "--" sinon, ou bien "p" vs "n" (null) si on veut gagner de la place sur les séparateurs). Le Data Officer sera aux anges et vous n'aurez pas l'air aussi à l'Ouest que vous l'êtes en cas de contrôle de la CNIL.

TLDR

Tous ces détails étant donnés, voici notre proposition finale :

• une criticité à une lettre parmi Low, Medium, High et Critical
• un type à une lettre parmi Server, Workstation, Laptop, Cellphone/smartphone, Tablet, Network equipment, Printer, WiFi, IoT, Hypervisior, VoIP
• un OS à une lettre parmi Windows, Linux, BSD, Android, iOS, firmware
• un trigramme pour désigner le site géographique de stockage
• un tiret
• une chaine de caractères pour désigner le réseau
• un tiret
• une chaine de caractères pour désigner l'usage
• un tiret
• un 'p' s'il y a des données personnelles, un 'n' sinon

Donc l'actif qui héberge le site sur lequel vous lisez actuellement cet article se nommerait mslscp-b2cp-sitew-n. C'est un serveur (s) Linux (l) de criticité moyenne (m) localisé dans le datacenter parisien de Scaleway (scp) qui appartient au réseau que j'ai nommé B2C de production (b2cp) et qui est un site Web (sitew) et il n'héberge aucune donnée personnelle (n) (car oui si vous ne voyez pas de bandeau chiant pour accepter les cookies, ce n'est pas un oubli, il n'y a juste aucun tracking sur notre site).

Le pouvoir de tout nommer

Bien entendu, vous pouvez/devez réappliquer la puissance d'une bonne convention de nommage à toutes les couches d'abstraction: nom d'utilisateur, de groupe, de partages, de bâtiment, de règles de pare-feu, etc.
Par exemple, vous verrez souvent des "ext" dans les noms d'utilisateurs des sous-traitants dans les grandes entreprises ou encore des préfixes "adm" pour les comptes à privilège. Mais on peut aller bien plus loin.