Protection contre l’utilisation non autorisée des données
La protection des données (data protection, en anglais) vise à protéger les données contre l’accès et l’utilisation non autorisés. Les mesures de protection englobent des techniques pour identifier une personne de manière unique et gérer les autorisations d'accès aux données, ainsi que des méthodes cryptographiques pour le stockage et la transmission des informations confidentielles.
Protection contre la destruction et la perte des données
À la différence de la protection des données, la notion de sécurité des données (data security, en anglais) concerne les mesures techniques et les solutions logicielles destinées à protéger un système contre la corruption, la destruction ou la perte des données. Au chapitre 4 nous traiterons des méthodes pour sauvegarder et restaurer les bases de données.
Le concept de vue permet de
restreindre une table
Une mesure fondamentale de protection des données consiste en ceci : seules les tables ou parties de tables nécessaires à l'accomplissement de leurs tâches sont mises à la disposition des utilisateurs dûment autorisés. Dans ce but nous créons des vues (views, en anglais) sur les tables. Une vue est définie par la commande SELECT à partir d’une ou de plusieurs tables physiques :
Définir une vue CREATE VIEW nom de la vue AS commande SELECT
Figure 3-12
Définition des vues pour protéger les données
La figure 3-12 donne à titre d'exemple deux vues définies à partir de la table de base PERSONNEL. La vue EMPLOYÉ contient tous les attributs sauf les salaires. Dans la vue GROUPE_D figurent uniquement les employés qui gagnent entre 70’000 et 90’000 francs suisses par année. De manière analogue, nous pouvons créer d'autres vues, par
PERSONNEL
E# Nom Ville Salaire
D6
SELECT E#, Nom, Ville, Affectation
FROM PERSONNEL
CREATE VIEW GROUPE_D AS
SELECT E#, Nom, Salaire, Affectation
FROM PERSONNEL
WHERE Salaire BETWEEN 70'000 AND 90'000 E#
exemple pour mettre les données confidentielles à la disposition des responsables du personnel selon les classes de salaires qu'ils supervisent. Les deux vues dans la figure 3-12 illustrent un important mécanisme de protection des données : d'une part l'accès aux tables peut être personnalisé par groupes d'utilisateurs grâce aux projections sur des attributs déterminés par leurs besoins. D'autre part le contrôle d'accès aux classes de salaires, par exemple, peut se baser sur des valeurs fournies au moment de l'exécution d'une application. Ces valeurs détermineront les vues autorisées grâce à la clause WHERE. La modification des
vues est problématique
Nous interrogeons les vues comme nous le faisons avec les tables. En revanche, la manipulation des vues ne s'exécute pas de manière unique à chaque opération. Lorsqu'une vue résulte, par exemple, de la jointure de plusieurs tables, le système de bases de données rejette toute opération de mise à jour de la vue en question.
Les vues ne sont pas matérialisées
Il est primordial d’éviter une administration redondante de la table de base et de ses différentes vues qui, à cette fin, ne doivent donc pas stocker les données de la table en question. Il s’agit plutôt de créer simplement des définitions de vues. C'est au moment où l'on interroge une vue par la commande SELECT qu’une table résultat sera générée avec des valeurs de données autorisées provenant de la table de base correspondante. Pour cette raison, les deux vues EMPLOYÉ et GROUPE_D sont représentées en hachures dans la figure 3-12.
Gestion des droits de l’utilisateur
Une protection efficace des données ne se limite pas à la seule création des vues pour restreindre les tables. Les fonctions qui opèrent sur les tables doivent aussi être définies par catégories d'utilisateurs. À cette fin, les commandes SQL GRANT et REVOKE permettent de gérer les droits des utilisateurs.
Les privilèges accordés à l'utilisateur par GRANT peuvent lui être retirés par REVOKE :
Attribution et révocation des droits
GRANTprivilege ON relation TO user REVOKEprivilege ON relation FROM user
La commande GRANT met à jour la liste des privilèges pour que l’ayant droit puisse lire, insérer ou supprimer les données dans des
tables ou des vues spécifiques. À l'inverse, la commande REVOKE permet de retirer à l'utilisateur un privilège qui lui a été accordé.
Par exemple, si nous voulons seulement autoriser la lecture de la vueEMPLOYÉ dans la figure 3-12, il faut écrire :
Droit de lecture accordé à tout le monde GRANT SELECT ON EMPLOYE TO PUBLIC
En spécifiant PUBLIC au lieu d'une liste d’utilisateurs, nous accordons le droit de lecture à tous sans aucune restriction. Ce droit leur permet de consulter une partie de la table de base à travers la vue EMPLOYÉ.
Les privilèges peuvent être accordés de manière sélective. Dans l'exemple suivant, le droit de mise à jour de la vue GROUPE_D (figure 3-12) est accordé exclusivement à un responsable du personnel identifié par le numéro d'utilisateur ID37289 :
Droit d’écriture limité
GRANT UPDATE ON GROUPE_D TO ID37289 WITH GRANT OPTION
Transmission des droits L'utilisateur ID37289 peut alors modifier la vue GROUPE_D. En
outre, avec GRANT OPTION, il a la compétence de transmettre ce privilège ou un droit de lecture restreint aux autres utilisateurs, et aussi de les retirer ultérieurement. Ce concept nous permet de définir et de gérer l’interdépendance des droits.
Responsabilité du chargé de la protection des données En mettant à la disposition de l'utilisateur final un langage
relationnel de requête et de manipulation de données, l'administrateur de base de données ne doit pas sous-estimer l'ampleur des tâches administratives pour gérer l’attribution et la révocation des droits, même s'il dispose des commandes GRANT et REVOKE. La pratique montre que d'autres outils de contrôle sont nécessaires pour accomplir efficacement les tâches quotidiennes de mise à jour et de surveillance des droits des utilisateurs. En outre, des autorités de contrôle internes et externes peuvent exiger la mise en œuvre de dispositifs particuliers pour garantir l'utilisation légale des données sous protection (examiner à ce sujet le cahier des charges d'un responsable de la protection des données).
3.8 La formulation des contraintes
L'intégrité d'une base de données est une propriété vitale qui doit être garantie par tout système de gestion de bases de données. Les règles qui doivent être respectées lors de chaque opération d'insertion ou de mise à jour sont appelées contraintes d'intégrité (integrity constraints, en anglais). Il est logique de définir ces contraintes une fois pour toutes au niveau de la base de données, mais pas dans chaque programme. Nous distinguons les contraintes d'intégrité déclaratives et les contraintes d'intégrité procédurales.
Figure 3-13
avenue de la Gare rue Faucigny
E# Nom Rue Ville
D6 ON DELETE RESTRICT )
Définition de la clé primaire Définition de la clé étrangère
Suppression restreinte