Skip to content

Gestion des droits et des rôles#

L’objectif des rôles et droits gérés directement dans la base de données est de créer des droits uniques et individuels, disponible pour chaque acteur de la gestion de l’eau. Ces rôles doivent être gérés de manière à soit limiter l’accès à certaines données, soit ne permettre d’effectuer qu’une ou plusieurs actions particulières de lecture ou d’écriture sur les données présentent dans la base.
De ce fait, chaque utilisateur de la base, qu’il soit amené à analyser les données (décideurs, géomaticiens) ou à les renseignées (techniciens rivière) aura accès à son propre rôle, souvent nominatif. De cette manière, il sera également possible par la suite d’avoir connaissance de quel acteur précis est responsable de chaque action sur la base de données et ainsi de mettre en place un suivi précis.

1.1. Principe des « Row level security »#

Avant d’entrer dans les détails de rôles et droits, il est essentiel de bien comprendre le principe de « Row Level Security » (aussi abrégé en RLS), système de base de notre modèle de gestion des droits utilisateurs. L’objectif est de limiter l’accès aux données, on peut le faire à différentes échelles :

  • A l’échelle d’un schéma de données (un ensemble de tables)
  • A l’échelle d’une table
  • A l’échelle d’un champ spécifique, c’est-à-dire la colonne d’une table

Cette limitation s’effectue grâce à des politiques de sécurité qui permettent, grâce à des conditions simples, de déterminer champs par champs quelles données sont accessibles par un utilisateur.

À noter

Même si un rôle possède un ensemble de droits sur une table spécifié, cela ne signifie pas qu'il a la possibilité de visionner, éditer, supprimer ou mettre à jour l'ensemble des données sur cette table. En effet, après l’activation du RLS sur une table, ne seront accessible seulement les données répondant à des conditions spécifiées dans des politiques de sécurité, en SQL, cela correspond à des structures de type « POLICY ». Si aucune politique n’est spécifiée, les données ne seront par défaut accessible ni en lecture, ni en écriture.
~SQL ALTER TABLE donnees_diag.commune ENABLE ROW LEVEL SECURITY; ~~~

L’activation de la RLS et sa configuration va permettre, sur une table donnée, de définir quelles lignes de données sont accessibles ou non par un utilisateur spécifié. Il est très important de bien comprendre qu’une ligne n’est visible si et seulement si elle répond à une condition spécifique présente dans les structures de type « POLICY ». Ces structures possèdent deux systèmes de condition selon l’action sur la base de données :

  • Condition « USING », permettant de gérer les droits en lecture seule (SELECT), en modification (UPDATE) et suppression de données (DELETE).
  • Condition « WITH CHECK », permettant de gérer essentiellement les droits en écriture (INSERT INTO).
CREATE POLICY policy_example
ON example_table
TO example_role
USING example_table.id = 'example'
WITH CHECK example_table.id = 'example';

1.2. Mise en place des rôles et des droits basiques#

Dans la mesure ou le projet traite essentiellement de données spatiales, il est nécessaire, dans un premier temps, de définir des groupes utilisateurs génériques ayant des droits de lecture ou d’écriture de données géométriques ou géographiques. Ces données se situent dans des tables automatiquement générées lors de l’installation du plugin PostGis sous PostgreSQL. Ensuite, puisque nous travaillons sur un territoire divisé en différents syndicat, dit « syndicat gemapi », un groupe utilisateur a également été créer pour chaque syndicat. Ce groupe serra par la suite constituer de l’ensemble des acteurs de ce syndicat, à savoir l’ensemble des techniciens rivière présente sur celui-ci. Enfin, des rôles seront défini au besoin afin de permettre l’accès aux données pour les géomaticiens, pour des décideurs ou encore pour des profils publics.

1.2.1 Configuration des groupes utilisateurs génériques#

Afin de facilité la mise en place des droits aux différents utilisateurs et groupes d’utilisateurs spécifiques, il est préférable de créer des rôles génériques permettant de ne pas répéter les mêmes requêtes un grand nombre de fois pour un grand nombre d’utilisateur. Il est possible de créer des rôles génériques grâce au système d’héritage de base entre les utilisateurs et groupes d’utilisateur sous PostgreSQL. Grâce à un simple mot clé lors de la création d’un groupe, l’ensemble des utilisateurs en faisant partie hériterons des droits de celui-ci. Deux rôles seront ainsi crées : l’un pour la lecture seule des données de la base, le second pour l’ensemble des droits d’écriture de données (insertion, mise à jour ou suppression de données).

1.1.1.1 Groupe « postgis_reader »#

Le premier groupe générique, appelé « postgis_reader », aura par défaut accès aux tables de géométries et tables du schéma en lecture seule (visualisation de données uniquement). Chaque membre de ce groupe possèdera les mêmes droits que celui-ci, grâce au système d’héritage en SQL (mot clé « INHERIT).

CREATE ROLE postgis_reader INHERIT;

Ce rôle serra donner à l’ensemble des acteurs ayant un besoin en lecture sur les données, toujours selon les politiques de sécurité choisies sur chaque table de notre modèle de données. Il pourra notamment être donné aux rôles correspondant à des décideurs, des structures externes, géomaticien et technicien rivière (qui ont besoin d’accéder aux données avant d’en renseigner de nouvelles). On configure alors l’accès aux données spatiales, à notre schéma de données ainsi qu’aux tables, vues, séquences et autres éléments appropriés : 

GRANT SELECT ON geometry_columns TO postgis_reader;
GRANT SELECT ON geography_columns TO postgis_reader;
GRANT SELECT ON spatial_ref_sys TO postgis_reader;
GRANT USAGE ON SCHEMA donnees_diag TO postgis_reader;
GRANT SELECT ON ALL TABLES IN SCHEMA donnees_diag TO postgis_reader;
GRANT SELECT ON donnees_diag.objectif_gestion_line_view TO postgis_reader;
GRANT SELECT ON donnees_diag.objectif_gestion_point_view TO postgis_reader;
GRANT SELECT ON donnees_diag.objectif_gestion_poly_view TO postgis_reader;
GRANT SELECT ON donnees_diag.objectif_gestion_sequence TO postgis_reader;

1.1.1.2. Groupe « postgis_writer »#

Ce second groupe générique, appelé « postgis-writer », aura par défaut les droits d’écriture (INSERT, UPDATE et DELETE) sur l’ensemble des tables de géométries nécessitant des interventions terrains. De nouveau, chaque membre de ce groupe héritera des droits de celui-ci.

CREATE ROLE postgis_writer INHERIT;

Ce rôle sera quant à lui donné essentiellement aux techniciens rivières de chaque syndicat ayant des besoins d’écriture sur les différentes tables spatiales.

Pour ces droits, il est nécessaire de gérer au cas par cas quelles tables seront affectées ou non. En effet, les droits d’écriture sont à gérer correctement pour éviter les membres de ce groupe de déclencher des actions affectant l’intégrité de la base de données. Ainsi on limite ces droits aux tables de diagnostique terrain ainsi qu’aux vues et séquences nécessaires : 

GRANT INSERT, UPDATE, DELETE ON spatial_ref_sys TO postgis_writer;
GRANT UPDATE, INSERT, DELETE ON TABLE donnees_diag.elts_ponctuels, donnees_diag.abreuvement, donnees_diag.curage, donnees_diag.digue, donnees_diag.protection_berge, donnees_diag.facies, donnees_diag.ripisylve, donnees_diag.objectif_gestion, donnees_diag.objectif_gestion_line, donnees_diag.objectif_gestion_point, donnees_diag.objectif_gestion_polygon TO postgis_writer ;
GRANT UPDATE, INSERT, DELETE ON donnees_diag.objectif_gestion_line_view TO postgis_writer;
GRANT UPDATE, INSERT, DELETE ON donnees_diag.objectif_gestion_point_view TO postgis_writer;
GRANT UPDATE, INSERT, DELETE ON donnees_diag.objectif_gestion_poly_view TO postgis_writer;
GRANT USAGE, UPDATE ON donnees_diag.objectif_gestion_sequence TO postgis_writer;

1.2.2 Groupe syndicats#

Pour chaque syndicat, il a été décidé de créer un groupe d’utilisateur. Bien que la plupart des syndicats ne possèdent qu’un seul techniciens rivière, ce n’est pas une généralité. Il est donc nécessaire de gérer correctement ces rôles. 

CREATE ROLE sbaiss INHERIT;

Dans l’optique de pouvoir identifier l’acteur de chaque action sur la base de données, il a été décidé de créer un rôle par technicien, afin d’aider les administrateurs de la base de données à gérer les conflits et leur permettre d’identifier et contacter les auteurs ayant eu des problèmes techniques. Ainsi, chaque technicien aura un rôle nominatif lui étant associé, et serra membre du groupe syndicat dont il est membre. Les politiques de sécurité seront quant à elle définies sur les groupes syndicat, puisque bien que les techniciens soit multiple, ils possèdent les mêmes droits à partir du moment où ils appartiennent au même syndicat. Enfin, on donne à ce groupe utilisateur les droits des groupes génériques en lecture et écriture sur les tables de notre base de données : 

GRANT postgis_reader TO sbaiss;
GRANT postgis_writer TO sbaiss;

Ainsi un groupe utilisateur d’un syndicat choisi héritera des droits des groupes « postgis_reader » et « postgis_writer », ce qui permet de ne pas multiplier les lignes de code SQL similaire dans le but de gérer des droits similaires sur les tables, schémas ou autres éléments de notre base de données. Cela va également permettre de gagner beaucoup de temps lors de la création des utilisateurs, puisqu’il suffira, globalement, de l’associer de cette même manière à un syndicat existant.

1.3. Les politiques de sécurité#

Comme précisé précédemment avec le système de Row Level Security, maintenant que les rôles et groupes sont créés, il est nécessaire de définir des politiques de sécurité d’accès à l’ensemble des tables de notre base de données ayant la fonction de RLS activée.

1.3.1 Table syndicat#

Dans un premier temps, il est nécessaire de définir la géométrie du territoire de chaque syndicat. C’est par la table « syndicat_gemapi » que cette association se fait. On va donc créer une politique de sécurité sur cette table en limitant l’accès uniquement à la géométrie de son territoire. Cette association se fait grâce au nom abrégé de chaque syndicat de la manière suivante :

CREATE POLICY sbaiss_syndicat_gemapy
ON donnees_diag.syndicat_gemapi
FOR SELECT TO sbaiss
USING (syndicat_gemapi.nom_abrev = 'SBAISS');

Cette première politique de sécurité serra indirectement utile pour l’ensemble des autres politiques, en effet, maintenant qu’un groupe ou rôle n’a accès qu’à son territoire, on a la possibilité d’utiliser une requête combinée simple pour effectuer le traitement souhaité sur l’ensemble des tables possédant une géométrie.

1.3.2 Tables de diagnostic#

A l’exception des objectifs de gestion, l’ensemble des tables ayant un objectif de diagnostic rivière vont être affectées par des politiques relativement similaire dans la forme, les requêtes de limitation présentent dans les clauses « USING » et « WITH CHECK » étant les mêmes.

Bien que des politiques soient presque identiques, à l’exception de leur dénomination, il n’est pas possible de créer des politiques globales attribuable à différents groupes ou utilisateur. En effet, le système est fait pour que chaque groupe ou utilisateur soit géré indépendamment pour chaque table. De plus, bien qu’il soit possible de préciser sur quelle clause s’applique une politique directement dans sa déclaration, nous n’utiliserons pas cette fonction. Puisque nous avons d’ores et déjà effectuer la gestion des droits sur chaque tables (voir la section « MISE EN PLACE DES ROLES ET DROITS »), il n’est pas nécessaire de préciser une nouvelle fois sur quelles clauses s’applique la politique, les clauses affectées étant calquées sur les tables accessibles par l’utilisateur ou le groupe.

Afin d’être le plus cohérent et logique possible, on utilise la fonction « ST_INTERSECT » dans la définition des géométries visibles par un utilisateur ou groupe. En effet, de cette façon, même si une très grande entité (par exemple, une masse d’eau), possède une partie, aussi petite qu’elle soit, en commun avec le territoire d’un syndicat, l’élément apparaitra pour les utilisateurs de ce syndicat. Ainsi, pour une table nécessitant une gestion des droits en lecture uniquement (clause « SELECT »), notamment pour l’ensemble des tables de référentiel nationaux ou locaux, on obtient alors une politique de la forme suivante :

CREATE POLICY sbaiss_commune
ON donnees_diag.commune
FOR SELECT TO sbaiss
USING (ST_INTERSECTS(commune.geom, (SELECT syndicat_gemapi.geom FROM donnees_diag.syndicat_gemapi)));

On définit ensuite les droits en lecture (clause « SELECT ») et écriture (clauses « INSERT », « UPDATE » et « DELETE ») sur les tables correspondant à des éléments de diagnostics et nécessitant d’être éditées lors d’interventions terrain. 

CREATE POLICY sbaiss_digue
ON donnees_diag.digue
TO sbaiss 
USING (ST_INTERSECTS(digue.geom, (SELECT syndicat_gemapi.geom FROM donnees_diag.syndicat_gemapi)))
WITH CHECK (ST_INTERSECTS(digue.geom, (SELECT syndicat_gemapi.geom FROM donnees_diag.syndicat_gemapi)));

Ainsi on remarque qu’une clause « WITH CHECK » est venue s’ajoutée à notre politique, puisque comme précisé précédemment, il est maintenant nécessaire de gérer les droits en écriture (clause « INSERT »).

Back to top