Connaître son parc avant de le construire : Inventaire et CMDB

Dans le monde professionnel, on ne déploie jamais une infrastructure sans savoir précisément ce qu’on possède. Chaque serveur, chaque équipement réseau, chaque service est référencé, documenté, et relié aux autres composants du système d’information. C’est ce qu’on appelle une CMDB, Configuration Management Database, un concept central du référentiel ITIL, la bible des bonnes pratiques de gestion des services IT.

Avant de me lancer dans mon projet, j’ai joué un peu avec quelques services et leurs fonctionnalités par curiosité dans un esprit “homelab”. Maintenant avec PandaCyberLab, je veux introduire plus de rigueur et me rapprocher des pratiques professionnelles. Pour cela, je dois savoir exactement ce que je possède, quel rôle chaque équipement va jouer, et comment tout cela va s’articuler.

Cet inventaire va me servir de base sur laquelle je vais pouvoir construire la suite du projet : définir des VLANs pour isoler certains équipements et garder une source de vérité fiable à mesure que mon infrastructure va grandir.

Sommaire

Qu’est-ce qu’une CMDB ?

Une CMDB (Configuration Management Database) est une base de données qui centralise les informations sur tous les composants d’un système informatique, ce qu’on appelle des CI, Configuration Items. Un CI correspond à tout élément identifiable et gérable contribuant au fonctionnement d’un environnement informatique, tel que le matériel, le logiciel, les réseaux, la documentation ou même les personnes et les services eux-mêmes. Dans le référentiel ITIL, qui définit les bonnes pratiques de gestion des services IT, la CMDB est au cœur du processus de gestion des configurations.

Ce qui distingue une vraie CMDB d’un simple inventaire, c’est la notion de relations. Un inventaire répond à la question “Qu’est-ce que je possède ?”. Une CMDB va plus loin et répond à “Comment tout cela s’articule ensemble ?” Quel service tourne sur quel serveur, quel équipement dépend de quel autre, quel VLAN héberge quels équipements. Cette différence est ce qui permet, dans le monde professionnel, de comprendre l’impact d’une panne ou d’un changement avant même qu’il ne se produise.

Une CMDB référence généralement trois types d’informations pour chaque CI :

• Ses attributs : type d’équipement, rôle, caractéristiques techniques, état (actif, en test, retiré)
• Ses relations : de quels autres CI il dépend
• Son cycle de vie : de son acquisition jusqu’à son retrait

Pour mon projet, je n’ai pas besoin de la sophistication d’une CMDB d’entreprise. Mais le principe reste le même à mon échelle : savoir précisément ce que je possède, quel est le rôle de chaque équipement, et comment tout cela s’articule, pour pouvoir prendre des décisions éclairées au fur et à mesure que l’infrastructure se développe.

L’outil retenu

Pour construire ma CMDB, mon choix s’est porté sur NetBox. Né en 2016 au sein de l’équipe d’ingénierie de DigitalOcean, c’est aujourd’hui la référence open source pour modéliser et documenter une infrastructure réseau. Il est utilisé aussi bien par des hébergeurs que par des passionnés de homelab. Le projet est activement maintenu, avec une communauté large et un rythme de correctifs soutenu, un critère important pour moi : pas question de bâtir ma documentation sur un outil à l’abandon. J’ai aussi étudié Ralph, une alternative open source plus orientée gestion d’actifs et de datacenter, suivi du cycle de vie du matériel, gestion de licences, intégration avec un service desk. Un outil sérieux, mais moins focalisé sur le réseau, et dont la communauté semble aujourd’hui moins active. Pour mon usage, documenter mon réseau et préparer mes VLANs, NetBox correspond davantage à mes besoins.

Concrètement, NetBox va devenir la source de vérité de mon infrastructure. C’est ici que je vais centraliser :

• Mes équipements et leurs caractéristiques techniques
• Mon plan d’adressage IP (IPAM)
• Mes VLANs, dès que je les aurai définis
• Les relations entre équipements, quel service tourne sur quel serveur, quel équipement est connecté à quel autre

Au-delà de la documentation, NetBox a un autre intérêt qui prend tout son sens avec l’approche DevOps du projet : il expose une API complète. À terme, cette API pourra alimenter directement mon IaC, par exemple, générer automatiquement un inventaire Ansible à partir des équipements déclarés dans NetBox, plutôt que de le maintenir à la main. NetBox ne sera donc pas qu’un outil de documentation passive, mais une vraie brique active de l’infrastructure.

Pour l’instant, je n’ai pas encore d’infrastructure stable pour l’héberger, son installation viendra quand mon socle Proxmox sera plus avancé. En attendant, je vais commencer mon inventaire sous une forme plus simple, que je migrerai vers NetBox dès qu’il sera disponible.

Méthodologie de l’inventaire

Avant de remplir un tableau, j’ai besoin de définir une méthode pour éviter de me retrouver avec un inventaire incohérent, difficile à maintenir, ou simplement incomplet.

Deux niveaux d’inventaire

Tous les équipements de mon infrastructure n’ont pas le même rôle, et je n’ai pas besoin de les traiter avec la même précision. J’ai donc choisi de distinguer deux niveaux :

Niveau 1 : Équipements réseau (avec adresse IP) : serveurs, NAS, équipements réseau, appareils IoT connectés, PCs et mobiles de la famille. Ce sont les équipements qui constituent le cœur de ma CMDB, c’est sur cette base que je vais construire mon plan d’adressage et mes VLANs.

Niveau 2 : Inventaire étendu (sans IP propre) : onduleur, câblage physique, capteurs domotiques. Ils n’ont pas d’adresse IP mais ont un impact réel sur l’infrastructure. Un onduleur protège mes serveurs, un capteur de température m’alerte avant une surchauffe.

Cette distinction évite de noyer l’inventaire réseau sous des éléments qui n’ont pas leur place dans un plan d’adressage, tout en gardant une trace de tout ce qui compte pour le projet.

Les champs retenus

Pour rester exploitable, chaque équipement du Niveau 1 est documenté avec les champs suivants :

Ce sont volontairement des champs simples. L’objectif n’est pas de reproduire la complexité d’une CMDB d’entreprise, mais de poser une base claire et suffisante pour prendre de bonnes décisions par la suite.

Confidentialité

Un point important dans mes futures publications : certaines informations n’ont pas leur place dans un article public. Je ne mentionnerai donc ni les adresses IP, ni les adresses MAC, ni les numéros de série de mes équipements. Je partagerai uniquement ce qui est utile à la compréhension du projet, sans donner d’indices exploitables sur mon identité ou ma localisation.

L’inventaire actuel

Pour ce premier inventaire, je fais le choix de me concentrer sur les équipements qui vont concrètement intervenir dans mes prochains articles. Je ne vais pas tout lister dès maintenant si ça n’a pas encore d’utilité pour mon projet.

Les PC et téléphones du reste de la famille ne figurent volontairement pas dans cet inventaire, ils ne sont pas encore concernés par le projet à ce stade. Même chose pour les consoles de jeux, qui nécessitent aujourd’hui le protocole UPnP pour jouer en ligne : leur intégration mérite une réflexion dédiée, que j’aborderai plus tard dans un article spécifique.

Cet inventaire n’a donc rien de définitif. Il va s’enrichir au fil des articles, à mesure que de nouveaux équipements rejoindront l’infrastructure.

Faire vivre la CMDB dans le temps

Un inventaire figé n’a aucun intérêt. Une CMDB qui n’est plus à jour quelques mois après sa création devient pire qu’inutile car elle devient trompeuse, les décisions sont prises sur une base fausse. La vraie question n’est donc pas “comment créer une CMDB”, mais “comment la garder vivante”.

Phase 1 : Mise à jour manuelle

Tant que mon infrastructure reste de taille modeste, la mise à jour manuelle de NetBox reste tout à fait raisonnable. Chaque ajout, chaque changement de rôle, chaque mise hors service d’un équipement sera consigné au fil de l’eau, à mesure que le projet avance. Cela va m’obliger à rester rigoureux dès le départ plutôt que de remettre la discipline à plus tard.

Phase 2 : Vers une CMDB comme source de vérité active

À terme, l’objectif est que NetBox ne soit plus seulement un registre que je remplis à la main, mais qu’il devienne la source de vérité de mon infrastructure, au sens où c’est lui qui décrit l’état désiré, et où le reste de l’infrastructure s’aligne dessus, pas l’inverse.

Cela va se traduire par plusieurs intégrations possibles avec ma future couche Déploiement & Automatisation :

• NetBox et Ansible : pour générer dynamiquement l’inventaire Ansible à partir des équipements déclarés dans NetBox, via le plugin d’inventaire dynamique officiel. Plus besoin de maintenir un fichier d’inventaire à la main en parallèle.
• NetBox et Terraform/OpenTofu : pour utiliser NetBox comme source de données pour provisionner l’infrastructure, garantissant que ce qui est décrit correspond à ce qui est réellement déployé.
• Mise à jour automatique : à terme, des scripts ou des webhooks pourront mettre à jour NetBox automatiquement lors d’un déploiement via la CI/CD, réduisant le risque de désynchronisation entre la documentation et la réalité.

Cette bascule du mode manuel vers le mode automatisé ne se fera pas du jour au lendemain. Elle suivra naturellement la maturité de mon infrastructure et de mes pipelines CI/CD. Mais c’est cette direction qui donne tout son sens à la CMDB : il ne s’agit pas d’un document de plus à maintenir, mais une brique active qui pilote concrètement l’infrastructure.

De l’inventaire vers les VLANs

Maintenant que mon inventaire prend forme, une question se pose naturellement : comment organiser tous ces équipements sur le réseau ? La réponse passe par la segmentation en VLANs, un sujet suffisamment dense pour mériter son propre article, mais que je souhaite introduire dès maintenant, car c’est l’inventaire qui va directement nourrir cette réflexion.

Pourquoi segmenter plutôt que tout laisser sur un seul réseau ?

Sur un réseau domestique classique, tous les appareils se voient et peuvent communiquer entre eux sans restriction : la box opérateur, le NAS, le PC portable, le smartphone, et demain les services exposés sur Internet, tout cohabite sur le même réseau plat. C’est simple, mais c’est aussi le pire scénario en termes de sécurité : si un seul équipement est compromis, rien ne l’empêche d’accéder à tout le reste.

Un VLAN (Virtual Local Area Network) permet de créer des réseaux isolés les uns des autres, même s’ils partagent la même infrastructure physique (mêmes câbles, même switch). C’est la brique fondamentale qui va me permettre d’appliquer concrètement l’approche Zero Trust définie dans mon article précédent : chaque zone du réseau n’a accès qu’à ce dont elle a strictement besoin, et rien de plus.

Ce que j’apprends de mon inventaire

En listant les équipements de mon inventaire, plusieurs catégories naturelles se dessinent et c’est précisément sur cette base que je vais construire mes VLANs :

• Des équipements de gestion et d’administration de l’infrastructure (accès à Proxmox, à NetBox, à OPNsense…). Ces accès doivent être strictement limités.
• Des équipements de homelab, dédiés à l’expérimentation, qui n’ont aucune raison de communiquer avec la production.
• Des équipements de production, qui hébergent les services réellement utilisés au quotidien.
• Des clients (PC, smartphones) qui doivent pouvoir consommer les services, sans pour autant avoir un accès direct à l’infrastructure sous-jacente.
• Des équipements domotiques et IoT (ESP32, futurs capteurs), historiquement peu sécurisés et donc à isoler par précaution.
• Une zone opérateur, qu’on avait évoquée précédemment, pour les équipements qui ont besoin de rester proches du réseau du FAI (consoles avec UPnP, décodeur TV).

Une première ébauche, à affiner

Voici une première proposition de découpage, qui sera détaillée et probablement ajustée dans l’article dédié au plan réseau :

Ce découpage n’est pas figé, il évoluera très certainement à mesure que j’avancerai sur le plan d’adressage IP, les règles de pare-feu entre VLANs, et les contraintes concrètes de mes équipements (comme le cas de l’UPnP évoqué précédemment). Mais l’essentiel est là : mon inventaire qui a permis de faire émerger cette première structure, plutôt que de partir d’un schéma théorique déconnecté de ma réalité.

Conclusion

Cet inventaire, aussi simple soit-il en apparence, a déjà changé ma façon de voir le projet. Lister mes équipements un par un, noter leurs caractéristiques, leur rôle prévu. C’est un exercice qui m’a forcé à clarifier ce qui restait flou dans ma tête. Et la première leçon est là : mon parc actuel, même modeste, dessine déjà naturellement les contours de mon futur réseau, à travers les catégories qui s’en dégagent : gestion, homelab, production, clients, IoT, zone opérateur.

NetBox prendra le relais dès que mon infrastructure sera prête à l’accueillir, et cet inventaire deviendra alors une vraie source de vérité, vivante et connectée au reste de mes outils.

Pour la suite, place à la pratique ! Les prochains articles vont présenter concrètement le matériel qui constitue mon parc : la box, mon NAS, mon ThinkCentre, avant de m’arrêter sur un exercice qui me tient particulièrement à cœur : regarder mon infrastructure actuelle avec les yeux d’un attaquant, et faire l’état des lieux de mon exposition sur Internet. Une étape indispensable avant d’aller plus loin dans la construction de mon réseau et de ses VLANs. À très vite. 🐼