La gestion des privilèges

SQLPro

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 » ! ♪

- Titre : La gestion des privilèges

- Auteur : SQLPro

- Parution : 12 novembre 2003

- Licence : Copyright ® 2003 Frédéric Brouard. Aucune reproduction, même partielle, ne peut être faite de ce site et 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.

Sommaire

- 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

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

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

SELECT SYSTEM_USER, SESSION_USER, CURRENT_USER

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 :

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

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

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

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

<privilege d'usage> ::=
USAGE ON <objet d'usage>

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

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

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

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

<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

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

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

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

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

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 :

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 :

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

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

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

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

CREATE VIEW V_CHAMBRE
AS
SELECT CHB_NUMERO, CHB_ETAGE, CHB_BAIN, CHB_DOUCHE, CHB_WC
FROM   T_CHAMBRE

GRANT SELECT
ON V_CHAMBRE
TO DULAC

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

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

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…

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

GRANT SELECT, INSERT, UPDATE, DELETE
ON TABLE T_CHAMBRE
TO DUMONT

GRANT SELECT, INSERT, UPDATE, DELETE
ON TABLE T_PLANNING
TO DUMONT

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 :

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

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 :

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

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

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

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

<privilege d'usage> ::=
USAGE ON <objet d'usage>

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

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

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

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

<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

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

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

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

GRANT SELECT
ON T_CLIENT
TO DUCROS WITH GRANT OPTION

GRANT SELECT
ON T_CLIENT
TO DUGLAND

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

GRANT SELECT
ON T_CLIENT
TO DUGLAND

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

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

GRANT SELECT
ON T_CLIENT
TO PUBLIC

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

TABLE_PRIVILEGES

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

COLUMN_PRIVILEGES

GRANTOR, GRANTEE, TABLE_CATALOG, TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME, PRIVILEGE_TYPE, IS_GRANTABLE

USAGE_PRIVILEGES

GRANTOR, GRANTEE, OBJECT_CATALOG, OBJECT_SCHEMA, OBJECT_NAME,OBJECT_TYPE, PRIVILEGE_TYPE, IS_GRANTABLE

Exemple 23

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

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

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

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.