Sécurité dans les SGBD - cosy.univ-reims.frcosy.univ-reims.fr/~lsteffenel/AdminSGBD/Securite-SGBD.pdf · Sécurité dans les SGBD Olivier Perrin IUT Nancy-Charlemagne Département

Sécurité dans les SGBD

Olivier PerrinIUT Nancy-CharlemagneDépartement InformatiqueUniversité Nancy 2

[email protected]

Plan

• Introduction sur la sécurité

• Contrôle d’accès

• Bases statistiques

• Sécurité discrétionnaire

• Sécurité obligatoire

• Architectures des bases de données multi-niveaux

• Contre-mesures

2

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 mettrait pas de données sensibles

• Problème de confidentialité: prévention de la divulgation non autorisée de données/d’information

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

• les problèmes d’intégrité: prévention de modification non autorisée des données

• disponibilité: prévention de refus d’accès autorisé à des données

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

3

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


Définitions: menaces, vulnérabilités et attaques

• 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

Sécurité et SGBDs

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

• à l'achat de système de sécurité (firewalls, systèmes de 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


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


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 (.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

8


Les risques (2)

• Attaques sur les applicatifs

• injection SQL sur les applications Web

• 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


9

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

10


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 de la registry

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


11

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é)


12

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


13

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


14

Plan







• Contre-mesures

15

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é


16

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


17

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


18

Plan







• Contre-mesures

19

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


20

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


21


• 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


22


• Attaque par pisteur

• on doit d'abord identifier un pisteur général, un critère qui découpe la relation en 2 ensembles qui sont chacun plus grands que le seuil d'attaque directe (ex: 3)

• ex: dans la relation Étudiants, 'Prog = DESS' est un tel critère

• Ex: connaître la moyenne de Bob en 3 requêtes

Nom Sexe Prog Moyenne

Alice F DESS 65

Bob M M.Sc. 80

Carole F POLY 70

Diane F DESS 90

Éric M POLY 85

Frank M DESS 70

Relation Étudiants


23


• Comment procéder ?

• R1: Moyenne de ((étudiants de DESS) ou Bob):

• résultat du calcul de la moyenne d'Alice, Bob, Diane et Frank = 76,25

• R2: Moyenne de (étudiants pas de DESS) ou Bob):

• résultat du calcul de la moyenne de Bob, Carole et Éric = 78,33

• R3: Moyenne de tous les étudiants = 76,67

• On calcule ensuite: 4 x R1 + 3 x R2 - 6 x R3 = 80, la moyenne de Bob

• Pourquoi ?

• 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

24


Plan







• Contre-mesures

25

Sécurité discrétionnaire

• 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

• 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)


26

Sécurité discrétionnaire (2)

• 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


27

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


28

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


29

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)


30

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


31

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


32

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 :


33

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 :

• 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


34

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


35

Plan







• Contre-mesures

36

Sécurité obligatoire

• Sécurité multi-niveaux (cas particulier)

• Dans une politique de sécurité multi-niveaux:

• les utilisateurs reçoivent un niveau d’habilitation

• les informations reçoivent un niveau de classification

• Niveaux dans un ensemble partiellement ordonné

• Très secret > Secret > Confidentiel > Public


37

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


38

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

• Règle de simple sécurité:

• 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:

• 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...


39

Mise en œuvre d’une politique

• La mise en œuvre d’une politique de sécurité multi-niveaux dans un SGBD pose plusieurs problèmes:

• granularité de classification

• gestion des leurres

• inférence d’information


40

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 ?


41

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)


42

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


43

É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

44


Étiquetage des objets (2)

• Exemple

• la relation Réservations [P]

• les lettres entre crochets indique la classe d'accès

• C = Confidentiel, P = Public

• pour chaque attribut, la classe d'accès suit la valeur de l’attribut

• pour chaque n-uplet, la classe d'accès est à droite du n-uplet

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]


45


• 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


46


• 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


47


• 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.

Relationsde base

Vue (c) Usager

Vue (*)

Évaluer (c) Observer (c)

Observer (*)

Évaluer (*)


48

Polyinstanciation

• Dans un SGBD multi-niveaux, un utilisateur 'bas' ne peut connaître l'existence de données 'hautes'.

• il pourrait être tenter de mettre à jour un attribut contenant une donnée 'haute'

• ex: pour le 'Vol = AF211', il veut changer 'Dest = Nice' et 'Sièges = 0'

Vols Dest Sièges



AF211 [P] Paris [C] 7 [C] [C]

AF211 [P] Paris [C] 0 [P] [C]

AF211 [P] Nice [P] 7 [C] [C]

49


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 !

polyinstantiation


50


• On insère le n-uplet

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

• pour résoudre cette situation, on étend la notion de clé primaire, en y incorporant les classes 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 polyinstantiation

• 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


51


• Exemple de polyinstantiation

• sur le n-uplet 'Vol = AF211'

• après mise à jour 'Dest = Nice' [P] et 'Sièges = 0' [P]

Vols Dest Sièges



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]


52

Polyinstanciation: discussion

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

• la polyinstantiation 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é)


53

Polyinstanciation: discussion (2)

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

• 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


54

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é

55


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


56

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

• Exemple de séparation de relation

• Désavantages de l'insertion à bas niveau

• la création d'objets et l'assignation de la classe d'accès finale est sous le contrôle d'utilisateurs de bas niveau

• ceci peut entrer en conflit avec la politique de sécurité déjà établie

• une étape supplémentaire est requise, donc délai d'opération

Vols Dest Sièges


AF211 [P] Paris [C] 7 [C] [C]

Vols Dest Sièges


Réservations publiques

Réservations confidentielles

57


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 ?


58

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 !


59

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


60

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

• Un utilisateur sans le niveau Secret verra:

• 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) !

IDVol Avion Marchandise Classification

1254 A Bottes Public

1254 B Yahourts Public

1254 D Beurre Public


61


• On considère la base suivante:

• 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)

62

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é


• Q1 = (Âge; Nom = ‘Alice’)

• Q2 = (Département; Âge < 40)

62






Alice travaille dans ledépartement Marketing




• On suppose que l’on ne peut pas demander quel est le salaire d’un employé


• Q1 = (Âge; Nom = ‘Charles’)

• Q2 = (Âge, Salaire; Âge 40)

63









• On suppose que l’on ne peut pas demander quel est le salaire d’un employé


• Q1 = (Âge; Nom = ‘Charles’)

• Q2 = (Âge, Salaire; Âge 40)

63






Charles gagne 30000





• Q1 = (Nom; Emploi = ‘Manager’ ^ Âge = 35)

• Q2 = (Salaire; Emploi = ‘Manager’)

• Q3 = (Salaire; Âge = 35)

64










• Q1 = (Nom; Emploi = ‘Manager’ ^ Âge = 35)

• Q2 = (Salaire; Emploi = ‘Manager’)

• Q3 = (Salaire; Âge = 35)

64






Alice gagne 60000





• Q1 = (Salaire; Département = ‘Marketing’ ^ Bureau = ‘2ème’)

• Q2 = (Salaire; Emploi = ‘Manager’ ^ Bureau = ‘2ème’)

• Q3 = (Nom; Bureau = ‘2ème’)

65










• Q1 = (Salaire; Département = ‘Marketing’ ^ Bureau = ‘2ème’)

• Q2 = (Salaire; Emploi = ‘Manager’ ^ Bureau = ‘2ème’)

• Q3 = (Nom; Bureau = ‘2ème’)

65






Le manager qui travaille au 2ème gagne 60000


Plan







• Contre-mesures

66

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


67

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


68

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

69


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

70


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


71

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

72


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)

73


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


74

Plan







• Contre-mesures

75

Contre-mesures

• Contre-mesures SGBD statistiques

• exiger une taille très grande de l'échantillon

• permutation aléatoire des lignes de la relation

• ajout de petites perturbations autour des données

• meilleur design de la BD

• ex: séparation de la relation Étudiants en 2 sous-relations

Nom ID

Alice 108

Bob 204

Carole 833

Diane 048

Éric 564

Frank 444

ID Sexe Prog Moyenne

108 F DESS 65

204 M M.Sc. 80

833 F POLY 70

048 F DESS 90

564 M POLY 85

444 M DESS 70


76

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é…

77


Contre-mesures (3)

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

Internet

WWW

Tomcat

SGBD


78

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…

79


Contre-mesures (5)

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

• compte read-only

• compte read-write


80

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(); mysql_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 ...

• 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


81

Documents

Sécurité dans les SGBD - cosy.univ-reims.frcosy.univ-reims.fr/~lsteffenel/AdminSGBD/Securite-SGBD.pdf · Sécurité dans les SGBD Olivier Perrin IUT Nancy-Charlemagne Département