ASGARD

L’usage de commandes GRANT et REVOKE pour affiner les droits alloués par ASGARD est parfaitement légitime, qu’il s’agisse de ceux du lecteur^[1], de l’éditeur^[2], du producteur^[3] ou de n’importe quel autre rôle.

Cf. Modifier les privilèges pour plus de précision sur la manière dont ASGARD prend en charge cette « personnalisation » des droits.

Les fonctions utilitaires d’ASGARD asgard_initialise_obj, asgard_initialise_schema et asgard_initialise_all_schemas permettent d’effacer ces modifications manuelles pour revenir aux droits standards d’ASGARD.

Les privilèges par défaut, définis via la commande ALTER DEFAULT PRIVILEGES, permettent l’attribution automatique à un rôle A de privilèges sur les objets créés par un rôle B, soit dans un schéma spécifique, soit à l’échelle de toute la base de données.

C’est une fonctionnalité très utile dans le cas général pour accélérer et fiabiliser l’administration des droits, mais ASGARD propose une autre méthode pour parvenir à un résultat similaire : les éditeurs^[2] et lecteurs^[1] reçoivent automatiquement des droits sur les nouveaux objets créés dans les schémas sur lesquels ils ont été désignés, sans qu’il soit nécessaire de recourir à des privilèges par défaut. Ceci limite fortement l’intérêt des privilèges par défaut sur une base de données dotée d’ASGARD, bien qu’il reste possible de les utiliser.

Les fonctions asgard_initialise_schema et asgard_initialise_all_schemas permettent de les supprimer.

Lorsque des droits sont attribués sur un objet, PostgreSQL permet de déclarer que le rôle qui a reçu les droits pourra les transmettre à son tour à d’autres rôles. On ajoute pour cela WITH GRANT OPTION à la commande GRANT habituelle.

ASGARD n’interdit en rien le recours à cette possibilité.

Cependant, elle n’est pas conforme au principe d’ASGARD qui veut que seul le producteur^[3] du schéma (et tous ses membres) dispose de droits avancés sur les objets, incluant celui de conférer des privilèges à d’autres. Il est donc plutôt recommandé de ne pas l’utiliser, sauf éventuellement pour des objets hors schémas. ASGARD donne ainsi au rôle g_admin[4] le privilège CREATE sur la base courante avec GRANT OPTION, afin qu’il puisse déléguer ce privilège à d’autres rôles même s’il n’est pas le propriétaire de la base.

Cf. Modifier les privilèges pour plus de précision sur la manière dont ASGARD prend en charge cette « personnalisation » des droits (pour les objets rattachés à des schémas).

Les fonctions utilitaires d’ASGARD asgard_initialise_obj, asgard_initialise_schema et asgard_initialise_all_schemas les effacent (ainsi que toute autre modification manuelle des droits).

WITH ADMIN OPTION permet d’accorder à un rôle A la permission sur un rôle B, ce qui autorisera par la suite A à conférer la permission sur B à d’autres rôles.

GRANT %role_a TO %role_b WITH ADMIN OPTION ;

GRANT %role_a TO %role_b WITH ADMIN OPTION ;

Ce mécanisme est pleinement compatible avec ASGARD.

Par défaut, tous les rôles créés disposent de l’attribut INHERIT, qui leur permet de bénéficier des privilèges sur les objets qu’ont tous les rôles dont ils sont membres sans avoir à exécuter un SET ROLE.

NOINHERIT prohibe l’héritage des droits, ce qui le rend fondamentalement incompatible avec la logique des rôles de groupe^[5] sur laquelle se base ASGARD (cf. Rôle de connexion et rôle de groupe).

Les politiques de sécurité pour l'accès aux lignes, en anglais row level security, permettent de spécifier les rôles qui peuvent lire, créer, modifier ou supprimer un ensemble de lignes d'une table. Elle agissent comme un filtre (clause WHERE) qui s'applique à toutes les requêtes exécutée sur la table pour ne laisser le rôle agir que sur les enregistrements qui remplissent les conditions données.

Ce mécanisme est pleinement compatible avec ASGARD. Il est d'ailleurs utilisé par la fonction asgard_layer_styles.

Le rôle g_admin[4] dispose de l'attribut BYPASSRLS qui lui permet de passer outre toutes les politiques de sécurité, y compris sur des schémas dont il ne serait pas membre du groupe propriétaire. BYPASSRLS n'étant pas héritable (comme tous les attributs), les rôles de connexion membre de g_admin devront exécuter un SET ROLE g_admin pour en bénéficier.

Les droits alloués par l'intermédiaire de politiques de sécurité sont préservés par toutes les fonctions d'ASGARD, y compris les fonctions de réinitialisation des droits et la fonction de déplacement d'objet. Il ne sont pas transférés d'un rôle à l'autre en cas de changement d'éditeur^[2] ou de lecteur^[1] (cf. Modifier les privilèges pour ce principe de transfert, non applicable ici).