1. La sécurité en BI : Bonnes
questions, faux problèmes et
solutions pratiques

2. Enjeux
» Sécurité et BI: Vieux problèmes dans un
monde nouveau.
› Une sécurité classique ou une nouvelle façon de
l’aborder?
› Avec trop de sécurité, nos données ne prennent-
elles pas la poussière?
› N’allons nous pas vers une nouvelle vision d’un
environnement sécurisé?

3. Conférencier
» Gregoris Zikos
› Architecture BI
» 12 ans en Business Intelligence
› 4 ans dans des environnements de haute sécurité
(Agences gouvernementales, Cellule de crise
terroristes, protection nucléaire, Armement,…)
› Environnements divers (SAP, Cognos, PeopleSoft,
QlickView, OBIEE, Teradata,…)
› Environnements « Big Data »

4. Table des matières
1. La sécurité : + qu’une obligation légale
2. Rappel des notions : Sécurité, BI et opérationnel
3. Problématiques de sécurité en BI : Du neuf avec du vieux
4. Implémentation de la sécurité BI en (bonne) pratique
5. Les faux problèmes de la sécurité BI
6. La sécurité en BI, ça continue….
7. QA

5. LA SECURITÉ BI : + QU’UNE
OBLIGATION LÉGALE

6. La sécurité : + qu’une obligation légale
» La sécurité s’impose dans une compagnie aussi bien de l’extérieur que de
l’intérieur :
› Risques légaux tout d’abord : (RRDIPPI, C-SOX, …)
› Risques d’affaires : Une prise de décision sur des données de mauvaise qualité
› Risques de gestion de désastre : Une société ne peut se remettre d’un désastre TI
› Risques d’espionnage industriels : Vente de données à la concurrence
› Risques de catastrophe organisationnelles : Divulgation des informations de bulletins de
paie dans l’entreprise
› Risques d’image : Mauvaise utilisation d’informations clients
› Risques Technologique : Corruption , modifications ou perte de données
informationnelles

7. Exemples d’impact
» Les régulations nous donnent des devoirs à faire :
› Intégration de données
 Gestion du data lineage (SOX 302, 906)
 Gestion centralisée des exceptions(SOX 409)
› Gestion de la qualité
 Gestion de la sécurité de données (SOX 404)
› Gestion des méta données
 Documentation des flux (SOX 302, 906)
 Référentiel de méta données (SOX 404)
 Data stewards (SOX 404)
› BI et reporting
 Automatisation des rapports et de leurs approbations (SOX 302, 906)
 Stress test(SOX 404)

8. Exemples d’impact
» Une mauvaise gestion de la
sécurité concernant la continuité
de service
» 80% des entreprises dans les
tours WTC à New York ont fait
faillite suite aux attentats
Les mauvaises décisions
» Une erreur d’encodage et un
processus de validation
défectueux
» Chute du Dow Jones de 9%
Désastres TI

9. Exemples d’impact
Espionnage industriel
» Vol de la liste
fournisseurs et clients par
des employés
» Plusieurs millions de
dollars sont réclamés
Risques de catastrophe organisationnelles
» Un Directeur envoie la
liste des salaires à toute
l’entreprise
» Les employés quittent la
société en masse

10. Exemples d’impact
Mauvaise utilisation d’informations
clients
» Un opérateur téléphonique
propose des nouvelles options
aux clients … d’un opérateur
virtuel partenaire
» La société se retrouve au
milieu d’un reportage sur CBS.
Corruption , modifications ou perte de
données informationnelles
» Des informations d’un
ministère sont perdues
» Des plaintes de citoyens
affluent

11. RAPPEL DES NOTIONS :
SÉCURITÉ, BI ET
OPÉRATIONNEL

12. La sécurité des systèmes d’informations (SSI)
» Plusieurs axes à considérer :
› L’authentification : “Mettre en place un processus d’authentification est fondamental dans la
gestion des droits d’accès”
› La confidentialité : “S’assurer que les données légalement confidentielles ne soient
accessibles que par les personnes légalement autorisées”
› La responsabilité : “La responsabilité d’une action sur le système d’informations ne peut être
contestée ni usurpée”
› L’intégrité : “La donnée doit être de qualité, conforme à la norme mise en place et ne peut
être altérée de manière fortuite”
› La disponibilité : “S’assurer que les données majeures sont disponibles quand elles sont
nécessaires et avec un temps de réponse admissible”

13. Systèmes opérationnels Vs Systèmes
décisionnels
Systèmes opérationnels
» Systèmes aidant à la
gestion des tâches
quotidiennes et donc par
essence opérationnelles.
Ils sont orientés par
processus et/ou par
départements.
Systèmes décisionnels
» Systèmes de collection,
consolidation,
modélisation et restitution
des données afin de
permettre au décideur
d’avoir une vue
d’ensemble.

14. PROBLÉMATIQUES DE SÉCURITÉ EN BI :
APPLIQUER DU CLASSIQUE DANS UN
MONDE NOUVEAU?

15. Du classique dans un monde nouveau
» La sécurité TI traditionnelle est implémentée
depuis des dizaines d’années sur les
systèmes opérationnels
» Les spécificités de la BI doivent par contre
être implémentées lorsque nécessaires
» Il convient donc de se poser la bonne
question…

16. La bonne question
» Mon système est-il un outil opérationnel
ou un outil décisionnel ?
› La différence fondamentale entre le comment
et le pourquoi au sein des rapports
› La mise en place de la sécurité et sa
complexité seront différentes

17. Opérationnel : Le Comment
» Comment se porte mon processus de
facturation aujourd’hui?
› Aide à la gestion journalière d’un processus ou
d’un département
› On reste en contrôle
› L’impact est limité
Opérationnel!

18. Opérationnel : La facilité du Comment
» Reporting Opérationnel – sécurité classique
› Légalité assurée par le processus
› Transformations simples
› Interopérabilité minime
› Couches logiques orientées sujets
Données
Opérationnelles
Datawarehouse
Opérationnel
Rapports
Facturation

19. Décisionnel : Le Pourquoi
» Pourquoi mon processus de facturation pourrait-il être
perturbé et que faire?
› Intégration des informations de disponibilité de données,
des ressources humaines, des contacts clients, …
› Prises de décisions grâce à un ensemble de facteurs : +
de personnel, meilleur qualité de contacts clients,
changement du plan de continuité TI,…
Décisionnel!

20. Décisionnel : La Complexité du Pourquoi
» Le public cible peut être radicalement différent du
personnel autorisé du processus
» Les besoins-cibles peuvent évoluer plus vite que
le processus origine
» Les données mises en relation sont difficilement
prévisibles
» La mise en relation des informations doit rester
contrôlée et intègre

21. Opérationnel Vs Décisionnel
» Opérationnel
› Public identifié
› Décision de contrôle
› Impact restreint au
processus
» Décisionnel
› Public divers
› Décision pro-active
› Impact plus large
La donnée dans un reporting opérationnel est-elle utilisée à sa pleine valeur?
Ne peut-elle avoir une valeur décisionnelle plus grande que sa définition dans son
processus originel?

22. IMPLÉMENTATION DE LA SÉCURITÉ BI
EN (BONNE) PRATIQUE

23. Les axes d’actions
» La politique de sécurité de l’entreprise
» La politique de sécurité TI
» Les axes de sécurité
› L’authentification
› La confidentialité
› L’intégrité
› La responsabilité
› La disponibilité

24. Les bases : politique de sécurité
» Politique de sécurité
 Définition de la politique de sécurité de l’entreprise et validation
de la conformité juridique
 Gestion des risques corporatifs
 Communication vers le personnel (ex : Portal d’entreprise)
 Responsabilisation du personnel (ex : Tolérance zéro)
› Volet BI
 Importance de l’architecte de l’information et des data stewards
 Définition et identification de la sensibilité des données en
partenariat avec le département juridique
 Approbation de la haute direction

25. Les rôles
» Architecte d’information
› Catégorisation de l’information en structure claire
› Gestion de l’interopérabilité de l’information
› Définition de la sensibilité juridique des données
» Data stewards
› Responsable de la gestion du dictionnaire des méta données
› S’assure que la donnée est sans ambiguïté
› S’assure que la donnée n’est pas redondante dans l’entreprise
› S’assure que la donnée est encore utilisée

26. Les bases : politique de sécurité TI
» Intégrer les environnements BI dans la politique
de sécurité TI standard de l’entreprise. Exemples :
› Accès physique restreints aux serveurs
› Backup
› Disaster Recovery
› Accès en lecture aux base de données
› Processus de mise en production (DEV, QA, PROD)
Bref tout ce que l’on implémenterait dans un projet TI non
spécifique à la BI

27. L’authentification
» C’est la base même de la sécurité
› Mettre en place un annuaire d’authentification
global au sein de l’entreprise
› Interfacer tous les systèmes d’informations avec
cet annuaire
› Mettre en place un processus de revue régulière
de cet annuaire
C’est un principe de base de la sécurité TI qui s’applique
aussi en BI

28. Annuaire centralisé d’authentification (LDAP, Windows, SAP,…)
Reporting
Proposition d’architecture
Données
Opérationnelles
Données
Opérationnelles
Données
Opérationnelles
Entrepôt de
données avec
dimensions
conformes
Staging Area
Autres
systèmes

29. La confidentialité
› Standards TI
 Implémentation de la politique de sécurité
› BI
 Travail de l’architecte d’information et des data stewards pour la définition des
données sensibles
 Validation des accès aux données confidentielles via l’annuaire d’authentification
 Mise en place d’un environnement ouvert, consolidé et intègre ainsi qu’un
environnement de reporting avec les données non sensibles
 Mise en place d’espace confidentiel dans l’entrepôt de données avec un
environnement de reporting associé
 Mise en place d’un cryptage au niveau de la couche confidentielle
 Mise en place d’un anonymisation au niveau de la couche BI

30. Annuaire centralisé d’authentification (LDAP, Windows, SAP,…)
Reporting
Proposition d’architecture
Données
Opérationnelles
Données
Opérationnelles
Données
Opérationnelles
Confidentiel
Confidentiel
Confidentiel
Entrepôt de
données avec
dimensions
conformes
Staging Area
BI
(DWH)
Opérationnel
(DWH
+
Confidentiel)
Autres
systèmes

31. L’intégrité
› Standard TI
Gestion de la qualité au sein des applications sources
› BI
Gestion des interfaces inter-systèmes (introduction de
la notion de DataHub)
Gestion de la qualité des données et des dimensions
conformes aidant à l’interopérabilité
Gestion des méta données
Gestion du data lineage

32. Datahub
» Une plateforme d’échange de données
 Entre systèmes opérationnels
 Entre les systèmes sources et le datawarehouse et vice-versa
 Entre le datawarehouse et les utilisateurs et vice-versa (via un
processus de demande officielle d’interface)
» Sécurisée via l’annuaire centralisé d’authentification
» Avec une gestion des méta données
Toutes les interfaces de l’entreprise sont centralisées
dans cette notion

33. Interface Vs Rapport
» La principale différence se situe dans l’utilisation finale de la donnée.
› Les données doivent être manipulées ou altérées. Ceci est une interface de données.
› Les données doivent être extraites sans être altérées (ex: pdf,..). Ceci est un rapport.
» Un rapport peut être à l’origine d’une interface, mais celle-ci sera obligatoirement
consommée depuis le datahub. L’altération de données devant être suivie, une
demande de consommation d’interface (voire de création) sera introduite et justifiée.
» Une interface servant à mettre en relation des données devra être justifiée.
› Les données ‘ouvertes’ des départements sont disponibles.
› SI nécessaire, une action sera ajoutée au backlog de l’entrepôt de données BI.

34. Annuaire centralisé d’authentification (LDAP, Windows, SAP,…)
Reporting
Proposition d’architecture
Données
Opérationnelles
Données
Opérationnelles
Données
Opérationnelles
DATAHUB
sécurisé
E
T
L
T
Confidentiel
Confidentiel
Confidentiel
Entrepôt de
données avec
dimensions
conformes
Staging Area
BI
(DWH)
Opérationnel
(DWH
+
Confidentiel)
Gestion Méta données
ETL
M
D
M
M D M
M
D
M
ETL
ET
L
M D M
Autres
systèmes

35. La Responsabilité
› Standards sécurité
Définition de la responsabilité via un processus
› BI
Identification des acteurs via l’annuaire
d’authentification
Responsabilisation des extractions non sécurisés
par un processus de demande sur le DataHub

36. Annuaire centralisé d’authentification (LDAP, Windows, SAP,…)
Reporting
Proposition d’architecture
Données
Opérationnelles
Données
Opérationnelles
Données
Opérationnelles
DATAHUB
sécurisé
E
T
L
T
Confidentiel
Confidentiel
Confidentiel
Entrepôt de
données avec
dimensions
conformes
Staging Area
BI
(DWH)
Opérationnel
(DWH
+
Confidentiel)
Gestion Meta données
ETL
M
D
M
M D M
M
D
M
ETL
ET
L
M D M
Autres
systèmes

37. La disponibilité
› Standards TI
Plan de gestion de désastres TI
› BI
Plan de criticité des données d’historique
Gestion de la sensibilité des données dans les
backups et les gestions de désastres
Processus de vérification de la performance

38. LES FAUX PROBLÈMES DE LA
SÉCURITÉ BI

39. Les faux problème de la sécurité BI
» Les problématiques suivantes ne
proviennent pas de la BI :
› Mobilité
› Cloud
› Confidentialité

40. Les faux problèmes
» La mobilité & la confidentialité : des
problématiques TI existantes depuis les lustres
» Le Cloud : les TMA (tierce maintenance
applicative) existent depuis longtemps dans
l’opérationnel
Elles feront l’objet d’une solution globale de la part
de l’entreprise

41. LA SÉCURITÉ BI, ÇA CONTINUE…

42. La sécurité en BI : Ça continue…
» Contacts
› Gregoris Zikos – Architecte BI et conseiller stratégique –
g.zikos@biz-intelligence.com
» Informations et conseils
› BIZ Intelligence : http://www.biz-intelligence.com
Questions ?