Sécurité dans les SGBD

Sécurité dans les SGBD Olivier Perrin IUT Nancy-Charlemagne Département Informatique Université Nancy 2 Olivier.Perrin@loria.fr

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 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 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 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 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 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 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 22

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 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 Relation Étudiants 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 23

Les bases statistiques (5) 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 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 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 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 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

É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 46

É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 47

É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. Vue (c) Observer (*) Usager Évaluer (c) Observer (c) Relations de base Évaluer (*) Vue (*) 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 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] 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

Polyinstanciation (3) 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

Polyinstanciation (4) 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 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] 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 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 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 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: 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)! 61

Inférence non autorisée d informations (3) 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) 62

Inférence non autorisée d informations (3) 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) Alice travaille dans le département Marketing 62

Inférence non autorisée d informations (4) 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 ne peut pas demander quel est le salaire d un employé Exemples d inférence Q1 = (Âge; Nom = Charles ) Q2 = (Âge, Salaire; Âge 40) 63

Inférence non autorisée d informations (4) 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 ne peut pas demander quel est le salaire d un employé Exemples d inférence Q1 = (Âge; Nom = Charles ) Q2 = (Âge, Salaire; Âge 40) Charles gagne 30000 63

Inférence non autorisée d informations (5) 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 Exemples d inférence Q1 = (Nom; Emploi = Manager ^ Âge = 35) Q2 = (Salaire; Emploi = Manager ) Q3 = (Salaire; Âge = 35) 64