SécuritéSecurity · 5 août 2026 · 7 min de lecture· August 5, 2026 · 7 min read

La gestion des permissions et de la sécurité en SQL

Managing Permissions and Security in SQL

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".

ContexteBonne pratique
Application webCompte dédié avec accès limité aux tables utilisées
Rapports / BIRôle en lecture seule, idéalement sur des vues
AdministrateurAccès complet, mais utilisé seulement pour les tâches d'administration
ContextBest Practice
Web applicationDedicated account limited to the tables it uses
Reports / BIRead-only role, ideally against views
AdministratorFull 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());
Astuce : auditez régulièrement les permissions accordées — les accès s'accumulent avec le temps et sont rarement retirés spontanément quand ils ne sont plus nécessaires. Tip: audit granted permissions regularly — access tends to accumulate over time and is rarely removed spontaneously once it's no longer needed.

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
← Article précédent : Vues et procédures stockées ← Previous article: Views and Stored Procedures Article suivant : Optimisation des performances → Next article: Performance Optimization →
Publicité Advertisement