Cartographie par consolidation de référentiels

Quand vous commencer une mission en régie ou pour de l’audit, vous aurez besoin de préciser le périmètre sur lequel vous allez travailler. Il arrive que celui-ci ne soit pas fiable ou clair. Dans ce cas réaliser une cartographie des actifs sur lesquels vous allez travailler peu être une bonne idée. Je vous propose une méthodologie à suivre pour réaliser cette cartographie à travers le recoupement de différents référentiels actuellement en place.

Identifier les référentiels en place

La première étape sera d’identifier la liste des référentiels existants. Habituellement il y a un référentiel officiel qui est sous la responsabilité de l’architecture IT. Pour des raisons souvent pratiques d’autres services ont créé leur référentiel. Souvent il est valable sur un périmètre plus réduit ou va apporter des meta données supplémentaires. Il est donc important de savoir le contenu de chaque référentiel. Les principales questions à se poser sont :

-Qui a construit/est le responsable du le référentiel? On comprendra plus facilement le contexte du référentiel

-Quel est son besoin ou qu’elles sont les informations stockées? On pourra déterminer les informations utiles du référentiel ainsi que la logique de construction.

-Quelle est la granularité du référentiel? On pourra réaliser si les identifiants sont comparables ou non.

La dernière question est très importante, car entre deux référentiels nous retrouvons rarement une relation de 1 pour 1. Généralement car un référentiel est construit sur une vision technique (maintenu pour l’IT) tandis que l’autre est construit sur une vision fonctionnelle (maintenu pour le business). Selon moi le référentiel devrait définir le type d’asset qui est étudié. Celui-ci peut être un serveur physique, un serveur logique, un middleware, une application, un module d’une application. Ce modèle n’est pas fixe et sera très différent dans le cas d’un environnement Cloud ou SAAS, la responsabilité n’étant pas la même pour tous. Les définitions des assets doit être un chapitre d’une politique de cartographie pour faciliter l’enrôlement de tous dans le modèle défini.

Si vous souhaitez être exhaustif lors d’une cartographie des actifs et que vous n’avez pas assez de référentiels, voici une liste de services qui devraient avoir un référentiel à vous fournir:

-Architecture IT

-RSSI (dans les entités complexes il peut y avoir une séparation entre IAM, l’App sec et la continuité)

-DPO (RGPD)

-Etude IT

-Manager d’équipes business

Préparer l’analyse

Vous venez de récupérer deux à trois référentiels (plus avec de la chances), il est maintenant temps de les croiser pour mettre à jour votre cartographie. Il est temps désormais de recouper les informations entre chaque base de données. Si vous avez pu échanger avec les créateurs ou sachant de chaque référentiel, vous avez la chance de savoir comment le référentiel a été construit et certainement ces points forts et faibles. Vous aurez aussi l’information la plus importante, l’origine des id et s’ils sont réutilisés. Que l’id soit numérique ou alphanumérique, il est une valeur de recherche bien plus fiable que le nom de l’actif. Celui peut avoir subi les fautes de frappes, les accentuations perdues ou des majuscules oubliées. Il est aussi possible de créer son propre ID en transformant ou concaténant certains champs. Par exemple transformer tous les “é” en “e” et supprimer les espaces ainsi que les ponctuations dans le nom d’une application peut faire un ID utilisable même s’il n’est pas certains. On peut aussi créer une concaténation entre l’id alphanumérique et le nom de l’application si on souhaite faire des recherches pour éviter les homonymes.

Pour illustrer mes propos voici un exemple entre 2 référentiels

Référentiel 1:

Référentiel 2:

L’analyse

Une fois que vous avez identifié les id que vous pouvez recroissez, munissez-vous de votre tableur préféré pour effectuer des rechercheV. Il est important de faire la recherche dans les 2 sens. Ceci permettra d’identifier les actifs manquant d’un référentiel à l’autre. Vous pouvez faire votre recherche sur un ou plusieurs id parmi ceux que vous venez de créer. Je conseil de faire apparaitre un texte simple à trier et de faire les recherches dans des colonnes séparées. Le rajout d’une colonne de consolidation vous permettra d’évaluer la charge de recherche manuelle que vous allez avoir.

Le “code” à mettre en place pour la recherche est :

SI résultat recherche existe ALORS “trouvée” SINON “absente”

Si le nombre d’id à comparer est important, il est alors possible de mettre en place un indice de confiance sur la consolidation globale. Pour chaque ligne on peut avoir nombre de “Trouvée” / nombre de recherche. Cet indicateur est très important en cas de recherche entre de nombreux référentiels.

L’avantage d’avoir indiqué si l’application a été trouvée ou non dans un référentiel et que vous pouvez rapidement filtrer pour rechercher les applications absentes. La présentation de ces résultats sera aussi plus simple à un interlocuteur qui ne vous a pas aidé. Cependant avant cette étape je conseille de faire un filtre sur toutes les applications qui n’ont pas un score de confiance de 100% et d’ajouter un commentaire pour expliquer la différence. Cette recherche manuelle pourra dans certains cas mettre en avant des erreurs ou de trouver des associations qui n’ont pas pu être identifiées avec la recherche manuelle. Dans ces commentaires n’hésitez pas à mettre des suppositions que vous ferais valider lors d’un atelier de validation.

Il ne vous reste plus qu’à définir la date d’un atelier avec les différents sachants. Ils vous remercieront d’avoir pré-maché l’analyse des référentiels. Vous aurez désormais une cartographie de vos assets. Cependant il faudra mettre en place un processus pour la maintenir en vie car de nombreux changements lui seront apportés.

N’hésitez pas à faire part de vos impressions sur les réseaux sociaux concernant cet article !