sécurité des entropot des données

1. Ce sont vos données - êtes-vous sûr que
cela est sécurisé?
3/9/2020 1

2.  Introduction
 Context et problematique General
 Solution :
 Article 1 : A Pragmatic Approach to Conceptual Modeling of OLAP
Security
 Article 2 :Data Warehouse Security Based on Metadata
 Article 3 : USING DATATYPE-PRESERVING ENCRYPTION TO ENHANCE
DATA WAREHOUSE SECURITY
 Etude comparative
 Conclusion
3/9/2020 2

3.  La mise en place d'entrepôts de données (DW) pour les énormes bases de
données est devenue l'un des besoins majeurs de notre époque. Les
grandes organisations disposant de différentes petites bases de données
ont besoin d'une intégration appropriée de leurs petites bases de données
et du développement d'entrepôts de données.
 Data-Warehouse est l'une des technologies les plus récentes qui donne
accès à des sources d'informations diverses et distantes, améliorant les
capacités de prise de décision de l'organisation.
 la production de données agrégées dérivées de l'entrepôt de données
nécessite le maintien continu de l'intégrité, de la confidentialité et de la
disponibilité.
3/9/2020 3

4.  Le but d'un entrepôt de données est
généralement de rendre de grandes
quantités de données facilement
accessibles aux utilisateurs, leur
permettant ainsi d'extraire des
informations sur l'entreprise dans son
ensemble.
 Toute restriction de sécurité peut être
considérée comme un obstacle à la
réalisation de cet objectif et devient une
contrainte pour la conception de
l'entrepôt.
3/9/2020 4

5. Problématique spécifique :
 Les entrepôts de données étaient traditionnellement
interrogés par des utilisateurs de haut niveau.
 Cette hypothèse n'est toutefois plus appropriée.
 Tous les utilisateurs ne devraient pas pouvoir accéder à
toutes les données.
 La protection n'est pas définie en termes de tables, mais
de dimensions, de chemins hiérarchiques, de niveaux de
granularité.
 La nécessité d'une conception de sécurité OLAP appropriée
apparaît.
 Le présent document porte principalement sur la phase de
conception.
3/9/2020 5

6. Concepts de base :
 Dans la zone d'entrepôt de données et OLAP, les
notations basées sur UML ne sont pas encore très
acceptées dans la pratique.
 Si une modélisation conceptuelle explicite est
effectuée, une notation intuitive, telle que la
notation ER, est utilisée.
 La notation ADAPT semble être l’une des rares
exceptions. Il est par exemple mentionné lors de
différentes conférences de groupe d'utilisateurs
ORACLE Express.
 Cependant, ADAPT manque d'une formalisation
appropriée et parfois d'une définition claire de
sa sémantique.
3/9/2020 6

7. Solutions :
 Afin de fonder correctement notre approche de modélisation de
la sécurité, nous avons tenté d'éliminer ces inconvénients en
créant une notation UML nommée «ADAPTed UML» (qui utilise les
symboles ADAPT comme stéréotypes).
 Le modèle (méta) conceptuel développé pour les modèles OLAP
conceptuels introduit le cube d'éléments, la mesure, le niveau de
dimension et l'attribut de dimension.
 Les niveaux de dimension sont organisés en ordres partiels
(dimensions implicites).
 La granularité d'un cube est définie via un ensemble de niveaux
de dimension de base.
3/9/2020 7

8. 3/9/2020 8

9.  Outre les éléments de modèle mentionné, le méta-modèle
contient également des références aux éléments UML
principaux pour leur représentation graphique dans ADAPTed
UML.
 Les dépendances entre le cube et la mesure sont dessinées
sous forme d’associations avec une navigabilité définie.
 les hiérarchies de dimension sont représentées par des
agrégations.
 Les symboles ADAPT sont utilisés comme stéréotypes
graphiques
3/9/2020 9

10. Languages :
 un modèle OLAP logique basé sur Microsoft
Analysis Services est utilisé pour la
conception.
 Dans le cadre de la spécification OLEDB pour
OLAP, Microsoft propose une instruction
CREATE CUBE dans le cadre des
fonctionnalités DDL du langage de requête
MDX (expressions multidimensionnelles).
3/9/2020 10

11. Sécurité de modélisation:
 Notre modèle de sécurité pour OLAP repose sur l'hypothèse
d'une politique de sécurité centrale (basée sur l'administrateur).
 Les restrictions d'accès sont définies comme des contraintes
d'autorisation rendant nécessaire l'identification d'objets et de
sujets de sécurité.
 À ce stade, nous assumons la notion de rôles (sans
chevauchement ni hiérarchie) en tant que sujets de sécurité.
 Par conséquent, en plus des éléments ci-dessus (cubes,
dimensions, etc.), le rôle de l'élément est introduit.
 Les contraintes d'autorisation peuvent être positives
(subventions explicites) ou négatives (refus explicites).
 Nous basons le modèle de sécurité sur une politique de monde
ouvert (c’est-à-dire que l’accès aux données est autorisé sauf
refus explicite) avec des contraintes d’autorisation négatives.
3/9/2020 11

12. Spécification de contraintes de sécurité OLAP avec MDSCL
(exemples) :
 ces questions ont été explorées dans le cadre d'un projet
visant à étudier l'intégrité des données et la sécurité d'une
application concernant les entrées de visiteurs dans les ch
âteaux et autres monuments du sud de la Bohême.
 Ce document utilise un langage de contrainte de sécurité
multidimensionnelle (MDSCL) basé sur MDX avec une syntaxe
similaire à celle de l'instruction CREATE CUBE.
 Afin d'exprimer les contraintes d'autorisation (négatives), un
ensemble d'instructions HIDE est utilisé.
3/9/2020 12

13. Graphical representation :
3/9/2020 13

14. Avantages et les inconvients :
 Dans ce modèle, seul l’accès direct aux données sensibles
a été envisagé.
 Le contrôle de l'accès indirect au moyen de requêtes de
suivi n'a pas été abordé.
 Le modèle de sécurité est limité aux autorisations
négatives.
 une combinaison d'autorisations négatives et positives
serait possible (par exemple, les instructions HIDE et
SHOW)..
3/9/2020 14

15. Problématique spécifique :
 Il faut Faites attention aux métadonnées de
l'entrepôt de données , Mais pourquoi ? …….
 Ils contiennent des informations de sécurité
telles que des règles d'accès, des classifications
d'objets de sécurité ou des autorisations des
sujets de sécurité.
3/9/2020 15

16. Concepts de base :
 Les aspects de sécurité doivent déjà être pris en compte
lors de la phase de conception de l'entrepôt de données.
 Ce modèle affecte une vue d'entrepôt de données réduit à
chaque groupe d'utilisateurs.
 Les métadonnées peuvent décrire les mécanismes de
sécurité dans un environnement DW. Dans ce cas, les
règles d'accès avec les informations correspondantes sur
les objets de sécurité et les sujets sont stockées sous
forme de métadonnées.
 Ce modèle de sécurité limite la portée des requêtes des
utilisateurs aux données qui ne menacent pas les règles de
sécurité du système d'information.
3/9/2020 16

17. Solution :
 En basant sur des métadonnées, le modèle de sécurité
proposé a pour objectif principal de réduire les requêtes
des utilisateurs aux seules données qu’elles doivent
consulter.
 Security Manager définit pour chaque utilisateur (ou pour
chaque groupe d'utilisateurs) des zones de données
auxquelles cet utilisateur (groupe d'utilisateurs) peut
accéder.
3/9/2020 17

18. Langage
 Ce modèle de sécurité basé sur le logiciel a été
implémenté dans «JAVA». Il est indépendant de la plate-
forme, ce qui signifie que la version actuelle est exécutée
sous Windows NT et UNIX.
3/9/2020 18

19. Méthode :
 Les métadonnées peuvent décrire les mécanismes de
sécurité dans un environnement DW.
 Dans ce cas, les règles d'accès avec les informations
correspondantes sur les objets de sécurité et les sujets
sont stockées sous forme de métadonnées.
 Les sujets de sécurité sont responsables des modifications
apportées à l'entrepôt de données et font en sorte que les
informations circulent dans différents objets et sujets.
 Lorsqu'un utilisateur accède aux données de l'entrepôt de
données, la couche de gestion de requête sécurisée doit
vérifier si cet accès est autorisé ou non. Pour ce faire, il
vérifie les autorisations d'accès correspondantes en
analysant les métadonnées de sécurité.
3/9/2020 19

20. Modèle :
Les principales composantes de ce modèle sont:
 Security Manager: pour l’administration, la définition et la
description des utilisateurs et des groupes d’utilisateurs.
 SQML (Secure Query Management Layer): qui a pour tâche
de filtrer les requêtes des utilisateurs en vérifiant si leur
exécution est autorisée.
3/9/2020 20

21. Avantages :
 Les aspects de sécurité sont d'ores et déjà pris en compte
dans la phase de conception de l'outil de travail, afin
d'éviter des adaptations fondamentales ultérieures très
coûteuses.
 Ce modèle de sécurité est avantageux pour ces types de
solutions d'entrepôt de données, dont le contenu peut être
décrit par des métadonnées.
 Cela donne l'impression que le contenu de l'entrepôt de
données, pour l'utilisateur respectif, n'est en réalité pas
plus que ce qui doit être vu (transparence pour l'utilisateur
final).
3/9/2020 21

22. Inconvients :
 Les restrictions de sécurité appliquées au DW peuvent entraîner
une perte d'informations. Si les analystes ont un accès restreint
aux données du DW, il leur sera peut-être impossible d’obtenir
une image complète des tendances dans la zone analysée.
 Pour identifier les exigences de sécurité, les problèmes
juridiques, d'audit, de réseau et autres doivent être pris en
compte.
 La vérification des restrictions de sécurité aura un prix en
affectant les performances de l'environnement de l'entrepôt de
données (cycles de calcul et temps d'exécution supplémentaires).
 Ce modèle de sécurité est basé sur une «zone de données
prédéfinie» pour chaque utilisateur (ou pour chaque groupe
d'utilisateurs). Ainsi, dès que le nombre de groupes d'utilisateurs
/ utilisateurs augmente, la configuration de ces «zones» devient
une tâche ardue pour le responsable de la sécurité. .
3/9/2020 22

23. Problématique spécifique :
Les données sont à risque pendant chacune de ces phases.
Plusieurs facteurs rendent les entrepôts de données
particulièrement vulnérables aux attaques :
 Environnement hétérogène
 Plusieurs copies de données sensibles
 pression limite
 informations précieuses concentrées
 Transmission sur des lignes non sécurisées
 Fichiers de chargement non protégés
 Changements fréquents de sources et de cibles
3/9/2020 23

24. Concepts de base :
Lorsque nous avons décidé de développer une approche
cryptographique de la sécurité des entrepôts de données
pouvant être appliquée dans les environnements complexes
et hétérogènes rencontrés dans le monde des affaires, nous
avons identifié certains objectifs critiques:
 Crypto-graphiquement fort
 Travailler avec n'importe quel SGBD et OS
 Travailler avec différents jeux de caractères
 Aucune modification de l'application ou de la base de
données
 Aucune dépendance au langage de programmation
3/9/2020 24

25. Solution :
 Notre méthode réduit le besoin de modifications des
structures de la base de données et des applications en
préservant le type de données du champ chiffré. La
préservation du type de données signifie simplement
que chaque champ de texte chiffré est aussi valide que
le champ de texte en clair qu’il remplace. La clé de
notre approche consiste à définir un alphabet approprié
de caractères valides et à effectuer toutes les
opérations dans les limites des contraintes de l’alphabet
défini.
 Chaque type de données nécessite un choix judicieux
d'alphabet.
3/9/2020 25

26. Méthode :
 L’approche utilisée peut être combinée à des algorithmes
de chiffrement bien connus, tels que DES ou IDEA, afin
d’augmenter considérablement la charge de l’attaquant.
 L'idée de base est d'utiliser un algorithme établi de force
connue pour produire les valeurs de «décalage».
 L'algorithme DES prend en entrée un bloc d'entrée de 64
bits et une clé de 64 bits (56 bits de clé et 8 bits de parité)
et utilise ces deux valeurs pour produire une sortie de 64
bits.
 La sortie du texte chiffré peut être déchiffrée à l'aide de
la même clé.
3/9/2020 26

27. 3/9/2020 27

28. 3/9/2020 28

29. Avantages :
 Crypto graphiquement fort
 Travailler avec n'importe quel SGBD et OS
 Travailler avec différents jeux de caractères
 Aucune modification de l'application ou de la base de
données
 Aucune dépendance au langage de programmation
3/9/2020 29

30. inconvients :
 Les données cryptées peuvent être mal interprétées.
 Fonctions de colonne (SUM, AVG, MIN, MAX) peut ne pas
être utilisé.
 Le problème de distribution des clés existe toujours.
 La compromission des clés nécessite un rechiffrement de
la base de données entière.
3/9/2020 30

31. Critères de Comparaison :
 C1: règles d'autorisation :
 C2: Règles d'audit :
 C3: Règles de sécurité des attributs
 C4: Transparence des restrictions de sécurité
 C5: prototype destiné ou non à être utilisé dans différentes
politiques de sécurité
 C6:modification de l'application ou de la base de données
 C7: dépendance au langage de programmation
 C8: performance
3/9/2020 31
C1 C2 C3 C3 C4 C5 C6 c7 c8
Solution 1 Oui Non Oui - oui - oui Oui -
Solution 2 oui non oui ++ non ++ oui - ++
Solution 3 oui oui oui + Oui +++ Non Non ++

32.  L'évaluation du document 1 en fonction de certains critères
(performance, par exemple) avec les autres documents ne
pouvait pas être suffisamment rationnelle, car elle mettait
l'accent sur les aspects conceptuels sans toucher aux aspects liés
à la mise en œuvre.
 Pour l’article 3 Nous ne proposons pas de chiffrement préservant
les types de données comme solution ultime à tous les problèmes
de sécurité liés à l'entrepôt de données. Il est plutôt présenté
comme un des nombreux mécanismes à utiliser dans une
stratégie de sécurité plus globale.
 Plus précisément, nous considérons cette technique comme un
dispositif de confinement qui limite les dommages potentiels en
cas de contournement réussi des autres contrôles de sécurité.
3/9/2020 32

33.  Les restrictions de sécurité appliquées à l’entrepôt de
données peuvent avoir de bonnes raisons d’affaires, mais il
convient de noter qu’elles peuvent entraîner une perte
potentielle d’informations.
 Si les analystes ont un accès restreint aux données de
l’entrepôt de données, il leur sera peut-être impossible
d’obtenir une image complète des tendances dans la zone
analysée.
 La vérification des restrictions de sécurité aura bien sûr
son prix en affectant les performances de l'environnement
de l'entrepôt de données, car des contrôles de sécurité
supplémentaires nécessitent des cycles de processeur et
un temps d'exécution supplémentaires.
 Cela mene a chercher comment optimiser ces cycles de
processeur et de temps d’éxuction ?
3/9/2020 33

34. 3/9/2020 34