Sécurité BI

588 vues

Publié le

0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
588
Sur SlideShare
0
Issues des intégrations
0
Intégrations
10
Actions
Partages
0
Téléchargements
21
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Sécurité BI

  1. 1. La sécurité en BI : Bonnes questions, faux problèmes et solutions pratiques
  2. 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. 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. 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. 5. LA SECURITÉ BI : + QU’UNE OBLIGATION LÉGALE
  6. 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. 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. 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. 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. 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. 11. RAPPEL DES NOTIONS : SÉCURITÉ, BI ET OPÉRATIONNEL
  12. 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. 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. 14. PROBLÉMATIQUES DE SÉCURITÉ EN BI : APPLIQUER DU CLASSIQUE DANS UN MONDE NOUVEAU?
  15. 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. 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. 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. 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. 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. 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. 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. 22. IMPLÉMENTATION DE LA SÉCURITÉ BI EN (BONNE) PRATIQUE
  23. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 38. LES FAUX PROBLÈMES DE LA SÉCURITÉ BI
  39. 39. Les faux problème de la sécurité BI » Les problématiques suivantes ne proviennent pas de la BI : › Mobilité › Cloud › Confidentialité
  40. 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. 41. LA SÉCURITÉ BI, ÇA CONTINUE…
  42. 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 ?

×