systèmes de gestion de bases de donnéesanciaux/ensta/asi13/1-cours/... · systèmes de gestion de...
TRANSCRIPT
1
Systèmes de Gestion
de Bases de Données
Nicolas Anciaux, Inria PETRUS
Ressources web pour ce cours
http://petrus.inria.fr/~anciaux/ENSTA/ASI13
2
Objectifs du module
• Pré requis: connaissances de base (IN206)
– Conception de BD : modèle entité association, modèle relationnel
– Programmation SGBD : SQL, programmation SQL
– Propriétés transactionnelles : concurrence d’accès
• Objectifs des sessions
– Connaissance générales (culture)
• Raison d’être d’un SGBD
• Fonctionnalités : indépendance physique/logique, vues, langage de
manipulations, cohérence (contraintes d’intégrité et triggers), standards…
– Connaissances avancées
• Optimisation de requêtes
• Droits d’accès
• Tolérance aux pannes
• Audit des accès
• Chiffrement et anomymisation des données
• SGBD No-SQL (au-delà du relationnel)
3
1
Planning des sessions
– L’optimisation de requêtes
– Création et interrogation de base de données relationnelle en SQL (Oracle XE)
– Expériences sur l’optimisation de questions
– Politique de contrôle d'accès
– Modèles DAC-SQL, RBAC, MAC
– Bases de données privées virtuelles (Oracle VPD), Sécurité multi-niveau (Oracle Label Security)
– Expériences d'implantation de droits d'accès, principe du moindre privilège
– Tolérance aux pannes, algorithmes de journalisation et de reprise
– Audit des accès : triggers d’audit et outils internes au SGBD
– Expériences mettant en évidence les techniques de tolérance aux pannes
– Outils d’audit disponibles sur Oracle XE
– Place de la cryptographie dans la sécurité d'un SGBD
– Chiffrement de bases de données
– Utilisation des outils cryptographiques disponibles sur OracleXE
– Introduction à la gestion de données personnelles
– anonymat dans un SGBD
– Procédure d’anonymisation / déanonymisation de données
– NoSQL : Panorama des bases de données au-delà du SQL
– Installation et utilisation d’un système NoSQL
– Point de vue ‘bases de données’ sur certains buzzword: Blockchain, deep learning…
– Conclusion du cours
Examen
Cours:
TD:
Cours:
TD:
Cours:
TD:
Cours:
TD:
Cours:
TD:
Cours:
TD:
Cours:
3
4
5
7
2
6
4
Compétences à acquérir
• Concevoir une base de données
– Réaliser un modèle conceptuel avec le modèle E/A
– Concevoir un modèle relationnelle de base de données
• Créer une application base de données
– Ecrire des requêtes SQL d’interrogation/mise à jour
– Interfacer un programme Java/JDBC avec une base de données
– Ecrire et invoquer des fonctions et procédure stockées en PL/SQL Oracle
– Implanter des triggers sur une base de données en PL/SQL Oracle
• Administrer une base de données en vue d’optimiser les performances
– Optimiser une base de données multi utilisateurs (gestion de la concurrence)
– Créer des index
– Réécrire des requêtes SQL pour obtenir un plan d’exécution plus performant
• Administrer une base en vue d’en assurer la sécurité
– Créer des utilisateurs/rôle et des droits d’accès (DAC-SQL, RBAC-SQL)
– Implanter une stratégie de tolérance aux pannes
– Auditer les accès
– Chiffrer des données sensibles
5
Optimisation de requêtes
6
Du stockage à l’optimisation
• A la base de tout, le hardware
– Cache CPU, RAM, disques magnétiques, disques Flash
• Organisation des données
– Stockage des attributs, tuples, pages, fichiers
– Indexation des données
• Exécution de requêtes (algorithmes)
• Optimisation de requêtes
• Mises en oeuvre dans Oracle
7
Problème de l’optimisation
• Un problème global
– Touche l’ensemble des acteurs (pas seulement l’éditeur…)
Select
From
Where
Requête SQL Arbre logique Arbre Physique
Optimisation
8
8
Un problème d’équivalence sémantique
• Une question
• Plusieurs expressions
équivalentes en SQL
• Plusieurs expressions
équivalentes en algèbre
• Plusieurs algorithmes
algébriques équivalents
Co
ût
Plans sémantiquement équivalents
Ex. 9 jointures17 Milliards de plans…
9
9
Objectifs de l’optimisation
• Objectif de l’optimiseur : trouver le meilleur plan …– Donnant les résultats le + vite ….
• Optimisation pour le temps de réponse (response time)
– Minimisant la consommation de ressources• Optimisation du travail total (Total work)
– Minimisant le temps de délivrance des premiers tuples• Optimisation de la latence (Latency / First tuples …)
• Qui optimise ?– Idéalement 2 requêtes équivalentes même plan, le meilleur !
Seuls les concepteurs de SGBD doivent maîtriser l’optimisation
– Pratiquement, ce qui conduit à des plans différents• 2 modèles conceptuel/physiques différents (d’un même problème)
• 2 opérations sémantiques équivalentes (série de requêtes SQL différentes)
• 2 requêtes SQL équivalentes
Le concepteur et le programmeur BD jouent un rôle majeur
10
10
Importance du Schéma Physique
• L'utilisation d'index
– accélère l'exécution des sélections et des jointures
– ralentit l'exécution des mises à jour et des insertions
– offre des informations statistiques à l'optimiseur
– permet le contrôle efficace de contraintes d'intégrité
• L'organisation des données
– égaliser les I/O entre disques (log et bases, index et tables,
partitions de tables sur ° disques) Ex: tablespaces en Oracle
• Le choix des "bons" index et l'organisation des
données sont déterminants pour les performances
11
11
Indexation (principe et B+Tree)
• Objectif : accès rapide à partir d’une clé
• Moyen : ajout de structures de données
(généralement hiérarchiques)
• Exemple : B+Tree
• Attention :
– Surcoût lors des mises à jour !
– Un accès par index plus coûteux qu’un parcours séquentiel ?
C’est parfois vrai…. Pourquoi ?
Jean
Adam
Alain
Ben
Claire
Felix
Gil
Hilda
Jean
Karine
Martin
Nicole
Paul
Sophie
Théo
Tom
Zoe
12
Index primaire vs. secondaire
Tuples triés sur la clé de l’index
Index
Table
Tuples rangés aléatoirement sur la clé de l’index
Index
Table
Index primaire : 1 seul par table Index secondaire : n par table
NB: Index couvrant une requête : les clés (composites) contiennent
tous les attributs nécessaires à la requête
=> Inutile d’accéder aux tuples…
13
13
Optimisation logique
• Pour une requête SQL :
• Produire un arbre algébrique optimal
– Jeu d’operateurs algébriques (opérateur logiques)
– Équivalence de plan algébriques => propriété algébriques
• Notions d’algèbre…
Select Patients.Nom, Patients.Prénom
From Patients, Visites
Where Patients.Id-P = Visites.Id-P
and Patients.Ville = ’Paris’
and Visites.Date = ’15 juin’
14
14
Optimisation logique (1)
• Opérateurs principaux:
– Projection :
• Elimination des attributs non désirés et suppression des doublons
• Opérateur Relation Relation, noté : a1,a2,...Ap (R)
VINS Cru Mill Région Qualité
VOLNAY BOURGOGNE
CHENAS BEAUJOLAIS
JULIENAS BEAUJOLAIS
(VINS) Cru Région
VOLNAY 1983 BOURGOGNE A
VOLNAY 1979 BOURGOGNE B
CHENAS 1983 BEAUJOLAIS A
JULIENAS 1986 BEAUJOLAIS C
Cru,Région
Cru,Région (VINS) =
15
15
Optimisation logique (2)
• Opérateurs principaux:
– Projection
– Selection (restriction)• Obtention des tuples de R satisfaisant un critère Q
– Q est le critère de la forme : Ai Valeur, ={ =, <, ≥, >, ≤ , != }
– Possible de réaliser des "ou" (conjonction) et des "et" (disjonction) de
critères
• Relation Relation, notée Q(R)
MILL>1983
VINS Cru Mill Région Qualité
VOLNAY 1983 BOURGOGNE A
VOLNAY 1979 BOURGOGNE B
CHENAS 1983 BEAUJOLAIS A
JULIENAS 1986 BEAUJOLAIS C
VINS Cru Mill Région Qualité
JULIENAS 1986 BEAUJOLAIS C Mill>1983 (VINS) =
16
16
Optimisation logique (3)
• Opérateurs principaux:
– Projection
– Selection (restriction)
– Jointure
• Relation Relation Relation
– notée
• Critère de jointure– Attributs de même nom égaux
» Attribut = Attribut
» Jointure naturelle
– Comparaison d'attributs
» Attribut1 Attribut2
» Théta-jointure
» Cas particulier : équi-jointure
17
17
Optimisation logique (4)
• Opérateurs principaux:
– Projection
– Selection (restriction)
– Jointure : exemple
VINS Cru Mill Qualité
VOLNAY 1983 A
VOLNAY 1979 B
CHABLIS 1983 A
JULIENAS 1986 C
LIEU Cru Région QualMoy
VOLNAY Bourgogne A
CHABLIS Bourgogne A
CHABLIS Californie B
VINSREG Cru Mill Qualité Région QualMoy
VOLNAY 1983 A Bourgogne A
VOLNAY 1979 B Bourgogne A
CHABLIS 1983 A Bourgogne A
CHABLIS 1983 A Californie BVINS
Cru=Cru
LIEU =
18
18
Optimisation logique (5)
Patients Visites
Visites
Patients
Select Patients.Nom, Patients.Prénom
From Patients, Visites
Where Patients.Id-P = Visites.Id-P
and Patients.Ville = ’Paris’
and Visites.Date = ’15 juin’
19
19
Optimisation Physique
Sélection
– FTS (Full Table Scan) ?
– Index Scan (B+tree) ?
– Index Scan (Bitmap) ?
Jointure
– Nested Loop Join ?
– Index Join ?
– Hash Join ?
– Sort Merge Join ?
Visites
Patients
20
20
Algorithmes de jointure
• Nested loop Join : Jointures par boucle imbriquées– Pour chaque visite, parcourir les patients
• Index Join : Utilisation d’index sur une des relations– Pour chaque visite, retrouver le patient grâce à l’index
• Sort Merge Join– Trier les visites sur le N° de patient
– Trier les patients sur le N° de patient
– Fusionner les deux tables triées (jointure ‘à deux doigts’)
• Hash Join– Hacher les patients sur le N° de patient
– Pour chaque visite, calculer la valeur de hachage et chercher dans la table de hachage le patient correspondant
21
21
Optimiseur heuristique
• L’optimisation est indépendante des données
– Dépend uniquement de la requête SQL…
• Exemple d’heuristiques classiques
– Effectuer les sélections en premier
– Ajouter un maximum de projections
– Utiliser tous les indexes disponibles
– Utiliser les ‘meilleurs’ algorithmes de jointure, dans l’ordre
1. Hash join
2. Sort merge join
3. Nested Loop join avec index
4. Nested loop join
• Conclusion
– L’ordre des opérations dépends de l’expression SQL
• Ex = ordre des jointures déterminé par leur ordre d’apparition
– Présent dans Oracle = Rule Based Optimizer (RBO)
22
Optimiseur basé sur un modèle de coût
Générateur de
Plans
Graphe d'opérations
Heuristiques
de choix
Plan d'exécution
Optimal
Schéma interne
Plans d'exécution(espace de recherche)
Statégie de
Recherche
Bibliothèque de
transformations
Modèle de coût
• Dépend des caractéristiques des données
• Présent dans Oracle (Cost Based Optimizer ou CBO)
• Plus efficace que le RBO !
23
Difficultés de l’optimisation basée coût
• Espace de recherche (plans candidats)– Plusieurs algorithmes pour chaque opérateur
– Coûts et comportement différents
– Plusieurs ordonnancement pour les opérations binaires
• Sans considérer les algorithmes, il y a 1620 ordres possibles pour joindre 5 relations, et 17 milliards pour 10 relations !
Utilisation d’heuristiques et de programmation dynamique
• Modèle de coût (choix du plan)– Difficulté pour estimer le coût de chaque opérateur
– Difficulté encore plus importantes pour estimer la taille des résultats intermédiaires (permettant de calculer l’opérateur suivant)
– Propagation exponentielle des erreurs (dans l’arbre d’exécution) !
Utilisation de statistiques re-calculés fréquemment
24
24
Les statistiques
• Possibilité d’histogrammes
– RunStat(<Table>, <attribut>) construction et stockage d’un
histogramme de variation de l’attribut dans la table.
– Utilisation par le modèle de coût
– Sinon, hypothèse d ’uniformité
• Exemple :
– Personnes ayant un salaire entre 2K€ et 4 K€ ?
– Personnes ayant 2 véhicules ?
– Personnes ayant 2 véhicules et un salaire entre 2 et K4 K€?
0 0.5 1 1.5 2.0 2.5 3.0 3.5 4
20%
0 1 2 3 4
15%
20%
15%
3% ? Non !
En fait, 14%
25
25
Qualité de l’optimisation
1. Qualité du schéma physique
– Indexes
– Partitionnement, placement
– Configuration
2. Qualité de l'optimiseur (heuristique/coût)
– Qualité du modèle de coût utilisé
– Qualité de la stratégie de recherche de l'optimiseur
3. Qualité de l’administration
– Qualité des traces ou indicateurs générés par le système
– Qualité des outils d'aide à l'administration
– Qualité de l’administrateur !
4. Qualité des développeurs d’application ?
26
26
Réglage du SGBD – Database Tuning
• Réglages du SGBD, amélioration des performances
– Manuel par l’administrateur BD
– par des outils externes de diagnostiques
– par des outils intégrés automatiques
• Oracle : Automatic SQL Tuning
• SQL Server : Database Tunning Advisor
27
Oracle : Automatic SQL Tuning
Statistiques
manquantesSQL Profile
Index
manquants
Mauvaises
constructions SQL
SQL Tuning Advisor
Requête SQL
Automatic Tuning Optimizer
Analyse des
StatistiquesSQL Profiling Analyse des
chemins d’accèsAnalyse des
structures SQL
28
28
Conclusion sur l’optimisation
• Mécanismes puissant mais complexes à maîtriser
• Fort impact sur les performances du système
• Les performances dépendent d’autres facteurs
– Schéma physique
– Configuration du serveur (mémoire, disques, etc.)
– Administration adéquate
• De plus en plus de tâches automatiques ou automatisables
– Gestion de la mémoire automatique dans Oracle 9
– Automatic SQL Tuning dans Oracle 10
– Database Tunning Advisor dans SQL Server 2005
– Etc.
• Mais aussi : une bonne application BD
des concepteurs qui connaissent le SGBD
29
Petite classe : exercices de SQL
et optimisation de requêtes
30
Droits d’accès SGBD
31
Politique de contrôle d’accès (ie, ensemble de règles)
• Précise qui est autorisé à faire quoi sur quelles
données et dans quelles conditions
• Format des règles :
Sujet
Permission
Interdiction
Obligation
Action
Objet
Ensembled ’objets
avoir
avoir
avoir
réaliser
réaliser
réaliser
agir
sur
agir
sur
32
Ex. Système d’information médical
• Sujets = Personnels du
groupe médical
• Objets = Dossiers des
patients
• Actions = Ex.
Jean
Jeanne
Médecin
Nadine
Secrétaire
médicale
Dossier_Patient
Dossier_Admin
Dossier_Médical
Dossier_Soins_Infirmiers
Partie_Admin
Partie_Secu_Sociale
Ausculter un patient
Créer le dossier d’un nouveau patient
Consulter le dossier
Mettre à jour les parties
« Dossier_médical » et« Dossier_soins_Infirmiers »
Renseigner « Dossier_Admin »
33
Exemple de règles
• Règles indépendantes du contenu
– Les plus simples
– Règle qui permet d’accéder un objet indépendamment de son contenu
– Ex.
• R1 : La secrétaire médicale a la permission de gérer le « Dossier_Admin »
d’un patient du groupe médical
• Permet de consulter et de mettre à jour n’importe quelle information du
« Dossier_Admin » d’un patient
• Règles dépendant du contenu
– La permission d’accéder à un objet dépend du contenu de cet objet
– Ex.
• R2 : Le médecin a la permission de consulter l’intégralité du dossier d’un de
ses patients (permet de consulter un dossier médical à condition qu’il
s’agisse d’un patient de ce médecin)
• R3 : Le médecin a la permission de mettre à jour les parties
« Dossier_Medical » et « Dossier_Soins_Infirmiers » d’un de ses patients
34
Exemple de règles (suite)
• Règles dépendant du contexte– La permission d’accéder à un objet dépend d’une condition
associée au contexte d’exécution et indépendante du contenu de cet objet
• Exemples :– R4 : En l ’absence de la secrétaire médicale, le médecin a le droit
de créer le « dossier_admin » d’un nouveau patient
– R5 : La secrétaire médicale a accès au « Dossier_Admin » du patient uniquement pendant les heures de travail
– R6 : La secrétaire médicale a accès au « Dossier_Admin » du patient uniquement à partir d’un poste interne à la clinique
– R7 : en cas d’urgence, tout membre de l’équipe soignante à accès au dossier du patient
• Contrôle a posteriori de la réalité de la situation d’urgence
35
Exemple de règles (suite)
• Délégation et transfert de droit– Règles liées à l’administration de la politique de contrôle
d’accès
• Exemple :– R8 : Un médecin du groupe médical a la permission
d’autoriser la secrétaire médicale à mettre à jour la prescription contenue dans le « Dossier_médical » du patient
• Contrepartie de la délégation– La secrétaire médicale ayant reçu autorisation a la
permission de mettre à jour la prescription du « Dossier_médical » du patient
36
Modèle discrétionnaire (DAC)
• DAC = Discretionary Access Control
– Contrôle d’accès discrétionnaire
• Principes de DAC
– Le créateur d’un objet fixe la politique de contrôle d’accès
sur cet objet
– Les sujets reçoivent des permissions pour réaliser des
actions sur des objets
– Les sujets ont l’autorisation de transférer certaines
permissions à d’autres sujets
– Modèle par essence décentralisé
très souple
difficile à administrer
37
Exemple typique de DAC
• Gestion des droits dans UNIX
Répertoire
F
Contenu
du fichier F
User Group Other
R W X R W - R - -
Owner
Jean
• Concept de propriétaire
– Dans UNIX, chaque objet a un propriétaire
– C’est le propriétaire qui a les droits
discrétionnaires sur l’objet
• Le propriétaire décide des droits des autres sujets
38
Modèle discrétionnaire en BD
• La matrice d’accès peut être immense :– Grand nombre d’objets à protéger
– Objets de granule très hétérogène
(relations, tuples, attributs)
– Protection d’objets :
logiques (tables)
ou virtuels (vues), [et non physiques (fichiers)]
Implémentation difficile…
• Deux approches pour renseigner la matrice accès
– Capacité (Capability List)
• la matrice est gérée par ligne
• Une liste d’autorisations, appelée capability list, est affectée à chaque utilisateur
– ACL(Access Control List)
• la matrice est gérée par colonne
• Une liste d’autorisations est affectée à chaque objet
Nom Salaire . . .
Dupontreadwrite read
Robert
Durandread
39
Principe du modèle DAC-SQL
UUtilisateur
PPermission
VVue
AAction
OObjet
= N-uplet
Remarque : modèle fermé, basé exclusivement sur des autorisations
40
Politique de sécurité dans DAC-SQL
• Instruction GRANT/REVOKE– Permet de donner/retirer des privilèges à certains utilisateurs
• Privilèges associés aux « utilisateurs »
• Différents types de privilèges
• Privilèges sur les données basés sur le concept de « Vue »– Permet de diviser la base de données en plusieurs parties
– Ex: la vue dossier_patient_de_Jean… CREATE VIEW dossier_patient_de_Jean AS
SELECT *
FROM dossier_patient
WHERE dossier_patient.medecin_traitant = ”Jean” ;
…contient tous les dossiers des patients de Jean
41
Création d’utilisateur – Ex. d’Oracle (1)
Créés par l’administrateur…
… ou tout utilisateur ayant la permission de créer des utilisateurs
CREATE USER <utilisateur> IDENTIFIED {BY <mot de passe> | EXTERNALLY }
[DEFAULT TABLESPACE <tablespace>] /* Tablespace par défaut : SYSTEM */
[TEMPORARY TABLESPACE <tablespace>]
[QUOTA { entier [K,M] | UNLIMITED } ON <tablespace…>]
/* Tablespace par défaut : SYSTEM */
[PROFILE <profile>] /* Profile par défaut: sans l’imitation de ressource */
[PASSWORD EXPIRE] /* Force le changement de mot de passe */
Ex. CREATE USER biblio IDENTIFIED BY auteur
DEFAULT TABLESPACE data
TEMPORARY TABLESPACE temp
QUOTA UNLIMITED ON data
QUOTA UNLIMITED ON indx
PASSWORD EXPIRE;
DROP USER utilisateur [CASCADE]; /* CASCADE supprime aussi les objets créés */
42
Création d’utilisateur – Ex. d’Oracle (2)
• Un profil = un ensemble nommé de :
– limites de ressources
– Contraintes sur le mot de passe
CREATE PROFILE <profile> LIMIT
SESSIONS_PER_USER {int | DEFAULT | UNLIMITED}
CPU_PER_SESSION {int | DEFAULT | UNLIMITED}
CONNECT_TIME {int | DEFAULT | UNLIMITED}
IDLE_TIME {entier | DEFAULT | UNLIMITED}
…
FAILED_LOGIN_ATTEMPTS {entier | DEFAULT | UNLIMITED}
PASSWORD_LIFE_TIME
PASSWORD_REUSE_TIME
…
ressources
Mot de passe
43
Privilèges SQL
• Deux types: Privilèges « objets » et « système »
• Privilèges objets– SELECT : permet la consultation de la table
– INSERT : permet l ’insertion de nouvelles données dans la table
– UPDATE : permet la mise à jour de n ’importe quelle colonne de la table
– UPDATE(nom_colonne) : permet la mise à jour d ’une colonne spécifique de la table
– DELETE : permet de supprimer n ’importe quelle donnée de la table
– Etc.
• Privilèges systèmes– CREATE/ALTER/DROP TABLE : Modifier la définition d’un objet
– EXECUTE : Compiler et exécuter une procédure utilisée dans un programme
– REFERENCE : référencer une table dans une contrainte
– INDEX : Créer un index sur une table
– Etc.
• Les privilèges sont stockés dans la métabase
– Oracle: dba_sys_privs, dba_tab_privs, dba_role_privs, …
44
Commandes SQL Grant
GRANT <liste privileges>
ON <table ou vue>
TO <liste utilisateurs>
[ WITH GRANT OPTION ] /* pour les privilèges objets */
[ WITH ADMIN OPTION ] /* pour les privilèges système*/
;
– WITH GRANT ou ADMIN OPTION
• est optionnel
• signifie que l ’utilisateur qui obtient le privilège peut ensuite accorder
ce privilège à un autre utilisateur
45
Commande SQL Revoke
REVOKE [ GRANT OPTION FOR ] <liste privileges>
ON <table ou vue>
FROM <liste utilisateurs>
[option] ;
– [GRANT OPTION FOR]
• signifie que seul le droit de transfert est révoqué
– [option] = RESTRICT ou CASCADE
• Si A accorde le privilège p à B et B accorde ensuite p à C:
CASCADE => si A révoque p à B alors C perd aussi le privilège
RESTRICT => si A révoque p à B alors la révocation échoue
Et si un utilisateur U a reçu le privilège p de A et de B
(sans relation entre A et B) ?
46
Gestion des vues
• Les vues permettent d’implémenter l’indépendance
logique en créant des objets virtuels
• Vue = expression d’un requête SQL
• Le SGBD stocke la définition et non le résultat
• Exemple : la vue du dossier patient
CREATE VIEW dossier_patient AS
SELECT *
FROM dossier_admin DA, dossier_medical DM, dossier_soins_infirmiers DSI
WHERE DA.id_patient = DM.id_patient AND
DA.id_patient = DSI.id_patient
47
Gestion des vues
Le SGBD transforme la question sur les vues en
question sur les relations de base
Requête Qsur des vues
Gestionnaire de Vues
Définition des vues
Requête Q’ sur les relations
de base
Exécution de requête
Résultat
48
Confidentialité via les vues
Principe : Restreindre l'accès à la BD en
distribuant les droits via des vues :
Vérification des droits
Requête Q sur des vues
Gestionnaire de Vues
Requête Q’ sur les relations
de base
Exécution de requête
OK
OKRésultat
Définition des
droits
Définition des vues
49
Confidentialité via les vues
Id-E Nom Prénom Poste Adresse Ville Salaire
1 Ricks Jim 5485 ………. Paris 230
2 Trock Jack 1254 ………. Versailles 120
3 Lerich Zoe 5489 ………. Chartres 380
4 Doe Joe 4049 ………. Paris 160
Id-E Nom Prénom Poste
1 Ricks Jim 5485
2 Trock Jack 1254
3 Lerich Zoe 5489
4 Doe Joe 4049
Nombre
d’employés
Masse
Salariale
4 890
Service des
ressources
humaines
Employés
(intranet)
Public
(internet)
50
Application du modèle DAC-SQL
• Politique de sécurité du groupe médical
– Quels sont les privilèges respectifs ?
– NB : aussi, quels utilisateurs ont des privilèges système ?
• Sujets = Utilisateurs
• Objets = 3 relations
– dossier_admin
– dossier_medical
– dossier_soins_infirmiers
• Définition du dossier du patientCREATE VIEW dossier_patient AS SELECT *
FROM dossier_admin DA, dossier_medical DM, dossier_soins_infirmiers DSI
WHERE DA.id_patient = DM.id_patient AND
DA.id_patient = DSI.id_patient
51
Expression des règles (exemples)
• R1 : La secrétaire médicale a la permission de gérer le « Dossier_Admin » des patients du groupe médical
GRANT ALL PRIVILEGES
ON dossier_admin
TO Nadine ;
• R2 : Le médecin a la permission de consulter l’intégralité du dossier de ses propres patients
CREATE VIEW dossier_patient_du_medecin ASSELECT *
FROM dossier_patient
WHERE dossier_patient.medecin_traitant = CURRENT_USER ;
(CURRENT_USER : opérateur prédéfini SQL)
GRANT SELECTON dossier_patient_du_medecin
TO Jean, Jeanne ;
52
Expression des règles (exemples)
• R4 : En l’absence de la secrétaire médicale, le médecin a la permission de créer le « dossier_admin » d’un nouveau patient
– Deux tables
• user_status (nom, status) => à créer (et à maintenir)
• user_role (nom, role) => existante dans la métabase
– Définition d’une vue
CREATE VIEW dossier_admin_medecin AS
SELECT * FROM dossier_admin
WHERE NOT EXIST (SELECT *
FROM user_status, user_role
WHERE user_status.nom = user_role.nom
AND user_role.role = ”secretaire_medicale”
AND user_status.status = ”present” ) ;
GRANT INSERT ON dossier_admin_medecin TO Jean, Jeanne ;
– Puissance d’expression élevée mais définition complexe
53
Expression des règles (exemples)
• R5 : les dossiers administratifs ne sont accessibles que pendant les
heures ouvrables
– CREATE VIEW dossier_ouvrable
AS SELECT * FROM dossier_admin
WHERE TO_CHAR(SYSDATE,'HH') BETWEEN '08' AND '18'
en dehors de la période 8H – 18h le predicat est faux!
• R6 : les dossiers administratifs ne sont accessibles qu’à partir des
terminaux du secrétariat
– CREATE VIEW dossier_ouvrable
AS SELECT * FROM dossier_admin
WHERE sys_context(‘USERENV’, 'IP_ADDRESS') IN (‘T1', ‘T2')
le prédicat est faux pour tous les postes clients autres que T1 et T2 !
54
Règle de délégation
• R8 : Un médecin a la permission d’autoriser la secrétaire médicale à mettre
à jour la prescription contenue dans le « Dossier_médical » de ses patients
– Création d ’une vue
CREATE VIEW prescription_du_medecin AS
SELECT dossier_medical.nom_patient, dossier_medical.prescription
FROM dossier_medical
WHERE dossier_medical.medecin_traitant = CURRENT_USER ;
GRANT SELECT, UPDATE(prescription)
ON prescription_du_medecin
TO Jean, Jeanne
WITH GRANT OPTION;
NB: pas de restriction possible des futurs grant
(eg, seulement à la secrétaire médicale…)
55
Conclusion sur DAC-SQL
• Intérêt du concept de vue
– Permet d’exprimer des règles dépendant du contenu
– Permet d’exprimer certaines règles dépendant du contexte
• Règle de délégation
– Complexe à gérer
– « WITH GRANT OPTION » n’est pas suffisant
• Structuration des objets
– Grâce au concept de vue
• Contrôle d’accès basé sur l’identité des sujets
– Pas de structuration des sujets
Intérêt de RBAC
56
RRôle
PPermission
VVue
AAction
OObjet
=N-uplet
UUtilisateur
RBAC : Role-Based Access Control
• Rôle = ensemble de privilèges
• Les accès des utilisateurs sont gérés en fonction de
leur rôle organisationnel
• Principe de la gestion des rôles dans SQL3 :
57
RBAC introduit dans SQL3
• Instructions RBAC de SQL3
– CREATE ROLE <nom_role> ;
• Création d’un nouveau rôle nom_role
– DROP ROLE <nom_role> ;
• Suppression du rôle nom_role
– SET ROLE <liste_roles> ;
• Permet à un utilisateur d’activer un ensemble de rôle pendant la
durée d’une session SQL
58
Adaptation de l’instruction GRANT
• Affectation des privilèges aux rôlesGRANT <liste privileges>
ON <table ou vue>
TO <liste roles>
[ WITH GRANT OPTION ] ;
• Affectation des rôles aux utilisateurs GRANT <liste roles>
TO <liste utilisateurs>
• Rôle junior et rôle seniorGRANT <role1> TO <role2>
Le rôle role2 reçoit tous les privilèges du rôle role1
59
Ex. d’application du modèle
• Création des rôles
CREATE ROLE secretaire_medical ;
• R1 : La secrétaire médicale a la permission de gérer le
« Dossier_Admin » d’un patient du groupe médical
GRANT ALL PRIVILEGES
ON dossier_admin
TO secretaire_medicale ;
• Puis affectation de Nadine au rôle secretaire_medicale
GRANT secretaire_medicale to Nadine ;
60
Hiérarchie de rôles
• Spécialisation/Généralisation
– R1 est un rôle senior de R2
si chaque fois qu’un utilisateur
joue le rôle R1, cet utilisateur
joue aussi le rôle R2
Personnel médical
Médecin
Généraliste Spécialiste
Cardiologue Rhumatologue . . .
• Hiérarchie organisationnelle
– R1 est un rôle senior de R2
si un utilisateur jouant le rôle R1
est un supérieur hiérarchique d’un
utilisateur jouant le rôle R2Médecin
Chef de service
Directeur d ’un département
Directeur d ’un hôpital
61
UUtilisateurs
RRôles
PPermissions
.
.
. SSessions Contraintes
Users-Role Assignment (URA)
Permission-Role
Assignment (PRA)
Hiérarchies
RBAC0 : le noyau (URA + PRA)
RBAC1 : Les hiérarchies
RBAC2 : les contraintes
RBAC3 : hiérarchies + contraintes
Le modèle RBAC complet
62
Les contraintes dans RBAC
• Contrainte sur Utilisateur Rôle
– Contrainte de type « Séparation des pouvoirs »
• Exemple : rôles anesthésiste et chirurgien sont exclusifs
• u, ( URA(u,Anesthésiste) URA(u,Chirurgien) )
• Contrainte sur Session Rôle
– Un utilisateur peut cumuler plusieurs rôles mais pas les
activer dans une même session
• Contrainte de type « Séparation des tâches »
• Contrainte sur Rôle Permission
– Un rôle ne doit pas pouvoir cumuler certaines permissions
• Autre contrainte de type « Séparation des tâches »
63
Exemple de politique RBAC
64
Conclusion sur RBAC SQL
• Conservation des avantages de DAC-SQL
– Possibilité d’exprimer des règles dépendant du contenu et
du contexte
• Intérêt des concepts de vue et de rôle
– Les vues permettent de structurer la gestion des objets
– Les rôles permettent de structurer la gestion des sujets
• Limites des modèles DAC et RBAC (détail après...)
– DAC et RBAC : l’application utilisateur a des droits élevés
– Risque de programmes malveillants
Besoin du modèle MAC
65
Gestion MAC dans un SGBD
• Limites des modèles DAC et RBAC – Hypothèse de DAC
• L’application utilisateur hérite des droits de l’utilisateur
– Hypothèse de RBAC• L’application utilisateur hérite des droits de la session
• Droit de la session = ensemble des rôles activés par l’utilisateur
• Risque de programmes malveillants– Cheval de Troie : programme qui a une fonctionnalité
apparente mais qui contient des fonctions cachées
• Lutte contre les chevaux de Troie – A la connexion, l’utilisateur réduit ses droits à la partie
strictement utile pour la session
– L’usage détourné des données est restreint
66
Exemple de Cheval de Troie
67
Exemple de Cheval de Troie
68
MAC : Mandatory Access Control
• Basé sur le modèle de Bell-LaPadula
• Politique de sécurité multi-niveaux
– Niveaux de sécurité hiérarchiques: cloisonnement vertical
• Unclassified < Confidentiel < Secret < Très secret…
– Catégories: cloisonnement horizontal
• cardiologie, pédiatrie, rhumatologie, ...
– 1 niveau de sécurité + 1 catégorie = 1 classe d’accès
• Le niveau de sécurité d’une classe d’accès associée à un utilisateur
est appelé niveau d’accréditation
• Le niveau de sécurité d’une classe d’accès associée à un objet est
appelé niveau de classification
• Ex. de systèmes supportant un modèle mandataire
– Oracle Label Security, Label-Based Access Control DB2,
Label Security SQL-Server
69
Dominance
• La décision d’accès est prise en comparant les deux
classes d’accès de l’objet et du sujet
– No read up : un sujet est autorisé à lire un objet seulement si
sa classe d’accès domine la classe d’accès de l’objet
– No write down : un sujet est autorisé à écrire un objet si
sa classe d’accès est dominée par la classe d’accès de
l’objet
• Une classe d’accès c1 domine () c2 ssi :
– Le niveau de sécurité de c1 >= niveau de sécurité de c2
– Les catégories de c1 c2
• Les deux classes c1 et c2 sont dites incomparables
ssi ni c1 c2 ni c2 c1 ne sont vérifiées
70
Mandatory Access Control (2)
wri
tes
U
C
TS
S
wri
tes
wri
tes
wri
tes
…..TS
…..S
…..C
…..U
Flot d’information pour la confidentialité
Subjects Objects
71
Mandatory Access Control (3)
Médecin
Le médecin se connecte comme un sujet Unclassified
Fichier D
Unclassified
Pirate
Unclassified
Martin ; pneumonia
David ; ulcer
Dossier médical
Secret
Unclassified
Médecin
Martin ; pneumonia
David ; ulcer
Dossier médical
SecretSecret
Fichier D
Unclassified
Pirate
Secret
Le médecin se connecte comme un sujet Secret
read
A la connexion, un utilisateur reduit ses droits à la partie strictement utile pour la session
Hélas, il est difficile de contrôler tous les moyens de transmettre une information…
72
Synthèse sur les modèles de contrôle d’accès
• Principe fondateur
• DAC– Permet de structurer les Objets
• RBAC– Permet de structurer les Sujets
• MAC– Lutte contre les programmes malveillants
– Mais permet peu de souplesse dans la définition des politiques
=> Vers d’autres modèles (VPD) permettant une implantation de MAC plus souple (OLS)…
Sujet Action ObjetRéaliser Agir sur
73
Base de données privée virtuelle (VPD)
• Principe– Associer une règle de sécurité à une table ou une vue, en fonction d’un
contexte quelconque (lié à cet utilisateur et/ou à l’application)
– Si la VPD est activée, toute requête qui accède à cette relation ou cette vue est automatiquement modifiée en incluant une clause WHERE
• Egalement appelé ‘Fine-grained Access Control’ (FGAC)
Requête Q
Fonction d’ajout de
condition liée au contexte Exécution de
requête
Résultat
Requête Q’ Complétée en
fonction du contexte
Gestionnaire de VPD
Contexte
BD
74
VPD : Contexte d’application
• Oracle a prévu un contexte par défaut
– USERENV : contient des informations système relatives à la
session courante (équiv. sys_context)
– Exemple : CURRENT_USER, HOST, ISDBA …
• Possibilité de créer un nouveau contexte et d’y
associer des attributs
– Exemple :
• Create context CTX_SEC_MEDICALE using
SCHEMA_MED.SEC_MEDICALE
• CTX_SEC_MEDICALE sera un contexte associé au package
PL/SQL nommé SEC_MEDICALE et stocké dans le schéma
SCHEMA_MED
75
VPD : Définition des règles de sécurité• Les règles de sécurité sont écrites en PL/SQL
create package body SEC_MEDICALE asfunction DOSSIER_SEC return varchar2 is
MY_PREDICATE varchar2(2000) ;
begin
MY_PREDICATE := 'id_patient in
(SELECT id_patient
FROM dossier_medical
WHERE medecin_traitant = sys_context(‘USERENV’, ‘CURRENT_USER’))' ;
return MY_PREDICATE ;
end DOSSIER_SEC ;
end SEC_MEDICALE ;
• Puis associées à un objetDBMS_RLS.add_policy // RLS = Row Level Security
( policy_name => ‘mesdossiers',object_schema => 'SCHEMA_MED',object_name => ‘dossier_patient',policy_function => ' DOSSIER_SEC');
Une vue autorisée
Une clause where ad-hoc
76
Exemple de transformation de requêtes• Supposons que Jean formule la requête suivante :
SELECT *
FROM dossier_patient
WHERE id_patient = 'Paul'
• L’application de la politique mesdossiers va automatiquement transformer cette requête en la requête suivante :
SELECT *
FROM dossier_patient
WHERE id_patient = 'Paul'
AND id_patient in (SELECT id_patient
FROM dossier_medical
WHERE medecin_traitant = 'Jean' ) ;
– Jean ne pourra ainsi accéder qu’aux dossiers médicaux de ses patients
Clause where ad-hoc renvoyée par
SEC_MEDICALE.DOSSIER_SEC()
77
Oracle Label Security• Une adaptation de MAC…
• …construite au dessus de VPD et ne nécessitant pas de programmation
• Data label
– Constitué de 3 composants (Level, Compartment, Group)
– Intégré aux tuples dans une colonne additionnelle (déclarée par le DSA)
– Valeurs définies par le DSA
• Level
– Obligatoire, unique, hiérarchique, dénotant la sensibilité de la donnée
– Exemple: Confidential, Sensitive and Highly Sensitive
• Compartment
– Optionnel, non unique, non hiérarchique, utilisé pour compartimenter les données
– Exemple: types de données, liste de projets ou de secteur d’activité
• Group
– Optionnel, non unique, potentiellement hiérarchique, utilisé pour isoler les données par organisation
– Exemple: FBI, CIA
78
Data Label (exemple)
79
User Label
• User Label
– associé à chaque utilisateur
– Mêmes composants: Level, Compartment, Group
• Autorisations requises pour accéder aux données
UserLabel.level DataLabel.level
AND UserLabel.compartment DataLabel.compartment
AND UserLabel.group DataLabel.group
• Exemple
– Une donnée de “DataLabel” (L2: C1,C3: G1,G2)
est accessible avec un “UserLabel” (L2: C1,C2,C3: G1)
mais pas avec un “UserLabel” (L3: C1: G1,G2)
/!\ raffinement dans les slides suivants….
80
Détail des composants du UserLabel (1)
81
Détail des composants du UserLabel (2)
82
Exercice
– C = Confidential, S = Secret
83
Autorisations complémentaires
• Autorisations complémentaires pouvant être données à un
utilisateur ou une procédure stockée
– READ : Oracle ne vérifie plus les labels lors des SELECT
• les opérations update/delete/insert restent contrôlées
– FULL: Oracle ne vérifie plus aucun label
• mais les droits standards sur les objets continuent à s’appliquer (ex: un
GRANT SELECT ON T est toujours requis pour interroger T)
– WRITEUP – WRITEDOWN: donne le droit au user d’augmenter (resp.
réduire) le DataLabel.Level d’un tuple dans la limite de ses propres
capacités
– WRITEACCROSS: donne le droit de modifier Groups et Compartment
d’un DataLabel
• Performance ?
– Un test supplémentaire par tuple (sauf si READ, FULL)
– Création d’un index bitmap sur l’attribut Label est recommandé
84
Synthèse sur les modèles de contrôle d’accès
• Via des vues
• DAC : Permet de structurer les Objets
• RBAC : Permet de structurer les Sujets
• MAC : Intègre l’hypothèse de programmes malveillants
– Lutte contre les chevaux de Troie
– Lourdeur d’implémentation (besoin de cartographier tout le système)
• VPD : Droits fins et contextuels
– Complexe à mettre en œuvre
• OLS: repose sur VPD, facilite (un peu) la mise en œuvre MAC
• Tout cela est TRES puissant… mais pas infaillible
– Nécessite d’avoir confiance dans les utilisateurs
– Nécessite de passer par la porte d’entrée
Audit des accès autorisés et chiffrement de la base
85
Petite classe :
Mise en place de droits d’accès
86
Audit des accès
et
tolérance aux pannes
87
AuditToutes les actions sont auditables…
Problèmes: quoi auditer ? Quoi rechercher ?
88
Objectifs de l’audit
• Sécurité
– Identifier les usages illicites
• Utilisateurs cherchant à outrepasser leurs droits (inférences),
Injection SQL ou Attaque d’un Cheval de Troie (dump), Pertes de
données suspectes (suppressions), etc.
– Identifier les données / comptes compromis
– Tracer des usages exceptionnels (ex: bris de glace)
– Vérifier la conformité d’un usage (ex: prise de décision
médicale)
– Imputer des actions
• Performance
• Amélioration organisationnelle, financière, etc.
89
Comment auditer ?
• L’audit du SGBD peut concerner les objets de la base
– Tables, vues, index, procédures, etc.
– Créations, modification, destruction, mises à jour, etc.
… et toutes les actions systèmes
– Connections à la base, attribution des privilèges, etc.
• Tout peut être audité
– Problème: le volume et l’exploitation de l’audit…
• Moyens:
– Audit par des déclencheurs (triggers)
– Audit en utilisant la commande AUDIT, peuplant la table
d’audit du SGBD
90
Audit par Triggers
• Triggers crées par l’administrateur BD/sécurité
– Déclenchés sur des événements « systèmes » (LOGON,
CREATE, DROP…)
• Localité de l’événement contrôlable (dans un schéma, etc.)
– Déclenchés sur des événements « objets » (INSERT,
DELETE, UPDATE)
• Avantages: faible volume, analyse ciblée
– choix fin des actions à auditer, activation à la demande
• Limites: certaines actions son difficiles à auditer
– Ex: auditer les requêtes (SELECT)
91
Les triggers dans la norme SQL• Définition
– Action ou ensemble d'actions déclenchée(s) automatiquement lorsqu'une condition se trouve satisfaite après l'apparition d'un événement
• Un déclencheur est une règle ECA– Événement = mise à jour d'une relation (INSERT, DELETE, UPDATE)
– Condition = optionnelle, équivaut à une clause WHERE
– Action = exécution de code spécifique (ordre SQL ou PL/SQL)• Requête SQL de mise à jour, exécution d'une procédure stockée, abandon
d'une transaction, ...
• De multiples usages sont possibles– Étendre les mécanismes de contrôle d’intégrité
• Validation des données entrées, maintien de règles d’intégrité complexes
– Contrôle dynamique et évolutif des manipulations de la BD• Maintien de statistiques, audit de la base (sécurité)
– Duplication • Mise à jour de copies multiples, Dérivation des données additionnelles
– Mise à jour au travers de vues
93
Norme SQL : Gestion des Triggers
• La création d’un trigger déclenche son activation
• On peut remplacer la version précédente d’un trigger
• On peut manuellement activer/désactiver un trigger
CREATE [OR REPLACE ] TRIGGER <nom-trigger>
<événement> [<condition>] <action>*
DROP TRIGGER <nom-trigger>
ALTER TRIGGER <nom-trigger> ENABLE
ALTER TRIGGER <nom-trigger> DISABLE
94
Triggers des SGBD commerciaux
• Différences avec le standard
• Oracle– 1 seul trigger déclenché par un même évènement
– Condition : ne peut contenir de requête SQL
– Action : • 1 bloc PL/SQL anonyme sans COMMIT/ROLLBACK
• Pas de mise à jour de la table ayant levé le trigger
• Pas de lecture de la table ayant levé le trigger ligne
• Informix9– Condition : ne peut contenir de requête SQL
– Action• 1 seul ordre PL/SQL
• ou 1 seul appel de procédure/fonction
95
Définition globale des triggers Oracle
• Lors d’une requête de MAJ sur une table…
– Insert, delete, update
• […si la clause when est vérifiée…]
– Condition sur le tuple mis à jour
• … exécution du bloc PL/SQL
– Une fois trigger ordre
• Avant ou après l’ordre
– Une fois par tuple mis à jour trigger ligne
• Avant ou après chaque mise à jour
– Pour la syntaxe détaillée du PL/SQL, voir cours PL/SQL…
– NB : des clauses PL/SQL sont propres aux triggers
• INSERTING, DELETING, UPDATING utilisables dans les IF
CREATE TRIGGER <nom-trigger>
<BEFORE | AFTER>
<INSERT | DELETE | UPDATE>
ON <nom_de_table>
[WHEN (<condition_sur_la_ligne>)]
[FOR EACH <ROW|STATEMENT>]
-- BLOC PL/SQL
DECLARE …
BEGIN …
END;
96
Triggers ordre Oracle (1)
CREATE TRIGGER <nom-trigger>
<qd_executer> <ordre_sql> ON <nom_table>
[FOR EACH STATEMENT]
<bloc_plsql>
<qd_executer> ::= BEFORE | AFTER
<ordre_sql> ::= < INSERT | DELETE | UPDATE [OF<liste_colonnes>] >
[OR <ordre_sql>]
CREATE TRIGGER vérif_qté
AFTER INSERT OR UPDATE OF qté ON Abus
DECLARE
qté_produite NUMBER;
qté_bue NUMBER;
BEGIN
SELECT SUM(qté) into qté_produite FROM Vins;
SELECT SUM(qté) into qté_bue FROM Abus;
IF qté_produite > qté_bue THEN
raise_application_error(-20001, ‘mise à jour incohérente’);
END IF;
END;
Exemple
97
Triggers ordre Oracle (2)
• Exécution du trigger avant ou après la requête (ordre)
– Avant : mises à jour de l’ordre toutes invisibles
– Après : mises à jour de l’ordre toutes visibles
– Dans le trigger : mise à jour impossible de la table modifiée
• Ex. du trigger vérif_qté
Ch
ron
olo
gie
SCN = 8
SCN = 9
SCN = 10
SCN = 7
SCN = 11
Transaction
Insert into Abus as select…
Req
uête
SCN = 9
SCN = 8
Trigger vérif_qté
Abus
Déclenche
(après insertions)
SCN =11
98
Exercice 1
• Créer un trigger ordre qui s’assure que les
modifications sur la table Emp ont bien lieu pendant
les jours ouvrables (du lundi au vendredi)
– Vous pourrez utiliser la fonction TO_CHAR(SYSDATE, ‘DY’)
qui retourne le jour courant ‘MON’, ‘TUE’, ‘WED’, ‘THU’,
‘FRI’, ‘SAT’, ‘SUN’
CREATE TRIGGER emp_changements_permis
BEFORE DELETE OR INSERT OR UPDATE ON Emp
BEGIN
IF TO_CHAR(SYSDATE,‘DY’)=‘SAT’ OR TO_CHAR(SYSDATE,‘DY’)=‘SUN’ THEN
raise_application_error(-20001, ‘pas de changement le week end’);
END IF;
END;
99
Triggers ligne Oracle (1)
• Variables de transition old et new– nommées implicitement old et new, ou explicitement dans le referencing
– utilisables dans le bloc PL/SQL par :new.nom_col et :old.nom_col
– NB: pas de new lors d’un delete, pas de old lors d’un insert
• Clause when– Attribut = valeur du tuple avant ou après (old.nom_col ou new.nom_col)
– Valeur = attribut ou ‘xxx’, mais ne peut être résultat d’une requête
CREATE TRIGGER <nom-trigger> [INSTEAD OF]
<qd_executer> <ordre_sql> ON <nom_table>
[REFERENCING OLD AS <nom_old> NEW AS <nom_new>]
FOR EACH ROW
WHEN(<condition>)
<bloc_plsql>
<qd_executer> ::= BEFORE | AFTER
<ordre_sql> ::= < INSERT | DELETE | UPDATE [OF<liste_colonnes>] >
[OR <ordre_sql>]
<condition> ::= <attribut> <|>|!=|=|[NOT]<IN|BETWEEN|LIKE> <valeur>
100
Triggers ligne Oracle (2)
• Exécution avant ou après chaque mise à jour de tuple
• Difficile de gérer les requêtes sur la table en mutation
– Les exécution du trigger devraient pouvoir lire la table
– Mais lecture de la table mise à jour erreur ‘mutating table’
• Raison technique : mise à jour des index en fin de requête, update et
delete posent des verrous sur les tuples à modifier ou supprimer, …
Ch
ron
olo
gie
SCN = 8
SCN = 9
SCN = 10
SCN = 7
SCN = 11
Transaction
Update from Vin where…
Req
uête
Req
uête
SCN = 9
SCN = 8
SCN = 11
Trigger degrès_croissant
Vin
Déclenche
SCN =9
Déclenche
SCN =9
Trigger degrès_croissant
101
Exercice 2
• Créer un trigger ligne qui s’assure que lorsqu’un employé est
embauché pour un type d’emploi, son salaire soit dans les
bornes admises pour ce type d’emploi. Les tables ont la
structure suivante :
– Employés (Id, Nom, Prénom, Salaire, Emploi, Dept)
– TypeEmploi (Emploi, Sal_inf, Sal_sup)CREATE TRIGGER verif_salaire
BEFORE INSERT OR UPDATE OF salaire, emploi ON Emp
FOR EACH ROW
DECLARE
min_sal NUMBER;
max_sal NUMBER;
BEGIN
SELECT Sal_inf, Sal_sup INTO min_sal, max_sal
FROM TypeEmploi WHERE Emploi = :NEW.Emploi;
IF min_sal > :NEW.Salaire OR max_sal < :NEW.Salaire THEN
raise_application_error(-20001,
‘Salaire hors limite pour ’|| :NEW.Nom);
END IF;
END;
102
Commandes Oracle relatives aux triggers
• DROP TRIGGER… : efface le trigger
• Slash (/) : permet de compiler le trigger dans SQLPlus
• SHOW ERRORS
– affiche les erreurs dans le cas où le trigger aurait été crée
avec des erreurs de compilation dans SQLPlus
• CREATE OR REPLACE TRIGGER… : permet de
remplacer le trigger s’il existe déjà
103
Résumé des limites des triggers Oracle
• Un trigger– Ne peut contenir de COMMIT ou de ROLLBACK
– Ne peut mettre à jour la table qui le déclenche
• Un trigger ordre – ne peut utiliser OLD et NEW
• Un trigger ligne– Ne peut selectionner (lire) la table qui le déclenche, sauf dans le cas
d’un BEFORE INSERT déclenché par un ordre SQL unitaire du type INSERT INTO <table> VALUES(…);
• Un trigger INSTEAD OF– Ne peut etre déclenché lors d’un ordre sur autre chose qu’une vue (ex:
une table)
104
Exercice 3
• Dire ce qu’il se passe quand on exécute les triggers suivants
CREATE TRIGGER auto_count
AFTER INSERT OR DELETE ON employee
DECLARE
i NUMBER;
BEGIN
SELECT COUNT(*) INTO i FROM employes ;
INSERT INTO stat VALUES (‘nombre d’employes = ’|| i);
END;
CREATE TRIGGER audit_temp
AFTER DELETE ON temp
BEGIN
INSERT INTO temp VALUES (‘suppression de ligne:’||SYSDATE);
END;
CREATE TRIGGER dates_commandes_croissante
AFTER INSERT ON commande
FOR EACH ROW
DECLARE
max_date NUMBER;
BEGIN
SELECT MAX(date_com) INTO max_date FROM commande;
IF :NEW.date_com < max_date THEN
RAISE_APPLICATION_ERROR(20001, ‘date invalide’);
END IF;
END;
105
Le mode AUDIT du SGBD
• Les actions auditées sont stockées
– dans une table du SGBD (Oracle: SYS.AUD$)
– dans un fichier de l’OS (permet l’audit de plusieurs bases)
• Actions auditables:
– les connexions à la base
– les actions qui affectent un type d’objet (table, rôle, etc.)
– les actions qui affectent un objet (table EMP)
… Aussi bien pour les actions réussies et non réussies
• Activer / désactiver l’audit:
– ALTER SYSTEM SET audit_trail=db,extended scope=spfile;
• Puis redémarrer l’instance Oracle…
– NOAUDIT ALL;
106
Utilisation de la table d’audit
• Table d’audit Oracle
– SYS.AUD$ du tablespace SYSTEM
• L’archiver et la purger périodiquement
– Privilège DELETE_CATALOG_ROLE
• Pour consulter l’audit
– L’interroger en SQL la table SYS.AUD$
– Utiliser les vues de l’audit_trail
• DBA_AUDIT_OBJECT,
• DBA_AUDIT_STATEMENT,
• DBA_AUDIT_SESSION,
• etc…
107
Types d’audit• Audit de connexion
– Audite chaque tentative de connexion:
Ex: AUDIT SESSION [WHENEVER [NOT] SUCCESSFUL];
– Résultat de l’audit: SYS.AUD$, DBA_AUDIT_SESSION
• Audit des actions
– Audite chaque tentative d’action d’un certain type
Ex: AUDIT CREATE TABLE; AUDIT ROLE;
AUDIT CONNECT; AUDIT DBA; …
• Résultat de l’audit: SYS.AUD$, DBA_AUDIT_STATEMENT
• Pour arrêter l’audit: commande NOAUDIT Ex: NOAUDIT CREATE TABLE, NOAUDIT
ROLE; …
• Audit des objets
– Audite un objet particulier (par session, ou par accès)
Ex . AUDIT INSERT ON EMP; AUDIT DELET ON COM BY SESSION
– Résultat de l’audit: SYS.AUD$, DBA_AUDIT_OBJECT
• Audit d’un utilisateur particulier
– AUDIT SELECT TABLE, UPDATE TABLE BY scott, blake;
108
Conclusion sur l’audit
• Contrôler le volume et le contenu de la table d’audit
• Limiter le droit de supprimer dans la table
– Attention au DBA et à tous les utilisateurs ayant le privilège
DELETE_CATALOG_ROLE
• Toute action ou tentative d’action sur la table d’audit
peut être auditée elle aussi
109
La tolérance aux pannes
• Types de pannes qui peuvent survenir…
– Abandons de transaction (transaction failure)
– Pertes de la mémoire vive (system failure)
– Perte du disque (media failure)
• Ce que l’on veut éviter en cas de panne
– L’exécution partielle de transactions
– La perte de transactions validées
transgression des règles d’Atomicité / Durabilité
• Solution : des techniques de tolérance aux pannes
– Journalisation, sauvegardes
– Algorithmes de reprise après panne
111
Abandon de transaction
Assurer l’Atomicité
A solde1
A A -
Solde1 A
A Solde2
A A +
Solde2 A
Commit
Transaction 1
Défaire sur disque
Base de données
Terminal 1 Terminal 2
Contrainte
d’intégrité
Plantage
client
Concurrence
Abort
client
Transaction 2
A solde
A A +
Solde A
CommitC
hro
no
log
ie
112
Défaillance de site
Assurer l’Atomicité et la Durabilité
A solde1
A A -
Solde1 A
A Solde2
A A +
Solde2 A
Commit
Transaction 1
Base de données
Terminal 1Terminal 2Plantage
serveur
Panne de
courant
Transaction 2
A solde
A A +
Solde A
Commit
Ch
ron
olo
gie
Terminal 3
Transaction 3
A solde
A A +
Solde A
Commit
Défaire sur disque Défaire sur disque Refaire sur disque
113
Défaillance de mémoire secondaire
Assurer la Durabilité
A solde1
A A -
Solde1 A
A Solde2
A A +
Solde2 A
Commit
Transaction 1
Base de données
Terminal 1Terminal 2
Transaction 2
A solde
A A +
Solde A
Commit
Ch
ron
olo
gie
Terminal 3
Transaction 3
A solde
A A +
Solde A
Commit
Refaire sur disque
Incendie
Crash disque
Défaire sur disque Défaire sur disque
114
Tolérer l’abandon de transaction
• Objectif
– Éliminer les effets de l’exécution partielle de la transaction
• Mise en œuvre
– Effacer la mémoire de la transaction abandonnée (son cache)
• Ne plus rien reporter sur disque de ses effets en cache
– Retirer les effets de la transaction sur disque
• Si aucune modification reportée sur disque Rien à faire…
• Sinon
– Remplacer les valeurs modifiées par leur valeur avant modification
– Retirer tous les objets ajoutés par la transaction
• Cela suppose
1 Pendant la transaction: Garder l’historique des valeurs avant
modification par la transaction
2 Au commit : Ajouter sur disque les pages modifiées*
et faire un commit atomique
*peut être effectué avant le commit de façon asynchrone
115
• Pour retirer du disque les effets de la transaction abandonnée
– Journal avant
• Fichier séquentiel stockant les valeurs avant mise à jour de chaque objet modifié
– Mise à jour d’un objet par la transaction
écriture de sa valeur avant modification
– Validation de la transaction : écrire le fait qu’elle a validé
• Le journal est ensuite utilisé pour défaire les mises à jour reportées sur disque
• Utilisation: on part de la fin du journal, toute MAJ rencontrée effectuée par une
transaction non validée est annulée (en place) sur le disque
Abandon utilisant le journal avant
Mémoire
secondaire
Mémoire de la
transaction
Base de données
Mises à jour
Écrit p
ageL
it p
age
Lit p
ageImages avant
modification
Pourquoi ?
116
Tolérer la défaillance de site• Perte du contenu de la mémoire vive
– S’appelle aussi la reprise à chaud
• But– Annuler les effets sur disque des transactions non validées
– Rétablir les effets sur disques des transactions validées avant la panne
• Mise en œuvre – Défaire les effets présents sur disque des transactions non validées
• Aucune modification reportée sur disque rien à faire…
• Sinon défaire avec le journal d’images avant
Journal avant en mémoire secondaire (support persistent) !
– Refaire les effets absents du disque des transactions validées• Si toutes les modifications sont déjà reportées sur disque
– rien à faire…
• Sinon
– Remplacer les valeurs par leur valeur après modification
– Écrire tous les objets crées par la transaction
A la validation d’une transaction, on journalise ses valeurs après mise à jour
117
Reprise à chaud utilisant les journaux• Défaire les effets présents sur disque des transactions non validées
– Journal avant, sur un stockage persistant
• Refaire les effets absents du disque des transactions validées
– Journal après (en mémoire secondaire)
• Fichier séquentiel stockant les valeur après mise à jour de chaque objet modifié
• Mise à jour d’un objet par la transaction écriture de sa valeur après modification
• Le journal est ensuite utilisé pour refaire les mises à jour non reportées sur disque
• Utilisation : on part du début du journal après, on refait toutes les transactions sur disque
Mémoire
secondaire
Mémoire de la transaction
Base de données
Mises à jour
Écrit p
ageL
it p
age
Lit p
age
Journal aprèsJournal avant
RefaireDéfaire
118
Conclusion intermédiaire…• Abandon de transaction
– Journal avant : défait les effets sur disque de la transaction
• Peut être en RAM
• Utile si on reporte le cache de la transaction sur disque avant validation
• Il contient les images avant de chaque transaction (non validée)
• Reprise à chaud– Journal avant : pour défaire
• Doit être en mémoire persistante
• Utile si on reporte le cache de la transaction sur disque avant validation
– Journal après : pour refaire
• Doit être en mémoire persistante
• Utile si on ne reporte pas le cache de la transaction après validation
• Il contient les images après des transactions validées
La gestion du cache détermine l’existence des journaux
119
Politiques de gestion de cache
• Détermine l'instant du report sur disque des pages modifiées
– STEAL (resp. NO_STEAL)
• Des pages modifiées par des transactions non validées peuvent être reportées sur
disque
– FORCE (resp. NO_FORCE)
• À la validation d'une transaction, toutes les pages qu'elle a modifiées sont
obligatoirement présentes sur disque
• Politiques de gestion de cache possibles
– NO-STEAL / FORCE
– STEAL / FORCE
– NO-STEAL / NO-FORCE
– STEAL / NO-FORCE : aucune hypothèse sur la politique de gestion de cache
( politique considérée par les SGBD commerciaux)
Détermine le mode de gestion du journal en cas de reprise à chaud
120
No-steal, Force
• Avantage: Presque rien à faire pour la reprise à chaud…
• Reprise à chaud des transactions validées
– Tous les effets de la transaction sont dans la base
Inutile de refaire des mises à jour
• Reprise à chaud : des transactions non validées…
– …. Dont les effets ne sont pas dans la base
Inutile de défaire des mises à jour
– Cas de la panne pendant le commit
• Mais: mauvaises performances…
– BUT: support du mode STEAL / NO FORCE
Mémoire de la transaction
Base de données
Mises à jour
Lit p
age
Lit p
age
Mini-journal
(temp.)
– Une partie des effets de la
transaction est dans la base
Gérer sur disque un mini-journal
temporaire d’images avant pour
défaire la transaction…
121
• Des pages modifiées par des transactions non validées peuvent être déjà
reportées sur disque
• En cas de panne avant le commit, l’Atomicité n’est pas assurée
Stocker les images avant pour défaire éventuellement les mises à jour
• Règle du Write Ahead Logging (WAL)
– Toute mise à jour est précédée d'une écriture dans le journal d'images avant
permettant d'invalider cette mise à jour en cas de ‘panne’
Steal => journal avant
Journal avant
Mémoire de la transaction
Base de données
Mises à jour
Lit p
age
Lit p
age
Écrit pages
Ste
al
Mémoire
secondaire
WAL
122
• Les pages modifiées par une transaction ne sont pas toutes nécessairement
reportées sur disque au commit
• En cas de panne après le commit, la Durabilité n’est pas assurée
Stocker les images après pour refaire éventuellement les mises à jour
• Règle du Force Log at Commit
– Toute validation de transaction doit être précédée de l'écriture de son journal
d'images après sur un disque différent de celui contenant la base de données
Mémoire
secondaire
No-force => journal après
Mémoire de la transaction
Base de données
Mises à jour
Co
mm
itLit p
age
Lit p
age Journal après
Force log
123
• Steal
– Mises à jour peuvent être effectuées dans la base avant le commit
Défaire les mises à jour non commises (journal avant)
• No-force
– Mises à jour pas forcément reportées dans la base après le commit
Refaire les mises à jour commises (journal après)
Les problèmes possibles : panne avant/après commit
Steal, No-force : défaire et refaire
Mémoire
secondaire
Mémoire de la transaction
Base de données
Mises à jour
Ste
al
Lit p
age
Lit p
age
Journal aprèsForce log
Journal avantWAL
Refaire
Panne avant commit
Défaire
Panne après commit
124
Tolérer la défaillance de mém. 2ndaire
• S’appelle aussi reprise à froid…
– Perte du contenu de la mémoire persistante
• Refaire sur disque les effets des transactions validées
– Reconstruction complète de la base avec le journal après
Journal après sur un autre disque !
Mémoire de la transaction
Base de données
Mises à jour
Écrit p
ageL
it p
age
Lit p
age
Journal aprèsJournal
avant
RefaireDéfaire
Mémoire
secondaire
Force logWAL
125
Algorithme de reprise à froid
• Performances: utilisation de « backup »
(ie, points de reprise ou « checkpoints »)
– Recharger la base avec le dernier « backup »
– Refaire les transactions validées du journal redo log (image après)
• NB: le backup peut être réalisé à partir du redo log…
Sauvegarde du
journal après
Chronologie
Journal aprèsForce Log at Commit
Base de données
Réduit la taille
sur disque du
journal
Sauvegarde de
la BD
Pour
reconstruire
plus vite…
Disponible? Disponible!
126
Conclusion sur la journalisation
• Journaux : qu'y trouve t-on ?– Identifiant de la transaction
– Identifiant de l'enregistrement de la BD
– Valeur avant
– Valeur après
• Défaire– Lecture de la fin vers le début du journal des images avant
– On défait toutes les transactions non commises
– Garantir l‘Atomicité des transactions
• Refaire– Lecture du début vers la fin du journal des images après
– On refait toutes les transactions validées
– Garantir la Durabilité
127
Vrai ou faux ?
• Le concept de transaction (ACID) n’est nécessaire que dans le cas où il y a plusieurs utilisateurs
• Les protocoles de reprise assurent uniquement l’Atomicité et la Durabilité des données
• Le SGBD doit assurer la validation et la durabilité de la transaction dès qu’il reçoit le commit
• Le crash du disque servant à stocker le journal après empêche la reprise à froid
• Le group commit empêche de refaire les transactions validées du groupe en cours
• Le crash du journal avant empêche la reprise à chaud
• Un point de reprise ne sert qu’à accélérer la reprise à chaud
• Dans un système qui ne tombe jamais en panne, les journaux d’images avant et d’images après ne servent à rien.
Faux (même pour I!)
Quand il a répondu favorablement au commit
C’est son rôle
Le système répond aux commits seulement si tout le groupe est reporté sur disque
C’est son rôle
Une optimisation
Un ABORT n’est pas une panne et a besoin du journal avant (mais pas journal après)
Oui, par définition
128
Tolérance aux pannes dans Oracle (1)
• Gestion de cache : steal, no-force
– Des pages modifiées par des transactions non validées
peuvent être reportées sur disque
– À la validation d'une transaction, toutes les pages qu'elle a
modifiées ne sont pas obligatoirement reportées sur disque
Gestion de journaux avant et après
• Journal avant : les Rollback segments
• Journal après : les fichiers Redo Logs
129
Tolérance aux pannes dans Oracle (2)• Les Rollback Segments
– En cas de panne, servent à défaire des mises à jour
– Un Rollback Segment par transaction active
– Écritures en Rollback Segmentsprotégées par le journal après
les premiers objets restaurés en cas de reprise après panne…
– Remarque : ce sont ces segments qui sont utilisés pour implémenter la lecture cohérente des données
NB : Read Consistency d’Oracle
Partie active
Partie inactive
T1 T2
130
Tolérance aux pannes dans Oracle (3)
• Les Redo Logs– En cas de panne, servent à refaire des mise à jour
• Ils refont en premier les Rollback Segments
– Les Redo Logs sont remplis en mode circulaire• On en sauve un sur disque pendant que les autres se remplissent
• Il doit y avoir au moins deux fichiers formant les Redo Logs
– Écriture sur disque des Redo Logs• Au commit
• Quand le buffer cache stockant les logs est rempli au tiers
• Lors d’un checkpoint
• Après time-out
Fichier log 1 Fichier log 2
Sauvegarde du
journal après
« switch »
« switch »
131
Conclusion – Tolérance aux pannes
• Le SGBD assure que chaque transaction reste
– Atomique
• Entièrement exécutée ou pas du tout
• Tolérance aux pannes (journal avant, commit atomiques, …)
– Cohérente
• Respecte les règles d'intégrité…
• Comment définir et implanter les contraintes ) voir la suite
– Isolée
• Seules les mises à jour validées sont visibles
• Contrôle de concurrence (verrouillage, estampillage, versionning, …)
– Durable
• Les mises à jour validées ne peuvent jamais être perdues
• Tolérance aux pannes (journal après, checkpoint, …)
132
Petite classe
Expériences sur l’audit des
accès et la tolérance aux
pannes
133
Sécurité du SGBD
134
Sécurité des SI (ITSEC)Information Technology Security Evaluation Criteria
• Confidentialité
– Seules les personnes autorisées ont accès aux ressources
• Intégrité
– Les ressources du SI ne sont pas corrompues
• Disponibilité
– L’accès aux ressources du SI est garanti de facon
permanente
• BD: les ressources sont les données de la BD + traitement
activables sur les données
• Et dans certains contexte
– Auditabilité, imputabilité
135
DBMS : qui attaque ?
• Pirate externe– capable de s’infiltrer sur le serveur
BD et de lire ses fichiers
– capable de casser une clé de chiffrement avec un texte connu
• Pirate utilisateur– est reconnu par le SGBD et a accès
à une partie des données
– suivant le mode de chiffrement, il a accès à certaines clés
• Pirate administrateur (DBA)– employé peu scrupuleux ou pirate
s’étant octroyé ces droits
– a accès à des données inaccessibles aux autres pirates (journal)
– peut espionner le SGBD pendant l’exécution
Client C2
Pirate utilisateur
Client C3
Client C1
Pirate administrateur
BD P.M.E.
Serveur BD
BD
Pirate externe
136
Principales défenses
137
Chiffrement de BD
• Protection cryptographique pour
• Protéger les données de la BD
– Observation / altération illicite
• Protéger le moteur d’exécution de la BD
– Vérifier la complétude/exactitude des résultats
138
Objectifs du chiffrement de la BD
• Seule solution pour résister aux attaques sur les fichiers=> Chiffrer l’empreinte disque de la BD
• Questions:– Peut-on chiffrer une BD de manière sûre avec un algorithme de
chiffrement sûr ?
– A quel niveau faut-il chiffrer: OS / application / SGBD ?
– Quelle approche de chiffrement SGBD: serveur / client / matériel sûr ?
• Solutions commerciales: basées sur l’approche serveur– Procédures stockées de chiffrement: Obfuscation Toolkit
– SQL étendu au support du chiffrement: Transparent Data Encryption
– Séparation des tâches: Ex. Protegrity Data Security Platform
139
Chiffrement Symétrique (“à clé secrête”)
• Auteur et destinataire des messages partagent un secret (clé)– Le secret permet de chiffrer et le déchiffrer les messages
• La sécurité repose sur ce seul secret – Tous les détails du système sont publics, même les fonctions de
chiffrement/déchiffrement
ALICE BOB
m c
MARVIN
c m
c = CK(m) m = DK(c)
= DK(CK(m))
Ch
iffr
e
dé
ch
iffr
e
Secret partagé: clé
K
140
Chiffrement symétrique (algos)
• Un algorithme sûr résiste aux attaques suivantes:
– L’attaquant connait le texte chiffré c il trouve m, ou mieux, la clé K
– L’attaquant connait des couples clair / chiffré (m, c) il trouve K, ou peut déchiffrer d’autres messages
• DES : Data Encryption Standard (1976 – 1997)
– Chiffrement par bloc de 64 bits
– Chiffrement/déchiffrement = même algorithme
– La clé fait 56 bits
• 3DES : Remplace DES (1997 – 2001)
– Nécessite 3 clés de 56 bits
– 3DES(k1k2k3, m) = DES(k3,DES(k2,DES(k1,m)))
• RIJNDAEL (AES) : Utilisé depuis 2001 (standard depuis 2002)
– Chiffrement par bloc de 128 bits
– La clé fait 128, 192 ou 256 bits
– Rapide, nécessite peu de mémoire
– 1997: 39 jours sur 10 000 Pentium
– 1998: une clé DES cassée en 56h (pour 250 000 $)
– 2007: 6.4 jours sur une machine parallèle ($10,000)
– La meilleure attaque connue nécessite 232
messages clairs connus, 2113 étapes, 290
chiffrements DES, et 288 mémoire !!
– 3DES est sûr (actuellement)
– Seules des attaques canal latéral ont été réussies
sur AES
– Voir www.cryptosystem.net/aes/ pour information
– AES est sûr (actuellement)
Puis-je chiffrer une BD avec 3DES ou AES sans problème ?
141
Application du chiffrement à une BD
• Les algorithmes de chiffrement résistent aux attaques
… mais pas toujours leur mise en œuvre
• Le contexte BD a des spécificités difficiles à prendre en compte
– Gros volume de données
– Gros besoins de performance
– Motifs répétés, distribution qui peuvent être connues
– Données modifiables
142
Problème du choix du mode opératoire
• Mode ECB => attaque par analyse de fréquence
– ECB : Motif en clair identiques => motif chiffré identique
• Mode CTR => attaque par comparaisons successives
– CTR : m XOR m’ = DK(m) XOR DK(m’) => information sur le contenu des MAJ !
Les spécificités du contexte BD doivent être prises en compte…
Quid des “concessions” faites à la sécurité pour raisons de perf.?
3DES + Mode opératoire ECB
3DES + Mode opératoire CBC
Chiffrer une BD avec un algorithme sûr pose problème…
143
Problème de performance
• Traiter directement les données chiffrées est
impossible
• Indexer des données chiffrées ne sert à rien
• SAUF SI: on dispose de chiffrement à propriétés
particulières
– Ex. Préservant l’égalité [Ora07, BoP02], l’ordre [AKS+04], ou
l’homomorphisme [GeZ07]
=> Compromis sécurité / performance…
144
A quel niveau chiffrer ?
• Chiffrement niveau OS => chiffrement fichiers/stockage
– Transparent pour le SGBD et l’application
– … mais chiffrement non sélectif• Chiffrement non lié au droits d’accès
(1 clé par privilège)
• Chiffrement partiel proscrit => performances !
Encrypted Data
Storage layer
Encrypt/Decrypt
Server
RAM
Database Server
DBMS engine
Keys
Data
Application
Solution retenue par certains SGBD(ex: MS SQLServeur, IBM DB2)
145
Chiffrer au niveau application
– Chiffrement sélectif possible
– Résistance aux attaques internes
– Aucune transparence pour l’application• L’application pilote chiffrement/déchiffrement
– Et gère les clés…
• Et prend en charge des traitements BD
– Requêtes, droits, contrôle d’intégrité…
– Dégradation importante des performances
– Le client peut attaquer les droits d’accès• Les données et les clés sont en clair sur le client
– Difficile d’implanter plusieurs applications
Database Server
Encrypted Data
Storage layer
Server
RAM
DBMS engine
Client
RAM
Keys
Data Application
Encrypt/Decrypt
Application
Solution toujours possible mais pose bcp de problèmes
146
Chiffrer au niveau SGBD
– Chiffrement sélectif (spécifique)
• Chiffrer selon les privilèges utilisateur
• Chiffrer les données les plus sensibles
– au niveau table, ligne, colonne…
– … de façon conditionnelle (salaire >10K)
– Transparence pour l’application
– … mais mécanismes internes SGBD à revisiter
• Evaluation de requête + indexation sur des données chiffrées impossible
– sauf chiffrement à propriétés particulières (préservant égalité ou l’ordre => dangereux pour la sécurité)
• Surtout dans un contexte où le serveur n’est pas de confiance (approche client)
– … et problème de performance en perspective
Encrypted Data
Storage layer
Server
RAM
Database Server
DBMS engine
Keys
Data
Encrypt/Decrypt
Application
Solution retenue par certains SGBD (Oracle)
147
Solution « crypto package »
• L’éditeur du SGBD fournit un « package »
– Procédures / fonctions de chiffrement / déchiffrement
– Ex: Oracle Obfuscation Toolkit
• Problèmes
– Difficile à mettre en œuvre
• Package utilisé par le programmeur du SGBD (trigger/proc.) / de l’application
• Gestion des clés laissée aussi à la charge du programmeur
• Impossible d’interroger des données chiffrées…
– Limites inhérentes à l’approche serveur
• Les packages peuvent être substitués (par le DBA, …)
• Les clés sont transmises (voire stockées) au serveur qui chiffre/déchiffre
• Les données apparaissent en clair sur le serveur à l’execution
En pratique: usage limité aux données très sensibles
(Ex: chiffrement des logins/mots de passe)
148
Solution « chiffrement transparent »
• SQL étendu à la gestion du chiffrement
– Transparent pour les applications
• Chiffrement niveau attribut (Oracle 10g)
– Certaines colonnes sont chiffrées dans tous les tablespaces
(même temporaires), SGA, logs/backups…
• La colonne peut rester indexable (option NO_SALT)
…. Mais l’attaque par analyse de fréquence est alors possible !
– Certains tablespace sont chiffrés (Oracle 11g)
• Tablespaces complets chiffrés sur disque, déchiffrés en SGA
• Indexation classique (indexes chiffrés fabriqués sur le clair)
• Master key chiffrée par un mot de passe (admin.)
ou stockée dans un HSM
• Exemples: Oracle Transparent Data Encryption (TDE),
SQL server 2008 TDE, …
149
Approche client : le principe
• Chiffrement coté client– Pas de transmission du texte clair ni des clés au serveur
– Le traitement s’effectue sur le client (pire cas)
• La BD est protégée coté serveur– Le serveur résiste aux attaque internes
– Mais… dégradation très importante des performances
Problème : déporter la majeure partie du traitement sur le serveur (données chiffrées), sans perte de sécurité
• Limites de l’approche client– Gestionnaire de droits côté client
– Données et clés en clair sur le client
– Or le client n’est pas forcément un site de confiance
– Donc ne convient pas à une BD partagée (BD privée uniquement)
Database Server
Encrypted Data
Storage layer
Server
RAM
DBMS engine
Client
RAM
Keys
Data Client
Encrypt/Decrypt
150
Approche client : les techniques
• L’objectif est de déporter le plus possible de taches
sur le serveur sans compromettre la sécurité
• Indexation des données
– Indexation sur le chiffré
• Utilisation d’un mode de chiffrement avec des propriétés particulières
• Ex: préservant l’égalité [Ora07, BoP02], l’ordre [AKS+04], ou
l’homomorphisme [GeZ07]
• Le serveur maintient un index sur le chiffré
• Le client interroge en posant des questions sur le chiffré
• C’est un compromis sécurité / performance…
– Etiquetage des tuples
• Le client pose des étiquettes, pour sélectionner/joindre
• Les étiquettes sont statistiquement indistingables
151
Solution par étiquetage [HIL+02]
• Granule de chiffrement = tuple
• Ajout d’étiquettes d’attributs
– Indique qu’un attribut de tuple appartient à une plage de
valeurs
– Permet des traitements (approximatifs) sur le serveur
• Sélection, jointure, groupement
id name salaryage
Encrypted row Iid Iname IageIsalary
tuple:
tuple chiffré:
étiquète
152
• Partitionner le domaine de variation d’un attribut
Attributs numériques
Connaissance du client
Connaissance du serveur
32<Age<40
IAge= 12
OR
IAge= 3
Age=53
IAge= 9
h(1)=17
20 54
h(2)=4 h(3)=12 h(4)=3 h(5)=6 h(6)=1 h(7)=9
24 31 35 40 48 50
Inférences => distribution
uniforme
(nb tuples par partition identique)
• connaissance a priori vs.
updates?
• combinaison d’indices?
• (à suivre…)
E(R1) 3
E(R2) 9
E(R3) 4
(Age=37)
(Age=53)
(Age=26)
IAge
153
Architecture
Encrypted User
Database
Query
Translator
Server Site
Temporary
Results
Query
Executer
Metadata
Original Query
Server Side
Query
Encrypted
Results
Final Results
Service Provider
User
Client Site
Client Side
Query
+vite
154
Conclusion
• Importance actuelle de la thématique
• Produits
– Oracle TDE, SQLServer TDE, etc.
• Recherche en cours : purement SW trusted HW
– CryptDB @ MIT (SW)
– Cypherbase @ Microsoft research (FPGA, SGX)
– TrustedDB @ Stonybrooks (crypto-proc. IBM)
– PlugDB @ Inria (secure element)
– Etc.
155
Données personnelles
et anonymat
• Une donnée personnelle est reliée à un individu
• Une donnée est dite anonyme si elle ne peut pas, de
quelque manière que ce soit, être reliée à un individu donné
156
Intérêt « industriel » pour l’anonymat
• Calculs statistiques sur des données personnelles
– Intérêt commercial évident…
– Marketing et publicité (profilage)
– Compagnies d’assurance et banque (évaluation du risque,
tarification des contrats)
– Santé, recherche (études épidémiologiques), etc.
• Mais des difficultés (au moins pour l’Europe)…
– 1) Obtenir le consentement de l’usager
– 2) L’informer du traitement statistique, etc.
… qui ne se posent pas si les données personnelles
sont rendues « anonymes »…
– Car ces données n’entrent pas dans le champ de la loi
(depuis 2004)
157157
Anonymisation : le principe
Données
personnelles
Serveur de
confiance
Serveur de
statistiques
Individus
Données anonymes
(non personnelles)
158
Anonymisation : les techniques• Pseudonymat: remplace les identifiants par des pseudonymes
– Hachage (cryptographiques) des identifiants
– Conservation des colonnes sensibles utiles
• k-anonymat: cache chaque individu dans une classe de k individus
– Généralisation et suppression des quasi-identifiants
– Conservation des colonnes sensibles utiles
• l -diversité: diversifie les valeurs sensibles des classes
– Complète le k-anomymat
– Contrôle les valeurs sensibles présentes dans chaque classe
• t-fermeture: contrôle la distribution des valeurs sensibles
– Complète le k-anonymat et la l-diversité
– Contrôle la distribution des valeurs sensibles dans les classes
• Confidentialité différentielle
– Ajout de bruit
– Assure qu’un résultat anonyme change très peu avec ajout d’1 individu supplémentaire
• Suivi de cohorte
– M-invariance: les résultats successifs pour une population restent anonymes
159
123 "M2 Stud." 22 Flu
456 "M1 Stud." 25 HIV
789 "L3 Stud." 20 Flu
SSN Activity Age Diag
ABC "M2 Stud." 22 Flu
MNO "M1 Stud" 25 HIV
XYZ "L3 Stud." 20 Flu
Pseudo Activity Age Diag
Le pseudonymat…
• Base du pseudonymat
– Retirer les identifiants et les remplacer par un pseudo
Données
personnellesDonnées anonymes
(non personnelles)
…ne garantie pas l’anonymat !
Identifiants
(ID)
160
Etude de L. Sweeney – 2002 (1)
• Un fichier anomyme produit par une compagnie d’assurance
– Sans d’identifiant (ni nom, ni numéros de sécu, etc.)
– Avec des données sensibles (traitement médical, diagnostique, etc.)
– Et d’autres non sensibles (code postal, genre, etc.)
• Un fichier nominatif (liste de grands électeurs)
– Des identifiants (nom, adresse, parti politiques, etc.)
– Des champs non sensibles (code postal, genre, etc.)
• Ces deux fichiers étant publics…
– L’identité de certaines personnes ne peut pas être préservée
– Sweeney retrouve facilement le dossier médical du gouverneur W. Weld
Comment dé-anonymiser les données ?
Quelle est la proportion de personnes qui reste protégée?
161
Etude de L. Sweeney – 2002 (2)
• Jointure des deux fichiers sur les données non sensibles
• Sur la base du recensement de 1990 aux USA
– « 87% of the population in the US had characteristics that likely made
them unique based only on {5-digit Zip, gender, date of birth} » [1].
[1] L. Sweeney. k-anonymity: a model for protecting privacy. Int. J. Uncertain.
Fuzziness Knowl.-Based Syst., 10(5), 2002.
162
k-anonymat[Sweeney]
• Le k-anomynat répond au problème du pseudonymat
• Base du k-anonymat
1) classifier les données
2) retirer les identifiants (comme pour le pseudonymat)
3) supprimer et/ou généraliser les quasi-identifiants (restent vrais!) …
… de manière à former des classes d’individus équivalents de taille k
SSN Activity Age Diag
Identifiers
(ID)
Quasi-Identifiers
(QID)
Sensitive data
(SD)
"Student" [20, 22] Flu
"Student" [20, 22] HIV
"Student" [20, 22] Flu
"Teacher" [24, 27] Cancer
"Teacher" [24, 27] Cancer
"Teacher" [24, 27] Cancer
Activity Age Diag
Jeu 3-anonymes
(par généralisation)
Sue "M2 Stud." 22 Flu
Pat "MC" 27 Cancer
Dan "PhD" 26 Cancer
Bob "M1 Stud." 21 HIV
Bill "L3 Stud." 20 Flu
San "PhD" 24 Cancer
Name Activity Age Diag
163
k-anonymat : algorithme de Mondrian
164
Le k-anonymat garantit que…
• Un individu donné est toujours associé à
au moins k individus participants au jeu anonyme
– C’est-à-dire à tous ceux appartenant à une même classe
– Par exemple: « Sue » est associée à au moins 3 tuples du
jeu 3-anonyme
164
"Student" [20, 22] Flu
"Student" [20, 22] HIV
"Student" [20, 22] Flu
Activity Age Diag
Sue "M2 Stud." 22 Flu
Name Activity Age Diag
Jeu 3-anonyme
(par généralisation)
165
… mais ne garantit pas tout
• Il n’y a pas de contrôle sur les valeurs des attributs
sensibles associées dans une même classe de taille k
– On peut donc avoir moins de k valeurs sensibles par classe
– Voire même une seule valeur sensible !
• Exemple:
– L’individu « Pat » est bien relié à une classe de taille 3…
… mais tous les individus de cette classe ont le même Diag !
Le k-anonymat ne protège pas contre
la dé-anonymisation des attributs sensibles !
"Teacher" [24, 27] Cancer
"Teacher" [24, 27] Cancer
"Teacher" [24, 27] Cancer
Activity Age Diag
Pat "MC" 27 Cancer
Name Activity Age Diag
166
La l-Diversité
• Complète le k-anonymat
– Afin d’éviter la dé-anonymisation des attributs sensibles
• Assure que chaque classe contient au moins l valeurs
sensibles différentes et « représentatives »
– « représentatives » peut signifier différentes choses
[3] A. Machanavajjhala, D. Kifer, J. Gehrke, M. Venkitasubramaniam, L-diversity: Privacy
beyond k-anonymity, ACM Transactions on Knowledge Discovery from Data (TKDD), 2007.
"Student" [20, 23] Flu
"Student" [20, 23] HIV
"Student" [20, 23] Cancer
"University" [22, 24] Flu
"University" [22, 24] Cold
"University" [22, 24] Cancer
Activity Age DiagName Activity Age Diag
Sue "M2 Stud." 22 Flu
Pat "MC" 27 Cancer
Dan "PhD" 26 Cancer
Bob "M1 Stud." 21 HIV
Bill "L3 Stud." 20 Flu
San "PhD" 24 Cancer
John "M2 Stud" 22 Cold
Jim "M2 Stud" 23 Cancer
Jeu 3-anonyme
et 3-divers
167
La l-Diversité garantie que…
• Un individu donné est toujours associé à
au moins l valeurs d’attributs sensibles différentes
parmi les plus représentatives
– Par exemple: l’individu « Bob » est bien associé à trois
valeurs sensibles représentatives {Flu, HIV, Cancer}
– Mais elle ne garantit pas que la classe contienne des
valeurs sensibles reflétant la distribution globale
– Donc: possibilité de discriminer un individu s’il appartient à
une classe « à risque »…
"Student" [20, 23] Flu
"Student" [20, 23] HIV
"Student" [20, 23] Cancer
Activity Age Diag
Bob
168
La t-fermeture
• Complète la l-Diversité
– Dans chaque classe d’individus, la distribution des valeurs
sensibles suit la distribution globale
(…s’y écarte au maximum d’un facteur t)
– L’appartenance d’un individu à une classe n’apprend rien de
plus sur l’individu que ce qui est connu (distribution globale)
– Exemple
[4] N.Li, T. Li, S. Venkatasubramanian. t-closeness: Privacy beyond k-anonymity and l-diversity. In IEEE
23rd International Conference on Data Engineering, 2007.
Même distribution
Age Gender Diag Count
< 40 M Flu 400
< 40 M Cancer 200
40 M Flu 400
40 M Cancer 200
40 F Flu 400
40 F Cancer 200
169
Suivi de cohorte
• Objectif: produire successivement dans le temps un jeu de
données anonymes correspondant à un groupe d’usagers
(cohorte), pour voir comment les données évoluent
• Problème: les mises à jour des données (suite à un
changement de valeurs sensibles ou à l’entrée ou la sortie d’un
individu dans le groupe) permettent de dé-anonymiser…
– Example
"Student" [20, 23] Flu
"Student" [20, 23] HIV
"Student" [20, 23] Cancer
Activity Age DiagName Activity Age Diag
t1
"Student" [19, 21] HIV
"Student" [19, 21] Cold
"Student" [19, 21] Dysp
Bob "M1 Stud." 21 HIV
Helen "L1 Stud." 18 Cold
Jules "L1 Stud" 19 Dysp.t2
Bob "M1 Stud." 21 HIV
Bill "L3 Stud." 20 Flu
Jim "M2 Stud" 23 Cancer
=> Sachant que Bob est toujours dans la cohorte, on connait son Diag…
170
Introduction de bruit• Résolution par introduction de données factices
• La m-Invariance [5]
– Les données ne doivent pas (trop) varier d’une version à la version suivante
• La garantie différentielle d’anonymat
– Un algorithme offre une garantie différentielle d’anonymat SSI
sont résultat diffère au plus de 0 quand on retire 1 individu (n’importe lequel)
"Student" [20, 23] Flu
"Student" [20, 23] HIV
"Student" [20, 23] Cancer
Activity Age DiagName Activity Age Diag
t1
"Student" [20, 23] HIV
"Student" [20, 23] Flu
"Student" [20, 23] Cancer
"University" [18, 24] Cold
"University" [18, 24] Dysp.
"University" [18, 24] Gast.
Bob "M1 Stud." 21 HIV
Helen "L1 Stud." 18 Cold
Jules "L1 Stud" 19 Dysp.
Gary "PhD" 24 Gast.
t2
Bob "M1 Stud." 21 HIV
Bill "L3 Stud." 20 Flu
Jim "M2 Stud" 23 Cancer
2 tuples
factices
[5] X. Xiao, Y. Tao. M-invariance: towards privacy
preserving re-publication of dynamic datasets, In
ACM SIGMOD 2007
171
La garantie différentielle d’anonymat
• But: répondre à des calculs sur des données privées et fournir
un résultat anonyme avec une garantie
• Idée de base: que les données concernant un seul individu
soient présentes ou non, les résultat des requêtes doivent être
indistingable
• Ce modèle résiste aux attaques conduites par des attaquants
“informés” (ayant une connaissance antérieure)
Bob "M1 Stud." 21 HIV
Bill "L3 Stud." 20 Flu
Jim "M2 Stud" 23 Cancer
Algo.
(GDA)
R: Count « Flu » patients
R(D): 1 + bruit = p
R: Count « Flu » patients
R(D’): 0 + bruit = q
D:
Bob "M1 Stud." 21 HIV
Jim "M2 Stud" 23 Cancer
D’:
indistingablesD et D’ sont des tables voisines
(ne diffère que par 1 seul tuple)
172
Définition formelle
• Distribution des résultats possibles
• L’algo. A offre une garantie différentielle d’anonymat de A SSI:
Pro
babili
té
Résultat de la requête (ensemble S)(count « Flu » patients)
Base D
Base D’
Paramètre d’anonymat
174
Et les dossiers « historiques » ? Cas NetFlix (trace GPS, trace d’accès, etc.)
• NetFlix Prize :1M€
• Fin en 2010 suite à une
« class action »
• 500K recommandations
anonymes
– Arvind Narayanan & Vitaly
Shmatikov
– connaissance antérieur
prises dans Imdb
– www.cs.utexas.edu/~shmat/
shmat_oak08netflix.pdf
175
Conclusion sur l’anonymat
• Permet de calculer des statistiques
– En sortant de la régulation sur les données personnelles
• De nombreuses techniques
– Pseudonymat
• Une phase incontournable mais très insuffisante
• Garanties d’anonymat très faibles voire inexistante
– k-anonymat, l-diversité, t-fermeture
• Le k-anonymat empêche la dé-anonymisation des tuples par jointure sur les
quasi-identifiants
• Le k-anonymat est préconisé aux USA
• Il ne garantie pas la dé-anonymisation des attributs sensibles
• Une famille de techniques complète les garanties d’anonymat
• … mais réduisent fortement l’usage
– Difficile d’assurer l’anonymat pour des versions successives
• Ou conduit à dégrader très fortement l’usage…
• Mais aucune ne garanti vraiment l’anonymat
176
Petite classe : Chiffrement et
anonymisation de BD
177
Panorama des SGBD NoSQL
?
178
Panorama des SGBD NoSQL
Source : nosqldatabase.org Hadoop / HBase
MapR
Hortonworks
Cloudera
Cassandra
Scylla
Hypertable
Accumulo
Amazon SimpleDB
Cloudata
MonetDB
HPCC
Apache Flink
IBM Informix
Splice Machine
eXtremeDB
ConcourseDB
Druid
KUDU
Elassandra
Document Store
Elastic
ArangoDB
OrientDB
gunDB
MongoDB
Cloud Datastore
Azure DocumentDB
RethinkDB
Couchbase Server
CouchDB
ToroDB
SequoiaDB
NosDB
RavenDB
MarkLogic Server
Clusterpoint Server
JSON ODM
NeDB
Terrastore
AmisaDB:
JasDB
RaptorDB
djondb
EJDB
densodb
SisoDB
SDB
NoSQL embedded db
ThruDB
iBoxDB
BergDB
ReasonDB
IBM Cloudant
BagriDB
DynamoDB
Azure Table Storage
Riak
Redis
Aerospike
LevelDB
RocksDB
Berkeley DB
GenieDB
BangDB
Chordless
Scalaris
Tokyo Cabinet / Tyrant
Scalien
Voldemort
Dynomite
KAI
MemcacheDB
Faircom C-Tree
LSM
KitaroDB
upscaledb
STSdb
Tarantool/Box
Chronicle Map
Maxtable
Pincaster
RaptorDB
TIBCO Active Spaces
allegro-C
nessDB
HyperDex
SharedHashFile
Symas LMDB
Sophia
NCache
TayzGrid
PickleDB
Mnesia
LightCloud
Hibari
OpenLDAP
Genomu
BinaryRage
Elliptics
DBreeze
TreodeDB
BoltDB
Serenety
Cachelot
filejson
InfinityDB
KeyVast
SCR Siemens
IOWOW
BBoxDB
NuSTER
JDX
Antidote
Neo4J
ArangoDB,
OrientDB
Infinite Graph
Sparksee
TITAN
InfoGrid
HyperGraphDB
GraphBase
Trinity
AllegroGraph
BrightstarDB
Bigdata
Meronymy
WhiteDB
Onyx Database
Virtuoso
VertexDB
FlockDB
weaver
BrightstarDB
Execom IOG
Fallen 8
ArangoDB
OrientDB
FoundationDB
Datomic
gunDB
CortexDB
Oracle NOSQL Database
179
Panorama des SGBD NoSQL
• NoSQL = Not Only SQL Au-delà du SQL
• De quoi veut-on s’affranchir ?
– Des lignes ?
• Intérêt des bases de données orientées colonnes
– Des colonnes ?
• Systèmes clés-valeurs
– De la structure ?
• Document peu structurés (JSON)
– Des transactions ACID ?
• Principes BASE
– De l’administration, de l’expertise ?
• Quelques produits
• Les tendances actuelles
180
Principes communs au NoSQL
• Partitionnement horizontal des données (Sharding)
– Plusieurs milliers de nœuds
– Architecture ‘Shared nothing’ / MPP
– Ajout/suppression dynamique des nœuds
– Equilibrage de charge automatique
• Réplication des données
– Résolution des conflit (cohérence à terme)
• Parallélisme des traitements
– Map/reduce (BigData de Google, Hadoop…)
– Map: analyse/découpe le problème
– Reduce: remonte des résultats
181
Théorème CAP
• Proposé par Eric A. Brewer, Prof à BerkeleyRéférence : https://people.eecs.berkeley.edu/~brewer/PODC2000.pdf
• Borne sup. de ce que peut faire un syst. distribué
• Ce qu’un système distribué doit savoir faire :
– Consistency
• Tous les clients voient les mêmes données
• /!\ C de ACID (contraintes d’intégrité)
mais A et I (les R/W sont atomiques et sérialisables)
– Availability
• Toute nœud du système, s’il n’est pas en panne, accepte toujours les
requêtes R/W des clients
– Partition tolerance
• Resistance aux pertes de messages entre les partitions
– NB : quid d’un SGBD relationnel ?
182
C&A&P non réalisable
• Req1 sur nœud 1 :
Ecrit a=2
• Req2 sur nœud 2 :
Lit a
• C&A ?
– A répondre à Req2 renvoyer a=1
– Mais C attendre le message de nœud 1…
• A&P ?
– A répondre à Req2 renvoyer a=1
– Mais P msg perdu a=1 sur nœud 2…
183
ACID vs BASE
• ACID = Atomique, Cohérent, Isolé, Durable
– Concept introduit par Jim Grey (Prix Turing)
• CAP = Consistency, Availability, Partition tolerance
– Théorème CAP : impossible d’assurer les 3 !
– Introduit par Eric Brewer (Prof. At Berkeley) en 2000
Systèmes BASE = Basically Available, Soft state, Eventual consistency
184
Classification des SGBD NoSQL
• SGBD colonnes (issus du relationnel)
– MonetDB, VectorWise, C-Store, Vertica, Cassandra, …
• SGBD documents
– CouchDB, MongoDB, ElasticSearch…
• SGBD clé-valeur
– Dynamo, Oracle NoSQL Database, Redis, …
• Et bien d’autres aussi :
– SGBD graphes (Apache Giraph, Neo4J, …
– SGBD MultiValue (U2, Zoebase, …)
– Etc.
185
Différents systèmes NoSQL
186
Principe des SGBD « colonnes »
• Le stockage en colonne est adapté à des charges
– Lecture intensive (voire lecture seule)
– Grand volume de données
• OLAP, pas OLTP !
+ Accès aux données utiles
– Insertion d’un tuple plusieurs accès
Stockage en ligne Stockage en colonnes
+ Ajout/suppression simple
– Lecture de données inutiles
187
SGBD colonnes : compression (1)
• Run-Length Encoding (RLE)
188
SGBD colonnes : compression (2)
• Vecteurs de bits
189
SGBD colonnes : exécution
• Exécution sur les données compressées
190
MonetDB / VectorWise
• Premier SGBD(R) orienté colonnes
• Support Relationnel (SQL) puis XML/Xquery
• Origine
– Prototype de recherche très utilisé dans la communauté
– Développé par le CWI (Amsterdam)
– Open source en 2004, 10 year Best Paper Award en 2009
• Particularités
– Efficacité (Colonnes, compression, maximisation caches CPU,
traitements par « lots de tuples », …)
• Base du produit VectorWise…
– Startup du CWI (MonetDB )
– Premiere place pour le Benchmark TPC-H !
– Racheté par INGRES (ACTIAN) en 2009
191
C-Store / Vertica
• Premier SGBD(R) orienté colonnes sur le cloud
• Travaux de recherche (VLDB’05) de M. Stonebraker
– Développé par MIT, Yale, UMass …
– Version commerciale : Vertica racheté par HP
• Particularités
– C-Store : 2 ‘stores’
– shared nothing/MPP cloud (AWS, Google, Azure)
– Scalabilité extrème (exascale)
– Hadoop nodes (MapReduce)
192
Cassandra (1)
• SGBD colonne NoSQL (A&P)
• Développé par Facebook
– open source en 2008, projet apache en 2010
– Utilisé par Netflix, Twitter, Spotify, etc.
• Répplication et partionnement : basé sur l’anneau Dymano
• Modèle de données : basé sur BigTable
– Des ‘tables’ peuvent être créées, supprimées ou modifiées pendant
l'exécution, sans bloquer les modifications et les requêtes.
– Les données sont stockées selon leur ‘clé’ dans les ‘tables’
– premier élément de la clé = clé de partition
• dans chaque partition, les données sont groupées selon les autres colonnes
composant la clé.
• Article de référence :
– “Cassandra - A Decentralized Structured Storage System”, Avinash
Lakshman et Prashant Malik, Facebook, 2009.
193
Cassandra (2)
• Eventual consistency (Dynamo)
– Données répliquées sur un anneau de serveurs
– Gestion des conflits pour forcer la convergence
• Échange des modifications entre les serveurs
• Réconciliation en cas de reception de modification incohérentes
– Ex: last writer wins basé sur des timestamps
• Réconciliation asynchrone, ou en Read repair / Write repair
– i.e., lors d’une lecture / écriture incohérente
• Langage CQL -SQL simplifié- :CREATE COLUMNFAMILY MesColonnes (id text, Nom text,
Prenom text, PRIMARY KEY(id));
INSERT INTO MesColonnes (id, Nom, Prenom)
VALUES ('1', 'Doe', 'John');
SELECT * FROM MesColonnes;
• Pas de jointures ni sous-requêtes, mais support MapReduce
194
MapReduce ? un exemple…
• Ex : faire un produit cartésien R S en Map/Réduce
• R et S sur un anneau de serveurs Cassandra
• Hypothèses
– Des Mappers distribuent les tuples de R et de S
– N Reducers ‘collent’ les tuples de R avec ceux de S
• Comment organiser le traitement pour le faire de
façon optimale en 1 round?
– But : minimiser les échanges de données entre mappers et
reducers
– Exemple de solution sous optimale :
• Envoyer chaque élément de R à tous les reducers, envoyer chaque
élément de S à un seul reducer
195
Solution
…
…
… … …
…
N reducersR1
R2
SN
S1 S2 SN
Part
itio
ns d
e R
Partitions de S
196
Principes des SGBD clé-valeur
• Modèle de données : (clé) valeur
– Users:2:friends {23, 76, 233, 11}
– Users:2:inbox {234, 3476, 33, 55}
– Users:2:settings theme=dark, cookies=false
• La valeur est vue comme un blob opaque
• Interface CRUD (create, read, update, delete)
• Exemples : Amazon Dynamo (A&P), Redis (C&P), …
197
Dynamo
• Développé par Amazon (2007)
• Partitionnement des données sur un anneau de
serveurs
• Chaque noeud stocke plusieurs partitions
• Chaque partition est répliqué N fois (ici 3)
A
B
C
D
E
F
A
DE
F
A
F
A
B
B
C
B
C
D
C
D
E
E
F
198
Lecture
• Un noeud arbitraire sert de coordinateur
• Paramètres : N, R, W
– N : nombre de replicas (ici 3)
– R : nombre de noeuds devant confirmer la lecture (ici 2)
– W : nombre de noeuds devant confirmer une écriture (ici 1)
A
B
C
D
E
F
199
Principes des SGBD documents
• Modèle de données : (collection, clé) documents
• Exemple :
– Order-12338
{
order-id: 23,
customer : { name : ”Felix Marx”, age : 25 }
line-items : [ {product-name = “x”, … } , … ]
}
• Interface CRUD, langage de requêtes, MapReduce
• Exemples : CouchDB (A&P), MongoDB (C&P)
200
MongoDB (1)
• Vient de “humongous” gigantesque
• Partitionnement par intervalle ou basé sur du hachage
• Replication (synchrone ou asychrone)
• Modèle de données : Json
– Tout est clé valeur => “clé” : “valeur”
– Un document est encapsulé par des accolades {...}
– valeur : une valeur, une collection [...], un document
• Le principe est donc :
– Schema libre : attributs par documents
– Dénormaliser plutôt que de réaliser des jointures
– “Imbriquer” pour remplacer les associations 1:n et 1:1
– Grain d’atomicité : le document
201
MongoDB (2)
• Exemple de document
• Interface : langage proche de javascript
– db.movie.selectOne()
– db.movie.find( { title : “Iron Man 3” } } );
– db.movie.find( { title : “Iron Man 3” } } ).count();
202
En conclusion
• S’affranchir des contraintes des systèmes SQL
– Schéma statique, transactions ACID
– Installation difficile, expertise extrême
– Performance => cluster dédiés / mainframe
• Réponse NoSQL poussée par les géants du Web
– Big Data : énormes quantité de données, générées par des machines
– Faiblement structuré, scalabilité extrême
– Mais : de l’expertise, des performances faibles vs les ressources…Réf.: Gessert, F. et al. Scalable data management: NoSQL data stores in research and practice. ICDE’16
• Tendance : performances ‘sub-second’ + ACID + cloud
– Covergence des systèmes : SGBD-R & NoSQL
– Besoin d’acidité : MongoDB tourne ACID en 2018…
– Dynamicité des ressources (allocation à la demande)
– BFM Awards 2018 : Snowflake computing
203
Petite classe :
Expériences NoSQL
204
Ouverture• Le paradoxe du Cloud personnel /!\ PUB
– Un problème enraciné dans des considérations architecturales
– Beaucoup de problèmes ouverts (=> des thèses)
• Traitement orientés données : Big data (focus: deep learning)
– Modèle de base : Perceptron
– Descente de gradients
– Conclusions et problèmes ouverts
• Bases de données et Blockchain
– Chaine de blocs de transaction BD liés cryptographiquement
– Preuve de travail pour chainer un nouveau bloc
• Beaucoup d’autres choses : ex. recherche d’informations
– Méthodes géométriques, recherche de séries temporelles, …
N. Anciaux – Audition DR2PETRUS - Personal & Trusted Cloud
The personal cloud paradigm
Management of personal data today
Delegation privacy issue
Concentration security issue
Fragmentation completeness issue
Smart disclosure & self-data movement
Law for the digital republic (FR), GDPR (EU)
Data portability, privacy impact assessment
BlueButton (US), MiData (UK), MesInfos (FR)…
Personal Cloud: return data to individuals
Sovereignty: make decisions with no delegation
Security: mutual security, risk management
Extensibility: Personal-big-data & Big-personal-data
205
(a) Current situation
Bankingdata
Healthdata
DS
P1
DS
P2
DS
P3
Quantifiedself
DS
P2
(b) Personal cloud
DS
P2
Personal
Cloud
DS
P1
Smart disclosure
N. Anciaux – Audition DR2PETRUS - Personal & Trusted Cloud
PETRUS: Personal and Trusted cloud
A personal cloud founded on Privacy & Empowerment
Problem statement: personal cloud paradox
Four research directions:
Axis 1 – Architectures for the personal cloud
Axis 2 – Administration models and enforcement
Axis 3 – Secure (global) query evaluation
Axis 4 – Economic, legal and societal studies
206
DS
P1
DS
P2
(a) Home Cloud
approach
(b) Personal Cloud provider
approach
Personal
Cloud un
de
r u
se
r co
ntr
ol
DS
P1
DS
P2
Personal
Cloud
N. Anciaux – Audition DR2PETRUS - Personal & Trusted Cloud
Vision PETRUS
Three layer architecture of a personal cloud:
The personal data life cycle:
Data collection
Cross computations
Distributed computations
Administration
207
Isolateddata-tasks
Untrustedapplications
App
App
App
App
App
App
Secure core
Data manager
Privacy /
Security
manager
Communication manager
Data task
Security
Data task
Data task Data task
Extensibility
N. Anciaux – Audition DR2PETRUS - Personal & Trusted Cloud
Architcture (1)
Data collection => isolation
Cross computations => attestation
208
Energy
bill
Power meter
measurements
DeclassificationAccess
controlQuery engine 1
23
Data
task
Apps
Internet
Energy
supplierLocal
computation
Core (proven code)
Isolated data task
Untrusted application
Protected database
Isolation property
Attestation property
TCP/IP
DNS
Attestat°
My collected
data
Bank
credentials
TCP/IP
DNSTLS-trusted Access
controlData accessCore (proven code)
Isolated data task
Untrusted application
Protected database
Isolation property
1
2
3
Data
task
Apps
Internet
Bank Data collector
N. Anciaux – Audition DR2PETRUS - Personal & Trusted Cloud
Architcture (2)
Distributed computations => confidentiality
Administration => peripherals isolation
209
- Results
- MyData
Participant's
dataParticipants
Global
manifest
Distributedcomputation
TCP/IP DNS
Core (proven code)
Isolated data task
Untrusted application
Protected database
Isolation property
Attestation property
Confidentiality prop.
TLS-trusted
Attestation checking
Access
control
Reference monitor Access
controlData access
User's
data
Credentials, policies,
manifests, etc.
Administration
Core (proven code)
Isolated data task
Untrusted application
Protected database
Isolation property
Periph. isolation prop.
N. Anciaux – Audition DR2PETRUS - Personal & Trusted Cloud
PETRUS Methodology
212
Scientific contributions
Single & common platform
(advanced environment, validation)
Flagship applications Teaching Multidisc. work
Indus. transfer
Institutional
impact PhDs
SD card
Bluetooth
Lecteur
d’empreinte
Secure chip
(DBMS)
(secrets)(data)
MCU
USB
DMSP / CozyCloud SIPD + FabLab Privacy-Lab
PlugDBPersonal
Cloud
CORE
TR HW
App
App
App
User’s
device(s)
App
Dedicated HW
UDF
UDF
UDF
Hypervisor
Administration App
UDF
UDF
UDF
CORE
213
Ouverture• Le paradoxe du Cloud personnel /!\ PUB
– Un problème enraciné dans des considérations architecturales
– Beaucoup de problèmes ouverts (=> des thèses)
• Traitement orientés données : Big data (focus: deep learning)
– Modèle de base : Perceptron
– Descente de gradients
– Conclusions et problèmes ouverts
• Bases de données et Blockchain
– Chaine de blocs de transaction BD liés cryptographiquement
– Preuve de travail pour chainer un nouveau bloc
• Beaucoup d’autres choses : ex. recherche d’informations
– Méthodes géométriques, recherche de séries temporelles, …
214
Apprentissage profond
• Des réseaux de neurones avec beaucoup de niveaux
– Les plus gros : plus de 100 niveaux
• De gros modèles (beaucoup de paramètres d’inputs)
– Pour de nombreuses tâches : autant de données qu’on veut
– Peu de risque de sur-apprentissage mais risques de
mauvais / sous-apprentissage
• Deux problèmes
– Problème d’optimisation => atteindre un optimum local
– Problème d’échelle => l’apprentissage coûte cher
• Nombreux choix dans le dimensionnement du modèle
– Faire bcp d’essais
– Un paramétrage ‘connu’ par type d’application
215
Modèle de base : multi-layer perceptron
• 1 neurone:
• Réseau de neurones = ens. de neurones défini par
– La topologie du modèle (connexions)
• Totales / partielles
• Sans boucles / Avec boucles
– La nature des neurones (fonctions C / A)
C / A
Fonction de Combinaison : Wt x I
Fonction d’Activation : sigmoide / Rect. Linear
Output
(valeur)Inputs
(vecteur I)
coéficients
(vecteur W)
216
Apprentissage : minimisation d’erreur
• Exemple simplifié : 1 seul neurone de type perceptron
• La sortie du perceptron est calculée comme suit
– Output = 1 si || I x W || = somme 1n ( xi.wi ) > theta; = 0 sinon
– Avec x0 = 1 et w0= - theta:
Output = 1 si || I x W || = somme 0n ( xi.wi ) > 0; 0 sinon
• C : PS (post-synaptique) = somme 0n ( xi.wi )
• A : 1 si PS > 0 ; 0 sinon
• Pour apprendre, essayer de minimiser la fonction d’erreur
suivante :
– E (W) = ½ somme {(inputs, output)} (output – PSinput)
– Remarque : E = 0 si tous les outputs sont ceux attendus
=> Trouver un W qui minimise E(W)
217
Méthode du gradient
• E(W) est une fonction de n variables (les wi)
• On calcule la dérivée partielle de E par rapport à
chaque variable wi => somme (inputs,outputs)(output-
PS)*(-xi)
• On définit : gradient wi = - epsilon x derivée partielle
de l’erreur par rapport à wi
• Après avoir consommé les inputs, on rectifie chaque
coefficient wi wi + gradient wi
• Epsilon : le ‘pas’ de la descente => si trop petit, long à
converger, si trop grand, ne converge pas
• On finit par identifier un minimum local
218
Ex. d’apprentissage (input x, output d)
• Phase forward
– Présentation de x en entrée du PMC
– Propagation et calcul de y en sortie du PMC
– Calcul de l’erreur ||d-y||
• Phase backward
– Rétropropagation de l’erreur
• Calculer le gradient de l’erreur par rapport à tous les poids du réseau,
couche par couche en partant de la sortie
• Puis mise à jour des poids
– wi wi – epsilon gradient_wi
219
Deep learning and databases
• Deux ‘vieilles’ activités
• Résurgence des réseaux de neurones, 3 raisons:
– Puissance de calcul (pour entrainer de nouveaux modèles)
– Jeux de données massifs (e.g., ImageNet)
– Nouveaux modèles (réseaux de DL convolutionnels)
• Bases de données deep learning
– Application de techniques BD de calcul distribué/parallèle et gestion
mémoire (Database Meets Deep Learning: Challenges and
Opportunities, SIGMOD records, 2014)
• Deep learning bases de données
– Application à la fusion de connaissance (From data fusion to knowledge
fusion, PVLDB, 7(10), 2014)
– Problèmes de crowsourscing (Contextual crowd intelligence, SIGKDD
Explorations, 16(1), 2014)
• Research issue : privacy preserving learning schemes
220
Ouverture• Le paradoxe du Cloud personnel /!\ PUB
– Un problème enraciné dans des considérations architecturales
– Beaucoup de problèmes ouverts (=> des thèses)
• Traitement orientés données : Big data (focus: deep learning)
– Modèle de base : Perceptron
– Descente de gradients
– Conclusions et problèmes ouverts
• Bases de données et Blockchain
– Chaine de blocs de transaction BD liés cryptographiquement
– Preuve de travail pour chainer un nouveau bloc
221
Blockchain : généralités
• Stoque des transactions (BTC: 268 millions, 139MB)
• Dans des Blocs (BTC : 1MB, 2000 transactions)
• Chainés entre eux et vérifiés cryptographiquement
• Tous les blocs sont publics
• Ils sont stockés sur tous les nœuds de la BC
• Pour BTC, voir https://blockchain.info/fr/charts
• 1BTC = 7353$
222
Création d’une transactions
• Le problème central (finance): ne pas permettre
d’engager le même argent pour deux transactions
différentes
• Chacun a une paire de clés pub/priv
• Une transaction est décrite par :
– (1) un nombre de BTC, et les transactions desquelles elles
proviennent
– (2) une signature (avec kpriv) du propriétaire sur le montant
dépensé et le destinataire, transmise au réseau avec kpub
– (3) des frais de transaction
223
Minage
• Un mineur, pour créer un nouveau bloc :
• (1) rassemble des transactions dans un bloc
• (2) vérifie ces transactions
• (3) résout un problème de hachage cryptographique
(doit produire un hachage crypto du bloc avec un
certain nombre de 0) => preuve de travail
• Le mineur gagne des bitcoin et récupère les ‘frais’
associés à la transactions
224
Attaques possibles
• Acheter 2 produits avec les mêmes BTC
• Recevoir le premier produit
• Produire un bloc en ignorant la première transaction,
qui alors ne passera plus jamais.
• Réponse BTC : longest chain rule
• Si 2 blocs sont produits en même temps, le premier
qui en chaine 1 a gagné… une fois que n (BTC:6)
personnes vérifient le bloc, il est accepté. Et l’autre est
abandonné.
225
Conclusion
• Un grand livre de comptes
• Attesté de manière cryptographique
• Equivalent d’un fichier de transactions notarisées
– Sur la base d’un consensus
• Mais pas une BD, notamment:
– Ne répond pas aux requêtes
– Pas de droits d’accès (droit public en lecture)
226
Annexes
227
Mode opératoire Electronic Code Book
• Les blocs sont chiffrés indépendamment
• Remarque : : P1=P2 => EK(P1)=EK(P2)
Plain-text 2 (P2)Plain-text 1 (P1) …
80
by tes
16
Cipher-text 2 (C2) …Cipher-text 1 (C1)
EK (P2)EK (P1)
228
Mode opératoire Cipher Block Chaining
Init. Vector (IV)
Plain-text 2 (P2)Plain-text 1 (P1) …
80
by tes
16
Cipher-text 2 (C2) …Cipher-text 1 (C1)
EK (IV P1) EK (C1 P2) EK (…)
• les blocs chiffrés intégrent la valeur des
précédents
229
Mode opératoire CTR
• Résultat du XOR entre le clair et un mot aléatoire
Init. Vector (IV)
Plain-text 2 (P2)Plain-text 1 (P1) …
80
by tes
16
Cipher-text 2 (C2) …Cipher-text 1 (C1)
EK (IV+1) P1+1
EK (IV+2) P2+2 +3