CMDB conforme à NIS2 : le modèle de données d’actifs minimum pour la cyber-résilience (UE)

Temps de lecture estimé : 15 minutes

Principaux points à retenir

• Une CMDB alignée sur NIS2 est un contrôle central pour la cyber‑résilience de l’UE, et non un inventaire « agréable à avoir ».
• Les attentes de NIS2 en matière de gestion des actifs, de déclaration d’incidents et de risque de chaîne d’approvisionnement se traduisent par des exigences très concrètes sur le modèle de données et les processus de la CMDB.
• Un ITAM robuste alimentant votre CMDB est indispensable pour obtenir une visibilité complète des actifs, une attribution claire et une traçabilité des fournisseurs.
• Les orientations nationales de l’ANSSI et du CCB Belgium renforcent la nécessité de disposer de données d’actifs structurées, à jour et orientées sécurité.
• Une feuille de route pragmatique — couvrant la conception du modèle de données, la découverte, l’intégration ITAM et la gouvernance — vous permet de construire concrètement une CMDB alignée sur NIS2.

Comment NIS2 redéfinit la gestion des actifs et des configurations

NIS2 élargit considérablement le périmètre des entités concernées. Elle s’applique aux entités essentielles, telles que les grandes organisations des secteurs de l’énergie, des transports, de la banque, des infrastructures numériques, de la santé, de l’eau potable, des eaux usées et de l’administration publique, généralement avec au moins 250 employés ou 50 M€ de chiffre d’affaires. Elle couvre également des entités importantes, comme les entreprises de taille moyenne dans les services postaux, la gestion des déchets, les fournisseurs numériques, la production alimentaire et divers secteurs manufacturiers, généralement avec au moins 50 employés ou 10 M€ de chiffre d’affaires, comme le résume la directive NIS2 officielle (EUR-Lex). En outre, les orientations d’autres commentateurs confirment cet élargissement du champ d’application ainsi que les obligations en matière de gestion des risques et de reporting dans ces secteurs, comme l’indiquent des observateurs du secteur.

Dans le cadre de NIS2, les entités essentielles comme les entités importantes doivent mettre en œuvre des mesures de gestion des cyber‑risques « appropriées et proportionnées », déclarer les incidents significatifs dans des délais stricts, assurer la continuité d’activité et la gestion de crise, et gérer les risques de la chaîne d’approvisionnement. Pour satisfaire ces obligations en pratique, vous avez besoin d’une gestion structurée des actifs et des configurations. Vous devez pouvoir répondre, clairement et rapidement :

• Quels actifs IT, OT, cloud et SaaS soutiennent chaque service essentiel ou important.
• Comment ces actifs sont interconnectés, afin de comprendre les impacts et la propagation.
• Quels changements ont été effectués, par qui, et avec quelles validations.
• Où se situent les prestataires tiers dans chaque chaîne de service critique.

Ces attentes déterminent directement les exigences NIS2 pour la CMDB. Un inventaire traditionnel « au mieux » ne suffit plus. À la place, vous avez besoin d’un modèle de données CMDB capable de :

• Recenser chaque élément de configuration (CI) pertinent, sur l’IT comme l’OT.
• Relier les CI aux services, aux niveaux de criticité et au contexte réglementaire.
• Soutenir la cybersécurité de la visibilité des actifs en exposant la surface d’attaque et les dépendances.
• Fournir des preuves fiables et auditables aux régulateurs et autorités de supervision.

Sans CMDB maintenue, il devient difficile de relier les vulnérabilités aux services, de comprendre l’impact d’un incident ou de visualiser les dépendances de la chaîne d’approvisionnement. Avec une CMDB pensée pour NIS2, vous pouvez voir instantanément quels services essentiels reposent sur un composant exposé, quels fournisseurs sont impliqués et à quoi ressemble l’impact métier pour votre régulateur.

Qu’exige NIS2 en matière de gestion des actifs ?

NIS2 attend des organisations qu’elles :

• Maintiennent un inventaire complet des actifs soutenant les services essentiels et importants.
• Classent les actifs par criticité métier et par service.
• Cartographient les dépendances techniques et métier entre services et composants.
• Suivent les changements et les configurations dans le temps.
• Surveillent les dépendances aux tiers et à la chaîne d’approvisionnement liées à chaque service.

Définir les exigences NIS2 pour la CMDB en termes pratiques

En pratique, les exigences NIS2 pour la CMDB correspondent aux capacités minimales que votre CMDB doit fournir afin de prouver la conformité aux obligations de la directive en matière d’actifs, de configuration et de gestion des risques. La loi utilise rarement le terme « CMDB », mais son insistance sur des inventaires structurés, la traçabilité et la documentation renvoie à des fonctionnalités CMDB très précises, comme le soulignent plusieurs analyses sectorielles de l’impact opérationnel de NIS2.

Une CMDB alignée sur NIS2 doit couvrir au minimum cinq domaines de capacité.

1) Couverture

Votre CMDB doit enregistrer des éléments de configuration couvrant :

• Actifs IT : serveurs, machines virtuelles, conteneurs, applications, bases de données, équipements réseau, terminaux.
• Actifs OT : composants SCADA, PLC, capteurs et contrôleurs industriels lorsqu’ils soutiennent des services essentiels ou importants.
• Cloud et SaaS : services IaaS, PaaS et SaaS, cartographiés par compte cloud, abonnement et région.
• Identités et rôles : comptes utilisateurs, comptes privilégiés et comptes de service, ainsi que les groupes.
• Stockages de données : bases de données, data lakes, partages de fichiers et plateformes qui contiennent des données personnelles, confidentielles ou opérationnelles critiques.

Une couverture partielle, comme documenter uniquement les serveurs on‑prem, ne suffit pas pour NIS2. Vous devez démontrer une visibilité sur l’ensemble de votre surface d’attaque numérique et physique.

2) Classification

Chaque CI doit disposer d’attributs répondant aux obligations NIS2 :

• Niveau de criticité (p. ex. élevé/moyen/faible selon l’impact métier).
• Lien vers les services métier, en identifiant quel service essentiel ou important chaque CI soutient.
• Entité juridique et juridiction pour ce service.
• Classification sectorielle (énergie, transport, banque, santé, etc.).

Cette classification sous‑tend la priorisation fondée sur le risque et l’acheminement correct des déclarations d’incidents vers l’autorité nationale compétente une fois la directive transposée.

3) Attributs de sécurité

Pour soutenir la cybersécurité de la visibilité des actifs, la CMDB doit contenir des données pertinentes pour la sécurité, par exemple :

• Propriétaire de l’actif et propriétaire du service.
• Sensibilité des données (publiques, internes, confidentielles, secrètes ; présence de données personnelles).
• Exposition (accessible depuis Internet, interne, réseau OT, réseau partenaire).
• Indicateurs simples de surface d’attaque, tels que des endpoints externes ou des ports d’administration ouverts.
• Liens vers des vulnérabilités connues via l’intégration avec des outils de gestion des vulnérabilités.

Ces attributs aident les équipes risques et les RSSI à se concentrer sur les actifs qui comptent réellement pour le reporting et la mitigation NIS2.

4) Historique des changements et des configurations

NIS2 met l’accent sur la gestion proactive des risques et l’investigation des incidents. Par conséquent, votre CMDB doit conserver :

• Des détails de configuration versionnés lorsque pertinent (version de l’OS, version applicative, paramètres clés).
• Un historique des changements pour chaque CI : date de création, de modification ou de retrait.
• Des liens vers les tickets de changement, les validations et les contrôles de sécurité mis en place pour les changements critiques.

Ce niveau de traçabilité soutient à la fois les investigations internes et la production de preuves pour les autorités de supervision après incident.

5) Automatisation et mises à jour continues

La maintenance manuelle d’une CMDB ne suffit pas, à elle seule, dans des environnements hybrides modernes. Pour NIS2, votre CMDB doit être alimentée par :

• Des outils de découverte automatisée pour les réseaux, les terminaux et les ressources cloud.
• Des intégrations avec des plateformes telles que Microsoft Azure pour l’inventaire cloud.
• Des règles de rapprochement pour fusionner les données de plusieurs sources, éviter les doublons et maintenir des enregistrements à jour.

Les régulateurs, y compris des autorités nationales comme l’ANSSI en France et le CCB en Belgique, s’attendront à ce que vous démontriez non seulement que vous disposez d’une CMDB, mais aussi qu’elle est exacte et à jour. Même s’il n’existe pas de modèle public « ANSSI CMDB » ou « CCB Belgium CMDB », leurs orientations alignées sur NIS2 pointent clairement vers une gestion structurée des actifs soutenue par l’automatisation.

Que doit inclure une CMDB pour se conformer à NIS2 ?

Pour s’aligner sur les exigences NIS2 pour la CMDB, votre CMDB doit inclure :

• Une couverture complète des actifs IT, OT, cloud et SaaS.
• Une classification par service et par criticité métier.
• Des attributs de sécurité tels que le propriétaire, la sensibilité des données et l’exposition.
• La cartographie des dépendances entre services et actifs.
• L’historique des changements et des configurations pour les composants critiques.
• Des mécanismes de découverte automatisée et de rapprochement.
• Des liens vers les enregistrements d’incidents, de changements et de risques.

ITAM pour NIS2 : comment la gestion des actifs alimente votre CMDB

La gestion des actifs informatiques (ITAM) se concentre sur les aspects financiers, contractuels et de cycle de vie des actifs IT, de l’achat à la mise hors service. La CMDB, en revanche, se concentre sur la configuration, les dépendances et le contexte opérationnel. Répondre aux exigences NIS2 en matière de CMDB nécessite que ces deux disciplines travaillent de concert au sein d’un modèle de gouvernance unique.

ITAM pour NIS2 signifie utiliser les informations de cycle de vie et l’intelligence fournisseurs de l’ITAM pour enrichir votre CMDB afin de répondre aux attentes de la directive en matière de gestion des risques, de supervision de la chaîne d’approvisionnement et de responsabilité. L’ITAM fournit généralement :

• Données de cycle de vie : dates d’achat, couverture de garantie et de support, échéances de fin de vie.
• Données de licences et de contrats : quel fournisseur fournit quel service, quels SLA s’appliquent, où les données sont traitées.
• Détails financiers et organisationnels : centres de coûts, responsables budgétaires, propriétaires d’actifs et de services.

Lorsque ces informations alimentent la CMDB, la cybersécurité de la visibilité des actifs s’améliore nettement. La découverte montre ce qui s’exécute, tandis que l’ITAM confirme ce qui devrait s’exécuter et sous quel contrat.

L’ITAM améliore également la gestion des risques fournisseurs et de la chaîne d’approvisionnement. Une entrée fournisseur unique dans l’ITAM peut être liée à de nombreux CI dans la CMDB, révélant où un fournisseur cloud, un MSP ou un éditeur logiciel sous‑tend plusieurs services essentiels. Vous pouvez ainsi identifier les risques de concentration, prioriser la due diligence et vous aligner sur les attentes NIS2 en matière de risque tiers.

La gouvernance et la responsabilité en bénéficient aussi. Les propriétaires définis dans l’ITAM peuvent être affichés dans les vues CMDB afin que chaque CI critique et chaque service métier ait une personne clairement responsable. En cas d’incident, cela accélère la prise de décision et améliore la communication avec les régulateurs.

Techniquement, l’intégration entre ITAM et CMDB suit généralement l’un des deux schémas suivants :

• CMDB comme consommatrice : la CMDB importe depuis l’ITAM les identifiants d’actifs, les propriétaires et les références fournisseurs, tout en conservant les détails de configuration et de relations.
• Synchronisation bidirectionnelle : l’ITAM récupère le statut et l’emplacement depuis la CMDB ; la CMDB récupère les données financières et fournisseurs depuis l’ITAM. Des clés partagées, telles que les étiquettes d’actifs, maintiennent l’alignement.

Dans les deux cas, il est essentiel de définir quel système est la « source de vérité » pour chaque attribut, et de contrôler les mises à jour via une gouvernance claire.

Comment l’ITAM contribue-t-il à la conformité NIS2 ?

L’ITAM aide à la conformité NIS2 en fournissant des données de cycle de vie, fournisseurs et financières qui, une fois intégrées à la CMDB, garantissent une visibilité complète des actifs, une supervision renforcée de la chaîne d’approvisionnement et une attribution claire. Ensemble, ces capacités vous permettent de prouver que les services essentiels et importants sont soutenus par des actifs gérés, responsables et couverts par des contrats appropriés.

Concevoir un modèle de données CMDB prêt pour NIS2

Un modèle de données CMDB définit les classes d’éléments de configuration que vous suivez, les attributs que vous stockez à leur sujet et les relations qui les relient entre eux. Pour NIS2, ce modèle doit évoluer de vues génériques des services IT vers une structure plus riche, consciente des exigences réglementaires.

Traditionnellement, de nombreuses CMDB se concentraient sur la cartographie des applications vers les serveurs et les équipements réseau. Sous NIS2, toutefois, vous devez modéliser explicitement :

• Les services essentiels et importants tels que définis dans la transposition nationale.
• Le contexte réglementaire, comme le secteur, la juridiction et l’autorité de supervision.
• La posture de sécurité et les dépendances fournisseurs pour chaque composant critique.

Les cadres de bonnes pratiques du secteur, tels que ITIL, encouragent des définitions claires des services et des CI. NIS2 ajoute des exigences d’attributs et de relations spécifiques liées au cyber‑risque et à la conformité.

Classes de CI principales

Un modèle de données CMDB prêt pour NIS2 inclura généralement au minimum :

• Services métier (y compris les services essentiels et importants).
• Applications (systèmes métiers, plateformes cœur, SaaS).
• Infrastructure (serveurs, VM, conteneurs, middleware).
• Composants réseau (routeurs, pare-feu, commutateurs, load balancers).
• Stockages de données (bases de données, entrepôts, dépôts de fichiers).
• Identités et groupes (comptes utilisateurs, comptes privilégiés, groupes IAM).
• Emplacements (data centers, sites OT, bureaux, régions cloud).
• Tiers et fournisseurs (éditeurs, MSP, fournisseurs cloud).

Les relations clés peuvent inclure :

• Service métier → pris en charge par → applications.
• Application → hébergée sur → infrastructure.
• Infrastructure → connectée via → équipements réseau.
• Application/stockage de données → utilisé par → identités et groupes.
• Service métier/application → dépend de → fournisseur.

Attributs spécifiques à NIS2

Pour les CI de service métier, ajoutez des attributs tels que :

• Classification NIS2 : essentiel / important / autre.
• Secteur : énergie, transport, santé, banque, etc.
• Autorité de supervision ou régulateur.
• Juridiction ou pays.
• Note de criticité (p. ex. impact en cas d’indisponibilité).
• Paramètres de reprise (RTO, RPO).

Pour les CI techniques (applications, infrastructure, réseau, stockages de données) :

• Services classés NIS2 associés.
• Note de criticité alignée sur l’impact du service.
• Posture de sécurité : niveau de patch, date du dernier patch, nombre et gravité des vulnérabilités connues, principaux contrôles de sécurité en place (EDR, chiffrement, MFA, journalisation).
• Attributs de données pour les stockages : classification des données et catégories de personnes concernées (clients, employés, fournisseurs).
• Dépendance fournisseur : nom du fournisseur, référence de contrat, niveau de SLA.

Pour les identités :

• Rôle (admin, utilisateur standard, compte de service).
• Niveau de privilège.
• Services et actifs associés.

Normalisation et gouvernance

Pour maintenir ce modèle exploitable, imposez :

• Normalisation : une dénomination cohérente des logiciels, plateformes et fournisseurs.
• Normes de nommage : des schémas de nommage des CI prévisibles par type, environnement et région.
• Gouvernance : un propriétaire de la CMDB, des data stewards pour chaque classe de CI, et des processus de changement contrôlés pour modifier le modèle de données.

En reliant ces choix de conception aux exigences NIS2 pour la CMDB, vous obtenez une CMDB qui soutient directement la cyber‑résilience de l’UE : analyse rapide de l’impact des incidents, circuits clairs de reporting réglementaire et visibilité des dépendances fournisseurs transfrontalières.

À quoi doit ressembler un modèle de données CMDB conforme à NIS2 ?

Un modèle de données CMDB prêt pour NIS2 inclut des classes de CI pour les services métier, les applications, l’infrastructure, les équipements réseau, les stockages de données, les identités, les emplacements et les fournisseurs. Chaque CI contient des attributs pertinents pour NIS2 tels que la classification (essentiel/important), le secteur, le régulateur, la criticité, les objectifs de reprise, la posture de sécurité et les références fournisseurs, et l’ensemble est relié par des relations claires service‑vers‑actif.

Obtenir une visibilité des actifs pour la cybersécurité sous NIS2

La cybersécurité de la visibilité des actifs consiste à disposer d’une vue complète, exacte et à jour de tous les actifs qui composent votre surface d’attaque et de la manière dont ils se rattachent aux services critiques. Sous NIS2, cette visibilité est essentielle pour cartographier l’exposition, cadrer rapidement les incidents et les vulnérabilités, et respecter des délais de déclaration exigeants.

Pour y parvenir, la CMDB doit ingérer des données provenant de multiples sources de découverte et d’inventaire. Les entrées typiques incluent :

• Des outils de découverte réseau qui identifient les équipements basés sur IP.
• Des agents endpoint qui collectent l’OS, les logiciels et les détails de configuration.
• Les API des fournisseurs cloud pour des plateformes telles qu’Azure, AWS et GCP.
• Les portails d’administration SaaS, qui révèlent les applications utilisées et les identités associées.
• Des plateformes EDR/XDR qui combinent inventaire et télémétrie de sécurité.
• Des plateformes d’identité (AD, Azure AD, autres systèmes IAM).
• Des référentiels ITAM qui listent les actifs achetés et sous licence.

Chaque source voit l’environnement sous un angle différent. Par conséquent, la logique de rapprochement de la CMDB doit fusionner les données qui se recoupent en un CI unique par actif. Les attributs provenant de sources plus autoritatives (par exemple, les API cloud pour les identifiants de ressources cloud) doivent prévaloir sur les autres.

Les environnements hybrides compliquent ce tableau. Les systèmes on‑prem, les charges de travail en cloud public et les déploiements en cloud privé ou en edge doivent tous apparaître dans un inventaire logique unique. Les équipements OT et IoT ajoutent une complexité supplémentaire, car ils se trouvent souvent sur des réseaux séparés, sont gérés par des équipes différentes et peuvent nécessiter des outils de scan spécialisés. Pourtant, lorsqu’ils soutiennent des services essentiels, NIS2 attend toujours qu’ils soient recensés et gérés.

Le Shadow IT constitue un autre défi. Des outils SaaS non approuvés ou du matériel non autorisé peuvent apparaître dans des notes de frais, des journaux d’authentification ou du trafic réseau sortant. Des processus doivent être en place pour :

• Détecter ces actifs.
• Les enregistrer dans l’ITAM et la CMDB.
• Décider de les régulariser ou de les retirer.

Enfin, le rapprochement continu est vital. Les scans de découverte et les synchronisations d’API doivent s’exécuter selon une fréquence adaptée à l’environnement : peut‑être quotidiennement, voire plus souvent pour les réseaux critiques et les comptes cloud. Les règles de rapprochement doivent :

• Faire correspondre les enregistrements par nom d’hôte, IP, numéro de série, étiquette d’actif ou identifiant de ressource cloud.
• Fusionner les attributs tout en respectant l’autorité de chaque source.
• Signaler les actifs inconnus ou non gérés pour revue.

Le résultat est une CMDB vivante qui reflète votre surface d’attaque réelle et peut être utilisée directement pour soutenir les exigences NIS2 pour la CMDB, la priorisation des vulnérabilités et la déclaration d’incidents.

Comment obtenir la visibilité des actifs pour NIS2 ?

Pour obtenir une cybersécurité de la visibilité des actifs sous NIS2 :

• Intégrez des outils de découverte automatisée et des API cloud à votre CMDB.
• Rapprochez les données issues de l’ITAM, des plateformes de sécurité et des systèmes d’identité.
• Incluez l’OT/IoT et le shadow IT dans l’inventaire des actifs.
• Mettez à jour en continu les enregistrements et signalez les actifs inconnus ou non conformes.
• Cartographiez chaque actif vers les services essentiels ou importants qu’il soutient.

Utiliser le cadre CyFun avec une CMDB alignée sur NIS2

Le cadre CyFun est cité comme un cadre de cyberrésilience orienté UE ou spécifique à un secteur, structuré autour du cycle de vie de la cybersécurité bien connu : connaître, protéger, détecter, répondre et rétablir. Bien que les spécifications publiques détaillées soient limitées, son orientation s’aligne clairement sur les exigences NIS2 en matière de CMDB pour une connaissance structurée des actifs et une résilience opérationnelle.

Dans ce contexte, vous pouvez considérer CyFun comme une surcouche qui vous aide à opérationnaliser les contrôles NIS2. Une CMDB solide est au cœur de cet effort, car elle fournit les données dont dépendent les fonctions CyFun.

• Connaître : la CMDB offre une cartographie consolidée des services, systèmes et données, répondant à l’exigence « connaître son patrimoine ».
• Protéger : les attributs de sécurité et les notes de criticité dans la CMDB guident l’application de contrôles et de surveillance renforcés.
• Détecter : l’intégration de la CMDB avec des outils SIEM et XDR permet de relier les alertes de sécurité à des services spécifiques et à leurs impacts métier.
• Répondre : les relations entre CI aident les équipes à planifier le confinement, comprendre les dépendances et éviter les dommages collatéraux.
• Rétablir : les enregistrements CMDB des RTO/RPO, des configurations et des dépendances soutiennent une reprise structurée et conforme.

Vous pouvez aligner les champs et rapports CMDB sur les domaines de contrôle CyFun. Par exemple :

• CyFun « Connaître » : un rapport CMDB listant tous les services essentiels et importants, leurs CI de support et les fournisseurs associés.
• CyFun « Protéger » : des attributs sur les CI indiquant quels contrôles de sécurité (EDR, sauvegardes, chiffrement) sont en place.
• CyFun « Détecter » : des liens cartographiés entre les outils de supervision et les CI, afin d’enrichir les alertes avec la criticité du service.
• CyFun « Répondre » : des playbooks d’incident qui interrogent les dépendances CMDB lorsqu’un actif est compromis.
• CyFun « Rétablir » : la référence aux objectifs de reprise CMDB et aux baselines de configuration lors de la reconstruction des systèmes.

Grâce à cette cartographie, les exigences NIS2 pour la CMDB deviennent le socle de la mise en œuvre de CyFun de manière mesurable et auditable.

Qu’est-ce que le cadre CyFun et quel est son lien avec NIS2 ?

Le cadre CyFun est une approche de cyber‑résilience orientée UE qui structure les activités autour de la connaissance, de la protection, de la détection, de la réponse aux incidents et du rétablissement. Une CMDB alignée sur NIS2 fournit les données d’actifs, de services et de dépendances dont CyFun a besoin pour délivrer efficacement chacune de ces fonctions.

Des attentes ANSSI en matière de CMDB à la conformité CCB Belgium

Bien que NIS2 soit une directive à l’échelle de l’UE, chaque État membre la transpose en droit national et en orientations. Deux exemples influents dans l’espace CMDB et gestion des actifs sont l’ANSSI en France et le Centre for Cybersecurity Belgium (CCB).

L’ANSSI, l’Agence nationale de la sécurité des systèmes d’information, promeut une cartographie robuste des actifs, une classification fondée sur le risque et la traçabilité des changements. Ses recommandations soulignent que les organisations doivent maintenir :

• Une cartographie à jour des systèmes d’information (« urbanisation »), incluant applications, infrastructures, réseaux et flux de données significatifs.
• Une identification claire des systèmes critiques et de leurs dépendances.
• Des changements contrôlés, documentés et auditables sur les actifs critiques.

Une CMDB bien structurée, alignée sur ces principes et répondant aux exigences NIS2 en matière de CMDB, devient de facto une « CMDB ANSSI », permettant aux organisations de satisfaire à la fois les obligations au niveau de l’UE et les obligations nationales grâce aux mêmes pratiques de gestion des actifs.

Le CCB Belgium est l’autorité nationale compétente en matière de cybersécurité et pilote la transposition de NIS2 dans le pays. Ses attentes, telles qu’elles ressortent d’un suivi plus large des mises en œuvre nationales dans l’UE via le ECS NIS2 transposition tracker, incluent :

• Des inventaires détaillés des systèmes et infrastructures qui soutiennent les services essentiels désignés par le droit belge.
• La capacité à respecter des délais stricts de notification d’incidents, ce qui exige des données d’actifs et de dépendances exactes.
• La possibilité d’obligations supplémentaires, spécifiques à la Belgique, autour des infrastructures critiques et du traitement des données.

Concevoir votre CMDB pour répondre aux exigences NIS2 pour la CMDB vous positionne donc favorablement à la fois pour des attentes de type ANSSI CMDB et pour la conformité CCB Belgium. Les thèmes communs sont :

• Des référentiels CMDB et ITAM centralisés et bien gouvernés.
• Une classification riche et une cartographie des dépendances.
• Une traçabilité fiable et la production de preuves.

Comment l’ANSSI et le CCB Belgium influencent-ils les exigences NIS2 pour la CMDB ?

L’ANSSI et le CCB Belgium mettent en œuvre NIS2 au niveau national et insistent sur une cartographie structurée des actifs, une classification fondée sur le risque et un reporting d’incidents robuste. La principale manière de répondre à ces attentes est de maintenir une CMDB bien gouvernée et une pratique ITAM intégrée, fournissant des données d’actifs et de configuration exactes et auditables.

Feuille de route de mise en œuvre : construire une CMDB alignée sur NIS2

La mise en pratique des exigences NIS2 en matière de CMDB nécessite une feuille de route de mise en œuvre structurée. Les étapes suivantes proposent un parcours pragmatique, de la CMDB actuelle à un environnement pleinement aligné sur NIS2.

Étape 1 : Évaluer l’existant

Commencez par une évaluation lucide de votre situation actuelle :

• Couverture de la CMDB : quels types de CI sont modélisés, quels services sont cartographiés et où se situent les lacunes.
• Qualité des données : complétude, exactitude et fraîcheur des enregistrements de CI.
• Maturité ITAM : quels actifs et contrats sont suivis, à quel point les données sont fiables et comment (ou si) elles se lient à la CMDB.
• Outillage de découverte : quels outils de découverte réseau, endpoint, cloud et SaaS vous utilisez, et comment les résultats sont exploités.

Comparez vos constats aux exigences NIS2 pour la CMDB et à toute orientation nationale applicable, comme les principes de l’ANSSI ou les attentes du CCB Belgium, en notant les écarts et les priorités.

Étape 2 : Reconcevoir ou améliorer le modèle de données CMDB

En vous appuyant sur le plan présenté plus haut :

• Ajoutez des attributs spécifiques à NIS2 pour la classification essentiel/important, le secteur, le régulateur, la criticité, les RTO/RPO et la posture de sécurité.
• Alignez le schéma CMDB avec l’ITAM, en garantissant des identifiants partagés et le référencement des fournisseurs et des contrats.
• Cartographiez les domaines du cadre CyFun (connaître, protéger, détecter, répondre, rétablir) vers les attributs et rapports CMDB.

Documentez le modèle de données mis à jour, publiez-le en interne et mettez en place des procédures de contrôle des changements afin qu’il reste stable et maintenu.

Étape 3 : Améliorer la découverte des actifs et le rapprochement

Ensuite, renforcez la découverte :

• Déployez ou ajustez la découverte réseau et endpoint, les intégrations d’API cloud et la collecte d’inventaire SaaS.
• Définissez des règles de rapprochement précisant la priorité des attributs et la résolution des doublons.
• Configurez la supervision et des alertes pour les nouveaux actifs inconnus ou non gérés issus de la découverte.

Le résultat est une cybersécurité de la visibilité des actifs plus complète et une baseline CMDB plus fiable.

Étape 4 : Intégrer l’ITAM pour NIS2

Avec une structure CMDB solide et une découverte en place, connectez l’ITAM :

• Décidez quel système fait autorité pour la propriété, les achats, la garantie, les licences et les données fournisseurs (souvent l’ITAM), et lequel pour la configuration et les relations (CMDB).
• Mettez en place des jobs d’intégration qui synchronisent les données régulièrement, souvent chaque nuit.
• Définissez un RACI afin qu’il soit clair qui est responsable de l’exactitude des données ITAM, qui est responsable de la qualité des données CMDB et qui consomme l’information combinée.

Vous disposez désormais d’une vue unique et cohérente du contexte financier, contractuel, opérationnel et de sécurité de chaque actif.

Étape 5 : Intégrer la CMDB aux workflows sécurité et risques

Pour que la CMDB compte pour NIS2, intégrez-la aux workflows clés :

• Gestion des incidents : utilisez la CMDB pour identifier les services affectés, les propriétaires et les dépendances pour chaque incident.
• Gestion des vulnérabilités : pilotez les priorités de remédiation en fonction de la criticité du service, de la classification NIS2 et de l’implication des fournisseurs.
• Gestion des changements : assurez-vous que chaque changement sur des CI critiques est lié aux entrées CMDB et suit des circuits d’approbation formels.
• Reporting : pré‑définissez des modèles de rapports d’incident NIS2 alimentés par la CMDB (actifs impactés, services, emplacements, fournisseurs).

L’intégration avec des outils ITSM établis qui prennent en charge une CMDB robuste et des capacités de workflow, tels que ServiceNow ou la plateforme ITSM d’Atlassian, peut accélérer cette étape.

Étape 6 : Gouvernance continue et préparation aux audits

Enfin, mettez en place une gouvernance continue :

• Définissez des KPI tels que la complétude des CI, la fraîcheur des données et le pourcentage d’incidents correctement liés aux services/CI.
• Réalisez des audits internes réguliers pour échantillonner des enregistrements de CI et vérifier leur exactitude.
• Suivez les évolutions des orientations NIS2 et des règles nationales de transposition, en mettant à jour votre modèle de données et vos processus en conséquence.
• Tirez les enseignements des incidents et des audits pour affiner la découverte, la classification et les workflows.

Cette boucle de gouvernance transforme la CMDB en un cadre de contrôle vivant plutôt qu’en un exercice de documentation statique.

Comment mettre en œuvre une CMDB alignée sur NIS2 ?

Pour mettre en œuvre une CMDB alignée sur NIS2 :

• Évaluez les capacités actuelles de CMDB, d’ITAM et de découverte au regard de NIS2.
• Reconcevez votre modèle de données CMDB avec des attributs et des relations spécifiques à NIS2.
• Renforcez la découverte automatisée et le rapprochement sur l’IT, l’OT, le cloud et le SaaS.
• Intégrez l’ITAM pour les données de propriété, fournisseurs et cycle de vie.
• Intégrez la CMDB aux workflows de sécurité, de risques et de reporting.
• Mettez en place une gouvernance, des KPI et des audits internes réguliers.

Comment une CMDB alignée sur NIS2 renforce la cyber‑résilience de l’UE

Construire une CMDB qui satisfait les exigences NIS2 pour la CMDB apporte des bénéfices bien au‑delà de la conformité administrative. À l’échelle de l’UE, les régulateurs et autorités de supervision visent à améliorer la cyber‑résilience entre secteurs et au‑delà des frontières. Une CMDB mature, soutenue par un ITAM solide, contribue à ces objectifs de plusieurs façons.

Premièrement, elle améliore la connaissance de la situation. Avec une vue quasi en temps réel des actifs, des dépendances et de la criticité, vous pouvez mieux anticiper les risques systémiques, comme une forte dépendance à une seule région cloud ou à un seul fournisseur. Cette clarté vous aide à planifier des mesures de mitigation avant que des incidents ne surviennent.

Deuxièmement, elle réduit le risque systémique et le risque de chaîne d’approvisionnement. La visibilité sur les fournisseurs qui soutiennent quels services essentiels ou importants facilite l’identification des risques de concentration et la coordination des réponses aux incidents au niveau des fournisseurs. L’information peut être partagée et comprise plus facilement entre opérateurs et régulateurs.

Troisièmement, elle crée une base de preuves robuste. Une CMDB et un référentiel ITAM conçus en tenant compte de NIS2 et de cadres comme les bonnes pratiques ITIL fournissent aux conseils d’administration, auditeurs et régulateurs les données nécessaires pour comprendre la posture de risque, l’impact des incidents et l’avancement de la remédiation. Les décisions deviennent davantage pilotées par les données et moins dépendantes de tableurs ad hoc ou de connaissances informelles.

Enfin, une telle CMDB améliore la performance opérationnelle. Une fois que vous disposez de cartographies claires service‑vers‑actif, la gestion des changements et des incidents peut être plus ciblée, réduisant les interruptions et accélérant la reprise. La conformité à NIS2 devient alors un sous‑produit naturel des bonnes pratiques plutôt qu’un projet séparé et contraignant.

Comment une CMDB contribue-t-elle à la cyber‑résilience de l’UE ?

Une CMDB bien gouvernée contribue à la cyber‑résilience de l’UE en donnant aux organisations et aux régulateurs une image en temps réel et exacte des actifs, des dépendances et des risques. Cette compréhension partagée est essentielle pour prévenir les incidents, en contenir l’impact lorsqu’ils surviennent et coordonner les réponses entre secteurs et au‑delà des frontières.

Conclusion : transformer les exigences NIS2 pour la CMDB en avantage de résilience

Les exigences NIS2 pour la CMDB poussent les organisations à repenser la manière dont elles gèrent les données d’actifs et de configuration. Une CMDB prête pour NIS2 combine un modèle de données CMDB adapté, un ITAM intégré pour NIS2 et une cybersécurité de la visibilité des actifs renforcée grâce à la découverte automatisée et au rapprochement. Elle intègre dans les opérations quotidiennes des attributs spécifiques à NIS2 tels que les classifications essentiel/important, les détails de secteur et de régulateur, la criticité, les objectifs de reprise et la posture de sécurité.

Alignée sur des cadres comme le cadre CyFun et éclairée par des orientations nationales telles que les attentes ANSSI en matière de CMDB et la conformité CCB Belgium, cette CMDB devient plus qu’un registre. Elle devient un point de contrôle stratégique qui soutient la cyber‑résilience de l’UE, réduit les délais de réponse aux incidents et améliore les taux de réussite des changements.

Pour passer de la théorie à la réalité, les organisations doivent commencer par une évaluation ciblée de la maturité CMDB/ITAM au regard des exigences NIS2 pour la CMDB, puis concevoir et exécuter une feuille de route réaliste couvrant la refonte du modèle de données, la découverte, l’intégration ITAM, l’intégration aux workflows et la gouvernance. Pour les organisations qui souhaitent traduire les exigences NIS2 pour la CMDB en outillage concret, une option pratique consiste à mettre en œuvre la gestion des configurations dans HaloITSM, en utilisant ses capacités de CMDB & gestion des configurations avec la gestion intégrée des actifs IT dans HaloITSM et des fondations de gestion des services IT plus larges. Si vous souhaitez un accompagnement expert pour accélérer ce parcours, de la stratégie à la mise en œuvre opérationnelle, envisagez de vous associer à des consultants ITSM et ITAM spécialisés comme SMC Consulting, qui peuvent vous aider à construire une CMDB alignée sur NIS2 en 30 jours en suivant des bonnes pratiques CMDB et des recommandations d’automatisation éprouvées.

À propos de l’auteur

Questions fréquemment posées