Sécurisation des entrepôts de données : État de l'art et proposition d'une architecture

See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/279257359 Sécurisation des entrepôts de données : Etat de l'art et proposition d'une architecture Article - November 2009 CITATION 1 4 authors: Salah Triki Université de Kairouan 6 PUBLICATIONS 9 CITATIONS READS 141 J. Feki University of Sfax 82 PUBLICATIONS 174 CITATIONS Hanêne Ben-Abdallah King Abdulaziz University 213 PUBLICATIONS 903 CITATIONS Nouria Harbi Université Lumiere Lyon 2 27 PUBLICATIONS 71 CITATIONS Some of the authors of this publication are also working on these related projects: Business process outsourcing to the cloud View project Security Governance in Multi-cloud View project All content following this page was uploaded by J. Feki on 30 May 2016. The user has requested enhancement of the downloaded file. All in-text references underlined in blue are added to the original document and are linked to publications on ResearchGate, letting you access and read them immediately. Sécurisation des entrepôts de données : Etat de l’art et propo- sition d’une architecture Salah TRIKI, Jamel FEKI, Hanene BEN-ABDALLAH, Nouria HARBI Laboratoire Mir@cl Département d’Informatique, Faculté des Sciences Economiques et de Gestion de Sfax, Route de l’Aéroport Km 4 – 3018 Sfax, BP. 1088 {Salah.Triki, Jamel.Feki, Hanene.BenAbdallah}@fsegs.rnu.tn, [email protected] Résumé. Les entrepôts de données intègrent des données provenant de sources hétérogènes et sont utilisés par les dirigeants pour prendre des décisions stratégiques. Etant souvent propriétaires, ces données peuvent être sensibles et doivent être contrôlées à l’accès d'où la nécessité de leur sécurisation. Dans cet article, nous présentons d’abord une synthèse des travaux de recherche relatifs à la sécurité des entrepôts de données, ensuite nous exposons les grandes lignes d’une proposition pour leur sécurisation. 1 Introduction et Motivations Les entrepôts de données sont alimentés par plusieurs sources de données qui peuvent être hétérogènes ; ils permettent aux utilisateurs décisionnels d’orienter leurs requêtes vers une seule cible, c’est-à-dire un seul espace de stockage. Cela évite de gérer l’hétérogénéité des sources au moment de l’expression et l’évaluation des requêtes. En collectant et consolidant les données de sources différentes , les entrepôts de données permettent aux dirigeants de prendre des décisions stratégiques et d'établir des prévisions. En aval des entrepôts, des extraits orientés sujet et réorganisés selon un modèle multidimensionnel sont construits. Ces extraits sont dits des magasins de données ; ils visent à faciliter les opérations d’analyse décisionnelles. Des outils dédiés du marché d’entreposage de données (« Data Warehousing ») offrent de nombreuses opérations pour les traitements analytiques en ligne (OLAP : « On-Line Analytical Processing »). Les entrepôts de données occupent ainsi une place centrale dans les systèmes d’information décisionnels des organisations. Les entrepôts de données visent à avoir une vue commune de l’ensemble des données du système opérationnel, permettant ainsi la prise de décision. Cependant ils créent un conflit (Ralph K. (1997)). D’une part, les entrepôts de données doivent permettre un accès facile aux données et, d’autre part, les organisations doivent s’assurer que ces données ne sont pas divulguées sans contrôle. En effet certaines données sont personnelles et peuvent porter préjudice à leurs propriétaires quand elles sont divulguées comme, par exemple, les données médicales, les croyances religieuses ou idéologiques (Eduardo F. et al (2006)). Ainsi, plu- sieurs gouvernements ont promulgué des lois pour la protection des vies privées de leurs citoyens. Parmi ces lois, HIPPA (« Health Insurance Portability and Accountability Act » 1 Sécurité des entrepôts de données HHS (1996)) vise à protéger les données médicales des patients américains en obligeant les établissements du secteur des soins de la santé à suivre des règles de sécurité strictes. De même, GLBA (« Gramm-Leach-Bliley Act » GPO (1999)) oblige les organismes financiers américains à protéger les données de leurs clients ; quant à Safe Harbor (Export (2008)) permet aux entreprises s'y conformant de transférer et d'utiliser les données concernant les internautes européens ; Sarbanes-Oxley (Soxlaw (2002)) garantit la fiabilité des données financières des entreprises. Les organismes doivent utiliser des règles de sécurité strictes pour être conformes à ces lois, autrement ils seront sanctionnés. Malgré la présence de ces lois, les aspects de sécurité sont quasiment absents dans les entrepôts de données. Le présent travail vise deux objectifs. Premièrement, il examine l’état de l’art de la sécurité des entrepôts de données, et deuxièmement propose une solution pour la sécurisation d’un entrepôt. 2 Etat de l'art L’étude de l’état de l’art des travaux sur la sécurité des entrepôts de données nous a permis d’identifier deux classes d’approches: les approches portant sur la sécurisation des opérations : ces travaux permettent de répondre aux questions Qui a le droit d’accès et A quoi a-t-il le droit ? les approches portant sur la prévention contre les problèmes d'inférence ; elles permettent de répondre à la question Comment interdire à un utilisateur d'inférer des don- nées protégées à partir des données accessibles ? Bien évidemment, les deux classes d’approches se complémentent dans les services de sécurité qu’elles offrent. Dans la suite de cette section, nous exposons les caractéristiques de chacune de ces deux classes afin de dégager leurs points forts et leurs insuffisances. Ensuite, nous enchainons sur une proposition pour la sécurisation des entrepôts de données. 2.1 Approches de sécurisation des opérations Priebe et Pernul (2000) proposent une méthodologie multi-phases pour la conception de la sécurité des entrepôts de données. Les phases de la méthodologie sont : analyse préliminaire, conception, modélisation logique, modélisation physique et implantation. En se focalisant sur la phase d’analyse préliminaire les auteurs définissent deux catégories de besoins en sécurité, les besoins basics et les besoins avancés . Les besoins basics consistent à cacher un cube, les faces d'un cube, les détails des données, et/ou les dimensions. Tandis que les besoins avancés consistent à cacher les détails de certaines faces d'un cube, et/ou définir des règles de sécurité dépendant des données elles mêmes. Les besoins définis par les auteurs couvrent toutes les données existantes dans un entrepôt de données, par contre ils n’ont pas proposé une démarche pour leur identification. Rosenthal et Sciore (2000) proposent une méthode basée sur le langage SQL. Elle permet de sécuriser un entrepôt de données en considérant les règles de sécurité définies par les administrateurs des sources de données. Cette méthode se base sur les trois règles suivantes : L’accès à une table nécessite deux autorisations : 2 Triki et al. - le droit d’information, accordé par l’administrateur de sources des données : _Qui a_ accès et à quelle information ? (Par exemple, le salaire des employés est accessible au président). - le droit physique, accordé par l’administrateur de l’entrepôt de données : _Qui a ac-_ cès et à quelle table physique ? (Par exemple, les analyste-décideurs ont le droit d’interroger la table des ventes). Ainsi un utilisateur n’a le droit d’accéder à une table que s’il possède simultanément ces deux droits, information et physique. Si un utilisateur a le droit d’exécuter une requête Q , alors cet utilisateur aura le droit d’exécuter toute requête Q’ équivalente à Q . Ainsi, cette règle permet d’inférer de nouvelles autorisations ; par conséquent, la tâche de l’administrateur sera allégée. Par exemple, si un utilisateur a le droit d’interroger une vue définie entre deux tables T1 et T2 mais ne dispose pas du droit d’interroger chacune de ces deux tables, alors il sera autorisé d’exécuter une requête de jointure entre T1 et T2 . La méthode proposée par les auteurs se base sur le langage SQL qui est très répandue et très simple, cependant elle présente les inconvénients suivants : La nécessité de récupérer les droits d’information par l’utilisateur de la source. Généralement, ces droits ne sont pas explicitement définis par des commandes LMD (« Langage de Manipulation de Données ») mais sont implicitement exprimés à travers des vues relationnelles d’où la nécessité d’une analyse de toutes les vues. La difficulté de faire correspondre une information sécurisée avec son homologue dans l’entrepôt de données surtout si cette dernière a subit une transformation significative ( e.g. , calcul) lors du processus ETL (« Extract/Transform/Load ») de son chargement dans l’entrepôt de données. Les entrepôts de données utilisent des modèles de contrôles d’accès. Parmi ces modèles, RBAC (Role-Based Access Control, Sandhu et al. (1996)) qui se base sur le rôle qu’occupe l’utilisateur dans l’organisation pour prendre les décisions d’accès. Les entrepôts de données doivent répliquer les contraintes de sécurité qui existent dans les sources. Si par exemple, les sources de données exigent une contrainte de sécurité qui indique que les analyste-décideurs n’ont accès qu’à la table Vente alors une contrainte du même type doit exister dans l’entrepôt de données. Lorsque l’administrateur de l’entrepôt veut augmenter les privilèges des utilisateurs, il faut qu’il informe l’administrateur de la source de données. Celui-ci peut accepter ou refuser. Thuraisingham et al. (2007) proposent le modèle E-RBAC (Extended-Role Based Access Control) qui permet de gérer ce cas. C’est une combinaison du modèle RBAC et du modèle de contrôle d’usage UCON (Usage Control Model, Jaehong P. R. S. (2004)). UCON se base sur des conditions des obligations et des droits pour prendre les décisions d’accès. Les obligations assurent le respect des droits d’accès définis dans les sources tandis que les conditions définies à partir des règles de sécurité permettent de gérer les conflits entre ces dernières. Un conflit se produit dans le cas de règles contradictoires, par exemple les analyste-décideurs ont le droit d’accéder à la table Vente dans la source A mais ne possèdent pas ce droit dans la source B . Le modèle proposé par les auteurs se base sur deux modèles très répandus facilitant ainsi son intégration dans les systèmes existants, néanmoins son implantation est difficile et nécessite un temps d’exécution important. Villarroel et al. (2006) proposent un profil UML (OMG (2005)) pour modéliser la sécurité ainsi qu’une extension du langage OCL (« Object Constraint Language ») (OMG (2006)) 3 Sécurité des entrepôts de données afin de spécifier les contraintes de sécurité lors de la phase de conception d’un entrepôt de données. Le profil UML, nommé SECDW (« Secure Data Warehouse »), comprend de nouveaux types, stéréotypes et valeurs étiquetées. Il permet de prendre en compte les contrôles d’accès obligatoire (« Mandatory Access Control » USDoD (1985)) et RBAC ( cf . Tab 1 et Tab 2). Le Tableau 1 indique les nouveaux types de données définis dans SECDW et le Tableau 2 montre leurs valeurs correspondantes. SECDW comporte quatre stéréotypes : les stéréotypes de classes sécurisées et entrepôt de données sécurisés comprenant des valeurs étiquetées associées aux attributs, niveaux de sécurité, rôles et compartiments, les stéréotypes d’attributs et d’instances contenant des valeurs étiquetées associées aux niveaux de sécurité , rôles et compartiments, les stéréotypes permettant de représenter les contraintes de sécurité, les règles d’autorisation et les règles d’audit. le stéréotype UserProfile concernant la création de contraintes dépendantes des informations des utilisateurs. Nom Classe de base Description Niveau Enumeration Le type Niveau est composé de tous les niveaux de sécurité considérés Niveaux (de sécurité) Primitif Le type Niveaux (de sécurité) contient le niveau de sécurité le plus bas et le niveau de sécurité le plus haut. Rôle Primitif Le type Rôle représente une hiérarchie de rôles d’utilisateurs Compartiment Enumeration Le type Compartiment est composé de tous les compartiment s d’utilisateurs Privilège Enumeration Le type Privilège est composé de tous les privilèges considé- rés TentativeAccés Enumeration Le type TentativeAccés est composé des différentes tenta- tives d’accès Tab 1 - Les nouveaux types de données de SECDW (Villarroel et al. 2006) Nom Type Description Valeur par défaut Classes Set(OclType) Spécifie toutes les classes du modèle. Cette valeur étiquetée permet de naviguer à travers toutes les classes du modèle. Ensemble vide. Attributs Set(OclType) Spécifie tout les attributs d’une classe. Cette valeur étiquetée permet de naviguer à travers tous les attributs du modèle. Ensemble vide. NiveauxSécurité Niveaux Spécifie la valeur de l’intervalle de niveau de sécurité, qu’une instance d’une classe peut rece- voir. Le niveau le plus bas. RôlesSecurité Set(Rôle) Spécifie un ensemble de rôles d’utilisateur. Chaque rôle est la racine d’un sous arbre de hiérar- L’ensemble est composé d’un rôle qui est la 4 Triki et al. Col1 Col2 chie de rôles définis dans l’organisation. hiérarchie de rôles définis pour l’organisation. Comparti- mentsSécurité Set(Compartiment) Spécifie un ensemble de compar- timents. Ensemble vide de compartiments ClassesImpliquées Set(OclType) Spécifie les classes qui sont im- pliquées dans une requête. Vide LogType TentativeAccés Spécifie les accès qui doivent être journalisés Vide AutorisationSign +,- Spécifie l’autorisation d’accès à une classe pour un utilisateur ou un groupe d’utilisateurs. – autorisé (+) – interdit (-) + AutorisationPrivi- lège Set(Privilège) Spécifie les privilèges attribués ou retirés à un utilisateur. Lecture estTemps Booléen Spécifie si une dimension repré- sente le temps ou non. Faux DérivationRôle Chaine de carac- tères Si l’attribut est dérivé, cette valeur étiquetée représente la règle de dérivation. Vide Tab 2 : Les valeurs étiquetées de SECDW (Villarroel et al. 2006) Il existe plusieurs types de modèle RBAC. Dans le type hiérarchique les rôles sont définis en suivant la hiérarchie des rôles des utilisateurs dans l’organisation. Ainsi un rôle est constitué d’un sous ensemble des droits d’accès appartenant à celui qui le précède dans la hiérarchie. Par exemple, les employés auront un sous ensemble des droits d’accès inférieur à celui du directeur. Villarroel et al. (2006) ont ajouté un nouveau type appelé Tree permettant de représenter la hiérarchie des rôles. Le profil proposé par les auteurs est basé sur le langage UML implanté par plusieurs outils ; cependant, ils se sont limités au niveau conceptuel et n’ont pas proposé une démarche pour l’élaboration d’un modèle d’entrepôt de données sécurisé. Soler et al. (2006) proposent une extension du CWM (« Common Warehouse Metamodel ») Dans cette extension, les auteurs se sont focalisés sur le package Relational de la couche Resource du CWM. Les extensions apportées sont ( cf . Fig 2) : 5 Sécurité des entrepôts de données l’ajout de la métaclasse SecurityProperty ainsi que ses sous-metaclasses SecurityLe- vels , SecurityCompartments et SecurityRole . Celles-ci permettent d’attribuer des catégories aux données et aux utilisateurs et d’affecter à ces derniers des rôles. l’ajout de la metaclasse SecurityConstraint et de ses sous-metaclasses AuditRule , AuthorizationRule et SecurityRule permettant de spécifier les contraintes de sécurité et les règles d’audit. L’extension proposée par les auteurs prend en compte les modèles de sécurité RBAC et obligatoire mais elle n’est valable que pour le modèle de données relationnel. Soler et al. (2007) proposent une approche MDA (« Model Driven Approach ») ( cf . Fig 3) pour le développement d’un entrepôt de données sécurisé. Cette approche exploite le langage QVT (« Query View Transformation ») pour automatiser le passage du niveau conceptuel (Villarroel et al. (2006)) au niveau logique (Soler et al. (2006)). L’approche MDA proposée par les auteurs traite la sécurité au niveau conceptuel et au niveau logique ; toutefois, ces auteurs n’ont pas prévu une méthode pour vérifier que les contraintes de sécurité définies au niveau conceptuel sont respectées au niveau logique. i* est un framework (Eric S. K. Y. (1997)) permettant de modéliser les besoins lors de la phase d’analyse d’un projet informatique. Soler et al. (2008) proposent un profil basé sur i* 6 Triki et al. qui permet de modéliser les besoins en sécurité d’un entrepôt de données au niveau métier d’une approche MDA. Ce profil permet de : représenter l’acteur Gestionnaire de sécurité qui est la personne chargée de la sécurité dans une organisation, modéliser les besoins en sécurité, et définir les compartiments , les niveaux et les rôles des utilisateurs en tant que ressources. Les auteurs proposent un profil qui prend en compte le modèle RBAC et le modèle obligatoire par contre ils n’ont pas proposé une démarche pour identifier les besoins en sécurité. Nouria H. et al (2008) ont étudié l’état de l’art et présenté une étude comparative concernant quelques travaux de recherche sur la sécurisation des entrepôts. De même ils ont détaillé l’aspect sécurité des outils commerciaux OLAP. L’étude comparative est basée sur les quatre critères suivants : Confidentialité : les données ne sont accessibles qu’aux utilisateurs autorisés, Intégrité : les données ne sont pas corrompues, Disponibilité : les données sont accessibles en permanence, et Authenticité : l’origine et l’intégrité des données sont garanties. Ces critères correspondent aux quatre services de sécurité retenus pour les entrepôts de données. L’étude a montré que : la majorité des travaux concluent que la sécurité physique (des infrastructures, des serveurs…) est insuffisante pour garantir la sécurité d’un entrepôt de données, l’essentiel des travaux a porté sur la gestion de la confidentialité, aucun travail ne propose une démarche pour la sécurisation de toutes les phases du processus d’entreposage (Nouria H. 2008), quelques outils commerciaux fournissent des mécanismes pour la gestion des droits d’accès, mais aucun outil ne propose un standard de contrôle d’accès dans le monde multidimensionnel. Les auteurs ont défini les exigences en sécurité d’un entrepôt de données ; cependant, ils n’ont pas pris en compte le cas des inférences. Après cette présentation des principaux travaux sur la sécurisation dans les entrepôts de données exprimée au niveau des opérations, nous passons à la deuxième classe d’approches, qui porte sur la prévention des inférences. 2.2 Prévention des inférences Sung et al. (2006) définissent la sécurisation des données comme un moyen pour préserver la confidentialité des données des cellules d’un cube tout en fournissant les réponses aux requêtes avec une exactitude élevée et en respectant les trois objectifs de : Sécurité : les données sensibles ne doivent pas être divulguées, Exactitude : les résultats des requêtes doivent avoir un degré d’exactitude élevé, et Accessibilité : les restrictions ne doivent pas interdire les requêtes légitimes. 7 Sécurité des entrepôts de données La méthode zero-sum , qu’ils proposent, prend en compte uniquement les requêtes de sommation. Elle consiste à ajouter des valeurs aléatoires aux cellules afin d’altérer leur contenu. Les sommes des valeurs aléatoires par lignes et par colonnes sont égales à 0. La méthode zero-sum préserve la sécurité des données tout en répondant aux requêtes avec un degré d’exactitude important ; toutefois, elle nécessite un temps de calcul important et ne traite que les requêtes de type somme. Cuzzocrea et al. (2008) proposent un framework qui permet de générer à partir d’un cube A un cube A’ respectant les contraintes de sécurité. Celles-ci se basent sur des métriques dont la fiabilité est reconnue par le domaine de la sécurisation des données (Dwork, C. (2008)). Ce framework permet de sélectionner : une fraction des dimensions, les régions des données ayant une distribution biaisée, et les données qui satisfont aux contraintes de sécurité pour chaque région. Le framework ne nécessite pas un temps de calcul important ; mais il présente l’inconvénient de ne pas traiter les requêtes de type SUM et AVG, très fréquentes dans les entrepôts de données. 3 Synthèse de l’état de l’art Les travaux sur la sécurisation des opérations traitant la sécurité aux niveaux conceptuel et physique sont les plus nombreux. Les travaux sur la prévention des inférences ne traitent qu’un seul type de requêtes. Le Tableau 3 récapitule les avan dans cet article. Travaux Col2 ntages et les limites des travaux q Avantages que nous avons présentés Limites Travaux Travaux Avantages Limites Sécurité des Opérations Priebe et Pernul (2000) Utilisation de langage naturel pour définir les besoins. Absence de démarche pour l’identification des besoins en sécurité. Difficulté de valida- tion/vérification des be- soins. Sécurité des Opérations Rosenthal et Sciore (2000) Simplicité car basé sur le langage SQL. La sécurité est traitée au niveau physique seulement. Sécurité des Opérations Thuraisingham et al. (2007) Comble les manques du modèle RBAC qui est très utilisé. Difficile à implanter. Sécurité des Opérations Villarroel et al. (2006) Prise en compte des modèles RBAC et obligatoire. – Uniquement le niveau conceptuel a été pris en compte, – Pas de démarche pour la conception d’un entrepôt de données sécurisé. Sécurité des Opérations Soler et al. (2006) Prise en compte du modèle RBAC et mandataire. Ne traite pas le modèle objet. Sécurité des Opérations Soler et al. (2007) Traitement de la sécurité au niveau conceptuel et au niveau logique. Pas de méthode pour véri- fier que les concepts de sécurité, définis au niveau conceptuel ont été respec- 8 Triki et al. Col1 Col2 Col3 tés au niveau logique. Soler et al. (2008) Prise en compte du modèle RBAC et obligatoire. Pas de démarche pour identifier les besoins. Nouria et al (2008) Définition des exigences en sécurité d’un entrepôt de don- nées. Le cas des inférences n’a pas été pris en compte. Prévention des Inférences Sung et al. (2006) Préservation de la sécurité des données tout en répondant aux requêtes avec un degré d’exactitude important. – Nécessite un temps de calcul important, – Traite uniquement les requêtes de types somme. Prévention des Inférences Cuzzocrea et al. (2008) Introduction de la notion de compression qui permet de ré- duire le temps de calcul. Pas de prise en compte des requêtes fréquentes dans les entrepôts de données de type SUM, AVG. 4 Proposition d’une approche pour la sécurisation des entre- pôts de données Afin de sécuriser un entrepôt de données, nous proposons une approche qui permet d’empêcher d’inférer des données cachées à partir des données accessibles tout en prenant en compte la sécurité des opérations. Ainsi, notre approche se base sur une combinaison des propositions actuelles permettant une sécurisation globale. La Figure 4 décrit cette approche qui comporte principalement les trois volets suivants : Détection des dépendances entre les données. 9 Sécurité des entrepôts de données Création d’un réseau Bayésien en se basant sur les dépendances entre les données. Un réseau Bayésien est un graphe dans lequel les relations de cause à effet entre les nœuds sont probabilisées. Par exemple, un avion ne peut atterrir que sur une piste ayant une certaine longueur minimale. Sachant que la longueur de la piste ne doit pas être divulguée, si nous savons que l’avion Av1 a atterri sur la piste P1 alors nous pouvons déduire la longueur minimale de la piste. La dépendance entre l’attribut Avion et l’attribut Piste d’atterrissage peut être représentée par le réseau Bayésien de la Figure 5. Le Tableau 4 contient les probabilités d’inférer la longueur d’une piste ; où l’on distingue quatre cas : 1- Longueur minimale de la piste d’atterrissage exigée par un avion est inconnue ; la probabilité concernant la longueur de la piste est la même pour les trois types d’atterrissage ; courte, moyenne et longue ; elle est égale à 0,33 2- Longueur minimale de la piste d’atterrissage exigée par un avion est courte ; après atterrissage de l’avion, la probabilité est aussi la même pour les trois types ; sa valeur est de 0,33 3- Longueur minimale de la piste d’atterrissage exigée par un avion est moyenne ; dans ce cas après atterrissage de l’avion la probabilité concernant le type de piste est 0 pour la courte, 0,5 pour la piste moyenne et de 0,5 pour la piste longue. 4- Longueur minimale de la piste d’atterrissage exigée par un avion est longue ; dans ce cas, après atterrissage la probabilité est de 0 pour la courte et la moyenne et elle est de 1 pour la piste longue. FIG 5 : Réseau Bayésien modélisant la dépendance entre Avion et Piste d’atterrissage Col1 Avion (longueur minimale de la piste d’atterrissage) Col3 Col4 Col5 Col6 Longueur de la piste Inconnue Courte Moyenne Longue Longueur de la piste Courte 0,33 0,33 0 0 Longueur de la piste Moyenne 0,33 0,33 0,5 0 Longueur de la piste Longue 0,33 0,33 0,5 1 Création d’un module de sécurité. Le fonctionnement de ce module concerne l’autorisation ou le refus de nouvelles requêtes. Il se compose de deux parties. La première partie est relative à la sécurisation des opérations, la deuxième porte sur la détection des inférences à l’aide de l’historique des requêtes et du réseau Bayésien : après lancement d’une requête, trois étapes sont à franchir : 1- la partie sécurisation des opérations vérifie que la requête, ne viole aucune règle de sécurité, 2- la partie détection des inférences consulte l’historique des requêtes de l’utilisateur et calcule les probabilités du réseau Bayésien, 3- après vérification, sur la base des probabilités calculées la requête demandée est autorisée ou refusée. 10 Triki et al. 5 Conclusion Dans cet article, nous avons mené une étude et présenté une synthèse de l'état de l'art sur la sécurité des entrepôts de données. Les travaux, jusque là proposés ont abordé la problématique de la sécurité des entrepôts de données selon deux approches : la sécurisation des opérations et la prévention des inférences. Toutefois, la majorité de ces travaux sont relatifs à la première classe sans pour autant prendre en compte les cas de sources structurellement hétérogènes ou ayant des modèles de sécurité différents. Quant aux quelques travaux dans le cadre de la prévention des inférences, nous constatons qu'ils ne prennent en compte qu'un seul type de requêtes utilisant les fonctions d’agrégation : MAX ou SUM . A la lueur de cet état de l'art, nous avons présenté une approche pour la sécurisation des entrepôts de données basée sur les réseaux Bayésiens et qui combine les deux axes de la sécurité des entrepôts : les opérations et les inférences de données cachées. Cette proposition est en cours de finalisation pour être implantée et testée. Références Cuzzocrea, A., Russo V., et Saccà D. (2008). A robust sampling-based framework for pri- vacy preserving olap. In DaWaK, pp. 97–114. Springer. Dwork, C. (2008). Differential privacy : A survey of results. In TAMC, pp. 1–19. Eduardo F., Juan T., Rodolfo V., et Mario P. (2006). Access control and audit model for the multidimensional modelling of data warehouses. In Decision Support Systems Volume 42, Issue 3, pages: 1270 – 1289. Eric S. K. Y. (1997). Towards modelling and reasoning support for early-phase requirements engineering. Proceedings of the Third IEEE International Symposium on Requirements Engineering. Export (2008). http://www.export.gov/safeharbor/ Jaehong P. R. S. (2004). The UCON usage control model. In Proceedings of ACM Trans. Inf. Syst. Secur., vol 7, pages 128--174. HHS (1996). http://www.hhs.gov/ocr/privacy/index.html Nouria H. (2008). Cours: Sécurité des entrepôts de données, Master 2 ECD, Université Lumière Lyon2. Nouria H., Maaroufi G., Omar B. (2008) Sécurité des entrepôts de données - état de l’art -. Troisième Atelier sur les Systèmes Décisionnels. 10-11 octobre 2008, Mohammedia, Maroc. OMG (2003). Common Warehouse Metamodel (CWM), Version 1.1. OMG (2006) Object Constraint Language (OCL), Version 2.0. OMG (2005) Unified Modeling Language (UML),Version 2.0. 11 Sécurité des entrepôts de données Priebe, T. et Pernul G. (2000). Towards OLAP security design - survey and research issues. In International Workshop on Data Warehousing and OLAP. GPO (1999). http://www.gpo.gov/fdsys/pkg/PLAW-106publ102/content-detail.html Ralph K. (1997). Hackers, Crackers, and Spooks; ensuring that your data warehouse is se- cure. DBMS Magazine. Rosenthal, A. et Sciore E. (2000). View security as the basis for data warehouse security. In CAiSE Workshop on Design and Management of Data Warehouses. Sandhu, R. S., Coyne E.J., Feinstein H.L. et Youman C.E. (1996), "Role-Based Access Control Models", IEEE Computer 29(2): 38-47, IEEE Press, 1996.- proposed a frame- work for RBAC models Soler, E., V. Stefanov, J.-N. Mazón, Trujillo J., Fernández-Medina E., et Piattini M. (2008). Towards comprehensive requirement analysis for data warehouses : Considering security requirements. In ARES, pp. 104–111. IEEE Computer Society. Soler, E., Trujillo J., Fernández-Medina E., et Piattini M. (2007). A framework for the devel- opment of secure data warehouses based on mda and qvt. In ARES, pp. 294–300. IEEE Computer Society. Soler, E., Villarroel R., Trujillo J., Fernández-Medina E., et Piattini M. (2006). Representing security and audit rules for data warehouses at the logical level by using the common warehouse metamodel. In ARES, pp. 914–921. IEEE Computer Society. Sung, S., Y. Liu, et P. Ng (2006). Privacy preservation for data cubes. Knowledge and Information Sys- tems 9, 38–61. Soxlaw (2002). http://www.soxlaw.com/ Sung S. Y., Liu Y., Xiong H., Peter A. (2006). Privacy preservation for data cubes. In Knowledge and Information Systems 9, pp 38-61. USDoD (1985). Trusted Computer System Evaluation Criteria. United States Department of Defense. December 1985. DoD Standard 5200.28-STD. Thuraisingham, B., Kantarcioglu M., et Iyer S.(2007). Extended rbac-based design and im- plementation for a secure data warehouse. IJBIDM 2, 367–382. Villarroel, R., Fernández-Medina E., Piattini M., et Trujillo J. (2006). A uml 2.0/ocl exten- sion for designing secure data warehouses. Journal of Research and Practice in Informa- tion Technology 38. Summary Data warehouses integrate data from heterogeneous sources and are used by decisional users to make strategic decisions. These data may be sensitive and should not be accessed without controls thus the need for their security is highly required. In this article we present a synthesis of research in the field of data warehouse security and we propose an approach for their secure. 12 View publication stats