Sécurité des datawarehouse

Question 1 - Objectif de l'entrepôt de données et paradoxe de la sécurité

L'objectif principal d'un entrepôt de données (ED) est la mise à disposition de quantités importantes de données pour les utilisateurs, afin de permettre l'extraction d'informations décisives sur la totalité d'un processus.

Cependant, il existe un paradoxe inhérent entre cet objectif et la sécurité. La nécessité d'appliquer des mesures de sécurité implique une restriction sur l'accès aux données. Par conséquent, en sécurisant l'entrepôt, il n'est plus possible pour un utilisateur d'avoir une image complète sur les tendances du domaine en question. Ces exigences de sécurité affectent les performances de l'ED, d'où la nécessité absolue de les déterminer dès la phase de conception, en anticipant les sources de données, les futurs utilisateurs, ainsi que les connaissances métier et les objectifs de l'ED.

Question 2 - Les composantes affectées par la sécurité

Selon le cours, la sécurité ne se limite pas à un seul domaine mais affecte quatre points majeurs de l'architecture d'un entrepôt de données :

1. L'accès des utilisateurs
2. La charge des données
3. Le flux (ou transfert) des données
4. La génération des requêtes

Question 3 - Stratégies de classification pour l'accès des utilisateurs

Pour gérer l'accès, les utilisateurs sont classés en fonction des données auxquelles ils sont autorisés à accéder. Cette gestion s'articule autour de deux axes de classification : la classification des données et la classification des utilisateurs.

Question 3.1 - La classification des données

Les données peuvent être classées de deux manières :

• Selon leur sensibilité : Les données les plus sensibles font l'objet de restrictions très strictes.
• Selon la fonction de travail : L'utilisateur est limité à la seule partie des données qui l'intéresse et dont il est responsable.

Question 3.2 - La classification des utilisateurs

Les utilisateurs peuvent être organisés selon deux types de hiérarchies :

• Classification selon le département : Les utilisateurs sont regroupés par départements, sections ou groupes. Si chaque département doit accéder à des données différentes, l'accès sécurisé doit être conçu séparément pour chacun. La méthode recommandée ici est l'utilisation de datamarts, en appliquant des restrictions de sécurité spécifiques à chaque datamart.
• Classification selon le rôle : Si les données sont globalement disponibles de manière transversale, il est plus pertinent de suivre une hiérarchie par rôle. Ainsi, des personnes appartenant à des départements différents mais ayant le même rôle partageront les mêmes accès.

Question 4 - Sécurisation de la charge, du transfert et des requêtes

Outre l'accès, les opérations internes de l'entrepôt soulèvent des défis de sécurité spécifiques.

Question 4.1 - La charge des données

La phase de chargement est alourdie par les exigences de sécurité. Les opérations de chiffrement sur le réseau ralentissent le système. De plus, les opérations d'audit nécessitent des ressources supplémentaires ; il est donc recommandé de désactiver ces audits en cas de fonctionnement normal pour préserver les performances.

Question 4.2 - Le transfert des données et le stockage

Une fois les données chargées, la gestion de l'espace disque devient critique. Il faut déterminer où l'ensemble de données est stocké et qui a accès à cet espace. La question des sauvegardes (backups) se pose également :

• Doivent-elles être cryptées ou déchiffrées ?
• Faut-il utiliser des bandes spéciales stockées séparément ?
• Qui est autorisé à accéder à ces bandes physiques ?

Question 4.3 - La génération des requêtes

La gestion des résultats de requêtes, souvent stockés dans des tables temporaires, est une faille potentielle. Les questions clés sont la localisation et la visibilité de ces tables.

• Le risque : Si un utilisateur autorisé à voir des données restreintes génère une table temporaire accessible à tous, ces données sensibles deviennent visibles pour des utilisateurs non autorisés.
• La solution : Il faut créer une zone temporaire distincte, exclusivement réservée aux utilisateurs ayant accès à ces données restreintes.

Question 5 - Impact de la sécurité sur la conception globale

L'intégration de la sécurité ne se fait pas sans coût : elle impacte le code, les délais et l'architecture globale.

Question 5.1 - Le développement d'applications

La sécurité modifie la conception de composants centraux comme le gestionnaire de chargement, le gestionnaire d'entrepôt et le gestionnaire de requêtes. Par exemple, le gestionnaire de chargement nécessitera du code de contrôle pour filtrer et aiguiller les enregistrements vers des emplacements distincts, ou des règles de transformation spécifiques pour masquer certaines données. La gestion de ces nouveaux objets exigera également des métadonnées supplémentaires.

Question 5.2 - La conception de la base de données

L'ajout de sécurité multiplie le nombre de vues et de tables. Cette prolifération augmente la taille globale de la base de données, rendant sa conception, sa gestion, ainsi que les plans de sauvegarde et de récupération beaucoup plus complexes.

Question 5.3 - Les tests

Tester un entrepôt de données est déjà un processus long. La sécurité affecte cette phase de deux manières :

1. Elle augmente le temps nécessaire pour l'intégration et le test du système.
2. Elle exige de tester des fonctionnalités de sécurité supplémentaires, ce qui augmente considérablement la taille de la batterie de tests.

Méthode

Pour aborder les questions théoriques sur la sécurité des entrepôts de données (Data Warehouse), il est essentiel de toujours garder à l'esprit le compromis fondamental (le "trade-off") de ce domaine : un entrepôt de données est conçu pour centraliser et partager massivement l'information, tandis que la sécurité cherche par nature à la cloisonner.

Lors de vos révisions, structurez votre pensée autour du cycle de vie de la donnée :

1. Qui y accède ? (Modèles par rôles vs départements/datamarts).
2. Comment y entre-t-elle ? (Impact sur les performances de chargement, audits, chiffrement réseau).
3. Où vit-elle et comment sort-elle ? (Stockage physique, sauvegardes, et le piège classique des tables temporaires lors des requêtes).
4. Quel est le coût global ? (Complexité accrue du code, de la modélisation des tables et explosion du temps de test).

Ne négligez jamais l'aspect "infrastructure physique" (accès aux disques et aux bandes de sauvegarde), car la sécurité logique (mots de passe, vues SQL) est inutile si le stockage physique n'est pas protégé.