Spécification des objectifs: Description des objectifs d une collecte d information et stockage de ces objectifs avec les données

Transcription

1 Bases de Données Hippocratiques Page 1

2 Les Dix Principes des BDH (1) Spécification des objectifs: Description des objectifs d une collecte d information et stockage de ces objectifs avec les données Consentement: Doter l utilisateur du droit de consentir ou pas à divulguer ses données par rapport à un objectif donné. Limitation de collecte: Ne collecter que les données strictement nécessaires à la réalisation des objectifs spécifiés Limitation d usage: Spécification des couples (objectifs / destinataires) conformes aux préférences et aux directives de privacité. Limitation de divulgation: Ne divulguer les données personnelles qu aux organismes autorisés avec le consentement du client. Page 2

3 Limitation de conservation: Suppression des données dépassant le délai de conservation Exactitude: Vérification des données fournies par l utilisateur Sûreté: Les Dix Principes des BDH (2) Protection des données contre les attaques Franchise: Doter l utilisateur du droit d accès et de modification de ses données personnelles. Conformité: Doter l utilisateur du droit d auditer le système et de juger de sa conformité Page 3

4 EXEMPLE DE VENTE DE LIVRES (1) Collecte de données personnelles pour: Effectuer les transactions et exécuter les ordres d achat, Maintenir le profil des utilisateurs fidèles, Générer des recommandations de livres basées sur l historique des achats, Publier des statistiques de ventes par région et par pays. Page 4

5 EXEMPLE DE VENTE DE LIVRES (2) Schéma de la base: Customer (purposes, customer-id, name, shipping-address, , credit-card-info) Order (purposes, customer-id, transaction-id, book-info, status) Tables de méta-données avec spécification des objectifs: Privacy-policies (purpose, table, attribute, {external-recipients}, retention) Privacy-authorizations (purpose, table, attribute, {authorized-users}) Page 5

6 EXEMPLE DE VENTE DE LIVRES (3) Privacy policies Table Privacy authorizations Table Page 6

7 Collecte des Données (1) L utilisateur opt-in ou opt-out pour chaque objectif. Garder un audit trail comme preuve du consentement de l utilisateur Ne pas retenir mes données personnelles une fois que la transaction d achat s est effectuée -Je ne vois pas d inconvénient à retenir mon adresse électronique et de livraison. - Utiliser mes transactions d achat pour des recommandations. -Par contre, je ne veux pas être publié dans apparaître les livres dans de les vente listings par de région. vente ALICE BOB Page 7

8 Processus (1) : pré-test sur la requête Les requêtes doivent inclure l objectif 2.1 Avant l exécution de la requête: Utilisateur et Attributs autorisés pour cet objectif (Attribute-based Access Control) Exemple: Customer Service Departement Q( Purchase, Credit Card info ) Mallory Non permis!!! HDB Page 8

9 Processus (2) : Exécution de la requête 2.2 Durant l exécution de la requête: Interdire les tuples résultats dont l attribut purpose ne contient pas le purpose de la requête (Record-based Access Control) Exemple: BOB Set of books Q(Recommendations) ALICE Non permis!!! Set of books Page 9

10 Processus (3) : audit des requête 2.3 Après l exécution: Vérification de l accès atypique pour un objectif et un utlisateur donné ( Query Intrusion Detector) Ajout de la requête à l audit trail (historiser qui accéde à quoi et quand) Customer Service Departement Mallory Q(Purchase, of all users) Query Intrusion Detector Requête suspecte!!! HDB -ex : le cumul des tuples résultats pour un commercial doit être inférieur à 1000 par jour. Sinon, alerte!! Page 10

11 BDH P3P & APPEL Challenges des BDH Audit de Conformité Limitation de divulgation Proto Carte à puce Principe de conformité et audit Page 11

12 Motivations Une plate-forme d audit pour vérification de la conformité de la base aux directives de privacité Suppose que l on fait confiance au serveur Peut permettre un meilleur calibrage de la politique de privacité Peut être mené par un organisme indépendant (e.g., CNIL) Doit permettre de déterminer a posteriori qui a accédé à quoi La journalisation des résultats de chaque requête est une approche possible mais coûteuse. Vérifier l accès ne donne pas de garantie sur la non divulgation des données!! Page 12

13 1. L auditeur formule une expression d audit (A) Qui a vu les données satisfaisant telle condition? 2. L «audit Query Generator» : Principe 1. Analyse statique: Sélection de requêtes journalisées candidates à la suspiscion (sur la base des attributs interrogés) 2. Combinaison de ces requêtes avec A pour produire une requête d audit A. 3. A exprimée en SQL standard et confrontée aux backlogs donne les requêtes précises ayant accédées aux données surveillées par l auditeur (i.e., réellement suspectes). Page 13

14 Architecture Page 14

15 Définitions Expression d audit (A): Otherthan purpose-recipient pairs During start time to end time Audit audit list From table list Where condition list Tuple indispensable: ind(t,q) Exemple : audit disease from Customer c, Treatment t where c.cid = t.pcid and c.zip = T est indispensable à Q si son omission modifie le résultat de Q. Requête candidate: cand(q,a) Q est candidate à A si Q accède à toutes les colonnes que A spécifie dans l audit list. Requête suspecte: susp(q,a) Une requête candidate Q est suspecte vis-à-vis de A si Q et A partagent un tuple indispensable. Page 15

16 Exemple (1) BD: Customer (cid, name, address, phone, zip, contact) Treatment (pcid, date, rcid, did, disease, duration) Doctor (did, name) A: audit disease from Customer c, Treatment t where c.cid = t.pcid and c.zip = Q: select address from Customer c, Treatment t where c.cid=t.pcid and t.disease= diabetes Q est-elle suspecte? Page 16

17 Exemple (1) BD: Customer (cid, name, address, phone, zip, contact) Treatment (pcid, date, rcid, did, disease, duration) Doctor (did, name) A: audit disease from Customer c, Treatment t where c.cid = t.pcid and c.zip = Q: select address from Customer c, Treatment t where c.cid=t.pcid and t.disease= diabetes Cand(Q,A) Ind(T,Q) Ind(T,A) Susp(Q,A)!!!!!! Q est suspecte s il existe un malade diabétique habitant le Page 17

18 A: audit address from Customer c, Treatment t where c.cid = t.pcid and t.disease = cancer Q: Exemple (2) select address from Customer c, Treatment t where c.cid = t.pcid and t.disease = diabetes Alice: une malade Je suis diabétique et j ai le cancer!!! Q est-elle suspecte? Alice Page 18

19 A: audit address from Customer c, Treatment t where c.cid = t.pcid and t.disease = cancer Q: Exemple (2) select address from Customer c, Treatment t where c.cid = t.pcid and t.disease = diabetes Cand(Q,A) Q non suspecte!!! Alice: une malade Alice Je suis diabétique et j ai le cancer!!! Il n existe aucun tuple dans C x T qui satisfait Q et A simultanément. Page 19

20 Log de requêtes et Backlogs Log de requêtes Interception et sauvegarde des requêtes Annotations: (temps, utilisateur, objectif) Backlog Objectif = déterminer si les données accédées par chaque requête lors de leur exécution initiale intersectent celles sélectionnées par l expression d audit, Recréation de l état de la BD au temps où la requête a été exécutée Page 20

21 «Interval Stamped» backlog Table T Table TB P C1 C2 C3 C4 P C1 C2 C3 C4 TS TE TS: temps de début TE: temps de fin Si l opération est : Insert: insertion d un nouveau tuple avec TE = null Update: 1-mettre à jour le tuple avec TE = ζ (temps courant) 2-insertion d un nouveau tuple TS = ζ TE= null Delete: mettre à jour le tuple avec TE = ζ Page 21

22 Exemple t1 t2 t3 t4 Table TB Insertion 20 Insertion 21 Update 20 Delete 21 P C1 C2 C3 C4 TS TE 20 jules 26 célib paris t1 Null t3 21 Marie 40 veuve Nice t2 Null t4 20 jules 29 Marié Paris t3 null Temps Page 22

23 En résumé: analyse statique 1. Comparaison des attributs de la requête vs. ceux de A. 2. Timestamp (Ts) de Q vs. During de A. 3. (purpose-recipient) vs. OtherThan de A. 4. Contradiction des prédicats (PQ vs PA) (ex: age > 40 vs. age < 20 ) Un ensemble de requêtes candidates : { Q1,Q2,Q3.Qn} Page 23

24 puis génération de la requête d Audit Enrichir chaque requête candidate Qi avec les informations incluses dans A => AQi Combiner les requêtes AQi en une seule requête d audit AQ Exécuter AQ sur la BD de backlogs pour aboutir à l ensemble des requêtes suspectes. Page 24

25 Oracle Audit Vault Outils permettant d auditer de multiples sources Oracle mais aussi SQLServer, DB2, Sybase ASE Récupération possible des logs d OS (Unix, Linux, Windows) Oracle Audit Vault Server Un Data Store entrepôt de données Une console d administration et de visualisation Des services de collecte de données, de gestion d alertes, d édition de rapports Page 25

26 Architecture Page 26

27 Flot de données Page 27

28 Oracle Audit Vault 3 étapes pour la mise en oeuvre Step 1: déclarer une politique d audit Step 2: exporter cette politique vers les BD sources et mettre en place les bons collectors pour collecter les données d audit Step 3: analyser les rapports d audit Page 28

29 Déclarer une politique d audit Possibilité d auditer 5 types de données/actions SQL statements Audite toutes les requêtes utilisant ce statement (ex: UPDATE). Database Schema Objects Audite toutes les requêtes portant sur cet objet précis (ex: table T1, View V2) Database Privileges Audite toutes les actions qui nécessitent un privilège particulier (ex: SELECT ANY TABLE) Fine-grained audit conditions. Audite toutes les actions satisfaisant une certaine conditions (ex: requêtes exécutée en dehors des heures de travail ) Redo log data. Récupérer les données des redo log files (par Table, Schéma ou pour toute une BD), pour tout statement DDL ou DML modifiant des tuples Page 29

30 SQL statements Auditing Exemple : AUDIT SELECT TABLE Audite tous les SELECT... FROM TABLE et SELECT... FROM VIEW statements, quelles que soient les tables et vues AUDITED BY All: pour tous les utilisateurs User: pour une liste d utilisateurs précis Execution condition WHENEVER SUCCESSFUL: quand la commande à réussie WHENEVER NOT SUCCESSFUL: quand elle a échouée BOTH: dans les deux cas Granularité de l audit BY ACCESS: à chaque fois que l opération est exécutée BY SESSION: la première fois de chaque session Page 30

31 Fine-grain auditing Exemple d usages Accéder une table en dehors des heures de travail ou pendant le week-end Utiliser une adresse IP hors intranet Visualiser un attribut précis d une table (Nro de Carte bancaire, salaire, etc) Modifier un attribut précis d une table Modifier une valeur précise d un attribut précis Ex : ajout de conditions sur AUDIT SELECT TABLE T1 Condition: department_id = 50 Columns: salary, commission_pct Page 31

32 Gestion des alertes : déclaration Page 32

33 Gestion des alertes : monitoring Page 33

34 Vision d un rapport d activité Page 34

35 Oracle Total Recall Basé sur Flashback data Archive (Oracle 11g) Permet d interroger une table telle qu elle était à une date précise. Répond à différents objectifs Data forensics Data retention Historical reporting Fine-grained auditing Tamper-proof files Fraud detection and repair La durée de rétention est paramétrable Page 35

36 Oracle Total recall (2) CREATE FLASHBACK ARCHIVE fda1 TABLESPACE tbs1 RETENTION 5 YEAR; ALTER TABLE EMPLOYEES FLASHBACK ARCHIVE fda1; SELECT last_name, first_name, salary FROM EMPLOYEES AS OF TIMESTAMP TO_TIMESTAMP( :00:00, YYYY-MM-DD HH24:MI:SS ) WHERE employee_id=193; Page 36

37 WORM databases (R. Sion, VLDB 2007) Garantir la véricaté (complétude/exactitude) de l histoire stockée dans une BD Traumatisme ENRON!! Impossible à réaliser sans HW sécurisé Page 37

38 Modèles de rétention des données Page 38

39 Rétention limitée des données Retention dans les BD Hippocratiques Suppression des données dépassant le délai spécifique à un objectif ( Data Retention Manager) Si donnée commune à plusieurs objectifs, utiliser la durée maximale. La destruction effective des données est un problème en soi (CIDR 07) Données marquées détruites mais non effacées Index non mis à jour Données présentes dans les journaux Page 39

40 Intérêt d une rétention limitée : modèle d attaque Le serveur est honnête Il applique correctement les politiques de sécurité Usagers Google Traces digitales personnelles Navigo Zone contrôlée, utilisable dans l intérêt de l usager Mais il n est pas sûr Les données peuvent tomber dans les mains d un tiers malveillant à cause d une négligence, d une attaque, ou d une politique faible Objectif = limiter la portée d une fuite d information Passage inopiné Page 40 Zone hors contrôle (publique) Analysée, utilisable contre l usager

41 Solutions de protection existantes Contrôle d accès et d usage Basé sur la confiance attribuée au serveur Ne répond pas au modèle d attaque considéré Anonymisation des données Dégradation de l utilité des données et perte de l identité (pas de service personnalisé) Doit être prévu a priori Ne répond pas au modèle d attaque considéré Mécanismes de rétention Rétention = principe légal de confidentialité Attache à chaque donnée un délai de rétention Comment définir la période de rétention? Une donnée conservée à des fins imprécises (ex: Google) Une donnée conservée à des fins multiples (ex: Amazon) Faible utilité pratique car période de rétention surdimensionnée Page 41

42 Alternative : la dégradation Dégradation progressive et irréversible des données Toute données passe de l état de précision initial à des états successifs moins précis puis disparaît complètement du système Intuition Compatible avec le modèle d attaque Les services personnalisés restent possibles Mais seront précis dans la mesure de ce qui aura été dégradé On peut gagner beaucoup en intimité, et perdre peu en qualité de service Une négociation entre intimité / qualité de service devient possible Page 42

43 Exemples Google Génère des profils Traces constituées à base de motsclés / catégories issues de requêtes, mails, sites accédés, etc. Suivi de localisation Assistance à la conduite Covoiturage, alertes de trafic PAYD: Pay As You Drive Traces issues de capture GPS Plus généralement, smart metering <Identifiant (IP/cookie), date, {mot-clés}> Exemple de contrôle de l intimité Supprimer toute entrée contenant un mots-clé (honteux) donné Supprimer les entrées introduisant des conjonctions de mots-clés révélatrices Généraliser les mots-clés avec le temps Ex: mot-clé catégorie <Identifiant, date, {localisations}> Exemple de contrôle de l intimité Supprimer une localisation/zone donnée Supprimer un trajet «anormal» un jour travaillé Généraliser des localisations avec le temps Ex: adresse exacte quartier Page 43

44 Comment envisager la dégradation Dégrader sur la base d automates États = états possibles des éléments de la trace Transition = condition de passage d un état à un autre honteux IS IN {mots-clés} T4 INRIA IS NOT IN localisation & date IS IN jour_travaillé T4 T1 T2 T3 S1 S2 S3 t 1 t 2 t 3 T5 Hypertension & Cholesterol IS IN Trace.{mots-clés} Sf T1 T2 T3 S1 S2 S3 t 1 t 2 t 3 Les automates peuvent être complexes NB : on peut imaginer les télécharger auprès d organismes ou d associations de consommateurs en charge de les construire T5 Sf COUNT( cardiologue IS IN Trace)=5 Page 44

45 Modèle de dégradation Pour chaque attribut dégradable définir son schéma de dégradation villes départements adresses précises Ø Bagneux 12, av. Pasteur 92 Bagneux d 1 f d 1 2 d 1 1 d 1 0 Ø dept. ville adresse Etats d un tuple Attribut d1 (l adresse) Attribut stable d 1 0 d 2 0 d Ville 2 0 d d d 3 1 Dept. 2 1 d États d attributs s 1 États de tuples t 0 t 0 t 1 t 2 t 3 t 4 t 5 t 6 t 1 t 2 t 3 t 4 t 5 t 6 t 7 Page 45

46 Challenges Impact sur le langage d interrogation DECLARE PURPOSE Stat SET ACCURACY LEVEL Country for P.location, Range1000 for P.salary SELECT * FROM Person WHERE location like %France% and salary in Impact sur la sémantique transactionnelle Redéfinition des propriétés d atomicité et de durabilité en -Atomicity et -Durability afin de garantir : les effets d une transaction à terme L irréversibilité des changements d états Impact sur le stockage et l indexation Efficacité de la dégradation vs. efficacité des requêtes dégradation irréversible : chiffrement vs réécriture? Page 46

47 Apport du modèle de dégradation à la sécurité L attaque non anticipée est affaiblie Ex : à la signature d un contrat (emploi, assurance) Le bénéfice d une dégradation opérée n est jamais perdu Tout au moins : le bénéfice et l intérêt de l attaque sont réduits L attaque anticipée doit être répétée Ex : espionnage industriel Plus facilement détectée par un IDS Plus coûteuse à mettre en œuvre Procédé orthogonal aux mesures de sécurité classiques Contrôle d accès, authentification, chiffrement, IDS, firewall, etc.. Mais : le mécanisme de dégradation est corruptible Pas de protection contre un serveur constamment malveillant Page 47