NIS2 et architecture d’entreprise : documenter systèmes, dépendances et fournisseurs
NIS2 demande des mesures de gestion des risques, une attention à la chaîne d’approvisionnement et la notification des incidents importants. Ces travaux supposent de connaître ses systèmes et leurs dépendances. Le référentiel d’architecture tient cette documentation ; il ne vaut pas attestation de conformité.
Mis à jour le
Ce que NIS2 demande aux entités essentielles et importantes
La directive (UE) 2022/2555, dite NIS2, couvre bien plus d’entités que la directive qui l’a précédée. Elle vise des entités essentielles et importantes dans des secteurs comme l’énergie, les transports, la banque, les infrastructures des marchés financiers, la santé, les infrastructures numériques et l’administration publique. Les États membres devaient la transposer au plus tard le 17 octobre 2024.
Les entités concernées prennent des mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées pour gérer les risques pesant sur leurs réseaux et systèmes d’information. Elles traitent la sécurité de leur chaîne d’approvisionnement et notifient les incidents importants dans des délais fixés. La qualification d’une entité et la portée de ses obligations se vérifient avec un conseil qualifié.
Pour une entité financière identifiée comme essentielle ou importante, DORA est l’acte juridique sectoriel au sens de l’article 4 de NIS2, comme le prévoit l’article 1, paragraphe 2, de DORA. La gestion du risque TIC et la notification des incidents suivent alors DORA, dans la mesure prévue par cet article.
Une question préalable : connaître ses systèmes et leurs dépendances
Gestion des risques, chaîne d’approvisionnement et traitement des incidents partagent un prérequis. Le risque d’un système absent de l’inventaire ne s’évalue pas. Un prestataire se suit jusqu’aux services qu’il soutient seulement si ce lien est documenté. Le périmètre d’un incident dépend de ce qui repose sur le composant touché.
Cette connaissance existe souvent, mais dispersée : une CMDB qui a dérivé, des schémas réseau dans un wiki, des listes de fournisseurs aux achats, une évaluation de criticité dans une présentation. Le référentiel d’architecture relie ces éléments : services métier, applications, technologies, dépendances et fournisseurs, chacun avec son responsable.
- La gestion des risques suppose un inventaire des réseaux et systèmes d’information.
- La sécurité de la chaîne d’approvisionnement suppose de relier chaque service à ses prestataires.
- Le traitement d’un incident suppose de savoir ce qui dépend du composant touché.
Systèmes, services et propagation
La proportionnalité des mesures se juge au regard de ce que chaque système soutient. Une liste d’actifs ne dit pas quel service s’arrête quand un système tombe ; un modèle de dépendances le montre.
Dans ArchiLU, chaque application porte son responsable, sa criticité, son cycle de vie et son fournisseur. Elle est reliée aux capacités, aux processus, aux interfaces et aux technologies. La vue 360 centrée sur une application montre ses flux, ses interfaces, les processus qu’elle sert et les capacités qu’elle réalise. Les décisions de traitement du risque restent aux fonctions sécurité et risques.
- Chaque application avec son responsable, sa criticité et ses technologies.
- Les processus et les capacités qu’elle sert.
- Les interfaces, leur protocole et les données qu’elles transportent.
- Les technologies et leur échéance de support, connue ou inconnue.
Fournisseurs et chaîne d’approvisionnement
NIS2 demande de prendre en compte la sécurité de la chaîne d’approvisionnement, y compris les relations avec les fournisseurs et prestataires directs. Cette exposition s’accumule au fil des contrats, chacun raisonnable au moment de sa signature.
Dans ArchiLU, la chaîne relie les fonctions aux applications, puis aux services TIC, aux fournisseurs et aux contrats. L’analyse d’exposition part d’un prestataire, remonte jusqu’aux fonctions qui en dépendent et signale la concentration. C’est la chaîne tenue pour DORA. L’évaluation de sécurité d’un fournisseur et la position contractuelle restent du ressort de l’entité.
Traitement des incidents : cadrer le périmètre
Après un incident, il faut établir vite les services touchés, ce dont ils dépendent et les personnes à prévenir. Ce cadrage prend souvent plus de temps que la correction technique, surtout quand les schémas sont dispersés.
Une architecture à jour accélère ce cadrage : du composant touché vers les processus et les fonctions qu’il soutient, puis vers les technologies et les fournisseurs dont il dépend. Chaque objet nomme son responsable. ArchiLU ne détecte pas les incidents et n’assure pas la réponse ; ces tâches relèvent des outils et des équipes de sécurité, que la carte des dépendances renseigne.
Hébergement et accès
La carte des systèmes qui soutiennent les services essentiels indique où l’organisation est la plus exposée. Dans ArchiLU, chaque organisation a son instance dédiée, hébergée dans l’Union européenne ; un déploiement chez le client est proposé en option, sur devis.
Les accès suivent les habilitations de chaque utilisateur. Un auditeur entre par sa mission et lit la chaîne en lecture seule, bornée à son périmètre et à sa période. La piste d’audit est chaînée, vérifiable et exportable par l’administrateur.
Dans ArchiLU
Partez de la fonction. Retrouvez le fournisseur.
Dans ArchiLU : Paiements → Moteur de paiements → Maelis Paiements. Quatre écrans du même logiciel, reliés par les mêmes objets.
Identifiez ce qui doit continuer à fonctionner.
La liste des fonctions donne la criticité, le responsable et les liens documentés. Les fonctions critiques ou importantes se distinguent des fonctions de soutien.
Comprenez pourquoi elle est critique et ce qui la soutient.
La fiche Paiements explique les conséquences d'une interruption, nomme son responsable et renvoie à l'application Moteur de paiements. Les liens encore absents restent visibles.
Identifiez le prestataire : Maelis Paiements.
Le registre des acteurs ouvre la fiche du fournisseur Maelis Paiements, avec son identité, son statut et son rôle. La chaîne de dépendances relie ce même fournisseur à l'application Moteur de paiements et au service TIC de maintenance.
Voyez la dépendance. Repérez ce qui manque.
La vue dédiée relie Paiements à son application, aux services TIC et aux fournisseurs documentés. Les contrats apparaissent quand ils couvrent ces services ; les liens manquants sont signalés, objet par objet.
Questions fréquentes
- Un référentiel d’architecture rend-il une organisation conforme à NIS2 ?
- Non. La conformité s’apprécie au regard des mesures organisationnelles, techniques et procédurales de l’entité, par l’autorité compétente. Le référentiel documente les systèmes, leurs dépendances et leurs fournisseurs, ce qui facilite la préparation des dossiers et leur mise à jour.
- Comment la cartographie aide-t-elle pour la chaîne d’approvisionnement ?
- Chaque application est reliée à ses services TIC, à ses fournisseurs et à leurs contrats. L’entité suit un service jusqu’aux tiers qui le soutiennent et repère les prestataires dont dépendent plusieurs fonctions. L’évaluation de sécurité d’un fournisseur reste un travail de l’entité et de ses conseils.
- Une banque soumise à DORA applique-t-elle aussi NIS2 ?
- Pour une entité financière identifiée comme essentielle ou importante, DORA est l’acte sectoriel au sens de l’article 4 de NIS2. La gestion du risque TIC et la notification des incidents suivent alors DORA, dans la mesure prévue par cet article. L’articulation se confirme avec le conseil juridique ; la chaîne de dépendances sert les deux dossiers.
- Que fournit la cartographie lors d’un incident ?
- Le périmètre de départ : les processus et les fonctions qui reposent sur le composant touché, les technologies et les fournisseurs dont il dépend, et le responsable de chaque objet. La détection, le confinement et la reprise restent dans les outils et les processus de sécurité.