You are on page 1of 101

Sécurité dans les SGBD

Olivier Perrin
IUT Nancy-Charlemagne
Département Informatique
Université Nancy 2

Olivier.Perrin@loria.fr
Version 2010
Plan

• Introduction sur la sécurité

• Bases statistiques

• Contrôle d’accès

• Sécurité discrétionnaire

• Sécurité obligatoire

• Architectures des bases de données multi-niveaux

• Contre-mesures

2
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Introduction

• Un SGBD organise les données et donne aux utilisateurs des moyens pour
extraire de l’information

• Cette information est basée sur des données: fonctions statistiques par exemple

• Si l’accès est incontrôlé, on n’y met pas de données sensibles

• Au sens large, la sécurité informatique inclut:


• les problème de confidentialité: prévention de la divulgation non autorisée de
données/d’information
• les problèmes d’intégrité: prévention de modification non autorisée des
données
• les problèmes liés à la disponibilité: prévention de refus d’accès autorisé à des
données

3
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Principes fondamentaux de la sécurité

• Identification/Authentification: qui êtes-vous, pouvez-vous le prouver ?

• Autorisation: pouvez-vous faire cette opération sur cet objet ?

• Intégrité: les données sont protégées contre toute modification accidentelle ou


malveillante

• Confidentialité: les données restent privées et elles ne peuvent pas être vues par
des utilisateurs non autorisés

• Audit: un audit et une journalisation sont essentiels pour résoudre les problèmes
de sécurité a posteriori

• Non-répudiation: le système peut prouver qu’un utilisateur a fait une opération

• Disponibilité: capacité pour des systèmes de rester disponibles pour les


utilisateurs légitimes (ex.: pas de refus de service)

4
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Définitions: menace, vulnérabilité et attaque

• Une menace est un événement potentiel, malveillant ou pas, qui pourrait nuire à
une ressource
• toute opération préjudiciable à vos ressources est une menace

• Une vulnérabilité est une faiblesse qui rend possible une menace
• peut être due à une mauvaise conception,
• à des erreurs de configuration ou
• à des techniques de codage inappropriées et non fiables

• Une attaque est une action qui exploite une vulnérabilité ou exécute une menace
• par ex., envoyer des données d'entrée malveillantes à une application ou
• saturer un réseau en vue d'entraîner un refus de service

5
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Sécurité et SGBDs

• Les budgets autour de la sécurité vont d’abord


• à l'achat de système de sécurité (firewalls, détection d’intrusion,…)
• à la formation
• à la sécurisation des applications
• le SGBD est le parent pauvre de la sécurité

• Complexité
• un SGBD est une affaire de spécialistes:
• au niveau de la gestion (DBA), au niveau de la programmation
• on ne peut pas sérieusement faire de l'Oracle deux fois par an
• quand c'est le cas, c’est encore pire pour la sécurité !

6
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Sécurité et SGBDs (2)

• Rôle du DBA
• maintenir le SGBD, gérer les comptes, les applications, ...
• pas de formation sécurité : ne peut pas « imaginer » les attaques possibles

• Mises à jour des systèmes


• 80% des serveurs de BD meurent avec le système et le SGBD initial
• « If it works, don't fix it ! »
• conséquence: failles système et applicatives qui ne sont JAMAIS corrigées

• Criticité des applications


• arrêts impossibles
• la sécurité passe en dernier

7
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Quelles sont les informations visées ?

• Dans un SGBD, qu’est-ce qui intéresse l’adversaire ?


• contenu exact: salaire d’un employé
• bornes: salaire > 2000€
• résultat négatif: nombre d’infractions n’est pas égal à 0
• existence: casier judiciaire
• valeur probable: inférence en combinant plusieurs attaques

• On doit appliquer les mesures de sécurité avec précision


• protéger les informations sensibles
• laisser libre accès aux informations non sensibles

8
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Les risques

• Attaques sur le SGBD lui même


• failles connues classiques (buffer overflows, bugs d'authentification,…)
• failles dans les applications associées: serveurs Web d'administration, démons
SNMP (Simple Network Management Protocol), programmes setuid root
installés par le SGBD,…

• Mauvaises configurations
• modes d'authentification dégradés (par exemple, fichiers .rhosts)
• mots de passe par défaut
• fichiers de la BD non sécurisés (lecture par tous)

• Interception de mots de passe


• par écoute du réseau
• par lecture de fichiers de configuration sur disque
9
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Les risques (2)

• Attaques sur les applicatifs


• injection SQL sur les applications Web (cf. démo)
• détournement des requêtes effectuées par un ERP
• autorisations trop larges

• Attaques sur l'OS via le SGBD


• écriture/lecture de fichiers, exécution de commandes
• la base de données tourne avec des privilèges différents
• contournement de la politique de sécurité: 'safe_mode' de PHP par ex.
• critique chez les hébergeurs Web mutualisés

10
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Quelques exemples: MS-SQL Server

• Produit complexe
• tourne avec les droits LocalSystem

• Deux modes d’authentification


• NT Only: authentification sur le domaine NT/2000
• Mixed-mode: idem + comptes internes (potentiellement, tous les utilisateurs du
domaine ont accès au serveur)

• Jusqu’à SQL2000, compte SA sans mot de passe par défaut à la création !

• Ver SQLSlammer: buffer overflow, déni de service réseau, heap overflow

• Problème dans l'authentification (août 2002)


• débordement de buffer: http://www.securityfocus.com/bid/5411

11
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Quelques exemples: MS-SQL Server (2)

• Passage du mot de passe en clair pour les logins non NT


• simple XOR avec 0xA5

• Débordement de buffer/tas dans les procédures externes


• un seul octet à écraser et le système de privilèges est ignoré

• Procédures dangereuses
• xp_readerrorlog : lecture de fichiers
• xp_regread : lecture du registry

• SQL Agent Job : submission de jobs, permet de monter les privilèges

12
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Quelques exemples: MySQL

• SGBD "Light" et facile à mettre en place


• très très utilisé dans les « petits » sites
• système de privilèges mais fonctions manquantes (vues notamment)

• 2000 : gros problème d'authentification


• dans la phase d'authentification, le serveur ne vérifie que le nombre de
caractères envoyés par le client : avec 32 essais il est possible de
compromettre n'importe quel compte
• resurgit en 2002 dans COM_CHANGE_USER (changement d'identité)

The flaw lies in the fact that the server uses a string returned by the client when the
COM_CHANGE_USER command is issued to iterate through a comparison when attempting to
authenticate the password. An attacker may authenticate as another database user if they can
successfully guess the first character of the correct password for that user. The range of the valid
character set for passwords is 32 characters, which means that a malicious user can authenticate
after a maximum of 32 attempts if they cycle through all of the valid characters.

13
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Quelques exemples: MySQL (2)

• 2001: Buffer Overflow dans SELECT

• Plusieurs corruptions de mémoire dans certaines fonctions

• Lecture du fichier de configuration dans $DATADIR/my.cnf


• tous les utilisateurs ayant le privilège 'FILE' peuvent écrire dans ce répertoire

14
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Quelques exemples: injection SQL avec PHP

• Les applications Web produisent des formulaires

• L’utilisateur remplit les champs du formulaire

• Une application traite ces informations

• Évidemment, l’utilisateur est honnête, c’est sûr !

15
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Quelques exemples: injection SQL avec PHP (2)

• Sauf que…
• le monde n’est pas parfait
• les programmes peuvent recevoir n’importe quoi

• Beaucoup d’applications web utilisent désormais une base de données


• les requêtes sur la base utilisent des informations issues de l’internaute
• il faut valider ces informations avant de les utiliser, sinon…

16
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Quelques exemples: injection SQL avec PHP (3)

• Injection
• consiste à concaténer une chaîne de caractères pour créer une instruction
SQL

• Objectifs
• usurper une identité: récupérer un mot de passe, se connecter sans mot de
passe
• contourner des règles de gestion: obtenir des informations auxquelles on ne
devrait pas avoir accès
• altérer des données de la base de données: modifier ou supprimer des
données

• Circonstance aggravante: afficher les erreurs SQL

17
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Quelques exemples: injection SQL avec PHP (4)

• Premier exemple ([Wikipédia])


• SELECT uid FROM … WHERE nom = '(nom)' AND mdp = '(mdp)';
• dans le formulaire
• Utilisateur: Dupont' --
• Mot de passe: n’importe quoi
• la requête devient : SELECT uid WHERE nom = 'Dupont' -- ' AND ...;
• équivalent à : SELECT uid WHERE nom = 'Dupont';
• connecté !

• Solution: mysql_real_escape_string()
• ' -- sera transformé en \' --

18
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Quelques exemples: injection SQL avec PHP (5)

• Exemple moins simple: formulaire d’authentification


• $sql = "SELECT login, pass FROM users WHERE login = '".$_POST["login"]."'
AND pass = '".$_POST["pass"]."'";
• vulnérabilité à cause de $_POST[“rech”]
• si on rentre a' OR 'a' = 'a, on obtient:
• $sql = "SELECT login, pass FROM users WHERE login = 'a' OR 'a'='a' AND
pass = 'a' or 'a'='a'";
• on se connecte sans connaître l’utilisateur ni le mot de passe

19
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Quelques exemples: injection SQL avec PHP (6)

• Obtenir un mote de passe


• reprenons la recherche d’articles
• $sql = "SELECT id_article, titre, contenu FROM articles WHERE titre LIKE '%".
$_POST["rech"]."%' OR contenu LIKE '%".$_POST["rech"]."%'";
• valeur saisie: ' UNION all select id_article, pass as titre, login AS contenu
FROM users,articles #
• on obtient: $sql = "SELECT id_article, titre, contenu FROM articles WHERE
titre LIKE '%' UNION all select id_article, pass as titre, login AS contenu FROM
users,articles #%' OR contenu LIKE '%' UNION all select id_article, pass AS
titre, login AS contenu FROM users,articles #%'";
• on obtient:
mdpalc
admin

20
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Attaque ([Bonnetain])

• Contenu d’une FAQ


• URL: http://site.org/pgm.php?id=36&PHPSESSID=456734
• résultat

• réfléchissons
• la valeur de l’identifiant sert à interroger une base de données
• c’est un numérique (36 dans l’exemple)
• utilisons un identifiant non valide

21
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Attaque (2)

• URL: http://site.org/pgm.php?id=
• résultat

• bilan
• la base de données est PostgreSQL
• on connaît les chemins d’installation
• on sait qu’il ne semble pas y avoir de validation !
• quelque fois, on a carrément accès à la requête

22
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Attaque (3)

• Composition de la requête
• le script PHP interroge la base en transmettant directement la valeur du champ
ID
• sans doute une requête du type SELECT … FROM … WHERE id = valeur AND

• on ne veut pas être gêné par la partie AND
• on ajoute -- (le reste de la ligne devient un commentaire)
• SELECT … FROM … WHERE id = 10 -- AND …
• on ne peut pas éliminer les clauses qui précèdent
• ça marche !

23
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Attaque (4)

• Réfléchissons !
• il y a un SELECT qui renvoie des informations
• pour extraire ces informations, on doit utiliser la sélection
• la commande UNION va nous aider
• SELECT … UNION SELECT …
• la sémantique de la clause UNION est stricte
• même nombre d’attributs
• mêmes types
• on doit déterminer le nombre d’attributs et le type des attributs du SELECT

24
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Attaque (5)

• Tant que l’on n’a pas le bon nombre d’attributs, PostgreSQL renvoie une erreur

• Il faut donc chercher par essai/erreur

• pgm.php?id=10 UNION SELECT 1--

• URL: http://site.org/pgm.php?id=10%20union%20select%201--

25
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Attaque (6)

• Après quelques requêtes, on obtient le bon nombre d’arguments (le message


d’erreur change)

• id=10 union SELECT 1,1,1,1,1,1,1 --

26
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Attaque (7)

• On procède de même pour le type des champs, et on s’arrête quand le message


change
• id=10 union true,1,1,1,1,1,1 --

• le premier champ est un int4 !

• On finit par trouver int4,text,text,int4,int2,date,int4

27
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Attaque (8)

• On peut extraire ce que l’on veut maintenant

• Il faut connaître les tables

• Dans PostgreSQL
• pg_database pour obtenir les bases de données (datname donne le nom de
la base)
• pg_shadow pour obtenir la table des utilisateurs (usename et passwd donne
l’identification des utilisateurs)

• Ainsi
• liste des bases de données:

id=10 union select 1,datname,text(100),10,1,date(1),1 from pg_database --

28
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Attaque (9)

• Ou
• utilisateurs et mot de passe:

id =10 union select 1,usename,passwd,10,1,date(1),1 from pg_shadow --

• en plus, on constate que les utilisateurs n’ont pas de mot de passe !

• On peut aller plus loin: insertion de données, suppression, injection de code


javascript,…

29
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Démo

30
Plan

• Introduction sur la sécurité

• Bases statistiques

• Contrôle d’accès

• Sécurité discrétionnaire

• Sécurité obligatoire

• Architectures des bases de données multi-niveaux

• Contre-mesures

31
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Les bases statistiques

• Une BD statistique permet de faire des requêtes statistiques sur des groupes de
n-uplets

• Ces opérations sont:


• COUNT: nombre de valeurs dans une colonne
• SUM: somme des valeurs dans une colonne
• AVG: moyenne des valeurs dans une colonne
• MAX: maximum des valeurs dans une colonne
• MIN: minimum des valeurs dans une colonne

• Dans une requête statistique, il y a un prédicat à satisfaire et l'opération se fait sur


les n-uplets qui satisfont ce prédicat

32
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Les bases statistiques (2)

• Les BD statistiques posent le problème de sécurité suivant:


• ces BD contiennent des données qui sont sensibles individuellement
➡ l'accès direct à ces données n'est donc pas permis
• les requêtes statistiques statistiques sont permises
➡ mais elles doivent lire chaque donnée individuellement

• Propriété d'agrégation
• le niveau de sensibilité d'une opération calculée sur un groupe de valeurs est
bien souvent inférieur au niveau de sensibilité des valeurs individuelles

• Problème d'inférence
• dans un tel cadre, il devient possible d'inférer de l'information sensible à partir
de résultats statistiques moins sensibles

33
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Les bases statistiques (3)

• Les attaques sur les BD statistiques sont de plusieurs types:


• attaque directe: opération sur un très petit échantillon
• attaque indirecte: combine le résultat de plusieurs opérations
• attaque par pisteur: une attaque indirecte redoutable
• attaque par système linéaire d'équations

• On peut résister aux attaques directes en forçant la taille de l'échantillon à être


plus grand qu'un seuil
• il faut aussi forcer la taille du complément de l'échantillon

34
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Les bases statistiques (4)

• Attaque par pisteur


• on doit d'abord identifier un pisteur général, un critère qui découpe la relation
BD relationnelles
en 2 ensembles qui sont chacun plus grands que le seuil d'attaque directe (ex:
3)
• Une BD relationnelle est une BD qui est perçue par ses
• ex: dans la relation Étudiants,
usagers 'Prog = DESS'
comme est un tel critère
un collection de tables.
• Ex: comment connaître •la moyenne
Exemple:de Bob en 3 requêtes ?
Relation Étudiants Relation Notes
Nom Sexe Prog Moyenne Nom Cours Note
Alice F DESS 65 Alice IFT6271 75
Bob M M.Sc. 80 Bob IFT1010 80
Carole F POLY 70 Bob IFT1212
Diane F DESS 90 Diane IFT6271 95
Éric M POLY 85
Frank M DESS 70
35
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Les bases statistiques (5) BD relationnell


• Une BD relationnelle est une BD qui e
usagers comme un collection de tables.
• Comment procéder ?
• Exemple:
• R1: Moyenne de ((étudiants de DESS) ou Bob): Relation Étudiants Rela
• moyenne d'Alice, Bob, Diane et Frank = 76,25 Nom Sexe Prog Moyenne Nom
Alice F DESS 65 Alice I
• R2: Moyenne de (étudiants pas de DESS) ou Bob): Bob M M.Sc. 80 Bob I
Carole F POLY 70 Bob I
• moyenne de Bob, Carole et Éric = 78,33 Diane F DESS 90 Diane I
Éric M POLY 85
• R3: Moyenne de tous les étudiants = 76,67
Frank M DESS 70

• Moyenne de Bob: 4 x R1 + 3 x R2 - 6 x R3 = 80

• Pourquoi ? IFT-6271

• cela correspond aux sommes de moyenne: (Alice+Bob+Diane+Frank)+(Bob


+Carole+Éric)-(Alice+Bob+Carole+Diane+Éric+Frank) = Bob

• Dans presque toutes les BD statistiques, il existe un pisteur général

36
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Les bases statistiques (5) BD relationnell


• Une BD relationnelle est une BD qui e
usagers comme un collection de tables.
• Comment procéder ?
• Exemple:
• R1: Moyenne de ((étudiants de DESS) ou Bob): Relation Étudiants Rela
• moyenne d'Alice, Bob, Diane et Frank = 76,25 Nom Sexe Prog Moyenne Nom
Alice F DESS 65 Alice I
• R2: Moyenne de (étudiants pas de DESS) ou Bob): Bob M M.Sc. 80 Bob I
Carole F POLY 70 Bob I
• moyenne de Bob, Carole et Éric = 78,33 Diane F DESS 90 Diane I
Éric M POLY 85
• R3: Moyenne de tous les étudiants = 76,67
Frank M DESS 70

• Moyenne de Bob: 4 x R1 + 3 x R2 - 6 x R3 = 80

• Pourquoi ? IFT-6271

• cela correspond aux sommes de moyenne: (Alice+Bob+Diane+Frank)+(Bob


+Carole+Éric)-(Alice+Bob+Carole+Diane+Éric+Frank) = Bob

• Dans presque toutes les BD statistiques, il existe un pisteur général

36
Plan

• Introduction sur la sécurité

• Bases statistiques

• Contrôle d’accès

• Sécurité discrétionnaire

• Sécurité obligatoire

• Architectures des bases de données multi-niveaux

• Contre-mesures

37
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Contrôle d’accès et SGBD

• Deux niveaux d’accès à un SGBD


• manipulation des données sur les relations de la base: protection sur les
entrées de la base
• opérations composées comme des vues: restriction de ce que l’utilisateur peut
faire sur la base

• Une politique de sécurité doit viser deux propriétés


• complétude: tous les attributs sont protégés, même si la protection indique
accès libre
• cohérence: pas de conflit entre les différentes règles de sécurité

38
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Contrôle d’accès et SGBD (2)

• Modèle de sécurité SQL: utilisateurs, opérations SQL, objets (tables, vues,


attributs)

• À la création d’un objet, son propriétaire a tous les droits, y compris celui
d’accorder ou de révoquer des privilèges à d’autres utilisateurs

• Un privilège est composé des éléments suivants


• utilisateur qui accorde le privilège
• utilisateur qui reçoit le privilège
• objet
• action permise
• transmission possible du privilège

39
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Contrôle d’accès et SGBD (3)

• Exemple
• si Alice est propriétaire de la relation R, elle peut accorder le privilège de la
consulter (SELECT) à Bob
• si elle indique que ce privilège est transmissible, Bob pourra à son tour
accorder ce privilège à un autre utilisateur
• si Alice révoque le privilège à Bob, alors Bob et tous ceux qui ont reçu ce
privilège de Bob perdent l’accès à la relation R

40
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Contrôle d’accès en pratique

• Trois modèles classiques pour le contrôle d’accès:


• Harrisson, Ruzzo, Ullman: matrice (objets, sujets, droits)
• Bell-LaPadula
• orienté confidentialité
• utilisé par les militaires
• Biba
• orienté intégrité
• utilisé dans les transactions financières
• En pratique
• contrôle d’accès discrétionnaire (Discretionary access control (DAC))
• contrôle d’accès obligatoire (Mandatory access control (MAC))
• contrôle d’accès basé sur les rôles (Role-based access control (RBAC))

41
Plan

• Introduction sur la sécurité

• Bases statistiques

• Contrôle d’accès

• Sécurité discrétionnaire

• Sécurité obligatoire

• Architectures des bases de données multi-niveaux

• Contre-mesures

42
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Sécurité discrétionnaire

• Principe
• restreindre l’accès aux informations en se basant sur l’identité des utilisateurs
et leur groupe d’appartenance
• discrétionnaire: à la discrétion du propriétaire !

• Accès: lecture, écriture, exécution

• Possession: propriétaire, groupe, autres

• Exemple: Unix
• -rw-r----- 1 olivier ens 67991 20 mar 13:25 partielS4

43
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Sécurité discrétionnaire (2)

• SQL gère les contrôles d’accès discrétionnaires

• Deux mécanismes
• les vues: permet de cacher des informations sensibles à des utilisateurs non
autorisés (notion de groupe)
• sous-système d’autorisation: permet aux utilisateurs ayant des privilèges
d’attribuer sélectivement et dynamiquement ces privilèges à d’autres
utilisateurs (et de les révoquer)

44
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Sécurité discrétionnaire (3)

• Contrôle d'accès discrétionnaire


• par des vues et le contrôle d'accès sur ces vues
• l'accès aux données seulement par des vues rappelle le modèle formel de
Clark-Wilson
• comment donner accès à un utilisateur l'accès à une vue sans avoir à lui
donner l'accès à toutes les relations sous-jacentes?
• par l'introduction d'un mode de référence
• ce mode est protégé par un privilège (comme les requêtes SQL)
• l’utilisateur n'a donc besoin que du privilège de voir la vue et de celui du
mode référence sur les relations sous-jacentes à cette vue

45
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Vues

• Les vues ont plusieurs avantages


• elles sont flexibles et permettent de définir des critères qui sont très proches de
ce que les applications ont besoin
• elles permettent de définir des politiques de sécurité qui dépendent des
données et des contextes d'opérations
• elles forment une sorte d'invocation contrôlée
• une vue sécure peut remplacer une étiquette de sécurité
• les données peuvent facilement être reclassées

46
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Vues (2)

• Supposons une relation Employé qui indique s’il s’agit d’un homme ou d’une
femme, son âge, son salaire et sa profession

• On définit la vue suivante

CREATE VIEW Emp_Programmeur AS


SELECT Nom, H/F, Profession
FROM Employe
WHERE Employe.Profession = "Programmeur" ;

47
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Vues (3)

• Permet de diviser conceptuellement la base de données en plusieurs parties

• Les informations sensibles peuvent être cachées aux utilisateurs non autorisés

• Ne permet pas de spécifier les opérations que certains utilisateurs sont autorisés à
exécuter sur ces parties de la base

• Cette fonction est réalisée par l'instruction GRANT (cf. Privilèges)

GRANT SELECT, DELETE


ON Emp_Programmeur
TO Jean, Paul, Marie ;

48
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Vues (4)

• Si l'application inclut une relation décrivant une table de contrôle d'accès, les vues
peuvent y faire référence

• Pour qu'une vue permette la mise à jour, il faut que tous les attributs formant la clé
primaire soient inclus dans la vue:
• de plus, il se peut que la mise à jour fasse en sorte que le n-uplet modifié ne
satisfasse plus aux critères de la vue
• ex: dans la vue DESS, une requête pour modifier le programme à POLY
ferait disparaître l’attribut de la vue
• une option dans la définition de la vue permet de bloquer ces écritures à
l'aveugle

49
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Vues (5)

• Une vue n'est pas qu'un objet. On peut aussi le considérer comme un sujet qui a
ses propres privilèges d'accès: invocation contrôlée

• Désavantages des vues


• la vérification des conditions d'accès peut devenir lourde et lente
• il faut vérifier que l'ensemble des définition de vues capture complètement la
politique de sécurité voulue
• certaines vues peuvent se superposer: incohérences dans les accès
• la partie sécuritaire du SGBD devient très grosse
• il faudra peut-être compléter la définition par l'ajout de procédures stockées
sur le serveur de BD

50
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Les privilèges

• Le créateur d'un objet obtient automatiquement tous les privilèges pour cet objet

• Par exemple, le créateur d'une relation T obtient automatiquement tous les


privilèges sur T

• En outre, ces privilèges sont obtenus avec l'option « grant authority » (le privilège
peut être donné à un autre utilisateur)

• Voici la syntaxe complète de l'instruction GRANT :

GRANT <liste privileges>


ON <objet>
TO <liste ID utilisateur>[WITH GRANT OPTION];

51
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Les privilèges (2)

• Si Bob donne un privilège à Alice, Bob peut ensuite révoquer ce privilège accordé
à Alice

• On utilise l'instruction REVOKE dont voici la syntaxe :

REVOKE [ GRANT OPTION FOR ] <liste privileges>


ON <objet>
FROM <liste ID utilisateur>
<option> ;

• GRANT OPTION FOR signifie que seul le droit de transfert doit être révoqué

• <liste privileges>, <objet> et <liste ID utilisateur> sont similaires à l'instruction


GRANT

• <option> est égal à RESTRICT ou bien CASCADE

52
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Les privilèges (3)

• RESTRICT vs. CASCADE


• supposons que p soit un privilège sur un objet et que l'utilisateur Bob accorde
p à l'utilisateur Alice, qui à son tour l'accorde à l'utilisateur Charlie
• que se passe-t-il maintenant si Bob révoque p à Alice?
• le privilège p détenu par Charlie doit être « abandonné » car il provient de
l'utilisateur Alice qui ne le détient plus

• L'objectif de l'option RESTRICT vs. CASCADE est d'éviter l'abandon de privilèges


• l'option RESTRICT a pour conséquence que le REVOKE échoue s'il conduit à
l'abandon de privilèges
• CASCADE a pour conséquence que de tels privilèges sont également
révoqués

53
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Sécurité discrétionnaire

• Avantages
• simple à comprendre
• très flexible

• Inconvénients
• suppose que les utilisateurs savent ce qu’ils font (chevaux de Troie)
• délicat/difficile de représenter certaines politiques
• exemple: partage de document

54
Plan

• Introduction sur la sécurité

• Bases statistiques

• Contrôle d’accès

• Sécurité discrétionnaire

• Sécurité obligatoire

• Architectures des bases de données multi-niveaux

• Contre-mesures

55
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Sécurité obligatoire

• Également appelée sécurité multi-niveaux

• Principe: dans une politique de sécurité multi-niveaux:


• les utilisateurs reçoivent un niveau d’habilitation
• les informations reçoivent un niveau de classification
• comparaison niveau de classification/d’habilitation

• Niveaux dans un ensemble partiellement ordonné


• Très secret > Secret > Confidentiel > Public

56
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

SGBD et sécurité multi-niveaux

• Comment obtenir un niveau élevé de protection sur les éléments d'un SGBD?
• contrôle d'accès obligatoire (étiquettes de sécurité)
• les principaux vendeurs de SGBD (Oracle, Informix, Sybase) ont tous une
version MAC de leur système, évaluée au niveau B1 du Livre Orange

• Modèle simplifié de Bell-La Padula


• soit S, un ensemble d’utilisateurs du système du SGBD
• soit O, un ensemble d'objets (ex: tables, relations, n-uplets, ...)
• une relation ≤ d'ordre partiel sur les étiquettes L, aussi appelées classes
d'accès
• soit fs : S → L et fo : O → L, assignant respectivement des classes d'accès aux
utilisateurs et aux objets

57
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

BD et sécurité multi-niveaux (2)

• Règle de simple sécurité (ss):


• un sujet s peut lire un objet o seulement si sa classe d'accès domine celle de
l'objet, c'est-à-dire fo(o) ≤ fs(s)

• Règle “étoile” (*-property):


• un sujet s peut modifier un objet o seulement si sa classe d'accès est dominée
par celle de l'objet, c'est-à-dire fs(s) ≤ fo(o)

• Ces politiques s'appliquent aux manipulations sur le SGBD et s'adressent aux


flots d'information directs

• L'information peut aussi s'échapper par des canaux cachés


• refuser l'accès à une requête donne de l'information à un utilisateur s'il ne
savait pas déjà que la requête allait échouer...

58
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Mise en œuvre d’une politique

• Dans un SGBD, la mise en œuvre d’une politique de sécurité multi-niveaux peut


poser plusieurs problèmes:
• granularité de classification
• gestion des leurres
• inférence d’information

59
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Granularité de la classification

• Quel est le grain d’information qui reçoit la classification ?

• Possibilités: schéma, relation, n-uplet, attribut de n-uplet

• Interprétation de la granularité n-uplet


• si on attribue un niveau de classification n à un n-uplet, l’information
représentée par le n-uplet est de niveau n
• soit Employe(Dupont, H, 30, 30 000, programmeur) un n-uplet avec le niveau
de classification Secret
• l’information «Dupont est un employé masculin ayant 30 ans, gagnant 30 000
euros et travaillant comme programmeur» est classée au niveau Secret
• pas très fin, pourquoi ?

60
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Granularité de la classification (2)

• Dupont est un employé

• Dupont est un homme

• Dupont a 30 ans

• Dupont gagne 30000 euros

• Dupont est programmeur

• Toutes ces informations sont au même niveau

• Gestion par le SGBD:


• ajout d’un attribut TC (Tuple-Class) qui décrit le niveau
• Employé(Nom, H/F, Age, Salaire, Profession, TC)

61
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Granularité de la classification (3)

• Interprétation de la granularité attribut de n-uplet

• Employé(Nom, P, H, P, Age, C, Salaire, S, Profession, C)

• Interprétation
• si on affecte un niveau de classification ni à l’attribut Ai d’un n-uplet t, alors ni
représente la classification de l’information correspondant à l’association entre
les attributs Ak et Ai où Ak est la clé de la relation
• exemple: Employé(Dupont, P, H, P, Age, C, Salaire, S, Profession, C)
• l’information «Dupont est un employé» est classée au niveau P
• l’information «Dupont gagne 30000 euros» est classée au niveau S

62
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Étiquetage des objets

• Chaque élément de la BD reçoit une étiquette: attribut, n-uplet, relation ou BD


• un n-uplet pourrait contenir des attributs ayant des étiquettes différentes
• ces étiquettes ne sont pas visibles aux utilisateurs

• L'étiquette a un rôle différent à chaque niveau:


• BD: l'utilisateur peut-il accéder aux relations de la BD?
• relation: l'utilisateur peut-il accéder aux n-uplets de la relation?
• n-uplet: l'utilisateur peut-il accéder aux attributs du n-uplet?
• attribut: l'utilisateur peut-il accéder à cet attribut en particulier?

• Le schéma d'étiquetage devra être complet et cohérent


• complet signifie que chaque élément a son étiquette
• cohérent signifie que les étiquettes n'entrent pas en conflit
63
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Étiquetage des objets (2)


Étiquetage des objets (2)
• Exemple
• Exemple
• la relation Réservations [P]
– La relation Réservations [P]
• les lettres entre crochets indique la classe d'accès
– Les lettres entre crochets indique la classe d'accès
• C = Confidentiel, P = Public
• C = Confidentiel, P = Public
• pour chaque attribut, la classe d'accès suit la valeur de l’attribut
– Pour chaque champ, la classe d'accès suit la valeur du champ.
• pour chaque n-uplet, la classe d'accès est à droite du n-uplet
– Pour chaque tuple, la classe d'accès est à droite du tuple.
Vols Dest Sièges
AC909 [C] Montréal [C] 4 [C] [C]
AA334 [P] Chicago [P] 10 [P] [P]
AF211 [P] Paris [C] 7 [C] [C]

64
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Étiquetage des objets (3)

• Pour qu'un utilisateur puisse observer les attributs d'un n-uplet, il faudra que:
• la classe d'accès de chaque attribut domine celle du n-uplet,
• la classe d'accès du n-uplet domine celle de sa relation,
• la classe d'accès de la relation domine celle de la BD

• Règle d'intégrité des entités (multi-niveaux)


• aucune composante de la clé primaire d'une relation de base ne peut être nulle
• toutes les composantes de la clé primaire d'une relation de base ont la même
classe d'accès
• les classes d'accès de tous les autres attributs du n-uplet dominent la classe
d'accès de la clé primaire

65
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Étiquetage des objets (4)

• Règle d'intégrité référentielle (multi-niveaux)


• le n-uplet référencé par une clé étrangère doit exister
• la classe d'accès de la clé étrangère domine celle de la clé primaire
correspondante

• Données visibles
• une relation R est visible à un utilisateur s si la classe d'accès de l’utilisateur
domine celle de la relation (fo(R) ≤ fs(s))
• un attribut ri est visible à un utilisateur s si la classe d'accès de l’utilisateur
domine celle de l’attribut (fo(ri) ≤ fs(s)). Dans le cas contraire,
• si l’attribut ri fait partie de la clé primaire, tout le n-uplet est invisible
• sinon, seul l’attribut est invisible à l’utilisateur

66
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Étiquetage des objets (5)

• Relations dérivées
• la classe d'accès d'une vue domine celles de toutes les relations utilisées dans
la définition de la vue
• l'instance d'une vue à une classe d'accès donnée correspond au résultat de
l'évaluation de la définition de la vue à cette classe.

67
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Polyinstanciation

• Dans un SGBD multi-niveaux, un utilisateur 'bas' ne peut connaître l'existence de


données 'hautes'. Polyinstantiation (3)
• il pourrait être tenter de mettre à jour un attribut contenant une donnée 'haute'
• Exemple de polyinstantiation
• ex: pour le
– 'Vol
Sur =leAF211',
tuple 'Volil =
veut changer 'Dest = Nice' et 'Sièges = 0'
AF211'
– Après mise à jour 'Dest = Nice' [P] et 'Sièges = 0' [P]

Vols Dest Sièges


AC909 [C] Montréal [C] 4 [C] [C]
AA334 [P] Chicago [P] 10 [P] [P]
AF211 [P] Paris [C] 7 [C] [C]
AF211 [P] Paris [C] 0 [P] [C]
AF211 [P] Nice [P] 7 [C] [C]
AF211 [P] Nice [P] 0 [P] [P]

68
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Polyinstanciation (2)

• Comment la BD doit-elle réagir?


• interdire la mise à jour
➡ canal caché !
• remplacer les anciennes valeurs par les nouvelles
➡ perte de l'information qui était mise en place par un utilisateur 'haut'
• effectuer la mise à jour tout en conservant l'ancienne valeur !
➡ polyinstanciation

69
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Polyinstanciation (3)

• On insère le n-uplet

• Ceci donne plusieurs n-uplets avec la même clé primaire !


• extension de la notion de clé primaire: ajout de la classe d'accès de chaque
attribut du n-uplet
• cette définition nous donne de nouveau une clé primaire unique

• Règle d'intégrité de la polyinstanciation


• si 2 n-uplets d'une relation de base ont la même clé primaire et qu'un des
attributs a la même classe d'accès dans les 2 n-uplets, alors la valeur de
l’attribut sera la même dans les 2 n-uplets
• si 2 n-uplets d'une relation de base ont la même clé primaire et que, pour un
des attributs, les classes d'accès diffèrent, alors la valeur de l’attribut pourra
être différente entre les 2 n-uplets

70
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Polyinstanciation (4)
Polyinstantiation (3)
• Exemple de polyinstanciation
• Exemple de polyinstantiation
• sur le–n-uplet
Sur le'Vol = AF211'
tuple 'Vol = AF211'
• après–mise à jour
Après 'Dest
mise = Nice'
à jour [P]=etNice'
'Dest 'Sièges
[P] =et0''Sièges
[P] = 0' [P]

Vols Dest Sièges


AC909 [C] Montréal [C] 4 [C] [C]
AA334 [P] Chicago [P] 10 [P] [P]
AF211 [P] Paris [C] 7 [C] [C]
AF211 [P] Paris [C] 0 [P] [C]
AF211 [P] Nice [P] 7 [C] [C]
AF211 [P] Nice [P] 0 [P] [P]

71
IFT-6271 460
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Polyinstanciation: discussion

• Une BD représente normalement des faits réels


• la polyinstanciation introduit une ambiguïté autour de ces faits, puisqu'il existe
plusieurs entrées pour la même entité externe
• à quel point est-il nécessaire de protéger un objet de haut niveau par un objet
de plus bas niveau et une fausse histoire ?

• Ces problèmes découlent d'une décision de camoufler l'existence d'objets


confidentiels
• on peut concevoir un SGBD multi-niveaux où tous les objets sont visibles, mais
dont le contenu est protégé par les classes d'accès
• même les étiquettes de sécurité sur les objets sont visibles
• dans ce cas, la révélation de l'existence d'un objet ne constitue pas un flot
d'information illégal (canal caché)

72
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Polyinstanciation: discussion (2)

• Reprenons l'exemple qui nous a amené à parler de polyinstanciation


• pour 'Vol = AF211', il pourrait vouloir changer 'Dest = Nice' et 'Sièges = 0'
• dans ce cas, on peut maintenant indiquer sans danger à l’utilisateur que la
requête est refusée

• Il reste un problème:
• comment ajouter des données à une relation sans violer la règle étoile ?
• en déléguant la création d'objet à un utilisateur spécial CRÉATEUR, dont la
classe d'accès correspond au bas du système
• des données bidon sont écrites dans l'objet
• la classe d'objet est ensuite montée à celle désirée par l’utilisateur original

73
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Insertion et contraintes d’intégrité

• Comment intégrer au SGDB multi-niveaux les contraintes d'intégrité (CI) ?


• ex: validation des attributs, des domaines et de la cohérence
• chaque CI est aussi un objet du SGBD, avec sa classe d'accès

• Règle sur les CI


• la classe d'accès d'une CI doit dominer la classe d'accès de toutes les
relations sur lesquelles elle s'applique

• Problème:
• un utilisateur 'bas' essaie de mettre à jour un attribut 'bas', contrôlé par une CI
'haute' (donc invisible à l’utilisateur)
• si on refuse l'accès, on indique à l’utilisateur qu'il existe une CI qu'il ne voit pas
(canal caché)
• si on accorde l'accès, on pourrait violer la contrainte d'intégrité

74
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Insertion et contraintes d’intégrité (2)

• Les contraintes d'intégrité peuvent elles aussi être créées à bas niveau et montées
au niveau désiré
• les utilisateurs 'bas' connaissent l'existence de la contrainte, mais pas son
contenu
• un utilisateur qui tente de mettre à jour un attribut 'bas' contrôlé par une
contrainte 'haute' pourra sans problèmes se faire dire que la mise à jour lui
sera refusée

• Si une relation contient des n-uplets dont la clé primaire est confidentielle, on
pourra séparer la relation en 2 sous-relations:
• une relation où toutes les clés primaires sont publiques
• une relation où toutes les clés primaires sont confidentielles

75
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Insertion et contraintes d’intégrité (3)


Insertion à bas niveau (5)
• Exemple de •séparation
Exempledederelation
séparation de relation
Réservations publiques
Vols Dest Sièges
AA334 [P] Chicago [P] 10 [P] [P]
AF211 [P] Paris [C] 7 [C] [C]

Réservations confidentielles
Vols Dest Sièges
AC909 [C] Montréal [C] 4 [C] [C]

• Désavantages de l'insertion à bas


• Désavantages niveau
de l'insertion à bas niveau
– La création
• la création d'objets d'objets etde
et l'assignation l'assignation de la classe
la classe d'accès d'accès
finale finaleleest
est sous
sous le de
contrôle d'utilisateurs contrôle d'usagers de bas niveau.
bas niveau
– Ceci peut entrer en conflit avec la politique de sécurité déjà établie.
• ceci peut entrer
– Uneen conflit avec la politique
étape supplémentaire estde sécurité
requise, doncdéjà établie
délai d'opération.
• une étape supplémentaire est requise, donc délai d'opération
IFT-6271 465

76
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Gestion des leurres

• Un leurre est une information fausse introduite dans une base de données multi-
niveaux pour protéger l’existence d’une information sensible

• Supposons que l’information «Dupont gagne 30000 euros» est classée au niveau
Secret
• on note cette information [Secret]Salaire(Dupont, 30000) où [Secret]p signifie
que l’information représenté par p est classée au niveau Secret

• Supposons que la base contient également [Public]Salaire(Dupont, 22000)


• c’est un leurre

• Pourquoi ?

77
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Gestion des leurres (2)

• Supposons qu’un utilisateur U de niveau Public pose la question: quel est le


salaire de Dupont ?

• La base ne peut pas répondre puisque l’information est secrète


• si la base répond: vous n’avez pas le droit de connaître cette information
• U peut déduire que le niveau de l’information n’est pas public, c’est déjà une
information !
• cela est représenté par ∃x, [Secret]Salaire(Dupont, x)
• mais on peut considérer que cette information doit être secrète
[Secret](∃x, [Secret]Salaire(Dupont, x))

• Dans ce cas, la base ne peut rien répondre, et utilise le leurre !

78
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Inférence non autorisée d’informations

• Pour simplifier le discours, on ne considère que deux niveaux de classification:


Secret et Public

• Le problème: est-il possible de déduire des informations de niveau Secret en


utilisant des informations de niveau Public ?

• Premier exemple
• on suppose la relation suivante:

IDVol Avion Marchandise Classification


1254 A Bottes Public
1254 B Yahourts Public
1254 C Bombe atomique Secret
1254 D Beurre Public

79
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Inférence non autorisée d’informations (2)

• Un utilisateur sans le niveau Secret verra:

IDVol Avion Marchandise Classification


1254 A Bottes Public
1254 B Yahourts Public
1254 D Beurre Public

• S’il essaie d’insérer le n-uplet(1254,C,Toto,Public), il y aura un message d’erreur,


et donc il pourra déduire qu’il y a une marchandise secrète dans (1254,C) !

80
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Inférence non autorisée d’informations (3)

• Deuxième exemple: on considère la base suivante:

Nom Emploi Âge Salaire Département Bureau


Alice Manager 35 60000 Marketing 2ème
Bob Secrétaire 35 25000 Marketing 2ème
Charles Secrétaire 40 30000 Production 1er
Denise Manager 45 65000 Ventes 2ème

• On suppose que l’on n’a pas le droit de demander dans quel département
travaille un employé

• Exemples d’inférence
• Q1 = (Âge; Nom = ‘Alice’)
• Q2 = (Département; Âge < 40)

81
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Inférence non autorisée d’informations (3)

• Deuxième exemple: on considère la base suivante:

Nom Emploi Âge Salaire Département Bureau


Alice Manager 35 60000 Marketing 2ème
Bob Secrétaire 35 25000 Marketing 2ème
Charles Secrétaire 40 30000 Production 1er
Denise Manager 45 65000 Ventes 2ème

• On suppose que l’on n’a pas le droit de demander dans quel département
travaille un employé

• Exemples d’inférence
Alice travaille dans le
• Q1 = (Âge; Nom = ‘Alice’)
département Marketing
• Q2 = (Département; Âge < 40)

81
Plan

• Introduction sur la sécurité

• Bases statistiques

• Contrôle d’accès

• Sécurité discrétionnaire

• Sécurité obligatoire

• Architectures des bases de données multi-niveaux

• Contre-mesures

82
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Architectures des bases de données multi-niveaux

• Plusieurs types d’approches


• approche filtre
• approche noyau de sécurité
• approche sujet de confiance
• approche réplication

83
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Approche filtre

• Principes
• on ajoute un filtre au SGBD, entre le client et le SGBD

• Chaque client est associé à un niveau de sécurité unique (mono-niveau)

• Le serveur gère toutes les données de la base (multi-niveaux)

• Comment fonctionne le filtre ?


• authentifie le client pour connaître son niveau de sécurité
• intercepte toutes les requêtes émises par les clients et toutes les réponses
fournies par le serveur

84
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Approche filtre (2)

• Fonctionnalités du filtre:
• modifie la requête émise par le client pour que l’évaluation de la requête ne
fournisse pas de données ayant un niveau de classification supérieur au niveau
du client
• filtre le résultat pour éliminer toutes les données qui n’auraient pas un niveau
de sécurité inférieur ou égal à celui du client

• Avantages
• simplicité de mise en œuvre (pas de modification des fonctionnalités)
• le filtre est de confiance

• Inconvénients
• vulnérabilité aux attaques (le SGBD n’est pas de confiance)
• contournement du filtre

85
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Approche noyau de sécurité

• Principes
• développer un SGBD en s’appuyant sur un OS multi-niveaux
• l’authentification et les contrôles d’accès sont réalisés par l’OS
• un OS multi-niveaux ne gère que des fichiers mono-niveau (un fichier ne
contient que des données ayant le même niveau de classification)
• partitionnement des données du SGBD sur plusieurs fichiers

• Avantages
• le SGBD n’a pas besoin d’être de confiance (on se repose sur l’OS)
• en fait, on fait l’hypothèse que certaines fonctions du SGBD sont de confiance

86
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Approche noyau de sécurité (2)

• Inconvénients
• performances à cause du partitionnement lié à la gestion mono-niveau des
fichiers
• avoir un OS multi-niveaux

• Exemple
• Oracle OS-MAC et DB-MAC

87
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Approche sujet de confiance

• Principe
• variante de l’approche noyau de sécurité
• les contrôles (accès et authentification) ne sont pas effectués par l’OS mais par
le SGBD
• le SGBD gère son propre ensemble de niveaux de sécurité
• il effectue les contrôles d’accès conformément à la relation d’ordre sur cet
ensemble

• Avantages
• gain de performance

• Inconvénients
• adaptation du SGBD à l’OS

88
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Approche réplication

• Principe
• un serveur séparé pour gérer toutes les données de niveau inférieur à un
niveau donné
• autant de serveurs que de niveaux
• les données sont répliquées
• une donnée de niveau n est répliquée dans tous les serveurs de niveau
supérieur à n
• les serveurs SGBD peuvent ne pas être de confiance
• c’est le serveur frontal qui est de confiance (authentification et contrôle
d’accès)

89
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Approche réplication (2)

• Avantages
• un seul serveur intervient pour évaluer la requête du client
• le serveur ne contient que les données que le client le droit d’observer
• pas de possibilité de détourner les données/requêtes

• Inconvénients
• réplication des données: cohérence, dégradation des performances

90
Plan

• Introduction sur la sécurité

• Bases statistiques

• Contrôle d’accès

• Sécurité discrétionnaire

• Sécurité obligatoire

• Architectures des bases de données multi-niveaux

• Contre-mesures

91
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Contre-mesures

• Contre-mesures SGBD statistiques


BD statistiques (5)
• exiger une taille très grande de l'échantillon
• Contre-mesures
• permutation aléatoire
– Exiger une taille des lignes de
très grande la relation
de l'échantillon
• ajout
– de petites perturbations
Permutation aléatoire des autour
lignes dedes données
la relation
– Ajout de petites perturbations autour des données
• meilleur design de la BD
– Meilleur design de la BD
• ex: séparation de laderelation
• Ex: Séparation Étudiants
la relation Étudiantsen
en 22 sous-relations
sous-relations

Nom ID ID Sexe Prog Moyenne


Alice 108 108 F DESS 65
Bob 204 204 M M.Sc. 80
Carole 833 833 F POLY 70
Diane 048 048 F DESS 90
Éric 564 564 M POLY 85
Frank 444 444 M DESS 70
92
IFT-6271 449
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Contre-mesures (2)

• Ne jamais exposer un serveur BD sur Internet


• s'il y a besoin d'accès directs au SGBD, il faut utiliser des tunnels, un firewall
avec authentification forte ouvrant le flux, ...
• il faut être sûr de filtrer les ports SGBD (1521, 1527, 3306, 1434, 135 ...)
• attention aux hébergeurs pas chers !

• Ne jamais partager un serveur BD

• Durcissement de l'OS
• va limiter l'exploitation de failles
• appliquer les procédures classiques
• non installation des composants annexes, limitation des services réseaux,
application régulière des correctifs de sécurité…

93
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Contre-mesures (3)

• Appliquer le principe de défense en profondeur et de cloisonnement par une


architecture en strates

WWW

Internet

SGBD

Tomcat

94
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Contre-mesures (4)

• Durcissement installation SGBD


• changer les mots de passe par défaut, supprimer les comptes par défaut
• ne pas installer les exemples, les applications annexes,…

• Séparation des privilèges


• recenser les rôles dans l'application: admin, mise à jour, lecture…
• appliquer ces rôles dans les privilèges attribués

• Audit des applicatifs


• parler sécurité avec les développeurs: SQL Injection, débordements de buffer,
validation d'entrées…
• recherche des points critiques, des flux utilisateurs…
• audit des sources Java, ASP, PHP, Perl, C…

95
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Contre-mesures (5)

• Se connecter avec des comptes différents si nécessaire


• compte read-only
• compte read-write

96
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Contre-mesures: injection

• Valider les entrées


• ne protégera pas que des problèmes d'injection SQL

• Utiliser les fonctions spécialement conçues du driver


• exemple avec perl DBI : $dbh->quote();
• exemple avec PHP: mysql_real_escape_string(), etc.
• attention, ça ne règle pas tout : il devient possible d'insérer du code SQL dans
la base elle-même (par exemple, création d'un compte admin'--)
• problème des entiers :
• vérifier que les entiers sont bien numériques…
• vérifier que l’on attend bien des numériques (pour éviter 1=1)

97
Introduction    »   Bases statistiques    »   Contrôle d’accès   »   Discrétionnaire   »   Obligatoire   »    Architectures    »   Contre-mesures

Contre-mesures: injection (2)

• Ne donner à l'utilisateur (SGBD) de l'application que les droits nécessaires


• par exemple SELECT dans le cas d'une simple consultation
• SELECT, INSERT et UPDATE dans la plupart des cas

• Procédures stockées ou requêtes pré-compilées (prepared statement): les


données sont transmises en paramètres, pas de risque d’injection

• Vérifiez toujours les données provenant de l’utilisateur

• Utiliser des comptes avec des droits d’accès limités au minimum nécessaire

98
Conclusion

• Les SGBDs sont


• complexes
• leur sécurité n’est pas toujours maîtrisée

• Les risques sont réels et parfois ignorés

• Il faut sensibiliser l’ensemble des acteurs


• concepteurs: appel d’offre/cahier des charges
• développeurs
• recettes
• DBA, administrateurs, réseau,…

99