Sécurité des bases de données
Jacques Le Maitre
Université du Sud Toulon-Var
Ce cours est mis à disposition selon les termes de la licence CreativeCommons
Paternité-Pas d'Utilisation Commerciale-Pas de Modification 2.0 France
p Il s’agit de détecter ou d’empêcher des accès non autorisés.
p C’est crucial :
n dans des environnements critiques ou stratégiques : militaires ou commerciaux, par exemple.
n pour respecter le droit des individus à décider comment et dans quel but les informations les concernant peuvent être extraites, mémorisées ou transmises à d’autres individus.
p Il s’agit de détecter ou d’empêcher des dénis de service.
p Il y a déni de service lorsqu’un utilisateur ne parvient pas à accéder dans un délai raisonnable, à une information ou à une
ressource pour laquelle il a une autorisation d’accès.
p Par exemple, une attaque consistant à saturer un serveur de fausses requêtes empêchant les requêtes valides d’être exécutées.
p Un système de contrôle d’accès comprend :
n des sujets : utilisateurs, processus… qui peuvent être classés par groupes,
n des objets : données, programmes…
n des opérations : lecture, ajout, modification, suppression…, déclenchées par les sujets sur les objets
n un règlement de sécurité constitué d’un ensemble de règles d’accès traduisant la politique de sécurité du système d’information.
n un processeur de sécurité qui vérifie que les requêtes adressées au système ne violent pas les règles d’accès et selon le cas autorise, modifie ou interdit la requête.
p Les ITSEC définissent la politique de sécurité comme l’ensemble des lois règles ou pratiques qui régissent la façon dont l’information sensible et les autres ressources sont gérées, protégées et distribuées à l’intérieur d’un système d’information.
p Ce principe stipule qu’un sujet ne doit disposer que des droits d’accès minimum pour assurer l’exécution des tâches qui lui sont assignées, pas un de plus.
p Ex : ne pas donner les droits de l’administrateur à tout utilisateur d’un système (système d’exploitation, SGBD).
p Les règlements les plus simples ne contiennent que des autorisations :
Ø ce qui n’est pas autorisé est interdit.
p Certains règlements incluent des interdictions afin de spécifier des exceptions à des permissions générales.
n Ex : les patients ont droit de consulter leur dossier médical sauf Jean Dupont.
p D’autres enfin, plus sophistiqués, incluent des obligations :
Ø difficiles à implanter dans les systèmes informatiques.
p On distingue deux grandes catégories de modèles de contrôle d’accès :
n les modèles discrétionnaires :
p Le créateur d’un objet en est son propriétaire et le transfert des privilèges sur ces objets est à sa discrétion.
n les modèles obligatoires :
p Il s’agit de protéger le secret et l’intégrité.
p Les sujets (ou utilisateurs) et objets sont classés par niveaux (ex: Top secret, Secret, Confidentiel, Public).
p L’objectif du contrôle d’inférence est protéger une BD des attaques consistant à déduire des données non autorisées à partir de données autorisées.
p Ex : interdire l’accès à des données individuelles dans une BD statistiques à partir de requêtes agrégatives (comptage, somme, moyenne...).
p Les attaques à une BD peuvent exploiter les failles des applications opérant sur cette BD :
n stockage des mots de passe dans les fichiers de configuration de l’application,
n scripts de connexion à la BD accessibles dans le code source de l’application,
n attaques par injection SQL,
n attaques exploitant les débordements de tampons
...
p On suppose qu’une application récupère le nom username et le mot de passe password saisi, dans un formulaire, par un utilisateur et se connecte à la BD en exécutant la requête affectée à la variable $requete composée par concaténation :
n $requete =
"SELECT *
FROM users
WHERE username = '" & username & "'
AND password = '" & password & "' ;"
p Un outil indispensable pour assurer la sécurité d’une BD est l’audit basé sur un journal des différents types d’accès à la BD :
n audit des entrées dans la base,
n audit des utilisations de la BD en dehors des heures ouvrables,
n audit de la manipulation du schéma,
n audit des erreurs,
n audit des modifications des sources des procédures stockées et des triggers,
n audit des modifications des attributs de sécurité (login, privilèges...) ...
Modèles de contrôle d'accès
p Modèles discrétionnaires à base de matrice d’accès
p Modèle à base de rôles
p Modèles obligatoires
n Modèle de Bell et LaPadula
Ø protection du secret
n Modèle de Biba
Ø protection de l’intégrité
p Les modèles à base de rôle et les modèles obligatoires s’appuient aussi sur une matrice d’accès.
p Chaque objet a un propriétaire (en général, son créateur) qui décide quels sont les autres sujets qui ont accès à cet objet :
Ø d’où le nom de « discrétionnaire »
p Il y a donc décentralisation du contrôle d’accès.
p Ce contrôle peut malgré tout être centralisé en confiant tous les droits à l’administrateur du système.
p Le modèle HRU est basé sur l’utilisation d’une matrice d’accès indiquant les modes d’accès à un objet autorisés pour un sujet.
p Le système est défini par le quadruplet (S, O, R, M) :
n S est l’ensemble des sujets,
n O est l’ensemble des objets, n R est l’ensemble des mode d’accès, n M est la matrice d’accès.
p Le créateur d’un objet reçoit automatiquement own sur cet objet :
Ø il en est le propriétaire.
p Le propriétaire d’un objet peut octroyer/révoquer à un autre sujet n’importe quel autre privilège sur cet objet excepté le privilège own.
p Un sujet ayant un privilège sur un objet sans en être le propriétaire peut transmettre ce privilège.
p Si m est un privilège r, w, a ou x et m* ? M[s, o] est autorisé à octroyer à s le privilège m sur l’objet o.
p Ils sont simples à mettre en œuvre.
p Ce sont les plus implantés : UNIX, SQL…
p Le contrôle de la propagation des droits et celui de la révocation des droits propagés posent des problèmes difficiles.
p Ils sont vulnérables aux chevaux de Troie.
p On peut améliorer les modèles discrétionnaires en créant des rôles qui sont des ensembles d’autorisation.
p Les autorisations sont octroyés aux rôles et les rôles aux utilisateurs.
p Pour pouvoir réaliser une action sur un objet un utilisateur doit ouvrir une session et activer celui de ses rôles qui contient l’autorisation de réaliser cette action.
p Un rôle peut hériter des privilèges d’un autre rôle.
p Les modèles à base de rôles :
n sont bien adaptés aux applications de gestion : un rôle pour chaque fonction dans l’entreprise.
n permettent une administration souple des privilèges.
p Le modèle de Bell et LaPadula a pour objectif la protection du secret des informations.
p Il est basé sur la classification des objets et des sujets par niveaux de secret.
p L’ensemble des niveaux de secret est muni d’un ordre partiel (?). Par exemple :
n Top secret (TS) > Secret (S) > Confidentiel (C) > Non classifié (NC).
p Le système est défini par le 7-uplet (S, O, R, b, M, f, H) :
n S, O, R, M comme dans le modèle HRU,
n b est l’ensemble des accès courants, il est composé de triplets (s, o, m) spécifiant que le sujet s a un accès courant à l’objet o en mode m,
n f est la fonction de niveau qui associe à chaque sujet ou à chaque objet un niveau de sécurité :
p fo(o) est le niveau de sécurité de l’objet o,
p fs(s) est le niveau de sécurité affecté à un sujet lorsqu’il est créé dans le système,
p fc(s) est le niveau de sécurité courant du sujet s, celui avec lequel il entre dans une session (fc(s) ? fs(s)).
n H une classification hiérarchique des objets.
p Les objets sont des éléments passifs du système qui contiennent des informations.
p Chaque objet reçoit un niveau de secret.
p Ce niveau reflète la sensibilité de l’information stockée dans cet objet et donc le problème que poserait la transmission de cette information à un utilisateur non autorisé à la consulter.
p Le niveau de secret d’un objet doit dominer celui de ses parents dans la hiérarchie de classification H.
p Chaque utilisateur reçoit un niveau de secret.
p Ce niveau traduit la confiance faite à un utilisateur de ne pas transmettre une information à un utilisateur ayant un niveau de secret inférieur au niveau de secret de cette information.
p Un utilisateur peut entrer dans le système à tout niveau ? à son niveau de secret.
p Les sujets sont des processus activés par les utiisateurs.
p Les sujets activés par un utilisateur reçoivent le même niveau de secret que celui-ci.
p Règles. Chaque accès courant doit être présent dans la matrice d’accès : un sujet ne peut effectuer que les accès pour lesquels il a les autorisations nécessaires.
p Un état (b, M, f, H) satisfait la propriété sd si, et seulement si, pour chaque (s, o, m) ? b on a m ? M[s, o].
p Règle. Un sujet s peut lire ou écrire une information dans un objet o seulement si le niveau de secret de s est ? au niveau de secret de o.
p Un état (b, M, f, H) satisfait la propriété ss si, et seulement si, pour chaque
(s, o, m) ? b tel que m = r ou m = w on a fS(s) ? fO(o).
p La satisfaction de cette propriété assure qu’un sujet n’accédera pas à une information classée à un niveau plus haut que lui.
p Règles. Un sujet s qui n’est pas de confiance peut :
n ajouter une information dans un objet o seulement si le niveau de sécurité courant de s est ? au niveau de secret de o,
n écrire une information dans un objet o seulement si le niveau de secret courant de s est = au niveau de secret de o,
n lire une information dans un objet o seulement si le niveau de secret courant de s est ? au niveau de secret de o.
p Un état (b, M, f, H) satisfait la propriété * si, et seulement si, pour chaque (s, o, m) ? b tel que s n’est pas un sujet de confiance on a :
n m = a ? fc(s) ? fo(o)
n m = w ? fc(s) = fo(o)
n m = r ? fc(s) ? fo(o)
niveaux de secret = 1 < 2 < 3 < 4 < 5 < 6 < 7 < 8 sujets : Alice et Odile (de confiance), Pierre (non de confiance)
| M | F1 | P | F2 | F3 |
| Alice | r, w | r | ||
| Pierre | r | r | w | |
| Odile | x | a | r |
| F1 | P | F2 | F3 | |
| fO | 4 | 8 | 3 | 1 |
| fS | fC | |
| Alice | 7 | 4 |
| Pierre | 5 | 1 |
| Odile | 6 | 2 |
b = {(Alice, F1, r), (Pierre, F3, w), (Odile, P, x)}
niveaux de secret = 1 < 2 < 3 < 4 < 5 < 6 < 7 < 8 sujets : Alice et Odile (de confiance), Pierre (non de confiance)
| M | F1 | P | F2 | F3 |
| Alice | r, w | r | r | |
| Pierre | r | r | w | |
| Odile | x | r |
| F1 | P | F2 | F3 | |
| fO | 4 | 8 | 3 | 1 |
| fS | fC | |
| Alice | 7 | 4 |
| Pierre | 5 | 3 |
| Odile | 6 | 2 |
b = {(Alice, P, r), (Pierre, F3, w), (Odile, F2, a)}
• l’accès d’Alice à P contrevient à ss
• l’accès de Pierre à F3 contrevient à *
• l’accès d’Odile à F2 contrevient à sd
p Le modèle de Biba (K. J. Biba, 1977) a pour objectif la protection de l’intégrité des informations.
p Il applique à la protection de l’intégrité une stratégie similaire à celle de la protection du secret par le modèle BLP : les sujets et les objets sont classés par niveaux d’intégrité.
p L’ensemble des niveaux d’intégrité est muni d’un ordre partiel (?). Par exemple :
n Crucial (TS) > Très important (TI) > Important (I) > Non classifié (NC)
p Chaque utilisateur reçoit un niveau d’intégrité.
p Ce niveau traduit la confiance faite à un utilisateur pour insérer, modifier ou supprimer de l’information.
p Les sujets activés par un utilisateur reçoivent le même niveau de secret que celui-ci.
p La création des utilisateurs est du ressort de l’administrateur de la base de données qui peut créer :
n des utilisateurs,
n des groupes d’utilisateurs.
p SQL2 ne spécifie pas de commande pour la création des utilisateurs :
Ø cette commande est donc spécifique à chaque SGBD.
n pour pouvoir lire le contenu de toutes ou de certaines colonnes d’une table.
n pour pouvoir insérer une valeur dans toutes ou certaines colonnes d’une table.
n pour pouvoir modifier le contenu de toutes ou de certaines colonnes d’une table.
n pour pouvoir supprimer des lignes d’une table.
p Un utilisateur ne peut révoquer que les privilèges qui lui ont été transmis.
p Si l’option CASCADE est spécifiée, la révocation d’un privilège est récursive.
p Si l’option RESTRICT est spécifiée, la révocation d’un privilège à un utilisateur n’est possible que si celui-ci n’a pas transmis ce privilège à un autre utilisateur.
p Si un utilisateur a reçu un privilège de plusieurs utilisateurs, il ne perd ce privilège que si tous ces utilisateurs le lui retirent.
Pierre
Alice : REVOKE SELECT ON département FROM odile CASCADE
Odile
Alice Alain Isabelle
SELECT
SELECT
ON departement*
ON departement*
Pierre
p Les vues jouent un rôle important car elles permettent de définir de façon précise les portions d’une BD sur lesquelles des privilèges sont accordés.
p Par exemple, si la BD est formée de la table :
n employe(nom, departement, salaire) on pourra restreindre l’accès à l’affectation ou au salaire d’un employé en définissant les deux vues suivantes :
n create view affectation_employe(nom, departement) as select nom, departement from employe n create view salaire_employe(nom, salaire) as select nom, salaire from employe
et en accordant des privilèges sur chacune de ces deux vues, par exemple :
n grant update on salaire_employe to pierre
p On considère une BD décrivant une petite entreprise :
n La BD décrit :
p les employés : nom, salaire, nom du département, p les départements : nom, nom du responsable.
n Les utilisateurs de la BD sont ses employés :
p Alice est l’administratrice de la BD,
p Odile est la directrice du personnel,
p Pierre est l’agent comptable,
p Alain est responsable du département Informatique,
p Isabelle est une employé du département Informatique.
p Alice crée une vue qui cache les salaires des employés :
CREATE VIEW affectation(nom, nom_dept) AS SELECT e.nom, e.nom_dept FROM employe e;
p Alice crée une vue qui donne le nom et le salaire de chaque employé du département dont l’utilisateur de cette vue est le responsable :
CREATE VIEW mon_employe(nom, salaire) AS
SELECT e.nom, e.salaire
FROM employe as e
WHERE e.nom_dept IN
(SELECT nom
FROM departement
WHERE responsable = USER);
p Alice transmet à tous les utilisateurs le privilège de consulter les affectations :
GRANT SELECT ON affectation TO PUBLIC;
p Alice transmet à Alain, responsable du département Informatique, le privilège de consulter le salaire des employés de ce département.
GRANT SELECT ON mon_employe TO alain;
p Alice transmet à Odile, la directrice du personnel, les privilèges de consulter et de modifier le département dans lequel travaille un employé et le responsable d’un département.
GRANT SELECT, UPDATE(nom_dept)
ON employe TO odile;
GRANT SELECT, UPDATE(responsable)
ON departement TO odile;
p Alice transmet à Pierre, l’agent comptable, les privilèges de consulter et de modifier le salaire des employés.
GRANT SELECT, UPDATE(salaire)
ON employe TO pierre;
| SELECT * FROM affectation | UPDATE employe SET salaire = 2000 WHERE nom = 'isabelle' | UPDATE departement SET responsable = 'isabelle' WHERE nom = 'informatique' | |
| alain | acceptée | refusée | refusée |
| alice | acceptée | acceptée | acceptée |
| isabelle | acceptée | refusée | refusée |
| odile | acceptée | acceptée | acceptée |
| pierre | acceptée | acceptée | refusée |
p Les privilèges sur une table ne peuvent pas être restreints à certaines des colonnes de cette table.
p Pour placer un privilège INSERT ou UPDATE sur certaines colonnes d’une table T, il faut :
1. construire une vue de cette table restreinte :
p aux colonnes à mettre à jour,
p aux colonnes permettant de sélectionner les lignes à mettre à jour ;
2. créer une règle ON INSERT ou ON UPDATE, déclenchant les mises à jour sur la table T.
p Le concept d’utilisateur est subsumé par celui de rôle.
p Un rôle est une entité qui peut posséder des objets ou bien des privilèges sur des objets.
p On distingue :
n les rôles de connexion, qui possèdent un login et peuvent se connecter à la BD,
n les rôles de groupe, qui ne possèdent pas de login.
p L’administrateur de la base de données a l’autorisation de créer les tables et de transmettre les privilèges sur ces tables.
p Le secrétaire a l’autorisation de créer et de modifier les informations concernant :
n les étudiants et les enseignants : nom, e-mail, adresse, téléphone, personne à prévenir en cas d’accident…
n les UE : code, responsable, intervenants, intitulé, ECTS…
p Le responsable d’une UE a l’autorisation d’ajouter ou de modifier la note réelle d’un étudiant dans cette UE.
p Le responsable du M2 a l’autorisation de créer ou modifier la note finale d’un étudiant à une UE et au M2. Il dispose de points de jury accordés par les membres du jury (les enseignants) qu’il répartit entre les différentes UE.
p Tous les utilisateurs ont l’autorisation de consulter :
n les informations qui les concernent,
n les noms, prénoms et e-mails des étudiants et des enseignants,
n les informations concernant les UE : code, intitulé, enseignants, ECTS, … n les notes finales.
p Le secrétaire a l’autorisation de consulter les informations personnelles des étudiants et des enseignants (adresse, téléphone, personne à prévenir en cas d’accident…).
p Les étudiants ont l’autorisation de consulter leurs propres notes réelles et leurs points de jury.
p Les enseignants ont l’autorisation de consulter les notes réelles et les points de jury.
p Tout ce qui n’est pas autorisé est interdit !
