ASGARD

ASGARD se veut facilitateur et offre des outils clés en main qui ne demandent qu’à être installés. Pour autant, il ne fait que poser un cadre formel sur lequel l’administrateur devra appliquer la stratégie de gestion des droits qu’il aura définie sur le fond en fonction des spécificités de son service.

Pour élaborer une nouvelle stratégie ou adapter à ASGARD une stratégie héritée d’un système antérieur, il est recommandé de lire attentivement la partie Fondamentaux de la gestion des droits avec ASGARD du présent guide.

En particulier, lors de la mise en route, et régulièrement par la suite, l’administrateur pourra être amené à s’interroger sur les points énoncés ci-après.

• Quels schémas permettront une organisation optimale des données du service ?

  La nomenclature nationale^[1] pré-implémentée par ASGARD fournit une base qui pourra répondre à une partie des besoins, toutefois elle se limite pour l’heure aux schémas qui mettent à disposition les données produites par le service, le bloc^[2] dit « consultation ». Pour les autres types de données (données référentielles, données externes, données des applications…), il revient à l’administrateur de déterminer les schémas à créer.

• Quels rôles de groupe doivent être créés pour permettre l’attribution de droits adaptés à chaque profil d’utilisateurs ?

  Cf. Rôle de connexion et rôle de groupe pour quelques précisions sur les rôles de groupe^[3].

• Quels rôles de groupe doivent être désignés comme producteur, éditeur et lecteur pour chaque schéma, afin que les utilisateurs disposent des droits dont ils ont besoin et pas davantage ?

  Cf. Principe pour la description des fonctions de producteur^[4], éditeur^[5] et lecteur^[6] des schémas.

• Certains utilisateurs devraient-ils être habilités à « gérer » les schémas dont ils sont producteurs, c’est-à-dire à les créer, les modifier, les supprimer, ou encore désigner leurs groupes éditeur et lecteur ?

  Le cas échéant, la marche à suivre est décrite dans la partie Déléguer la gestion des droits.

• Quels utilisateurs sont en charge de l’administration des rôles de groupe et des rôles de connexion individuels (création, suppression, attribution des permissions, etc.) ?

  La partie Attributs CREATEROLE et CREATEDB évoque les mesures à prendre les concernant.

Le plugin QGIS AsgardManager a été pensé pour permettre l’administration des droits sur le serveur PostgreSQL de manière simple, fiable et efficace, tout cela sans une ligne de code.

AsgardManager est plus directif que l'extension PostgreSQL ASGARD et sa cible est volontairement restreinte. Elle ne couvrira jamais toutes les actions qu’il est possible de réaliser sous PostgreSQL, et même certaines fonctionnalités avancées d’ASGARD resteront à terme hors de son périmètre. En somme, il est admis que les actions complexes ou les attributions de droits plus fines que prévu par le standard d’ASGARD seront à réaliser dans un éditeur de requêtes. Cependant, il est également acquis qu’un service qui gère ses droits selon les principes usuels d’ASGARD n’en aura jamais besoin : l'administration quotidienne peut être entièrement réalisée avec AsgardManager.

Ainsi, un service qui débute avec PostgreSQL pourra dans un premier temps administrer ses droits en utilisant exclusivement AsgardManager, puis, à mesure que ses administrateurs gagnent en compétence et si des besoins émergent, alterner entre une gestion courante dans AsgardManager et la réalisation ponctuelle de tâches plus sophistiquées dans pgAdmin, le cas échéant à l’aide des fonctions utilitaires d’ASGARD.

À noter toutefois que même AsgardManager nécessite un socle minimal de connaissances sur les bases PostgreSQL – concepts de schémas, tables, vues, rôles, etc. – que l’administrateur devra avoir acquis au préalable. Il en va de même pour la lecture de la présente documentation, qui ne redéfinit pas ces termes.