04/12/2023 22:50 Le SQL de A à Z - la gestion des privilèges

FORUMS TUTORIELS FAQ BLOGS CHAT NEWSLETTER EMPLOI ÉTUDES DROIT CLUB

DI/DSI Solutions d'entreprise Cloud IA ALM Microsoft Java Dév. Web EDI Programmation SGBD Office Mobiles Systèmes

SGBD 4D Access Big Data Data Science DB2 Firebird InterBase MySQL NoSQL PostgreSQL Oracle Sybase SQL-Server MongoDB

Accueil SGBD Forums SGBD FAQ SGBD Tutoriels SGBD SQL Outils SGBD Livres SGBD et SQL

La gestion des privilèges

Table des matières
1. La notion d'utilisateur
2. Octroyer des privilèges
2-1. Les différents privilèges
2-2. Attribution de privilèges
2-3. Gestion fine des privilèges
2-3-1. Privilèges INSERT et UPDATE sur colonne
2-3-2. Privilèges SELECT sur colonne
2-4. Particularité des privilèges d'usage
2-5. Privilèges de référence
3. Révocation des privilèges
3-1. Quelques exemples simples
3-2. Problématique de révocation
4. Retrouver les privilèges
5. Critiques diverses
5-1. Pas de privilèges simultanés sur plusieurs objets
5-2. Pas de privilèges « négatif »
6. SQL:1999 et les rôles
7. Confidentialité des données

On emploie à tort le mot « droit » pour expliquer, dans SQL, le sous-ensemble DCL dit « data control language » qui s'occupe de la gestion des privilèges. Cette partie de SQL 2 s'occupe de contrôler
quel utilisateur peut ou ne peut pas utiliser tel ou tel ordre SQL sur tel ou tel objet et en cette matière il n'y a pas que des droits, mais aussi des « usages » ! ♪

Article lu 156435 fois.

L'auteur
SQLPro

L'article
Publié le 12 novembre 2003

Version PDF Version hors-ligne

ePub, Azw et Mobi

Liens sociaux
Partager

1. La notion d'utilisateur▲

La notion d'utilisateur possède une lacune importante dans SQL, car elle fait l'impasse sur la façon dont on créé un utilisateur…

NOTA : SQL 2 a prévu des règles d'accès spécifiques pour les différentes familles d'ordre SQL. Ainsi pour la création d'un schéma (une base de données en fait) ou d'un catalogue (un ensemble de
bases de données), il laisse la règle à l'appréciation de l'éditeur du SGBDR. En revanche pour les ordres CREATE, ALTER et DROP, l'utilisateur courant doit être le même que l'utilisateur propriétaire
(auteur) du schéma modifié.

Rappelons que la création d'un utilisateur se fait au moment de la création du schéma. Par défaut ce dernier est le créateur des objets.

Souvent dans les implémentations commerciales, on trouve un pseudo-ordre SQL du genre CREATE USER nomUtilisateur, ou encore une procédure stockée permettant de définir un nouvel utilisateur.

Ainsi, pour MS SQL Server :

Exemple 1

Sélectionnez
sp_adduser 'nomConnexion', 'nomNouvelUtilisateur'

Permet d'ajouter un nouvel utilisateur affecté à la connexion donnée.

La norme SQL2 propose trois fonctions pour connaître l'utilisateur (c'est-à-dire celui qui se connecte au serveur) et l'auteur, c'est-à-dire le créateur des objets :

SYSTEM_USER nom de connexion

SESSION_USER nom du créateur

CURRENT_USER utilisateur courant

Ainsi, par défaut, SQL Server utilise les noms suivants :

Exemple 2

https://sqlpro.developpez.com/cours/sqlaz/dcl/ 1/9
04/12/2023 22:50 Le SQL de A à Z - la gestion des privilèges

Sélectionnez
Sélectionnez SYSTEM_USER SESSION_USER CURRENT_USER
SELECT SYSTEM_USER, SESSION_USER, CURRENT_USER ----------- ------------ ------------
sa dbo dbo

Notons en marge le super utilisateur SQL PUBLIC qui concerne tous les utilisateurs passés et à venir.

2. Octroyer des privilèges▲

Les privilèges sont, pour un ou plusieurs utilisateurs la possibilité d'utiliser certains objets et parmi ces objets, certains ordres SQL.

2-1. Les différents privilèges▲

Voici une liste des différents privilèges que SQL permet et les objets sur lesquels ces privilèges portent :

USAGE domaine, jeu de caractères, collation, translation

SELECT, INSERT, UPDATE, REFERENCES nom du créateur

CURRENT_USER table, vue, colonne(s)

Notons qu'il n'est pas possible de définir des droits sur la création, la modification ou la suppression des éléments de schema (base de données), ceci étant défini lors de la création du schema.

2-2. Attribution de privilèges▲

C'est l'ordre SQL GRANT qui permet d'attribuer un privilège à différents utilisateurs sur différents objets.

Voici la syntaxe de l'ordre SQL GRANT :

Sélectionnez
GRANT <privileges>
TO <gratifié> [ { , <gratifié> }... ]
[ WITH GRANT OPTION ]

Sélectionnez
<privileges> ::=
<privilège> [ { , <privilège> }... ]

Sélectionnez
<privilege> ::=
ALL PRIVILEGES ON <objet table>
| <privilège d'action>
| <privilege d'usage>
| <privilege de référence>

Sélectionnez
<privilège d'action> ::=
<action> [ { , <action> }... ] ON <objet table>

Sélectionnez
<privilege d'usage> ::=
USAGE ON <objet d'usage>

Sélectionnez
<privilege de référence> ::=
REFERENCES [ ( <liste de colonne> ) ] <nom de table>

Sélectionnez
<action> ::=
SELECT
| DELETE
| INSERT [ ( <liste de colonne> ) ]
| UPDATE [ ( <liste de colonne> ) ]

Sélectionnez
<objet table> ::=
[ TABLE ] <nom de table ou de vue>

Sélectionnez
<objet d'usage> ::=
DOMAIN <nom de domaine>
| COLLATION <nom de collation>
| CHARACTER SET <nom de jeu de caractères>
| TRANSLATION <nom de translation>

https://sqlpro.developpez.com/cours/sqlaz/dcl/ 2/9
04/12/2023 22:50 Le SQL de A à Z - la gestion des privilèges

Sélectionnez
<gratifié> ::=
PUBLIC
| <utilisateur>

La clause WITH GRANT OPTION, est utilisée pour autoriser la transmission des droits. La clause ALL PRIVILEGES n'a d'intérêt que dans le cadre de la transmission des droits.

Voici maintenant une batterie d'exemples afin de mieux comprendre comment utiliser cet ordre… Pour nos exemples, nous avons considéré que les utilisateurs DUPONT, DURAND, DUBOIS, DUVAL,
DULAC et DUFOUR étaient créés dans la base de données. Celui qui lance les ordres (sauf indication contraire) est l'utilisateur DUHAMEL.

Exemple 3

Sélectionnez
GRANT SELECT
ON T_CHAMBRE
TO DUBOIS

Autorise DUBOIS à lancer des ordres SQL SELECT sur la table T_CHAMBRE. Notez l'absence du mot TABLE.

Exemple 4

Sélectionnez
GRANT INSERT, UPDATE, DELETE
ON TABLE T_CHAMBRE
TO DUVAL, DUBOIS

Autorise DUVAL et DUBOIS à modifier les données par tous les ordres SQL de mise à jour (INSERT, UPDATE, DELETE), mais pas à les lire !

Exemple 5

Sélectionnez
GRANT SELECT
ON TABLE T_CMAMBRE
TO DUFOUR WITH GRANT OPTION

Autorise DUFOUR à lancer des ordres SQL SELECT sur la table T_CHAMBRE, mais aussi à transmettre à tout autre utilisateur les droits qu'il a acquis dans cet ordre.

Exemple 6

Sélectionnez
GRANT SELECT, INSERT, DELETE
ON TABLE T_CHAMBRE
TO DURAND WITH GRANT OPTION

Autorise DURAND à lancer des ordres SQL SELECT, INSERT, DELETE sur la table T_CHAMBRE.

Exemple 7

Sélectionnez
GRANT SELECT, UPDATE
ON TABLE T_CHAMBRE
TO PUBLIC

Autorise tous les utilisateurs présents et à venir à lancer des ordres SQL SELECT et UPDATE sur la table T_CHAMBRE.

Exemple 8 : DURAND lance l'ordre suivant :

Sélectionnez
GRANT ALL PRIVILEGES
ON TABLE T_CHAMBRE
TO DUBOIS

Ce qui autorise DUBOIS à lancer sur la table T_CHAMBRE, les mêmes ordres SQL, que ceux autorisés à DURAND (SELECT, INSERT, DELETE).

On parle alors d'héritage de droits c'est-à-dire que l'utilisateur doté de ces droits peut à nouveau les céder à un ou plusieurs autres utilisateurs.

Exemple 9 : DURAND lance l'ordre suivant :

Sélectionnez
GRANT UPDATE
ON TABLE T_CHAMBRE
TO DUBOIS

Cet ordre va provoquer une erreur, car DURAND n'est pas autorisé à lancer des ordres UPDATE sur la table T_CHAMBRE et ne peut donc transmettre un droit qu'il n'a pas !

2-3. Gestion fine des privilèges▲

Est-il possible de gérer des privilèges plus fins que sur l'intégralité de la table ou de vue ? En particulier, peut-on gérer des privilèges au niveau de certaines colonnes d'une table ?
La réponse est OUI, mais il faut utiliser un peu d'astuce…

2-3-1. Privilèges INSERT et UPDATE sur colonne▲

On peut employer l'ordre GRANT pour ce faire :

Exemple 10

https://sqlpro.developpez.com/cours/sqlaz/dcl/ 3/9
04/12/2023 22:50 Le SQL de A à Z - la gestion des privilèges
Sélectionnez
GRANT UPDATE (CHB_POSTE_TEL, CHB_COUCHAGE)
ON TABLE T_CHAMBRE
TO DULAC
Cet ordre permet à DULAC de modifier uniquement les colonnes « poste téléphonique » et « nombre de places de couchage » de la table T_CHAMBRE.

Plus curieux, on peut définir les colonnes utilisables pour un ordre d'insertion pour un utilisateur :

Exemple 11

Sélectionnez
GRANT INSERT (CHB_NUMERO, CHB_ETAGE, CHB_BAIN, CHB_DOUCHE, CHB_WC)
ON TABLE T_CHAMBRE
TO DULAC

Cet ordre permet à DULAC d'insérer une nouvelle ligne dans la table, uniquement en spécifiant les colonnes listées. Le problème est que dans cette liste ne figure pas la colonne clef… Autrement dit,
DULAC ne pourra jamais rien insérer du tout, sauf si la clef est calculée par un déclencheur avant insertion.

NOTA : dans le cas de l'attribution de privilèges d'insertion sur colonne, il est indispensable de faire figurer toutes les colonnes NOT NULL n'ayant ni clause de valeur par défaut, ni remplissage par un
trigger avant insertion. Sans cela cette autorisation est illusoire !

2-3-2. Privilèges SELECT sur colonne▲

Ce type de privilège n'est pas géré directement par un ordre SQL.

En effet, il n'est pas possible d'écrire :

Exemple 12

Sélectionnez
GRANT SELECT (CHB_NUMERO, CHB_ETAGE, CHB_BAIN, CHB_DOUCHE, CHB_WC)
ON TABLE T_CHAMBRE
TO DULAC

Cet ordre n'est pas légal au niveau de SQL.

Mais un ordre GRANT peut porter sur une vue !

Nous voilà donc sauvés : créer une vue pour gérer les privilèges de sélection de l'utilisateur DULAC..

Exemple 13

Sélectionnez
Sélectionnez
CREATE VIEW V_CHAMBRE
GRANT SELECT
AS
ON V_CHAMBRE
SELECT CHB_NUMERO, CHB_ETAGE, CHB_BAIN, CHB_DOUCHE, CHB_WC
TO DULAC
FROM T_CHAMBRE

Et le tour est joué !

2-4. Particularité des privilèges d'usage▲

Mais quel est donc l'intérêt de gérer des privilèges sur des domaines, des collations, des translations, ou des jeux de caractères ?

NOTA : pour les lecteurs qui ne seraient pas familiarisés avec ces objets d'une base de données, voici les références.
Pour les domaines :

le SQL de A à Z, 1re partie, 6.6 les domaines

le SQL de A à Z, 7e partie, 5.4 Définir des domaines

Pour les jeux de caractères, collations et translations, lire :

le SQL de A à Z, 7e partie, 4 Une question de caractères

Pour comprendre l'intérêt des privilèges d'usage intéressons-nous au domaine en rappelant que le domaine est constitué d'un type de données assorties d'autant de règles que l'on veut (contraintes)
et même aucune si on le désire. En outre, le domaine est utilisé en remplacement d'un type de donnée SQL basique, partout où on en a besoin, dans la définition des tables, comme dans l'utilisation
de la fonction CAST par exemple.
Voici la création d'un domaine permettant de spécifier un pourcentage :

Exemple 14

Sélectionnez
CREATE DOMAIN DMN_POURCENT FLOAT
CHECK (VALUE BETWEEN 0 AND 100)

Le problème réside dans le fait qu'une vue peut avoir été créée avec un transtypage de domaine…

Exemple 15

Sélectionnez
SELECT CHB_ID, CHB_COUCHAGE,
CAST(100 * (CHB_COUCHAGE
/ (SELECT SUM(CHB_COUCHAGE)
FROM T_CHAMBRE)) AS DMN_POURCENT) AS POURCENT_OCCUPATION
FROM T_CHAMBRE

Dans ce cas que va-t-il se passer lors de la suppression du domaine ?

Si la suppression du domaine se fait avec la clause RESTRICT, le fait que cette vue utilise un transtypage provoquera une erreur et interdira la suppression effective du domaine.

Si la suppression du domaine se fait à l'aide de la clause CASCADE, alors la vue est supprimée !

C'est pourquoi on aura tout intérêt à introduire des privilèges d'usage pour les domaines, collations, translations et jeux de caractères, mais de façon parcimonieuse à certains utilisateurs capables
d'instancier des vues par exemple. Cela permettra de limiter les dégâts…

https://sqlpro.developpez.com/cours/sqlaz/dcl/ 4/9
04/12/2023 22:50 Le SQL de A à Z - la gestion des privilèges
Bien entendu ce qui se passe dans notre exemple avec les domaines est similaire à ce qui peut se passer avec les collations, translations et jeux de caractères.

2-5. Privilèges de référence▲

Lorsque l'on crée des tables en liaisons les unes aux autres, on utilise très souvent le mécanisme d'intégrité référentiel afin de gérer les clefs étrangères.

Voyons ce qui se passe si, dans notre base exemple, nous attribuons les droits ainsi :

Exemple 16

Sélectionnez
GRANT SELECT, INSERT, UPDATE, DELETE
ON TABLE T_CHAMBRE
TO DUMONT

Sélectionnez
GRANT SELECT, INSERT, UPDATE, DELETE
ON TABLE T_PLANNING
TO DUMONT

Sélectionnez
GRANT SELECT, INSERT, UPDATE, DELETE
ON TABLE TJ_CHB_PLN_CLI
TO DUMONT

Dumont pourra sélectionner et supprimer sans problèmes dans toutes les tables. Il pourra mettre à jour les données et insérer sans aucun problème dans les tables T_CHAMBRE et T_PLANNING.
En revanche il se heurtera parfois à un refus de la base de données pour la mise à jour de la table de jointure TJ_CHB_PLN_CLI. Pire , il lui sera impossible d'insérer des données dans cette dernière
table…
Quelle en est la raison ?

Regardons comment a été créée cette table de jointure :

Sélectionnez
CREATE TABLE TJ_CHB_PLN_CLI
( CHB_ID INTEGER NOT NULL,
PLN_JOUR DATE not null,
CLI_ID INTEGER not null,
CHB_PLN_CLI_NB_PERS SMALLINT not null,
CHB_PLN_CLI_RESERVE NUMERIC(1) not null default 0,
CHB_PLN_CLI_OCCUPE NUMERIC(1) not null default 1,
CONSTRAINT PK_TJ_CHB_PLN_CLI PRIMARY KEY (CHB_ID, PLN_JOUR) ,
CONSTRAINT FK_CHB_ID REFERENCES T_CHAMBRE (CHB_ID) ,
CONSTRAINT FK_PLN_JOUR REFERENCES T_PLANNING (PLN_JOUR) ,
CONSTRAINT FK_CLI_ID REFERENCES T_CLIENT CLI_ID)
)

Elle utilise trois tables en référence : T_CHAMBRE, T_PLANNING, T_CLIENT. Or notre utilisateur DUMONT n'a aucun privilège sur la table T_CLIENT. Il lui sera donc impossible lors de l'insertion,
comme lors de la mise à jour de préciser une valeur pour cette colonne sans qu'il se voie automatiquement infliger un refus du serveur.

Or donc, pour pouvoir définir une valeur pour la colonne CLI_ID lors de l'exécution des ordres UPDATE et INSERT, notre utilisateur DUMONT, doit avoir un privilège supplémentaire défini comme suit :

Exemple 17

Sélectionnez
GRANT REFERENCES (CLI_ID)
ON TABLE T_CLIENT
TO DUMONT

NOTA : le privilège de référence ne porte pas exclusivement sur les contraintes d'intégrité, mais sur toute contrainte faisant référence à une colonne d'une table externe.

3. Révocation des privilèges▲

L'ordre SQL REVOKE permet de révoquer, c'est-à-dire « retirer » un privilège.

Sa syntaxe est la suivante :

Sélectionnez
REVOKE [ GRANT OPTION FOR ] <privileges>
FROM <gratifié> [ { , <gratifié> }... ]
[ RESTRICT
| CASCADE ]

Sélectionnez
<privileges> ::=
<privilège> [ { , <privilège> }... ]

Sélectionnez
<privilege> ::=
ALL PRIVILEGES ON <objet table>
| <privilège d'action>
| <privilege d'usage>
| <privilege de référence>

https://sqlpro.developpez.com/cours/sqlaz/dcl/ 5/9
04/12/2023 22:50 Le SQL de A à Z - la gestion des privilèges

Sélectionnez
<privilège d'action> ::=
<action> [ { , <action> }... ] ON <objet table>

Sélectionnez
<privilege d'usage> ::=
USAGE ON <objet d'usage>

Sélectionnez
<privilege de référence> ::=
REFERENCES [ ( <liste de colonne> ) ] <nom de table>

Sélectionnez
<action> ::=
SELECT
| DELETE
| INSERT [ ( <liste de colonne> ) ]
| UPDATE [ ( <liste de colonne> ) ]

Sélectionnez
<objet table> ::=
[ TABLE ] <nom de table ou de vue>

Sélectionnez
<objet d'usage> ::=
DOMAIN <nom de domaine>
| COLLATION <nom de collation>
| CHARACTER SET <nom de jeu de caractères>
| TRANSLATION <nom de translation>

Sélectionnez
<gratifié> ::=
PUBLIC
| <utilisateur>

La grande différence réside en fait dans l'usage des mots clefs RESTRICT et CASCADE. En cas de RESTRICT, si le ou les utilisateurs visés ont cédé leurs droits à d'autres, un message d'erreur
apparaîtra et le SGBDR refusera de révoquer le ou les droits. En revanche l'usage du mot clef CASCADE entrainera la révocation des droits cédés à la manière d'un château de cartes.

À noter que l'utilisation de l'expression GRANT OPTION FOR ne révoque pas les droits, mais supprime la possibilité de cession des droits lorsque ces droits ont été définis en utilisant la clause WITH
GRANT OPTION.

3-1. Quelques exemples simples▲

Exemple 18

Sélectionnez
REVOKE SELECT
ON T_CHAMBRE
FROM DUBOIS

Supprime le privilège de selection de la table T_CHAMBRE attribué à DUBOIS dans l'exemple 1.

Exemple 19

Sélectionnez
REVOKE INSERT, DELETE
ON TABLE T_CHAMBRE
FROM DUVAL, DUBOIS

Supprime les privilèges d'insertion et de suppression de la table T_CHAMBRE attribuées à DUVAL et DUBOIS dans l'exemple 2, mais pas celui de mise à jour (UPDATE).

Exemple 20

Sélectionnez
REVOKE GRANT OPTION FOR SELECT
ON TABLE T_CMAMBRE
FROM DUFOUR

Supprime la possibilité pour DUFOUR de transmettre le privilège de sélection sur la table T_CHAMBRE.

3-2. Problématique de révocation▲

Il existe cependant quelques pièges dans l'utilisation du mécanisme de révocation. Nous allons en montrer quelques-uns à l'aide de différents exemples. Rappelons simplement que celui qui lance les
ordres (sauf indication contraire) est l'utilisateur DUHAMEL.

Contrairement aux droits « système » les privilèges sont cumulatifs. On peut ainsi obtenir plusieurs fois le même privilège sur le même objet en provenance de différents utilisateurs. Le privilège sera
totalement retiré lorsque tous les utilisateurs ayant donné ce privilège l'auront retiré.

Exemple 21

Sélectionnez
GRANT SELECT
ON T_CLIENT
TO DUCROS WITH GRANT OPTION

https://sqlpro.developpez.com/cours/sqlaz/dcl/ 6/9
04/12/2023 22:50 Le SQL de A à Z - la gestion des privilèges

Sélectionnez
GRANT SELECT
ON T_CLIENT
TO DUGLAND

C'est maintenant DUCROS qui est l'utilisateur qui va lancer l'ordre suivant :

Sélectionnez
GRANT SELECT
ON T_CLIENT
TO DUGLAND

Enfin, DUHAMEL reprend la main pour révoquer ainsi :

Sélectionnez
REVOKE SELECT
ON T_CLIENT
FROM DUGLAND

DUGLAND peut-il sélectionner des lignes de la table T_CLIENT ? La réponse est OUI, parce qu'il possède encore un droit de sélection venant de DUCROS !

Voici une autre problématique. Le super utilisateur PUBLIC ne vise personne en particulier ni en général. On ne peut donc retirer un privilège particulier à un utilisateur donné même si l'on a attribué
des privilèges à « PUBLIC ».

Exemple 22

Sélectionnez
GRANT SELECT
ON T_CLIENT
TO PUBLIC

Sélectionnez
REVOKE INSERT, DELETE
ON T_CLIENT
FROM DUMOULIN

Ce dernier ordre SQL va retourner un message d'erreur et ne sera pas exécuté parce que DUMOULIN n'a jamais reçu les privilèges INSERT et DELETE sur la table CLIENT, bien qu'il hérite des
privilèges de PUBLIC !

En fait il faut comprendre que le modèle de gestion des privilèges dans SQL repose sur la théorie des graphes et peut devenir vite compliqué lorsque l'on veut gérer finement de multiples droits.

4. Retrouver les privilèges▲

Les vues d'information de schema permettent de retrouver les privilèges, les objets et les utilisateurs visés (originaires et destinataires). Pour cela la norme SQL 2 a prévu trois vues spécifiques :

INFORMATION_SCHEMA Colonnes

GRANTOR, GRANTEE, TABLE_CATALOG, TABLE_SCHEMA, TABLE_NAME, PRIVILEGE_TYPE,

TABLE_PRIVILEGES
IS_GRANTABLE

GRANTOR, GRANTEE, TABLE_CATALOG, TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME,

COLUMN_PRIVILEGES
PRIVILEGE_TYPE, IS_GRANTABLE

GRANTOR, GRANTEE, OBJECT_CATALOG, OBJECT_SCHEMA, OBJECT_NAME,OBJECT_TYPE,

USAGE_PRIVILEGES
PRIVILEGE_TYPE, IS_GRANTABLE

Exemple 23

Sélectionnez
SELECT GRANTOR, GRANTEE, TABLE_NAME, ' <TABLE>' AS COLUMN_NAME, PRIVILEGE_TYPE,
IS_GRANTABLE
FROM INFORMATION_SCHEMA.TABLE_PRIVILEGES
WHERE GRANTEE IN ('DUBOIS', 'DUVAL', 'DULAC')
UNION
SELECT GRANTOR, GRANTEE, TABLE_NAME, COLUMN_NAME, PRIVILEGE_TYPE, IS_GRANTABLE
FROM INFORMATION_SCHEMA.COLUMN_PRIVILEGES
WHERE GRANTEE IN ('DUBOIS', 'DULAC', 'DUVAL)
ORDER BY GRANTEE, TABLE_NAME, PRIVILEGE_TYPE, COLUMN_NAME

https://sqlpro.developpez.com/cours/sqlaz/dcl/ 7/9
04/12/2023 22:50 Le SQL de A à Z - la gestion des privilèges

Sélectionnez
GRANTOR GRANTEE TABLE_NAME COLUMN_NAME PRIVILEGE_TYPE IS_GRANTABLE
----------- --------- -------------- --------------- -------------- ------------
DUHAMEL DUBOIS T_CHAMBRE <TABLE> SELECT False
DUHAMEL DUBOIS T_CHAMBRE <TABLE> INSERT False
DUHAMEL DUBOIS T_CHAMBRE <TABLE> UPDATE False
DUHAMEL DUBOIS T_CHAMBRE <TABLE> DELETE False
DUHAMEL DUVAL T_CHAMBRE <TABLE> INSERT False
DUHAMEL DUVAL T_CHAMBRE <TABLE> UPDATE False
DUHAMEL DUVAL T_CHAMBRE <TABLE> DELETE False
DURAND DUBOIS T_CHAMBRE <TABLE> SELECT False
DURAND DUBOIS T_CHAMBRE <TABLE> INSERT False
DURAND DUBOIS T_CHAMBRE <TABLE> UPDATE False
DURAND DUBOIS T_CHAMBRE <TABLE> DELETE False
DUHAMEL DULAC T_CHAMBRE CHB_POSTE_TEL UPDATE False
DUHAMEL DULAC T_CHAMBRE CHB_COUCHAGE UPDATE False
DUHAMEL DULAC T_CHAMBRE CHB_NUMERO INSERT False
DUHAMEL DULAC T_CHAMBRE CHB_ETAGE INSERT Fals
DUHAMEL DULAC T_CHAMBRE CHB_BAIN INSERT False
DUHAMEL DULAC T_CHAMBRE CHB_DOUCHE INSERT False
DUHAMEL DULAC T_CHAMBRE CHB_WC INSERT False
DUHAMEL DULAC V_CHAMBRE <TABLE> SELECT False

Si vous avez suivi à la lettre tous les exemples d'octroi de privilèges jusqu'à l'exemple 13, alors la requête ci-avant donnera le résultat ci-dessus…

5. Critiques diverses▲
Pour aussi simple qu'il soit, ce système qui révèle quelques pièges est assez complet, mais insatisfaisant.
Voyons quelles en sont les limites…

5-1. Pas de privilèges simultanés sur plusieurs objets▲

Ainsi il n'est pas possible d'octroyer des privilèges à plusieurs objets simultanément :

Exemple 24

Sélectionnez
GRANT INSERT, DELETE
ON TABLE T_CHAMBRE, T_CLIENT, T_PLANNING
FOR DUVAL, DUBOIS

Un tel ordre est syntaxiquement incorrect du fait de la présence de plusieurs tables…

La conséquence est que la gestion fine des droits de cinq utilisateurs sur une base de données comportant une centaine de tables se traduit en au moins une centaine d'ordres à passer…

5-2. Pas de privilèges « négatif »▲

Il n'est pas possible d'appliquer un privilège de déniement à un objet. Cela n'est pas défini par la norme SQL.

Exemple 25

Sélectionnez
DENY DELETE
TO DUVAL, DUBOIS

N'existe pas en SQL. Ce serait pourtant bien pratique de passer par un tel mécanisme…

Nous allons voir cependant que la norme SQL:1999 (SQL 3) propose l'ajout du concept de ROLE afin de pallier certains de ces défauts.

6. SQL:1999 et les rôles▲

SQL:1999 introduit la notion de ROLE déjà présente dans de nombreuses implémentations de SGBDR.

Le but du rôle est de collecter des privilèges sur des objets puis de faire rentrer les utilisateurs dans un rôle ou un autre.

La description des rôles et les extensions des ordres GRANT et REVOKE du fait de l'introduction de nouveaux objets dans les définitions des schémas (procédures stockées, types utilisateur,
méthodes…) seront vues dans les pages spécifiques à la présentation de SQL:1999.

7. Confidentialité des données▲

La confidentialité d'un SGBDR repose sur quatre niveaux :

flux de données : le réseau et les trames qui y circulent ;

inférence : l'environnement du système informatique (OS) ses fichiers, ses utilisateurs, ses programmes ;
cryptage : quel codage et transformation subissent les données ou les fichiers contenant les données ;
contrôle d'accès : comment l'accès au SGBDR est-il géré (par SQL avec GRANT et REVOKE).

Faire l'impasse sur le contrôle d'accès en supposant que la confidentialité est assurée par une bonne gestion des utilisateurs « système » est illusoire. Les exemples dramatiques de pollution de bases
de données avec des virus parce que les techniciens n'ont pas voulu protéger, ne serait-ce que la connexion au serveur par un simple mot de passe sont légion !

D'autant que souvent les développeurs et chefs de projet font un amalgame entre gestion des droits au niveau de la base de données et gestion des droits au niveau applicatif. En outre l'arrivée
d'Internet a obligé l'introduction d'utilisateurs « anonymes ».

Tout cela a favorisé une non-gestion des droits et privilèges qui a fait monter au pilori certains SGBDR mal pensés ou mal utilisés.

La conclusion est simple : il faut gérer les droits à tous les étages de la pyramide. Au moins de manière simpliste.
Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Partager

Copyright © 2003 Frédéric Brouard. Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse
de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.

https://sqlpro.developpez.com/cours/sqlaz/dcl/ 8/9
04/12/2023 22:50
Le Tech Show Paris aura lieu les 15 et
16 novembre 2023, les inscriptions
sont gratuites pour l'évènement dédié
aux professionnels de la Tech en
France
Nous contacter
https://sqlpro.developpez.com/cours/sqlaz/dcl/
Le SQL de A à Z - la gestion des privilèges
5 ans après? 15 experts du stockage
des données se prononcent sur le
MariaDB se débarrasse de ses
DataGrip 2023.2 est disponible : RGPD : le RGPD a-t-il été un succès?
produits et de son personnel dans le
aperçu des améliorations un échec ou quelque chose entre les
cadre d'une restructuration
deux ? Le RGPD a-t-il atteint les
objectifs fixés ?
Contacter le responsable de la rubrique SGBD
Participez Hébergement Publicité / Advertising Informations légales Partenaire : Hébergement Web
© 2000-2023 - www.developpez.com
9/9