Le Data Catalog d’une organisation permet de valoriser l’ensemble de son patrimoine de données en s’appuyant notamment sur deux types d’informations – d’une part les informations purement techniques synchronisées automatiquement depuis les sources ; et d’autre part les informations métier qui sont issues du travail des Data Stewards. Ces dernières sont mises à jour manuellement et apportent ainsi leur lot de risques à l’échelle de l’organisation.
Un système de permissions est alors essentiel afin de définir et hiérarchiser les droits d’accès des utilisateurs du catalogue. Dans cet article, nous détaillons les caractéristiques fondamentales et les approches possibles pour bâtir un système de permissions efficace, ainsi que la solution mise en place dans le Data Catalog Zeenea.
Le système de permissions : un outil indispensable à l’échelle de l’organisation
Pour que l’utilisateur du Data Catalog ait confiance dans les informations qu’il consulte, il est essentiel que la documentation des objets catalogués soit pertinente, de qualité et surtout fiable. Vos utilisateurs doivent facilement trouver, comprendre et exploiter le patrimoine de données à leur disposition.
Origine des informations du catalogue et automatisation
Un catalogue de données intègre généralement deux types d’informations. D’une part, on trouve des informations purement techniques qui proviennent directement de la source de données. Chez Zeenea, ces informations sont synchronisées de façon complètement automatisée et continue entre le Data Catalog et chaque source de données, pour en garantir la véracité et la fraîcheur. D’autre part, le catalogue contient toute la documentation métier ou organisationnelle (majoritaire), qui est quant à elle issue du travail des Data Stewards. Ces informations ne peuvent pas être automatisées, elles sont mises à jour manuellement par les équipes de data management de l’entreprise.
Le système de permissions comme prérequis à l’utilisation du catalogue
C’est pour gérer cette deuxième catégorie d’informations que le catalogue doit comporter des mécanismes de contrôle de la saisie. En effet, il n’est pas souhaitable que n’importe quel utilisateur du Data Catalog de votre organisation puisse créer, éditer, importer, exporter ou même supprimer des informations sans avoir été crédité des autorisations préalables. Un système de gestion des permissions des utilisateurs est alors un prérequis, c’est lui qui joue ce rôle de garde fou. Il définit les droits d’accès des utilisateurs.
Les 3 caractéristiques fondamentales du système de permissions d’un Data Catalog
La mise en place d’un système de permissions à l’échelle de l’entreprise est soumise à de nombreuses attentes qui vont devoir être prises en compte pour sa conception même. Parmi elles, nous avons choisi dans cet article de nous concentrer sur trois grandes caractéristiques fondamentales d’un système de permissions : son niveau de granularité et de flexibilité, sa lisibilité et son auditabilité, ainsi que sa simplicité d’administration.
Granularité et flexibilité
Tout d’abord, un système de permissions doit avoir le bon niveau de granularité et de flexibilité. Certaines actions doivent être disponibles sur l’ensemble du catalogue afin d’en faciliter l’usage. D’autres actions doivent être restreintes à certaines parties du catalogue uniquement. Certains utilisateurs auront des droits globaux liés à tous les objets du catalogue, d’autres seront limités à ne pouvoir éditer que le périmètre qui leur aura été attribué. Le système de permissions doit donc permettre cet éventail de possibilités allant de la permission globale à la finesse d’un objet dans le catalogue.
Chez Zeenea par exemple, les clients sont de toutes tailles, avec des niveaux de maturité sur les sujets de la gouvernance data très hétérogènes. Certains sont des Start-ups, d’autres de grandes entreprises. Certains ont une culture data déjà bien intégrée dans leur processus, d’autres au contraire n’en sont qu’au début de leur démarche d’acculturation data. Le système de permissions doit donc être suffisamment flexible pour s’adapter à toutes les typologies d’organisations.
Lisibilité et auditabilité
Ensuite, un système de permissions doit être lisible et facile à suivre. Lors d’un audit, ou d’une revue des permissions du système, un administrateur qui explore un objet doit être en mesure de rapidement savoir qui est en capacité de le modifier. Inversement quand un administrateur regarde le détail des droits d’un utilisateur, il doit rapidement être capable de déterminer le périmètre qui lui est attribué et ses actions autorisées sur celui-ci.
Cela permet de s’assurer simplement que les bonnes personnes ont accès aux bons périmètres, et ont le bon niveau de permission par rapport à leur rôle dans l’entreprise.
Ne vous-êtes vous jamais retrouvé face à un système de permissions et d’autorisations tellement complexe qu’il était impossible de comprendre pourquoi un utilisateur avait le droit de consulter une information ? Ou au contraire en était incapable ?
Simplicité d’administration
Enfin, un système de permissions doit être résilient face à l’augmentation du volume du catalogue. On sait aujourd’hui que nous vivons dans un monde de données : 2,5 exaoctet de données étaient générées par jour en 2020 et on estime à 463 exaoctet le volume de données générées par jour en 2025. Nouveaux projets, nouveaux produits, nouveaux usages : les entreprises doivent faire face quotidiennement à l’explosion de leur patrimoine data.
Pour rester pertinent, un Data Catalog doit évoluer avec la data de l’entreprise. Le système de permissions doit alors absolument être résilient face à la modification de son contenu ou même suite aux mouvements de collaborateurs dans l’organisation.
Les différentes approches pour la conception d’un système de permissions d’un catalogue de données
Il existe différentes approches pour la conception du système de permissions d’un Data Catalog, qui répondent plus ou moins bien aux caractéristiques principales attendues et évoquées ci-dessus. Nous avons choisi d’en détailler trois dans cet article.
Le Crowdsourcing
Premièrement, l’approche crowd sourcing – on fait confiance au collectif pour s’auto-corriger. Une poignée d’administrateurs peuvent modérer le contenu et l’ensemble des utilisateurs peut contribuer à la documentation. Un système d’audit vient généralement compléter le dispositif pour s’assurer de ne pas perdre d’information par erreur ou malveillance. Dans ce cas, aucun contrôle a priori, mais une correction collective a posteriori. C’est typiquement le système choisi par des encyclopédies en ligne telles que Wikipedia. Ces systèmes sont dépendants du nombre de contributeurs et de leurs connaissances propres pour bien fonctionner, l’auto-correction ne pouvant être efficace que grâce au collectif.
Ce système répond parfaitement au besoin de lisibilité – tous les utilisateurs ayant le même niveau de droit, il n’y a pas de question à se poser sur les droits d’accès de chacun. Il est également simple à administrer – tout nouvel utilisateur possède le niveau de droit commun à tous, et tout nouvel objet dans le Data Catalog est accessible par tous. En revanche, il n’existe pas de possibilité de gérer la granularité des droits. Tout le monde peut tout faire et tout voir.
La permission rattachée à l’utilisateur
Seconde approche pour la conception du système de permissions : les solutions où le périmètre est attaché au profil de l’utilisateur. Lors de la création d’un utilisateur dans le Data Catalog, les administrateurs lui assignent un périmètre qui définit les ressources que celui-ci aura la possibilité de voir et de modifier. Dans ce cas, tous les contrôles sont faits en amont et un utilisateur ne peut pas avoir accès à une ressource par inadvertance. C’est le type de système d’un OS type Windows par exemple.
Ce système a l’avantage d’être très sûr, il n’y a aucun risque qu’une nouvelle ressource soit visible ou modifiable pour les personnes qui n’en auraient pas le droit. Ce système répond également au besoin de lisibilité : pour chaque utilisateur, toutes les ressources qui lui sont accessibles sont simples à retrouver. Le niveau de granularité attendu est également bon, puisqu’il est possible d’attribuer ressource par ressource les données du système.
En revanche, l’administration en est plus complexe – à chaque nouvelle ressource ajoutée au catalogue, il faut l’ajouter aux périmètres des utilisateurs concernés. Il est possible de pallier cette limitation en créant des périmètres dynamiques. Pour ce faire on peut définir des règles qui attribuent les ressources aux utilisateurs, par exemple tous les fichiers de type PDF lui seront accessibles. Mais des règles contradictoires peuvent facilement apparaître, compliquant alors la lisibilité du système.
La permission rattachée à la ressource
Dernière grande approche pour concevoir le système de permissions d’un Data Catalog : les solutions où les actions autorisées sont attachées à la ressource à modifier. Pour chaque ressource, les permissions possibles sont définies utilisateur par utilisateur. Ainsi c’est elle qui porte sa propre liste de permissions. En regardant la ressource, il est alors possible de savoir tout de suite qui peut la consulter ou l’éditer. C’est par exemple le type de système d’un OS de type UNIX.
Le besoin en lisibilité est parfaitement comblé – un administrateur voit immédiatement les droits des différents utilisateurs en consultant la ressource. Idem pour le besoin en granularité – cette approche permet de donner des droits au niveau le plus macro par un système d’héritage, ou au niveau le plus micro directement sur la ressource. Enfin, côté facilité d’administration, il est nécessaire de rattacher chaque nouvel utilisateur aux différentes ressources ce qui est potentiellement fastidieux. Il existe cependant des systèmes de groupe qui permettent de mitiger cette complexité.
Le modèle de permissions du Data Catalog Zeenea : simple, lisible et flexible
Parmi ces approches, détaillons celle qui a été choisie par Zeenea et comment elle est appliquée.
L’approche au niveau de la ressource privilégiée
Récapitulons les différents avantages et inconvénients de chacune des approches abordées précédemment. Dans les deux systèmes de permissions rattachées à la ressource ou à l’utilisateur, le besoin en granularité est correctement appréhendé – ces systèmes permettent d’assigner des droits ressource par ressource. En revanche, dans le cas du crowdsourcing, la philosophie de base est que tout le monde peut accéder à tout.
La lisibilité ensuite est clairement plus simple à suivre dans les systèmes de type crowdsourcing ou pour ceux dans lesquels les permissions sont rattachées à la ressource. Elle reste convenable dans les systèmes où les permissions sont rattachées à l’utilisateur mais souvent au détriment de la simplicité d’administration.
Enfin, la simplicité d’administration est très optimisée pour l’approche crowdsourcing et dépend alors de ce qu’on va le plus modifier – la ressource ou bien les utilisateurs.
Le besoin de granularité n’étant pas respecté dans l’approche crowdsourcing, nous l’avons éliminée. Il nous restait alors deux solutions : la permission rattachée à la ressource ou la permission rattachée à l’utilisateur. La lisibilité étant un peu meilleure sur les permissions rattachées à la ressource, et étant donné que le contenu du catalogue va évoluer plus vite que le nombre d’utilisateurs, l’option des permissions attachées à l’utilisateur nous semblait la moins pertinente.
L’option que nous avons privilégiée chez Zeenea est donc la troisième : les permissions sont rattachées aux ressources.
Le fonctionnement du système de permissions du Data Catalog Zeenea
Dans le catalogue de données Zeenea, il est possible de définir pour chaque utilisateur s’il aura le droit de manipuler les objets de l’ensemble du catalogue, un ou plusieurs types d’objets, ou uniquement ceux de son périmètre. Ainsi la granularité la plus fine est permise, mais également des rôles plus globaux. Par exemple, des “super-stewards” pourraient avoir la permission d’agir sur des parties entières du catalogue, comme le glossaire.
On associe ensuite une liste de dépositaires à chaque objet du catalogue, c’est-à-dire les responsables de la documentation de cet objet. Ainsi, simplement en explorant les détails de l’objet, on peut immédiatement savoir à qui s’adresser pour corriger, compléter la documentation, ou encore répondre à une question sur celle-ci. Le système est donc lisible et simple à comprendre. Les périmètres d’actions des utilisateurs sont déterminés avec précision grâce à un système granulaire, jusqu’à l’objet du catalogue.
Lorsqu’un nouvel utilisateur est ajouté au catalogue, il faut alors lui définir son périmètre d’actions. Pour le moment, cette configuration se fait en passant par une édition en masse des objets. Afin de simplifier encore la gestion, il sera bientôt possible de définir des groupes d’utilisateurs responsables, pour qu’à l’arrivée d’un nouveau collaborateur il n’y ait plus besoin de l’ajouter nominativement sur chaque objet dans son périmètre. Il suffira alors de l’ajouter au groupe responsable, et son périmètre lui sera automatiquement attribué.
Enfin, nous avons volontairement fait le choix de ne pas implémenter de workflow de validation de la documentation dans le catalogue. Nous pensons en effet que la responsabilisation des équipes est une des clés de la réussite d’une démarche de mise en place d’un Data Catalog. C’est pourquoi le seul contrôle que nous mettons en place est celui qui détermine les droits de l’utilisateur et son périmètre. Une fois ces deux éléments déterminés, les responsables de la documentation sont libres de leurs actions ! Un journal d’événements sur les modifications afin de permettre une auditabilité complète, ainsi qu’un système de discussion sur les objets, permettant à tous de proposer des évolutions ou de signaler des erreurs sur la documentation, viennent compléter le dispositif.
Si vous souhaitez en savoir davantage sur notre modèle de permissions, ou pour obtenir plus d’informations au sujet de Data Catalog :
