Configuration des droits d'accès avec GRANT et REVOKE

Imagine que tes données, c'est une forteresse, et chaque habitant de la forteresse a ses propres droits : y'en a qui peuvent juste se balader dans la cour, d'autres qui gardent les clés du trésor, et y'a le boss qui trône dans la salle du trône et gère tout. Dans notre base de données, ce sont les commandes GRANT et REVOKE qui jouent ce rôle. C'est elles qui décident qui peut aller où et pourquoi.

La commande GRANT, comme tout bon grant, permet de filer l'accès à des ressources (genre des bases de données, des tables, des schémas) à certains rôles. C'est un peu comme "inviter à la teuf", où tu choisis qui peut lire, écrire ou même casser les meubles.

La commande REVOKE, à l'inverse, retire les droits qui avaient été donnés. C'est comme dire : "Hey, la fête est finie pour toi, laisse les clés à la sortie".

Donner des droits avec GRANT

On commence par le niveau le plus haut : la base de données. Pour qu'un utilisateur puisse se connecter à la base, il faut lui donner le droit de connexion. Pour ça, on utilise la commande :

GRANT CONNECT ON DATABASE database_name TO role_name;

Par exemple, si on a une base de données university et un rôle student, on peut autoriser les étudiants à se connecter avec la requête suivante :

GRANT CONNECT ON DATABASE university TO student;

Mais juste se connecter, ça veut pas dire qu'on peut tout faire. Pour qu'un utilisateur puisse créer des objets dans la base, il lui faut aussi le droit de création :

GRANT CREATE ON DATABASE university TO student;

Tu peux vérifier les droits sur la base de données avec la commande :

\l+ university

Retirer des droits avec REVOKE

Si jamais un étudiant commence à faire des trucs louches (genre créer plus de tables que prévu), on peut lui retirer le droit de création avec la commande :

REVOKE CREATE ON DATABASE university FROM student;

Après ça, l'étudiant pourra juste se connecter, mais plus faire de "créativité sauvage".

Configurer les droits au niveau des schémas

Un schéma, c'est en gros une "pièce" dans notre base de données, où sont stockées les tables, vues et autres objets. Pour qu'un utilisateur puisse bosser avec les objets du schéma, tu peux régler les droits de lecture, écriture ou création d'objets.

Donner des droits sur un schéma

Imaginons qu'on a un schéma public (il est créé par défaut dans chaque base). On peut autoriser un utilisateur à voir le contenu du schéma :

GRANT USAGE ON SCHEMA public TO student;

Mais juste USAGE ça suffit pas pour bosser avec les tables. Pour que l'utilisateur puisse créer de nouveaux objets, on ajoute :

GRANT CREATE ON SCHEMA public TO student;

Comme ça, l'étudiant peut non seulement lire, mais aussi créer des tables dans le schéma public.

Retirer des droits sur un schéma

Si l'étudiant commence à polluer le schéma avec des tables cheloues genre bad_idea_01, on peut limiter ses droits :

REVOKE CREATE ON SCHEMA public FROM student;

Maintenant, il ne pourra plus ajouter de nouvelles tables. L'ordre est rétabli !

Configurer les droits au niveau des tables

La table, c'est sûrement l'objet le plus populaire d'une base de données. Voyons comment régler l'accès précisément aux tables. Ici, il y a trois grandes catégories d'actions : lecture, écriture et modification.

Droits de lecture

Pour autoriser un utilisateur à lire le contenu d'une table, on utilise :

GRANT SELECT ON TABLE table_name TO role_name;

Par exemple, pour que les étudiants puissent lire les enregistrements de la table courses :

GRANT SELECT ON TABLE courses TO student;

Maintenant, l'utilisateur student peut lancer des requêtes SELECT sur la table courses.

Droits d'écriture

Si tu veux qu'un utilisateur puisse insérer de nouvelles lignes dans une table, tu fais comme ça :

GRANT INSERT ON TABLE table_name TO role_name;

Exemple :

GRANT INSERT ON TABLE courses TO student;

Maintenant, les étudiants peuvent ajouter de nouveaux cours dans la table. Mais attends... On est sûrs que c'est une bonne idée ?

Droits de modification et suppression

Si un utilisateur doit pouvoir mettre à jour des lignes existantes ou les supprimer, il faut lui donner les droits UPDATE et DELETE respectivement.

GRANT UPDATE ON TABLE courses TO student;
GRANT DELETE ON TABLE courses TO student;

Conseil : évite d'abuser de ces droits. Si tu donnes aux étudiants le droit de supprimer des données, ils pourraient tout casser par accident (ou exprès).

Exemples : créer un rôle avec des droits limités

Imagine qu'on crée un rôle pour les profs, qui doivent pouvoir lire les données sur les étudiants et les cours, mais pas supprimer d'enregistrements. Voilà comment faire :

1. On crée le rôle :

CREATE ROLE teacher;

2. On donne les droits de lecture sur les tables students et courses :

GRANT SELECT ON TABLE students, courses TO teacher;

3. On limite l'accès à la suppression :

REVOKE DELETE ON TABLE students, courses FROM teacher;

Maintenant, nos profs n'ont que les droits nécessaires, rien de plus.

Comment combiner GRANT et REVOKE pour une config flexible

Imaginons qu'on a un rôle intern qu'on veut restreindre. Il doit avoir accès seulement aux données des cours, mais surtout pas aux données des étudiants. Voilà à quoi ça ressemble :

1. On autorise l'accès uniquement à la table courses :

GRANT SELECT, INSERT ON TABLE courses TO intern;

2. On s'assure que le rôle intern n'a aucun droit sur la table students :

REVOKE ALL ON TABLE students FROM intern;

Cette combinaison permet de régler les droits d'accès au poil.

Exemples d'utilisation dans des projets réels

Ce système de gestion des accès est super courant dans les vrais projets. Par exemple :

1. Dans les boutiques en ligne, les droits sur les tables utilisateurs et commandes sont répartis entre les rôles "admin", "opérateur" et "invité".
2. Dans les systèmes universitaires, les admins peuvent ajouter et modifier des cours, alors que les étudiants peuvent juste les consulter.
3. Dans les systèmes bancaires, l'accès aux comptes clients est séparé entre les employés de différents services.