Contrôler qui peut lire, modifier ou administrer vos données est aussi important que d'écrire des requêtes correctes. SQL offre un système de permissions granulaire basé sur GRANT et REVOKE.
Controlling who can read, modify, or administer your data is just as important as writing correct queries. SQL provides a granular permission system based on GRANT and REVOKE.
GRANT et REVOKE
GRANT and REVOKE
GRANT accorde un privilège précis à un utilisateur ou un rôle ; REVOKE le retire.
GRANT gives a specific privilege to a user or role; REVOKE removes it.
GRANT SELECT, INSERT ON commandes TO analyste_ventes;
REVOKE INSERT ON commandes FROM analyste_ventes;
GRANT SELECT, INSERT ON orders TO sales_analyst;
REVOKE INSERT ON orders FROM sales_analyst;
Les rôles : regrouper des permissions
Roles: Grouping Permissions
Plutôt que d'attribuer des permissions individuellement à chaque utilisateur, on les regroupe dans des rôles, que l'on assigne ensuite aux utilisateurs.
Instead of assigning permissions individually to each user, you group them into roles, which are then assigned to users.
CREATE ROLE lecture_seule;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO lecture_seule;
GRANT lecture_seule TO utilisateur_stagiaire;
CREATE ROLE read_only;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO read_only;
GRANT read_only TO intern_user;
Le principe du moindre privilège
The Principle of Least Privilege
Chaque utilisateur ou application ne devrait avoir que les permissions strictement nécessaires à sa tâche — jamais des droits d'administration "par précaution".
Every user or application should only have the permissions strictly necessary for its task — never admin rights "just in case".
| Contexte | Bonne pratique |
|---|---|
| Application web | Compte dédié avec accès limité aux tables utilisées |
| Rapports / BI | Rôle en lecture seule, idéalement sur des vues |
| Administrateur | Accès complet, mais utilisé seulement pour les tâches d'administration |
| Context | Best Practice |
|---|---|
| Web application | Dedicated account limited to the tables it uses |
| Reports / BI | Read-only role, ideally against views |
| Administrator | Full access, but used only for administration tasks |
Sécurité au niveau des lignes (Row-Level Security)
Row-Level Security
Certains moteurs SQL permettent de restreindre l'accès à des lignes précises selon l'utilisateur connecté, en plus des permissions sur les tables entières.
Some SQL engines let you restrict access to specific rows based on the connected user, on top of whole-table permissions.
ALTER TABLE commandes ENABLE ROW LEVEL SECURITY;
CREATE POLICY client_voit_ses_commandes ON commandes
USING (client_id = current_user_id());
ALTER TABLE orders ENABLE ROW LEVEL SECURITY;
CREATE POLICY customer_sees_own_orders ON orders
USING (customer_id = current_user_id());
Points clés à retenir
Key Takeaways
- Utilisez des rôles plutôt que des permissions individuelles pour rester gérable à grande échelle
- Appliquez le principe du moindre privilège par défaut, et élargissez seulement au besoin
- La sécurité au niveau des lignes complète les permissions de table pour des cas d'usage multi-locataires
- Use roles rather than individual permissions to stay manageable at scale
- Apply the principle of least privilege by default, and widen access only as needed
- Row-level security complements table permissions for multi-tenant use cases
