GRANT |
Droits d'accès |
|---|---|
| Microsoft SQL Server |
Syntaxe
| GRANT { ALL [ PRIVILEGES ] } | permission [ ( column [ ,...n ] ) ] [ ,...n ] [ ON [ class :: ] securable ] TO principal [ ,...n ] [ WITH GRANT OPTION ] [ AS principal ] |
Paramètres
| Nom | Description |
|---|---|
| ALL [ PRIVILEGES ] | Ce paramètre permet d'accorder toutes les autorisations disponibles sur l'objet concerné. L'option PRIVILEGES est facultative et rarement utilisée dans SQL Server (héritée du standard SQL). |
| permission | Ce paramètre permet de désigner le droit spécifique à accorder (exemple : SELECT, INSERT, UPDATE, EXECUTE,...). Plusieurs permissions peuvent être listées et séparées par des virgules. |
| (column [...n]) | Ce paramètre permet de restreindre une autorisation à une ou plusieurs colonnes d'une table ou d'une vue. Valable uniquement pour certaines permissions comme SELECT, UPDATE. |
| ON [ class :: ] securable | Ce paramètre permet de définir l'objet sur lequel porte l'autorisation, tel qu'une table, une vue, une STORED PROCEDURE, un schéma,... class:: est utilisé pour préciser le type (par ex. OBJECT::MaTable). |
| TO principal [...n] | Ce paramètre permet d'indiquer les utilisateurs, rôles ou connexions à qui accorder les permissions. Plusieurs entités peuvent être listées séparément. |
| WITH GRANT OPTION | Ce paramètre permet d'autoriser le bénéficiaire à transmettre à d'autres utilisateurs les mêmes permissions qu'il vient de recevoir. Cela permet une délégation contrôlée. |
| AS principal | Ce paramètre permet de spécifier un autre utilisateur (ou rôle) comme source des droits si l'utilisateur actuel a reçu ces permissions avec GRANT OPTION. Cela est utilisé dans des contextes d'imitation de privilèges. |
Description
Cette instruction permet de donner des droits d'accès à une base de données principal.
Remarques
- L'instruction GRANT est fondamentale pour la sécurité : Elle permet d'attribuer des permissions précises à des utilisateurs, rôles ou connexions, de façon très ciblée. Cela fait partie des mécanismes de contrôle d'accès basés sur les autorisations, indispensables pour limiter les actions possibles sur les objets d'une base.
- Il est possible de restreindre l'accès à certaines colonnes uniquement : Avec la clause (column [...n]), GRANT peut limiter une permission comme SELECT ou UPDATE à des colonnes spécifiques d'une table. Cela permet un contrôle fin et évite d'exposer des données sensibles tout en permettant l'accès au reste.
- La clause WITH GRANT OPTION introduit la notion de délégation : Lorsqu'un utilisateur reçoit un droit avec cette clause, il peut à son tour l'attribuer à d'autres utilisateurs. Cela facilite la gestion des permissions dans les grandes équipes, mais demande aussi une surveillance rigoureuse pour éviter des cascades incontrôlées.
- La clause AS principal est rarement utilisée mais puissante : Elle permet d'exécuter l'attribution de droits comme si l'on était un autre principal (généralement un rôle ou un utilisateur autorisé à déléguer). Cela peut être utile dans des scripts automatisés ou pour simuler des attributions dans un contexte délégué.
- Il est possible d'attribuer plusieurs permissions dans une même instruction : GRANT accepte une liste de permissions séparées par des virgules. Cela permet de simplifier l'administration des droits en regroupant plusieurs autorisations en une seule commande, au lieu de devoir les écrire une par une.
- La syntaxe class::securable permet de lever les ambiguïtés : En précisant le type de l'objet (OBJECT::, SCHEMA::,...), on peut éviter des confusions possibles, surtout quand des objets ont des noms identiques dans des contextes différents. Cela améliore la clarté et la précision du code SQL.
- Accorder ALL [PRIVILEGES] n'est pas recommandé en production : Cette commande donne tous les droits disponibles sur un objet, ce qui peut poser problème si des utilisateurs malveillants ou mal informés en abusent. Il est donc préférable d'attribuer les droits un par un, en fonction des besoins réels.
- GRANT peut être utilisé sur une grande variété d'objets sécurisables : Il ne se limite pas aux tables ou vues : on peut aussi accorder des droits sur des STORED PROCEDURES, des fonctions, des schémas, voire des niveaux plus globaux comme la base ou le serveur. Cela permet de bâtir une politique de sécurité très granulaire.
Dernière mise à jour : Vendredi, le 19 Juin 2020