Rapport PFE

70
1 Corrélation de logs et Audit des actions des administrateurs à haut privilèges Ingénierie Informatique et réseau Méthodes informatiques appliquées à la gestion des entreprises HAFID Oussama Mohamed Ramdani Oumar Traoré 2014/2015

Transcript of Rapport PFE

Page 1: Rapport PFE

1

Corrélation de logs et Audit des actions des administrateurs à haut privilèges

Ingénierie Informatique et réseau

Méthodes informatiques appliquées à la gestion des entreprises

HAFID OussamaMohamed Ramdani

Oumar Traoré

2014/2015

Page 2: Rapport PFE

2

AvantPropos

Nom et prénom de l’élève stagiaire

HAFID Oussama

Intitulé du travail

Corrélation de logs et audit des ac-tions des administrateurs à haut priv-ilèges

Société d’accueil

Finatech GroupCasablanca, CasanearShore, Shore 10

Tel: +212 520 377 000

www.Finatech.com

Etablissement d’origine

Ecole Marocaine des Sciences de l’ingénieur

Encadrant professionnel

Mr. Oumar TRAORETECHNICAL MANAGER

Encadrant pédagogique

Mr. Mohamed RAMDANIProfesseur enseignant à l’EMSI

Date de début et de fin du stage :

Du 01 Mars au 01 Septembre 2015 (6 mois)

Page 3: Rapport PFE

3

Dédicace

À ma très chère famille,Tous les mots du monde ne sauraient exprimer l’immense

amour que je vous porte. Votre sacrifice, votre éducation et votre soutien ont

fait de moi l’homme de valeur que je suis aujourd’hui. À mon cher père, l’école de mon enfance et la source de mes valeurs, à ma chère mère, symbole du sacrifice et de la bienveillance. À mes chers frères et sœurs pour leur présence, leur sacrifice et leur soutient inestimable.

À ma grande famille, pour leur unicité et leur soutien.

À la mémoire de Mr. Kasmi, homme de valeur et de savoir, du fond du cœur, que dieu te fasse miséricorde, te pardonne

et t’accueil dans ses paradis. À mes encadrants Mr. Oumar Traoré et Dr. Ramdani, c’est grâce à nos jours passées ensemble que mes navires ne perdent plus le cap, Merci pour toutes les leçons que vous m’avez appris, que cet humble travail puisse vous rendre fier de moi.

À mes chers amis et camarades, je me suis entouré par des li-ons, et c’est grâce à votre présence et vos conseils et que j’ai appris beaucoup de leçons .. mourad, youssef, abdessamad, wafae, tarek, lamyae, nadya, khalid, charaf, nassim, chaimaa, basma, ilyass, taib, zahra, yousra, abdel, othman, harith, wassim, nada, sahar, mahmoud et tous les autres.

Que ce travail soit l’exaucement de vos souhaits, de vos prières tant formulés et le fruit de vos innombrables sacrifices.

Page 4: Rapport PFE

4

Remerciement

Au terme de ce projet, je tiens à exprimer ma gratitude envers tous ceux qui ont assisté de près ou de loin

à sa réalisation.

Je tiens à remercier dans un premier temps, toute l’équipe pédagogique de l’ l’Ecole Marocaine des Sciences de l’Ingénieur et les intervenants professionnels responsables de la filière ingénierie informatique et réseau pour

avoir assuré une formation d’une haute qualité.

Je remercie ardemment mon encadrant à l’EMSI Monsieur le professeur Ramdani pour la qualité inédite

de son suivi et la pertinence de ses conseils.

Je tiens à remercier chaleureusement Monsieur Oumar Traoré, Project Manager à Finatech Group pour m’avoir donné l’occasion de travailler sur ce projet, et pour le savoir-faire qu’il m’a transféré, c’est à lui que je dois la réussite de ce stage.

D’une façon plus générale, je présente mes sentiments d’estime et de considération à tout le personnel de Finatech Group, pour leur parfaite collaboration. Merci à ceux qui m’ont beaucoup appris au cours de ce stage, et à ceux qui ont eu la gentillesse de faire de ce stage un moment très profitable.

Sans oublier, les sacrifices, le soutien continu, et la voix d’encouragement de ma famille. Qu’ils trouvent ici l’expression de mes sentiments de respect, d’amour, de gratitude et de reconnaissance.

Page 5: Rapport PFE

5

Résumé‘‘ Quand les anciens chinois ont construit la muraille, il a été franchi 3 fois dans les 100

premières années non pas à cause d’une faiblesse de la muraille mais un pot de vin aux gardiens suffit pour ouvrir les portes ’’ – Mehdi Elmandjra

Le problème des gardiens du temple est présent aussi sur les systèmes d’information, chaque serveur est surveillé par des administrateurs à haut privilèges, mais qui surveille ces administrateurs ?

Le monde des entreprises connaît aujourd’hui de profonds changements. Les entreprises sont confrontées à de nouvelles menaces telles que les attaques ciblées et persistantes.

En conséquence, la plupart d’entre elles mettent en œuvre les fonctionnalités essen-tielles que sont la collecte d’événements, leur corrélation, la génération d’alertes et la démonstration de la conformité aux exigences réglementaires.

C’est dans cette optique que s’inscrit le présent projet de fin d’étude, qui vise la maî-trise de la sécurité de ses systèmes d’information d’une banque en mettant en place une solution de suivi des actions d’administration des comptes à hauts privilèges relevant des systèmes d’exploitation Windows et ce, en vue notamment:

• de minimiser le risque de mauvaises manipulations des sources de données des habil-itations

• de centraliser la gestion des traces (logs) relatives aux comptes et habilitations et de garder une trace des actions effectuées.

Pour réaliser ceci, on fait appel aux solutions de gestion des événements et des infor-mations (solutions SIEM), sauf que les besoins exprimés sur le CPT ne sont pas toutes cou-vertes par ces solutions, ces derniers ne permettent pas de distinguer la nature des actions selon le besoin et la vision du client, ce qui nous mène à ajouter et développer des modules supplémentaires.

Les modules ajoutés se présentent sous forme de deux solutions, la première est une ap-plication de gestion d’un référentiel, qui présente une source de données pour distinguer la nature de chaque action selon des paramètres (le serveur, le profil et l’action). Le deuxième module et une solutio de reporting, où on charge les données extraite par l’outil SIEM et le référentiel vers un DataWarehouse pour des fins de reporting.

Sur ceci, le projet se compose de 3 modules :

> la configuration et le déploiement d’une solution SIEM qui répond le plus aux exi-gences du CPT

> Le développement d’une application de gestion de référentiel

> Le développement d’une solution d’aide à la décision

Page 6: Rapport PFE

6

Abstract‘‘ When the ancient Chinese built the wall, it was taken 3 times in the first 100

years not because of a weakness in the wall but a bribe to the guards open the doors ’’ – Mehdi Elmandjra

The temple guards problem is also present on IT systems, each server is monitored by administrators with high privileges, but who monitors these administrators ?

The business world is experiencing profound changes today. Companies are fac-ing new threats such as targeted and persistent attacks.

Consequently, most of them are implementing the essential features that are event collection, their correlation, alert generation and demonstration of compliance with regulatory requirements.

It is in this context that fits this final study project, which concerns the safety of the management of its information systems of a bank by setting up a monitoring solu-tion of administrative actions accounts of senior privileges under Windows operating systems and, inter alia:

• minimize the risk of mishandling authorizations data sources

• centrally manage traces (logs) of the accounts and authorizations and keep track of actions performed.

To achieve this, we use the event management solutions and information (SIEM), except that the needs expressed on the CPT are not all covered by these solutions, they do not distinguish the nature of actions by the needs and vision of the customer, which leads us to add and develop additional modules.

The added modules are in the form of two options, the first is a management ap-plication for a repository, which has a data source to distinguish the nature of the operation according to parameters (server, profile and action) . The second module is a reporting solution, where it loads the data extracted by the SIEM tool and the repository to a data warehouse for reporting purposes.

On this, the project is composed of 3 modules:

• configuring and deploying a SIEM solution that best meets the requirements of the CPT

• The development of a repository management application

• The development of a solution to aid decision

Page 7: Rapport PFE

7

ملخصتسلقه يستطيع من يوجد ال بأنه اعتقدوا العظيم.. الصين سور الصينيون بنى عندما لشدة علوه، ولكن خالل المئة سنة األولى بعد بناء السور تعرضت الصين للغزو ثالث مراتالباب - المهدي البرية تدفع للحارس الرشوة ثم يدخلون عبر ! حيث كانت جحافل العدو

المنجرة مشكل حرس القصر، حاضر كذلك في أنظمة المعلومات، كل سيرفر يكون مراقبا من قبلسيقوم من حول القصر، حراس في كما يكمن، المشكل لكن عالي، امتياز ذوو إداريين

بحراسة هؤالء اإلداريين ؟ عالم الشركات يعرف حاليا تغيتار هامة، الشركات تتعرض لمخاطر مثل الهجمات الموجهة

.و المستمرة كنتيجة لذلك، اغلب الشركات تنفذ وظائف مثل جمع جميع االحداث التي قام بها اإلداريون و المستعملون لنظام المعلومات، استخراج االحداث المعنية بأمر الخطر، إطالق رسائل إنذار و

.العرض التوضيحي إلحترام المتطلبات التنظيميةأمن ظبط و إتقان إلى يهدف والذي هذا، الدراسة نهاية مشروع يتجلى السياق هذا في أنظمة المعلومات لمؤسسة بنكية، وذلك بوضع مخطط لمتابعة تحركات اإلداريين ذوو اعلى

: رتبة امتياز، الشيء الذي سيمكن من _ تقليص خطر التالعب بمصادر المعلومات _ تركيز إدارة آثار تحركات اإلداريين و المحافظة عليها من أجل تطبيق هذا، نلجأ إلى حلول إدارة األحداث و المعلومات، إال أن المتطلبات المعبر عنها ال تغطى كلها عبر هاته الحلول، فهاته األخيرة ال تسمح بتمييز طبيعة األحداث حسب رؤية

.المؤسسة البنكية، و هذا ما يدفعنا إلى إضافة و تطوير وحدات إضافية الوحدات المضافة تتجلى في حلين إثنين، األول هو تطبيق إلدارة مستودع لألحداث، والثاني

هو تطبيق إلنتاج تقارير حول أحداث اإلداريين

Page 8: Rapport PFE

8

AAD : Active directoryAPI : Application Programming InterfaceASP : Active Server Pages

BBI : Business intelligenceBD : Base de données

CCPT : cahier des prescriptions techniques

DDC : Domaine controller (contrôleur de domaine)DBA : administrateur de base de donnéesDOSI : Direction de l’Organisation et des Systèmes d’’InformationDM : DatamartDWH : DataWarehouse

EEMSI : Ecole Marocaine des Sciences de l’ingénieurETL : Extract-Transform-Load

OOU : Unité organisationnelle OS : Système d’exploitationOLAP : On Line Analytical ProcessingOLTP : On Line Transactional Processing

TerminologieSSI : Système d’informationSIEM : Security Information Event Manage-mentSGBD : Système de Gestion de Bases de Données

SID : Surrogate ID (ID de substitution)

SPI : Service de production informatique

SSI : Service de sécurité informatique

UUML : United Modeling Language

Page 9: Rapport PFE

9

Tables et figuresFigure 1 : domaines de Finatech Group 13Figure 2 : Classement des outils SIEM Selon Gartner 19Figure 3 : Classement des outils SIEM 22Figure 4 : schématisation globale de la solution 23Figure 5 : schématisation de la solution SIEM 23Figure 6 : schématisation de l’application de gestion de référentiel 24Figure 7 : Schématisation de la solution décisionnelle 24Figure 8 : cycle de vie de l’application de gestion de référentiel 28Figure 9 : cycle de vie de l’application de gestion des rapports personnalisés 28Figure 10 : méthode 2TUP 29Figure 11 : diagramme de Gant prévisionnel 32Figure 12 : diagramme de Gant reel 33Figure 13 : Architecture globale de InTrust 35Figure 14 : Serveur InTrust 36Figure 15 : Fonctionnalités de l’agent InTrust 38Figure 16 : Fonctionnement détaillé de InTrust 39Figure 17 : architecture InTrust server 45Figure 18 : ETL de chargement InTrust 45Figure 19 : Maquete de la page de gestion des utilisateurs 46Figure 20 : Maquete de la page d’ajout d’un utilisateurs 47Figure 21 : description fonctionnelle de l’application web 48Figure 22 : diagramme global 48Figure 23 :Authentification 49Figure 24 : scénario de gestion de l’application web 50Figure 25 : diagramme de classe du Référentiel 51Figure 26 : modélisation du DM Supervision 53Figure 27 : Page d’acceuil 55Figure 28 : Page de gestion des utilisateurs 56Figure 29 : Page d’insertion d’un nouvel utilisateur 56Figure 30 :spécificaitonsdelapaged’ajout 57Figure 31 : page d’ajout d’une autorisation 57Figure 32 :pagedemodificationd’uneentité 58Figure 33 : page de détails sur une entité 58Figure 34 : page de supression sur une entité 59

Tableau 1 : matrice de conformité 22Tableau 2 : description des phases 26Tableau 3 : Matrice des risques 27Tableau 4 : liste des technologies web 41

Page 10: Rapport PFE

10

Sommaire Avant-propos Dédicace Remerciement Résumé Abstract ملخص Terminologie Listedesfigures Liste des tableaux Sommaire Introduction générale

Chapitre I : Contexte générale du projet 1.Présentation de l’organisme d’accueil 1.Présentation générale de Finatech : 1)Identité : 2)Histoire : 3)Finatech Group en quelques mots 4)Organisation opérationnelle : 2.Présentation de la BU Finashore : 1)Présentation : 2)Historique : 2.Présentation du projet : 1)Problématique : 2)Etude de l’éxistant : 3)Objectifs 4)Démarche 5)Matrice de conformité

CHAPITRE 2 : Analyse organisationnelle 1.Description des phases 2.Matrice des risques 3.ycle de vie 4.Gestion du projet 5.Planning du projet

Chapitre 3 : Notions, techniques et technologies I.Technologie SIEM : InTrust 1.Présentation générale : 2.Fonctionnement global 3.Les composants d’InTrust : 4.Fonctionnement 6.Outils

II.Notions et techniques de développement du site web 1.Contexte technologique

II.Technologies de développement de la solution décisionnelle 1.Architecture décisionnelle 2.Présentation de la solution MSBI

13

26

35

Page 11: Rapport PFE

11

SommaireChapitre 4 : Analyse, conception et modélisation I.Module 1 : conception et réalisation des ETL sur InTrust

II.Module 2 : Analyse et conception de l’application de gestion du référentiel 1.Les règles de gestion 2.Les maquettes 3.Diagramme des Use-cases globale: 4.Diagramme de Séquence : 5.Diagramme de classe :

III.Module 3 : Conception et modélisation du Datamart de supervision 1.Choix des indicateurs : 2.Modélisation

Chapitre 5 : Réalisation I.Réalisation du module de gestion du référentiel 1.Page d’authentification 2.Page d’accueil : 3.Consultation d’une entité (utilisateur) 4.Création d’une entité 5.Modification d’une entité 6.détails d’une entité 7.Suppression d’une entité

II.Réalisation du reporting 1.La phase d’ETL : 2.Déploiement du cube 3.Reporting

Conclusion Bibliographie

45

55

Page 12: Rapport PFE

12

IntroductionGénérale

Garder la trace de l’activité de l’utilisateur et de l’adminis-trateur est au cœur de garder la sécurité de l’environnement de l’entreprise et de se conformer aux différentes réglementations informatiques.

Afin de se conformer aux dernières réglementations et des normes de sécurité, une institution bancaire a besoin d’une solu-tion de corrélation de logs et d’audit des administrateurs à haut privilèges.

J’ai eu l’honneur de travailler sur ce projet au sein de la so-ciété Finatech Group, situé au Nearshore de Casablanca. Au fil des pages suivantes, je vais vous présenter l’entreprise et la réalisation du projet.

Dans un premier temps, mon environnement de travail sera décrit dans le premier chapitre avec une présentation générale de Finatech Group, ses missions et ses valeurs, ensuite je vais vous présenter la Business Unit Network qui s’occupe du projet.

Puis, je vais décrire le projet majeur que j’ai mené à terme.Pour chaque module, je vais vous présenter tout son parcourt de développement commençant par les périmètres du projet dans le premier chapitre, lanalyse organisationnelle dans le deusième chapitre, ensuite l’étude, la conception et la modélisation dans le chapitre 4 et enfin la réalisationdans le chapitre 5.

Page 13: Rapport PFE

13

ID

CONTEXTE GÉNÉRALEDU PROJET

Chapitre 1

Dans ce chapitre nous allons présenter la société d’acceuil et la division chargé du projet ainsi que

les périmètres du projet

Corrélation de log et Audit des actions d’administrateurs à haut privilèges

Chapitre1 Chapitre 2 Chapitre 3 Chapitre 4 Chapitre 5

Page 14: Rapport PFE

14

I. Présentation de la société d’acceuil : 1. Présentation générale de Finatech : 1) Identité :

Acteur majeur de l’énergie et des technologies numériques de l’information et de la communication, Finatech Group est un intégrateur de référence qui offre à ses clients privés et publics des solutions et infrastructures globales depuis la conception, la réal-isation, jusqu’à la maintenance et exploitation.

Avec 260 collaborateurs au Maroc, Finatech Group intervient sur des projets d’in-stallations électriques industrielles et tertiaires, de réseaux d’énergie, d’éclairage public, d’infrastructures de transport et de télécommunications, de sécurité globale, de sys-tèmes d’information, de gestion de contenu, d’ingénierie audiovisuelle, de Datacenter et d’applications et solutions métiers.

Finatech Group est une filiale de FinanceCom, un des tous premiers investisseurs institutionnels du Maroc.

2) Histoire :

2013 : Accélération du développement et collaboration forte avec des partenaires internationaux stratégiques. Lancement d’un nouveau site WEB.

2012 : Lancement d’une stratégie de partenariats et de croissance rentable pour devenir un intégrateur de solutions de référence dans les domaines des infrastructures liées à l’énergie et au numérique. Nouvelle identité visuelle.

2011 : Mise en place d’un plan de restructuration et de réduction des couts.

2010 : Simplification de la structure juridique de Finatech Group avec la fusion des entités marocaines du Groupe.

2009 : Développement organique et arrivée de managers issus de multinationales technologiques dans les principales filiales. Acquisition aux Etats-Unis de 100% de Data Analytics (webmarketing).

Figure 1 : domaines de Finatech Group

CHAPITRE 1 :CONTEXTE GÉNÉRALE DU PROJET

Page 15: Rapport PFE

15

2008 : Acquisition majoritaire de 18 sociétés marocaines opérant dans le domaine des TI, des télécoms et des infrastructures. Prise de participations minoritaires de so-ciétés high-tech basées à la Silicon Valley.

2007 : Création de Finatech Group SA avec l’ambition de créer un groupe tech-nologique d’envergure au Maroc.

3) Finatech Group en quelques mots:

Un intégrateur de référence au Maroc spécialisé dans l’énergie et les technologies de l’information.

Un groupe créé en 2007 et issu de la fusion de plusieurs entreprises ayant plus de 20 ans d’expérience dans les domaines de l’énergie et de l’information.

Une offre de solutions et de services pointus pour accompagner nos clients dans la conception, la réalisation, et la maintenance de leurs projets

Plus de 240 collaborateurs engagés au service des grands donneurs d’ordres pub-liques et privés.

Plus de 70% d’Ingénieurs

Plus de 36 chantiers et projets réalisés en 2014.

Des certifications et agréments dans tous nos domaines d’intervention (ONE, LYDEC, CONSTRUCTEURS, etc.)

Adossé à un investisseur institutionnel de référence : le groupe FinanceCom.

4) Organisation opérationnelle :

Structurée pour répondre aux défis de demain, Finatech Group est organisé autour de 2 pôles métiers et 10 Business Units.

Pôle Infrastructures

BU Energie

BU Télécom

Pôle Systèmes & Technologies

BU Média & Sécurité

BU Editique

BU IT Services

BU Docunet

BU Artémis

CHAPITRE 1 :CONTEXTE GÉNÉRALE DU PROJET

Page 16: Rapport PFE

16

BU Artémis Learning

BU Finashore

BU Finacard

260 collaborateurs composent cette organisation et accompagnent chaque jour nos clients dans le développement et la réalisation de tous leurs projets sur l’ensemble du Royaume du Maroc.

2. Présentation de la BU Finashore : 1) Présentation :

Finashore est une Business Unit au sein de Finatech Group, leader marocain des technologies de l’information, avec ses deux pôles d’activités qui se regroupent en qua-tre lignes métiers: Énergie, Infrastructures & Systèmes, Solutions, Applications et Ser-vices.

Nos services ont pour finalité de permettre pour chaque entreprise quelque soit son impact sur l’économie nationale ou mondiale de réaliser de significatives réduc-tions de coûts dans son projet d’externalisation de sous-traitance ou de co-localisation.

Le Savoir-faire, l’expertise et la spécialité de Finashore s’appuie non seulement sur une vingtaine d’années d’expérience de ses dirigeants, expérience passée dans la délé-gation de ressources en France; mais aussi sur la compétence dédiée à son Capital Humain.

2) Historique :

2002: Date de création de Cerdis (Centre Spécialisé dans la Relation Client)

2004: Date de création de Saisie.ma (Centre spécialisé dans le Back Office)

2008: Date de prise de participation de Finatech Group dans les deux Pôles de métier.

2010: Fusion/Absorption

CHAPITRE 1 :CONTEXTE GÉNÉRALE DU PROJET

Page 17: Rapport PFE

17

II. Présentation du projet : 1) Problématique :

L’évolution des systèmes d’exploitations orientés serveur, oblige beaucoup d’or-ganisations à mettre en place un système d’information très développé pour être viable.

Ces systèmes d’information contiennent des informations très critiques. Il est donc essentiel de les protéger contre les intrusions et les accès non autorisés. Dans cette per-spective, se munir d’un système de sécurité informatique est devenu une composante essentielle de l’infrastructure des entreprises.

Dans le cadre de la maîtrise de la sécurité de ses systèmes d’information, une in-stitution bancaire souhaite mettre en place une solution de suivi des actions d’admin-istration des comptes à hauts privilèges relevant des systèmes d’exploitation Windows et ce, en vue notamment:

• De minimiser le risque de mauvaises manipulations des sources de données des habilitations ;

• De centraliser la gestion des traces (logs) relatives aux comptes et habilitations et de garder une trace des actions effectuées.

2) Etude de l’éxistant :

L’architecture Windows de la Banque est composée d’un domaine racine et d’un domaine enfant. Il existe plusieurs OU (Unité Organisationnelle) liées au domaine en-fant. Les utilisateurs créés sont membres des différentes OU. L’institution bancaire dis-pose de :

• 22 Sites

• 26 contrôles de domaine

• 16 Agences – VPN MPLS 128 kbps

• 2 Agences – VPN MPLS 256 kbps

• Les sites de Casa et de Hay Riad – VPN MPLS 2 x 1Mbps

• Le site de l’Administration centrale - VPN 2 x 2Mbps

CHAPITRE 1 :CONTEXTE GÉNÉRALE DU PROJET

Page 18: Rapport PFE

18

Actuellement, l’administration des systèmes Windows est assurée de la manière suivante :

• L‘administration centrale de l’AD (Active Directory) est réalisée par le Service Production Informatique (SPI) de la DOSI

• Les administrateurs de l’équipe SPI agissent sur tout l’AD de la Banque

• Seuls les administrateurs du service SPI possèdent des comptes à hauts priv-ilèges au sein de la Banque. Ces comptes sont nominatifs et individuels

• Les comptes administrateurs sont répartis par groupes restreints. Les tâch-es d’administration par groupe sont définies et détaillées et les habilitations nécessaires identifiées

• Les administrateurs fonctionnels agissent, uniquement, sur les applications dont ils sont responsables. Ces administrateurs n’ont pas le droit d’agir sur l’AD et possèdent des comptes utilisateurs Windows normaux.

3) Objectifs

La solution recherchée devra contenir principalement les deux modules suivants :

• Le premier, destiné aux agents du SSI, devra offrir des outils permettant le suivi des actions des administrateurs centraux sur tous les systèmes Windows et la détec-tion des éventuels comportements déviants

• Le second, destiné aux agents de contrôle de la sécurité dans les entités, devra offrir des moyens pour le suivi des actions d’administration effectuées sur les comptes des utilisateurs de l’entité.

La solution permettra d’effectuer les actions de contrôle suivantes:

1) Visualiser toutes les actions des administrateurs centraux et des comptes de services ayant des droits de hauts niveaux.

2) Déterminer si les actions sont autorisées ou déviantes.

La consultation des actions se fera via des rapports clairs et synthétiques. Plu-sieurs niveaux de détails devront être disponibles (global, intermédiaire, détaillé).

CHAPITRE 1 :CONTEXTE GÉNÉRALE DU PROJET

Page 19: Rapport PFE

19

Afin d’atteindre cet objectif, la solution cible devra:

• Exploiter les journaux d’événements de sécurité des contrôleurs de domaine Windows 2008

• Appliquer des règles de gestion

• Générer des rapports ou bilans synthétiques périodiques et à la demande

• Gérer plusieurs profils d’utilisation de la solution

• être évolutive pour permettre l’intégration de nouveaux domaines ou forêts Win-dows.

La logique proposée est basée sur la collecte régulière d’informations de l’Active directory et la vérification de la concordance de ces éléments par rapport au référentiel tenu à jour par le SSI en collaboration avec la DOSI.

4) Démarche

Le développement de toute une solution de gestion des journaux d’événements du système d’exploitation Windows nécessite des ressources et des connaissances importantes, ce qui cause une augmentation au niveau des coûts.

Sur ceci, et suite aux recommandations de mon encadrant, on fait appel à des solutions déjà développées et prêtes afin de réaliser le travail souhaité. On va étudi-er la solution qui va répondre le plus aux besoins de notre projet, on va chercher les meilleures solutions sur le marché et à travers une matrice de conformité on choisit la bonne solution.

5) Matrice de conformité

1. Les technologies concernées :

SIEM – Security information and event management

C’est un principe pour gérer les évènements du système d’information. Ils permet-tent de gérer et corréler les logs. On parle de corrélation car ces solutions sont munies de moteurs de corrélation qui permettent de relier plusieurs évènements à une même cause.

APM – Application Performance Management :Dans les domaines de la technologie de l’information et la gestion des systèmes,

Application Performance Management (APM) est la surveillance et la gestion de la per-formance et la disponibilité des applications logicielles. APM s’efforce de détecter et de diagnostiquer les problèmes de performances des applications pour maintenir un niveau de service attendu.

CHAPITRE 1 :CONTEXTE GÉNÉRALE DU PROJET

Page 20: Rapport PFE

20

1. Les solutions disponibles :

Afin de choisir entre des dizaines de solutions sur le marché, nous allons nous ser-vir de Gartner, une entreprise américaine de conseil et de recherche dans le domaine des techniques avancées. Gartner mène des recherches, fournit des services de con-sultation, tient à jour différentes statistiques et maintient un service de nouvelles spé-cialisées.

Gartner fournit chaque année des rapports sur différentes technologies et principes dont SIEM, le classement des solutions SIEM est ainsi :

Après une recherche et une étude sur ces solutions, on a extrait 4 solutions qui

concernent aussi le principe du APM :

1. Intrust – Quest (DELL)

InTrust permet en toute sécurité de collecter, stocker, rechercher et analyser des quantités massives de données informatiques à partir de nombreuses sources de don-nées, systèmes et dispositifs en un seul endroit. InTrust permet d’obtenir un aperçu en temps réel sur l’activité des utilisateurs pour la sécurité, la conformité et la visibilité opérationnelle. Avec une vue, on peux savoir ce que les utilisateurs des ressources en ont accès, comment que l’accès a été obtenu et comment il a été utilisé.

InTrust permet de :• Réduire la complexité de la recherche, l’analyse et la conservation de données

informatiques critiques dispersées à travers les silos d’information

• Lancer des Enquêtes de sécurité et des audits de conformité avec une visibilité complète en temps réel de vos utilisateurs privilégiés et des données de la machine dans un emplacement consultable.

• résoudre les problèmes généralisés en cas d’incident.

• Économiser les coûts de stockage et respecter les exigences du journal des événements de conformité (HIPAA, SOX, PCI, FISMA, etc.) avec un dépôt de journal d’événement ultra-compressé et indexées en ligne à long terme.

Figure 2 : Classement des outils SIEM Selon Gartner

CHAPITRE 1 :CONTEXTE GÉNÉRALE DU PROJET

Page 21: Rapport PFE

21

2. ArcSight - HP

Leader de la technologie SIEM depuis 10 ans, ArcSight est une suite complète de solutions SIEM qui garantit la conformité à moindre coût et fournit une fonction d’anal-yse avancée de la sécurité pour identifier les menaces et gérer les risques, et assurer ainsi la protection des activités. ArcSight permet de :

• Transformer le Big Data à une intelligence de sécurité exploitable grâce à une corrélation en temps réel combinée à une puissante analytique de sécurité

• Gérer les risques de sécurité spécifiques à l’entreprise avec ESM Risk Insight.

• Repérer tout comportement anormal des utilisateurs et prévenez les menaces internes potentielles visant vos données sensibles à l’aide d’ArcSight IdentityView.

• Éliminer les angles morts et gagnez une visibilité complète des applications avec ArcSight Application View.

• Identifier et traiter les menaces persistantes significatives via la détection des profils suspects et la réponse automatisée à l’aide d’ArcSight Threat Detector, ArcSight Threat Response Manager et Reputation Security Monitor (RepSM).

• Utiliser le « data mining » pour l’analyse d’évènements en profondeur

3. EMC (RSA) EnVision

RSA enVision™ propose aux entreprises une solution « trois-en-un » unique et in-tégrée pour : simplifier leurs initiatives de conformité ; maximiser la sécurité et réduire les risques, et enfin, optimiser le fonctionnement opérationnel de leurs réseaux et sys-tèmes d’information.

Pour cela, elle automatise les activités de collecte, d’analyse, d’alerte, d’audit, de reporting et de stockage sécurisé de l’ensemble des logs de l’entreprise.

Les fonctionnalités essentielles sur EnVision :

• La collecte automatisée de l’ensemble des données des journaux simplifie le processus de mise en conformité.

• Les fonctionnalités d’alerte de sécurité en temps réel, de supervision et d’investi-gation par zooms successifs offrent aux administrateurs une vision claire des informa-tions importantes.

• trace et administration des journaux d’activité et également superviser les res-sources réseau, la disponibilité et l’état des utilisateurs, matériels et applications métier.

• Outil avancé d’investigation pour dépanner d’éventuels problèmes d’infrastruc-ture et protéger les ressources de cette infrastructure.

CHAPITRE 1 :CONTEXTE GÉNÉRALE DU PROJET

Page 22: Rapport PFE

22

4. LogRhythm

LogRhythm offre des solutions de Gestion de Logs, Analyse de Logs et SIEM 2.0 de classe entreprise qui permettent aux organisations d’être conformes aux régula-tions, de sécuriser leurs réseaux et d’optimiser leurs opérations SI.

Sans cesse en rapide croissance, la base de clientèle de LogRhythm comprend les entreprises Global 2000 ainsi que des entreprises de taille moyenne couvrant une variété d’industries telles que le commerce, la finance, les services publiques, les ser-vices de santé, l’éducation supérieure mais aussi les organismes gouvernementaux militaires et civils et les fournisseurs de services de gestion de sécurité..

Logrhythm permet de :

• Automatiser la collecte des journaux multiplateformes, l’archivage et la récupération

• Automatiser l’analyse des logs et les rapports

• Établir une surveillance en temps réel et des alertes sur les contrôles clés

• Effectuer des enquêtes faciles et rapides

• Automatiser la notification de violations de conformité légale

• Détecter et prévenir les intrusions sur le réseau et le système S.I. en temps réel

• Empêcher les fuites de données

• Détecter les anomalies

• Collecter, analyser, et archiver les journaux de toute base de données compatible ODBC

• Utiliser le « data mining » pour l’analyse d’évènements en profondeur

CHAPITRE 1 :CONTEXTE GÉNÉRALE DU PROJET

Page 23: Rapport PFE

23

2. Matrice de conformité :

Les quatre outils étudiés offres beaucoup de fonctionnalités, certaines sont part-agés et d’autres spécifient une ou quelques technologies.

Le tableau suivant compare les fonctionnalités entre les quatre outils :

D’après cette comparaison, on trouve que la solution InTrust est celle qui répond le plus aux fonctionnalités visées par notre projet, ensuite dans un deuxième lieu la solu-tion EnVision de RSA répond mieux que Logrhythm et ArcSight (figure 3).

Fonctionnalités Log-Rhythm InTrust EnVision Arcsight

Savoir ce que les utilisateurs des ressourc-es en ont accès

× % % ×

Comment que l’accès a été obtenu × % × ×

Comment l’accès a été utilisé % % % %

Lancer des Enquêtes de sécurité et des au-dits de conformité

% % % %

Visibilité complète en temps réel des utili-sateurs privilégiés

× % % ×

Génération de rapports % % % %

Planifier et automatiser la distribution des rapports entre les équipes

% % % %

Bibliothèque de rapports avec des pra-tiques prédéfinies

× % % ×

Tableau 1 : matrice de conformité

Figure 3 : Classement des outils SIEM

CHAPITRE 1 :CONTEXTE GÉNÉRALE DU PROJET

Page 24: Rapport PFE

24

6) Mission

La solution InTrust fournit des fonctionnalités qui remplissent nos besoins par rap-port au projet sauf au niveau de la catégorisation de la nature des actions par rapport au profil, aux machines et à la catégorie des actions.

Sur ceci, notre solution a besoin de modules complémentaires qui visent à :

• Distinguer la nature des actions

• Fournir une solution pour le changement des paramètres distinguant la nature de l’action.

La figure 4 présente une schématisation globale de notre solution, dans la suite nous allons détaillé chaque module de cette solution

La solution se divise donc en 3 modules :

1. Module 1 : mise en place de la solution InTrust

La solution Intrust permet de collecter les journaux d’événements et de les stocker dans une base de données ‘Audit’ et à partir de cette base de données, InTrust génére des rapports. (figure 5)

Figure 4 : schématisation globale de la solution

Figure 5 : schématisation de la solution SIEM

CHAPITRE 1 :CONTEXTE GÉNÉRALE DU PROJET

Page 25: Rapport PFE

25

2. Modules 2 : Développement d’une application web de gestion de référentiel

Le problème que cette application va régler est celui de la définition des privilèges de chaque utilisateur. Un utilisateur fait une action sur un serveur, c’est cette application qui va définir la nature de cette action ( autorisé, refusé, déviante ou tentative d’action déviante). (figure 6)

2. Modules 3: Développement d’une solution décisionnelle afin de générer des rapports personnalisés

L’application de gestion des rapports personnalisé va stocker les données extraite par le premier module et celle généré par le deusième, dans un datawarehouse pour générer à la fin des rapports personnalisés et pouvoir couvrir le besoin exprimé sur le CPS (figure 7)

Figure 6 : schématisation de l’application de gestion de référentiel

Figure 7 : Schématisation de la solution décisionnelle

CHAPITRE 1 :CONTEXTE GÉNÉRALE DU PROJET

Page 26: Rapport PFE

26

ID

ANALYSE ORGANISATIONNELLE

Chapitre 2

Dans ce chapitre, nous allons étudier les démarches à suivre pour organiser notre projet de

bout en bout et garantir son bon déroulement.

Nous allons dans un premier lieu décrire la description des phases avec la liste des livrables

ensuite nous allons élaborer la matrice des risques, le cycle de vie de notre projet, la méthode 2TUP et enfin la planification de notre travail.

Corrélation de log et Audit des actions d’administrateurs à haut privilèges

Chapitre1 Chapitre 2 Chapitre 3 Chapitre 4 Chapitre 5

Page 27: Rapport PFE

27

1) Description des phasesNotre projet est divisé en plusieurs phases, chaqu’une commence par des préreq-

uis et à la fin on doit présenter des livrables, le tableau suivant décrit ce travail :

2) Matrice des risquesL’une des préoccupations majeure en conduite de projet informatique est la maî-

triser des risques. Les risques sont définis comme la possibilité qu’un projet ne s’ex-écute pas conformément aux prévisions de dates, de coût ou de qualité.

L’identification initiale des risques s’est effectuée en fonction des objectifs, des exi-gences et du contexte du projet. Pour effectuer ce recensement, j’ai procédé à un brain-storming je me suis servi des risques effectués sur des projets similaires.

Ensuite les risques sont classifiés selon une typologie et estimation de leur proba-bilité d’apparition, leurs conséquences sont évaluées.

Le tableau dans la page suivante (tableau 3) illustre la matrice des risques identi-fiés susceptible d’affecter le déroulement normal du projet, leurs impacts et les actions préventives à réaliser pour limiter la probabilité de l’apparition de chaque risque.

Phase Prérequis livrable critère de fin de phase

Lancement et planifica-tion

CPS cahier des chargesCahier de charges validé, le travail est

planifié.

Spécification de la solu-tion

Description des solutions disponibles

matrice de conformité

La solution est choisie et les mod-

ules complémentaires sont définis

Analyse, conception et modélisation

NéantDossier d’architecture

fonctionnelle

Définition fonction-nelle et technique de

la solution

Création des maquettes Néant Liste des maquettes Maquettes validées

Développement de l’ap-plication web de gestion du référentiel

Liste des actions Win-dows et leurs

ID

_Dossier de déploie-ment

_guide de déploiement

_cahier de recettes

L’application de ges-tion de référentiel est

disponible

Développement du pro-cessus ETL

Accès aux données

Dossier d’ETLMise en place du

Datamart alimenté par le processus ETL

Reporting et tableaux de bord

NéantDossier de tableaux

de bords réalisés et du cube

Mise en place des tableaux de bords

réalisés et leur vali-dation

Tableau 2 : description des phases

CHAPITRE 2 : ANALYSE ORGANISATIONNELLE

Page 28: Rapport PFE

28

3) Cycle de vieDans cette partie nous allons présenter le cycle de vie de chaqu’un des deux mod-

ules : développement de l’application web de gestion de référentiel et le développe-ment de la partie décisionnelle du projet.

a. Cycle de vie de l’application de gestion du référentiel :

A partir des exigences exprimées sur le CPS, on commence par extraire les spéci-fications fonctionnelles de notre application, ensuite on élabore notre diagramme de planification, l’étape suivante est considéré la plus importante, la conception du projet présente le cœur de notre deuxième module, la réalisation ensuite se définie en tout ce qui est développement des interfaces et liaison avec la base de données … L’exécution enfin constitue la phase de test, et en cas de manque au niveau de l’application on re-prend le processus du début.

Tableau 3 : Matrice des risques

CHAPITRE 2 : ANALYSE ORGANISATIONNELLE

Page 29: Rapport PFE

29

b. Cycle de vie de l’application décisionnelle :

On obtient toujours de meilleurs résultats avec une méthode que sans méthode. Mon choix s’est porté sur le cycle de vie dimensionnel proposé par Ralph Kimball.

Cette méthode est illustrée par le schéma suivant. Ce schéma représente la succes-sion des tâches de haut niveau (macro tâches) nécessaires à la conception, au dévelop-pement et au déploiement d’entrepôts de données. Il décrit le cheminement du projet dans son ensemble: chaque rectangle sert de poteau indicateur ou de borne. Il appa-raîtra au début de chaque grande étape pour signaler notre position dans le cycle de vie.

Le schéma ci-dessous représente le cycle de vie dimensionnel :

Figure 8 : cycle de vie de l’application de gestion de référentiel

Figure 9 : cycle de vie de l’application de gestion des rapports personnalisés

CHAPITRE 2 : ANALYSE ORGANISATIONNELLE

Page 30: Rapport PFE

30

4) Gestion du projetLe processus de développement adopté, afin de mener dans les meilleures condi-

tions le présent projet est 2TUP. En effet ce dernier est le plus adapté vue la structure et l’environnement du projet.

1. Présentation de la méthode 2TUP :

2TUP Est un processus qui apporte une réponse aux contraintes de changement continuel imposées aux systèmes d’information de l’entreprise. En ce sens, il renforce le contrôle sur les capacités d’évolution et de correction de tels système « 2 Truck « sig-nifient littéralement que le processus suit deux chemins. Il s’agit des chemins Fonction-nels et d’architecture technique, qui correspondent aux deux axes des changements imposés au système informatique.

A l’issue des évolutions du modèle fonctionnel et de l’architecture technique, la réalisation du système consiste à fusionner les résultats des deux banches. Cette fusion conduit à l’ob-tention d’un processus de développement en forme de Y, comme illustré par la figure.

La branche fonctionnelle correspond à la tâche traditionnelle de modélisation du domaine, du problème à résoudre et des besoins des utilisateurs. On distingue deux phases :

Capture des besoins fonctionnels :

Qui produisent le modèle des besoins focalisés sur le métier des utilisateurs.

Elle qualifie, au plus tôt le risque de produire un système inadapté aux utilisateurs :

• Le niveau contexte a pour objet de définir la frontière fonctionnelle entre le système et son environnement.

• Le niveau « cas d’utilisation » définit ensuite les activités attendues des différents util-isateurs par rapport au système.

Figure 10 : méthode 2TUP

CHAPITRE 2 : ANALYSE ORGANISATIONNELLE

Page 31: Rapport PFE

31

L’analyse :

Qui consiste à étudier précisément la spécification fonctionnelle de manière à obtenir une

idée de ce que va réaliser le système en terme de métier, ouvre le système pour établir la structure des objets utilisés. Le modèle d’analyse du domaine définit la structure et le comportement des objets connus dans le métier des utilisateurs du système.

Le modèle d’analyse de l’application y rajoute, suivant le même processus les ob-jets qui sont connus des utilisateurs, dans le cadre de la mise en application de leur besoins.

La branche droite (architecture technique):

En effet, on a longtemps considéré que l’aspect technique se déduisait d’une manière ou d’une autre des aspects fonctionnels. Ce qui a changé et que :

• Il faut faire des choix en matière de technique.

• Il n’y a plus nécessairement une base de données centrale unique mais des bases de données réparties qui communique entre elles.

• Il faut donc créer de toutes pièces un modèle de ces composants et de leur inter-action.

La capture des besoins techniques :

Qui recense toutes les contraintes sur les choix de dimensionnant et la conception du système. Les outils et les matériels sélectionnés ainsi que la prise en compte des contraintes d’intégrations avec l’existant (pré requis d’architecture technique).

La conception générique :

Qui définit ensuite les composants nécessaires à la construction de l’architecture technique. Cette conception est complètement indépendante des aspects fonctionnels. Elle a pour objectif de d’uniformiser et de réutiliser les même mécanismes pour tout un système.

L’objectif de la branche technique est :

• Rassembler les besoins technique (sécurité, intégration à l’existant, ..) dans un dossier.

• Elaborer une architecture logicielle e et applicative qui réponde aux contraintes présentées dans le dossier technique.

• Identifier les besoins en Framework technique afin de pallier aux manques de la technologie.

• Propose des règles de développement afin d’industrialiser l’implémentation (gestion d’exception, règles de nom mage, règles de codage,..).

CHAPITRE 2 : ANALYSE ORGANISATIONNELLE

Page 32: Rapport PFE

32

La branche du milieu:

La conception préliminaire :

Qui représente une étape délicate, car elle intègre le modèle d’analyse fonction-nelle dans l’architecture technique de manière à tracer la cartographe des composants du système à développer.

La conception détaillée :

Qui étudie ensuite comment réaliser chaque composant.

L’étape de codage :

Qui produit ses composants et test au fur et à mesure les unités de code réalisées.

L’étape de recette

Qui consiste enfin à valider les fonctionnalités du système développé.

Plutôt superficiel sur les phases situées en amont et en aval développement : cap-ture des besoins, support, maintenance, gestion changement... Ne propose pas de doc-uments types.

5) Planning du projetConsiste à déterminer et à ordonnancer les tâches du projet, à estimer leurs charges et à

déterminer les profils nécessaires à leur réalisation.

La conduite d’un projet repose sur un découpage chronologique (phases) du projet en précisant :

• Ce qui doit être fait (tâches)

• Par qui cela doit être fait (Ressources)

• Comment les résultats (Livrables) doivent être présentés

• Comment les valider (Jalons)

a. Diagramme de Gant Prévisionnel :

Un diagramme de Gantt Prévisionnel permet de visualiser facilement les dates prévisionnelles de fin d’échéance des tâches d’un projet et/ou mesurer les écarts entre les dates prévisionnelles et le réalisé.

Pour réaliser notre projet nous avons utilisé un diagramme de GANTT pour repartir les taches sur des durées pour une meilleure organisation au sein du groupe de travail (figure 11).

CHAPITRE 2 : ANALYSE ORGANISATIONNELLE

Page 33: Rapport PFE

33

Figure 11 : diagramme de Gant prévisionnel

CHAPITRE 2 : ANALYSE ORGANISATIONNELLE

Page 34: Rapport PFE

34

b. Diagramme de Gant réel :

Apres la réalisation du projet il s’avère que les échéances du diagramme de GANT prévisionnel n’ont pas été complètement respectées, il y avait un décalage causé par la contrainte de la non disponibilité de la licence du produit InTrust, et une deuxième fois à cause d’un blocage au niveau du développement de la partie front-End de l’application de gestion du référentiel (figure 12).

Figure 12 : diagramme de Gant réel

CHAPITRE 2 : ANALYSE ORGANISATIONNELLE

Page 35: Rapport PFE

35

ID

NOTIONS, TECHNIQUESET TECHNOLOGIES

Chapitre 3

Dans ce chapitre allons présenter les notions, les tech-niques et les technologies qui nous ont permis de réaliser

notre projet, dans nos 3 modules, les technologies se divisent globalement en :• Technologies SIEM : InTrust• Technologies de développement des sites web : ASP.NET• Technologies d’informatique décisionnelle : MSBI (SSIS,

SSAS, SSRS)

Nous allons entamer la description de chaqu’une des tech-nologies écrites ci-dessus et toutes les techniques, frame-

work et notions qui ont fait partie de la solution du projet ainsi que les raisons de nos choix.

Corrélation de log et Audit des actions d’administrateurs à haut privilèges

Chapitre1 Chapitre 2 Chapitre 3 Chapitre 4 Chapitre 5

Page 36: Rapport PFE

36

I. Technologie SIEM : InTrust 1. Présentation générale :

InTrust offre une solution de gestion des journaux d’événements de l’entreprise, il permet aux entreprises :

• Assurer la conformité et de respecter les exigences réglementaire

• Surveiller les accès aux systèmes critiques,

• Détecter les événements suspects ou en violation de la stratégie de sécurité.

• D’avoir une compréhension approfondie de l’activité des utilisateurs en auditant l’accès des utilisateurs aux systèmes critiques, du moment de leur connexion jusqu’à leur déconnexion.

• Détecter en temps réel les événements relatifs aux accès inappropriés ou dou teux.

Cette solution unique permet:

• De simplifier la gestion du journal d’événements,

• De réduire les coûts d’administration du stockage de données,

• D’améliorer la sûreté de l’information,

• De réduire les risques

• Améliorer l’efficacité des rapports de conformité, d’opérations et de sécurité.

2. Fonctionnement globalInTrust collecte et stock les journaux d’événements de serveurs et d’ordinateurs,

il différencie entre les données qui doivent être notifiées instantanément (alertées) et celle qu’il faut stocker. A partir de ces données stockées, InTrust permet de générer des alertes et des rapports périodiques ou à la demande (figure 13).

Figure 13 : Architecture globale de InTrustCHAPITRE 3 : NOTIONS, TECHNIQUES ET TECHNOLOGIES

Page 37: Rapport PFE

37

Chaque travail est effectué par un serveur spécifique InTrust.

Les ordinateurs à partir desquelles les données d’audit doivent être recueillies sont organisés dans des sites InTrust, dans lesquelles les politiques de collecte sont appli-quées grâce à des emplois de collecte. Un travail de rassemblement réunit les entités suivantes :

• Une politique de rassemblement qui spécifie les pistes de vérification à partir de laquelle les données doivent être collectées, et un filtre à découper les données non pertinentes

• Un site InTrust qui définit des ordinateurs pour traiter

• Une base de données de dépôt et d’audit où les données collectées doivent être stockées

• Des options de collecte

• Un serveur InTrust responsable des processus de collecte de données

3. Les composants d’InTrust : 1) InTrust Site :

InTrust Site est une collection d’ordinateurs à auditer ou à surveiller.

InTrust découvre automatiquement et énumère les ressources du site.

Si on ajoute un nouveau contrôleur de domaine à un domaine traité par InTrust, il sera automatiquement détecté et inclus dans le site correspondant.

Les sites InTrust sont traités par des serveurs InTrust.

2) InTrust Server :

Figure 14 : Serveur InTrust

CHAPITRE 3 : NOTIONS, TECHNIQUES ET TECHNOLOGIES

Page 38: Rapport PFE

38

InTrust Server est fourni pour:

• La collecte des données à partir des sites InTrust et leur surveillance.

• L’installation des composants InTrust, leur configuration et leur maintenance.

• Interaction avec les agents InTrust.

InTrust Server est la base sur laquelle les composants responsables de la collecte des données de vérification et de surveillance en temps réel résident.

Les informations sur les plates-formes et les applications auditées et contrôlées sont fournies par des modules de connaissances. Ainsi, pour fournir un soutien à une nouvelle plate-forme ou à une application, vous n’avez pas à reconfigurer ou de redéployer tout le framework, il suffit d’installer le Knowledge Module correspondant sur le serveur InTrust.

Les serveurs InTrust permettent d’accéder aux données de configuration InTrust stockées dans les base de donnée Microsoft SQL Server 2000, 2005 ou 2008, appelé la base de données de configuration.

InTrust configuration comprend les éléments suivants:

• Les ordinateurs qui doivent être traités, et les serveurs InTrust pour les traiter

• Rassembler les tâches et les politiques

• Suivi des politiques et des règles

• Autres objets de configuration

Aux fins de l’équilibrage de charge, plusieurs serveurs InTrust peuvent être installés dans l’entreprise. Les serveurs InTrust qui partagent une base de données de configu-ration unique comprennent une organisation InTrust.

2) InTrust Server :

Une organisation InTrust est un groupe de serveurs InTrust avec une configuration partagée.

Une organisation InTrust prévoit ce qui suit:

• L’équilibrage de charge entre les serveurs InTrust

• La distribution et l’application des politiques uniformes de collecte et des règles de surveillance dans toute l’entreprise

CHAPITRE 3 : NOTIONS, TECHNIQUES ET TECHNOLOGIES

Page 39: Rapport PFE

39

2) InTrust Agent :

Un agent InTrust est un exécutable qui est habituellement installé automatique-ment par InTrust Server sur les ordinateurs cibles pour effectuer localement la vérifica-tion de collecte de données et le suivi en temps réel.

Cependant, vous devez, dans certains cas, installer des agents InTrust manuelle-ment (par exemple, si l’ordinateur cible est derrière un pare-feu ou dans un domaine non approuvé, ou il est une hôte Unix). En outre, un package Windows Installer pour l’agent InTrust permet de gérer les installations de l’agent en utilisant la stratégie de groupe.

Pour la collecte des données d’audit, les agents sont optionnels. Cependant, l’utili-sation de l’agent :

• Permet de collecter des données d’événements sur un pare-feu ou d’un domaine non approuvé

• Diminue considérablement les besoins en bande passante réseau en compres-sant les données envoyées au serveur: la charge du réseau est de 70 fois plus grande lorsque l’on travaille sans agents (donc, les agents sont particulièrement utiles lorsque vous travaillez sur des liaisons lentes)

• Renforce la sécurité des données transmises en utilisant l’authentification et le chiffrement

• Permet la distribution, le traitement parallèle des journaux d’événements sur de nombreux ordinateurs

Pour la surveillance en temps réel, les agents sont nécessaires.

Figure 15 : Fonctionnalités de l’agent InTrust

CHAPITRE 3 : NOTIONS, TECHNIQUES ET TECHNOLOGIES

Page 40: Rapport PFE

40

4. Fonctionnement

Les agents InTrust collectent les évènements du journal et les envoient _com-pressé, filtré, crypté _ vers les serveurs InTrust, ces dernier distinguent deux catégories : les données destinées à l’audit et celles destinés à l’alerte.

Les données d’audit sont destinées à des fins de reporting, celles d’alerte est aussi considéré par le reporting mais elle doit être notifié sur le champ puisqu’elle signale une information dangereuse (action déviante). Les informations stockées sur les bases de données d’audit et d’alerte font sujet du reporting, InTrust génère des rapports destinés à des e-mails, au Knowledge Portal et au Report Storage.

6. Outils 1) InTrust Manager

c’est un outil pour la gestion des :

• Sites

• Serveurs

• Data store

• Politiques

• Flux de travail

2) InTrust Repository Viewer

Outil pour visualiser les dépôts InTrust (Repository).

Figure 16 : Fonctionnement détaillé de InTrust

CHAPITRE 3 : NOTIONS, TECHNIQUES ET TECHNOLOGIES

Page 41: Rapport PFE

41

3) InTrust Monitoring

InTrust Monitoring Console permet aux utilisateurs de travailler avec les alertes fournies par InTrust surveillance en temps réel.

Une alerte est produite à la suite de l’activation d’une règle de contrôle sur les ob-jets de réseau sélectionnés. Si un événement qui a eu lieu sur l’objet répond à la condi-tion spécifiée par la règle (par exemple, un compte utilisateur est créé par une personne non autorisée), une alerte est générée par InTrust Server et stocké à la base de données Alerte.

4) Knowledge portal

Knowledge Portal (Portail de la connaissance) est un outil de reporting unifié qui étend Microsoft SQL Server Reporting Services (SSRS) avec des options supplémen-taires pour faciliter la gestion des sources de données et des rapports. Il vous permet de:

• Voir les rapports sur les données recueillies par les produits Quest

• Faciliter la gestion des sources de données

• Abonnement aux rapports

• Rechercher dans les rapports des informations dont vous avez besoin

• Lancer Report Builder pour créer des rapports personnalisés

• Organiser la structure des dossiers où sont stockés les rapports

• Appliquer facilement les propriétés nécessaires pour les rapports et dossiers

CHAPITRE 3 : NOTIONS, TECHNIQUES ET TECHNOLOGIES

Page 42: Rapport PFE

42

II. Notions et techniques de développement du site web 1. Contexte technologique

Dans cette partie, on va dresser un inventaire des différentes technologies qui ont servis pour la mise en œuvre de notre application web. Nous avons choisi de travaill-er avec les technologies microsoft puisque le premier module (InTrust) est compatible avec, le reporting sur InTrust est compatible avec SSRS ( outil de reporting de la série de solution MSBI ) que nous allons présenter ci-après.

Les technologies choisit sont les suivantes :

Technologie

Technologie web ASP.NET

Architecture MVC 4

moteur de vue Razor

Language de program-mation

C#

Requetage LINQ

Mapping Entity Framework

Présentation Bootstrap

éditeur Visual Studio

Modélisation Power designer

Tableau 4 : liste des technologies web

CHAPITRE 3 : NOTIONS, TECHNIQUES ET TECHNOLOGIES

Page 43: Rapport PFE

43

II. Technologies de développement de la solution décisionnelle 1. Architecture décisionnelle 1) Business Intelligence

L’informatique décisionnelle (en anglais « Business intelligence) est une discipline de l’informatique qui cible l’exploitation des données de l’entreprise afin de faciliter la prise de décision par les responsables, c’est-à-dire la compréhension du fonctionne-ment actuel et l’anticipation des actions pour un pilotage éclairé de l’entreprise.

Les outils décisionnels sont basés sur l’exploitation d’un système d’information décisionnel alimenté grâce à l’extraction de données diverses à partir des données de production, d’informations concernant l’entreprise ou son entourage et de données économiques.

2) DataMart

Le DataMart est un ensemble de données ciblées, organisées, regroupées et agrégées pour répondre à un besoin spécifique à un métier ou à un domaine donné. Il est donc destiné à être interrogé sur un panel de données restreint à son domaine fonctionnel, selon des paramètres qui auront été définis à l’avance lors de sa concep-tion. De façon plus technique, le DataMart peut être considéré de deux manières dif-férentes, attribuées aux deux principaux théoriciens de l’informatique décisionnelle, Bill Inmon et Ralph Kimball :

_ Définition d’Inmon : Le DataMart est issu d’un flux de données provenant du DataWarehouse. Contrairement à ce dernier qui présente le détail des données pour toute l’entreprise, il a vocation à présenter la donnée de manière spécialisée, agrégée et regroupée fonctionnellement.

_ Définition de Kimball : Le DataMart est un sous-ensemble du DataWarehouse, constitué de tables au niveau détail et à des niveaux plus agrégés, permettant de res-tituer tout le spectre d’une activité métier. L’ensemble des DataMarts de l’entreprise constitue le DataWarehouse.

Considérant le contexte auquel elle se rapporte, on peut privilégier suivant les en-treprises l’une ou l’autre de ces définitions.

Pour la modélisation des données et l’administration de la base de données, nous utiliserons Sql Server Management studio et Power Designer.

3) Modélisation DataMart/DataWarehouse :

La conception et la modélisation de DataMart (et plus généralement de DataWare-house) se ramènent à définir deux concepts principaux : faits et dimensions. C’est la mise en place de faits et de dimensions qui permet de définir le schéma de modélisa-tion que le DM/DWH doit suivre :

CHAPITRE 3 : NOTIONS, TECHNIQUES ET TECHNOLOGIES

Page 44: Rapport PFE

44

Les faits :

Une table de faits est une table qui contient les données observables (les faits) que l’on possède sur un sujet et que l’on veut étudier, selon divers axes d’analyse (les di-mensions). Les « faits », dans un entrepôt de données, sont normalement numériques, puisque d’ordre quantitatif. Il peut s’agir du montant en argent des ventes, du nombre d’unités vendues d’un produit, etc.

Les dimensions :

Une dimension est une table qui contient les axes d’analyse (les dimensions) selon lesquels on veut étudier des données observables (les faits) qui, soumises à une anal-yse multidimensionnelle, donnent aux utilisateurs des renseignements nécessaires à la prise de décision. On appelle donc « dimension » un axe d’analyse. Il peut s’agir des clients ou des produits d’une entreprise, d’une période de temps comme un exercice financier, des activités menées au sein d’une société, etc.

2) Présentation de la solution MSBI Microsoft Business Intelligence est une suite de produits dédiés au stockage, traite-

ment, analyse et visualisation des données. Les 3 modules avec lesquelles nous avons travailler sont :

SSIS

SSIS est un outil d’extraction, de transformation et de chargement de données. On extrait d’une source de données, puis suit la transformation si besoin, pour ensuite in-jecter ces données vers MS SQL Server ou encore d’autres destinations.

SSAS

Microsoft SQL Server 2005 Analysis Services (SSAS) fournit des fonctions OLAP (Online Analytical Processing) et d’exploration de données pour les applications déci-sionnelles. Analysis Services prend en charge OLAP en permettant de concevoir, de créer et de gérer des structures multidimensionnelles qui contiennent des données agrégées provenant d’autres sources de données, telles que des bases de données re-lationnelles. Pour les applications d’exploration de données, Analysis Services permet de concevoir, de créer et de visualiser des modèles d’exploration de données créés à partir d’autres sources de données en utilisant un large éventail d’algorithmes d’explo-ration de données standard.

SSRS

SQL Server Reporting Services fournit une gamme complète de services et d’outils prêts à l’emploi pour vous aider à créer, déployer et gérer des rapports pour votre or-ganisation.Reporting Services intègre des fonctionnalités de programmation qui vous permettent d’étendre et de personnaliser votre fonctionnalité de création de rapports.

CHAPITRE 3 : NOTIONS, TECHNIQUES ET TECHNOLOGIES

Page 45: Rapport PFE

45

ID

ANALYSE, CONCEPTION ET MODÉLISATION

Chapitre 4

Dans ce chapitre, nous allons présenter la partie main de notre projet, nous allons exposer dans 3 grandes parties

la conception et la modélisation des 3 modules :• La conception et la définition des filtres de chargement de

données à partir des journaux d’événements vers le dépôt et vers la base de données d’audit.

• L’analyse et la conception de l’application de gestion du référentiel.

• La conception et la réalisation d’un Datamart pour la su-pervision des actions chargées.

Cette partie est d’une telle importance car elle sert princi-palement à examiner la chaine BI de notre projet et l’ar-

chitecture de notre application web de gestion du référentiel.

Corrélation de log et Audit des actions d’administrateurs à haut privilèges

Chapitre1 Chapitre 2 Chapitre 3 Chapitre 4 Chapitre 5

Page 46: Rapport PFE

46

I. Module 1 : conception et réalisation des ETL sur InTrust

Après l’étape de l’installation et la configuration du serveur InTrust et des agents, on passe à l’étape de défi-nition et conception des ETL. Cette partie sert à définir les données dont on a besoin de collecter à partir des ordina-teurs à travers les agents.

Nous avons choisi de charger toutes les données du journal d’événement de tous les postes de travail et de les maitre sur le Repository et ensuite vers la base de données Audit.

Le schéma à coté (figure 17) montre les spécifications du travail du chargement d’InTrust.

Les sites présente les terminales de tous les serveurs de l’institut bancaire, on a choisi ensuite de charger toutes les données des journaux, donc pas de politiques de chargement ni d’import.

Le flux de travail créé présente notre ETL, il a pour mis-sion le chargement de toutes les données chargées au Re-pository vers la base de données ‘Audit’ :

Ensuite on crée des sessions périodiques afin de spéci-fier un temps où on stock les événements, en gardant les traces sur n’importe quel tentative de suppression ou d’édi-tion.

Figure 17 : architecture InTrust serverFigure 18 : ETL de chargement InTrust

CHAPITRE 4 :ANALYSE, CONCEPTION ET MODÉLISATION

Page 47: Rapport PFE

47

II. Module 2 : Analyse et conception de l’applica-tion de gestion du référentiel

Dans cette partie, on va présenter l’étude et la conception de l’application de ges-tion de référentiel. On va d’abord présenter les maquettes ainsi que les différents dia-grammes qui vont nous éclaircir la conception de notre application.

1. Les règles de gestion

L’application de gestion de référentiel devra permettre de définir la nature de chaque événement selon 3 critères : le profil de l’utilisateur, le type de serveur et la catégorie de l’action.

• L’authentification est nécessaire, seule le SSI pourra avoir accès à l’application.

• L’application devra permettre de spécifier un type à chaque serveur

• L’application devra permettre de spécifier un profil à chaque utilisateur

• L’application devra permettre de spécifier une catégorie à chaque action

• L’application devra permettre de spécifier un type à chaque événement

2. Les maquettes

Le Wireframe (ou maquette) en web design consiste à réaliser un schéma définis-sant les zones d’un site Web, ou d’une page Web. Il peut être réalisé par une personne non technique (client, graphiste, etc.). Pour notre projet, nous avons désigné plusieurs maquettes, on va vous exposer plutôt les plus signifiantes :

Maquette d’une page de gestion (utilisateur/ serveur/ action)

Figure 19 : Maquete de la page de gestion des utilisateurs

CHAPITRE 4 :ANALYSE, CONCEPTION ET MODÉLISATION

Page 48: Rapport PFE

48

Maquette représentant l’ajout d’une entité (utilisateur/ serveur/ action)

3. Diagramme des Use-cases globale:

1) Introduction :

Les diagrammes de cas d’utilisation sont des diagrammes UML utilisés pour don-ner une vision globale du comportement fonctionnel d’un système logiciel.

Ils sont utiles pour des présentations auprès de la direction ou des acteurs d’un projet, mais pour le développement, les cas d’utilisation sont plus appropriés. Un cas d’utilisation représente une unité discrète d’interaction entre un utilisateur (humain ou machine) et un système. Il est une unité significative de travail.

Dans un diagramme de cas d’utilisation, les utilisateurs sont appelés acteurs (ac-tors), ils interagissent avec les cas d’utilisation (use cases).

2) Les cas d’utilisation :

Ils permettent de décrire l’interaction entre l’acteur et le système. L’idée forte est de dire que l’utilisateur d’un système logiciel a un objectif quand il utilise le système.

Le cas d’utilisation est une description des interactions qui vont permettre à l’acteur d’atteindre son objectif en utilisant le système.

Les use case (cas d’utilisation) sont représentés par une ellipse sous-titrée par le nom du cas d’utilisation (éventuellement le nom est placé dans l’ellipse).

Figure 20 : Maquete de la page d’ajout d’un utilisateurs

CHAPITRE 4 :ANALYSE, CONCEPTION ET MODÉLISATION

Page 49: Rapport PFE

49

Diagramme des uses case 1 : Description fonctionnelle de l’application

Diagramme des uses case 2 : Diagramme Globale de l’application

Chaque cas d’utilisation représente la gestion d’une ou plusieurs entité, cette gestion se définie sur les actions dites CRUD, c’est-à-dire l’ajout, la modification, la création et la suppres-sion d’une entité.

Figure 21 : description fonctionnelle de l’application web

Figure 22 : diagramme global

CHAPITRE 4 :ANALYSE, CONCEPTION ET MODÉLISATION

Page 50: Rapport PFE

50

4. Diagramme de Séquence :

Il indique les objets que l’acteur va manipuler et les opérations qui font passer d’un objet à l’autre. On peut représenter les mêmes opérations par un diagramme de com-munication graphe dont les nœuds sont des objets et les arcs (numérotés selon la chronologie) les échanges entre objets.

Scénario 1 : Authentification

Scénarios de gestion de l’application :

Dans la figure 24 (page suivante) on va décrire le scénario technique de toutes les opérations que l’application fournit (l’ajout, la modification, la suppression et la consul-tation).

Figure 23 : Authentification

CHAPITRE 4 :ANALYSE, CONCEPTION ET MODÉLISATION

Page 51: Rapport PFE

51

Scénarios de gestion de l’application :

5. Diagramme de classe :

Le diagramme de classes est le point central dans un développement orienté objet.

En analyse, il a pour objet de décrire la structure des entités manipulées par les utilisateurs, il définit les briques de base statiques : classes, associations, interfaces, attributs, Opérations, généralisations, etc.

Le diagramme de classe suivant représente les différentes classes et les associa-tions dégagées.

Figure 24 : scénario de gestion de l’application web

CHAPITRE 4 :ANALYSE, CONCEPTION ET MODÉLISATION

Page 52: Rapport PFE

52

Figure 25 : diagramme de classe du Référentiel

CHAPITRE 4 :ANALYSE, CONCEPTION ET MODÉLISATION

Page 53: Rapport PFE

53

III. Module 3 : Conception et modélisation du Datamart de supervision

Dans cette partie, nous présentons les étapes d’une partie importante du volet dé-cisionnel de notre module. Il s’agit de la conception et la réalisation d’un DataMart pour la supervision des actions des administrateurs. Cette partie est d’une telle importance car elle sert principalement à examiner la chaîne BI en cours de construction et obtenir, par la suite, grâce aux techniques de reporting des rapports d’activités qui font sujet de notre besoin.

1. Choix des indicateurs :

Après avoir déterminé l’activité sur laquelle l’étude décisionnelle va porter, il faut relever des indicateurs clés génériques permettant d’extraire des rapports sur les ac-tions des administrateurs.

Suite aux besoins cités sur le CPS, on a pu extraire la liste des indicateurs relatifs à la supervision des administrateurs :

• Quantité des actions autorisées, refusé, déviante et tentative de déviante

• Quantité des actions autorisées, refusé, déviante et tentative de déviante par profil.

• Quantité des actions autorisées, refusé, déviante et tentative de déviante par serveur.

• La liste des actions par serveur

• La liste des serveurs par type d’événement

• La liste des types d’événement par utilisateur

• La liste des utilisateurs par profil

2. Modélisation :

Dans ce qui suit, nous allons présenter la modélisation de notre Datamart.

Le datamart Supervision est disponible pour effectuer des analyses sur les actions des administrateurs. Ces données vont permettre de trouver des réponses aux ques-tions du genre : combien d’action déviante ont été faites ? Qui l’a fait ? Quel est le profil dont ses utilisateurs tente des actions qui sont considéré déviante ? Sur quelle machine les actions ont été faite ? Quelle catégorie d’action est la plus marqué en tant que déviante ?

CHAPITRE 4 :ANALYSE, CONCEPTION ET MODÉLISATION

Page 54: Rapport PFE

54

Pour ceci, on a recueilli les dimensions suivantes :

• Dimension date : sert à localiser la date où l’action a été faite.

• Dimension serveur : sert à décrire la machine sur laquelle l’action a été faite

• Dimension type Serveur : sert à décrire le type de serveur sur lequel l’action a été faite.

• Dimension utilisateur : sert à identifier l’utilisateur qui a fait l’action

• Dimension profil : sert à identifier le profil de l’utilisateur qui a fait l’action

• Dimension action : sert à décrire l’action

• Dimension catégorie : sert à décrire la catégorie de l’action

• Dimension type_Autorisation : sert à spécifier le type de l’action (les 4 types d’action) des administrateurs.

Les indicateurs exprimés sur le diagramme de classe sont le nombre d’actions et le nombre d’actions déviantes.

Ces données vont permettre de trouver des réponses aux questions du genre : combien d’action déviante ont été faites ? Qui l’a fait ? Quel est le profil dont ses utili-sateurs tente des actions qui sont considéré déviante ? Sur quelle machine les actions ont été faite ? Quelle catégorie d’action est la plus marqué en tant que déviante ?

Figure 26 : modélisation du DM Supervision

CHAPITRE 4 :ANALYSE, CONCEPTION ET MODÉLISATION

Page 55: Rapport PFE

55

ID

RÉALISATIONChapitre 5

Dans ce chapitre, nous allons exposer ce que réalise chaque module de la solution. La solution est présenté sur un

navigateur web à partir de deux lieu : le site web pour l’application de gestion du référentiel et le Knowledge portal où nous exposons les rapports réalisés par InTrust et ceux réalisés par notre solution décisionnelle.

Nous allons exposer d’abord les résultats du module de gestion du référentiel, ensuite les rapports sur le Knowledge

Portal.

Corrélation de log et Audit des actions d’administrateurs à haut privilèges

Chapitre1 Chapitre 2 Chapitre 3 Chapitre 4 Chapitre 5

Page 56: Rapport PFE

56

I. Réalisation du module de gestion du référentiel

Nous allons exposer les différentes interfaces réalisées, et puisque nous avons 8 entités auxquelles on applique les mêmes fonctionnalités CRUD : Ajout, modification, suppression et consultation, on va exposer une seule entité et c’est à vous de compren-dre que c’est la même chose pour les autres.

1. Page d’authentification

La première page qui s’affiche est celle de l’authentification, seule le SSI a le droit d’accès à l’application.

Après l’authentification, on renvoie vers la page d’accueil

2. Page d’accueil :

La page d’acceuil (figure 27) se compose d’un menu qui renvoie vers les pages de gestion de chaque entité, et de quelques informations par rapport au processus du remplissage du référentiel.

Figure 27 : Page d’acceuil

CHAPITRE 5 : RÉALISATION

Page 57: Rapport PFE

57

3. Consultation d’une entité (utilisateur)

En cliquant sur une entité sur le menu, la page de consultation contenant toutes les informations s’affiche avec des liens vers des pages de modification, suppression, ajout et de détails.

4. Création d’une entité

L’ajout d’une entité dépendante d’une autre nécessite la spécification de l’autre, ici pour l’utilisateur on a besoin de spécifier le profil, la même chose pour les actions avec les catégories et pourles serveurs avec leur type .

Figure 28 : Page de gestion des utilisateurs

Figure 29 : Page d’insertion d’un nouvel utilisateur

CHAPITRE 5 : RÉALISATION

Page 58: Rapport PFE

58

Dans le cas où on ne remplie pas correctement une case obligatoire, un message d’érreur apparait.

Pour l’entité du centre et qui est l’autorisation, elle est lié avec le profil, le type de serveur, la catégorie et son type :

Figure 30 : spécificaitons de la page d’ajout

Figure 31 : page d’ajout d’une autorisation

CHAPITRE 5 : RÉALISATION

Page 59: Rapport PFE

59

5. Modification d’une entité

La page suivante présente la modification d’une entité :

6. détails d’une entité

La page suivante présente des détails sur l’entité, ainsi que des liens vers la page de modification ou de retour vers la page de consultation :

Figure 32 : page de modification d’une entité

Figure 33 : page de détails sur une entité

CHAPITRE 5 : RÉALISATION

Page 60: Rapport PFE

60

7. Suppression d’une entité

cette page présente une confirmation de suppression d’une entité, et elle décrit les conséquences de la suppression, par exemple si on supprime un profil, tous les utilisa-teurs contenus dans ce profil vont être supprimés aussi.

Figure 34 : page de supression sur une entité

CHAPITRE 5 : RÉALISATION

Page 61: Rapport PFE

61

1. La phase d’ETL :

Dans cette partie, nous allons utiliser l’outil Sql Server Integration Services (SSIS) présenté avec le principe ETL dans le chapitre précédent, pour charger les données à partir de deux base de données ‘Référentiel’ et ‘Audit’ vers le DataWarehouse Supervision

Ce processus se déroule en trois étapes :

• Extraction des données à partir d’une ou plusieurs sources de données.

• Transformation des données agrégées.

• Chargement des données dans la banque de données de destination (dataware-house).

On va maintenant expliquer pour chaque table du DW Supervision, sa source de données :

Table Dim_Temps :

Cette table est générée par un script, ce script est généré seulement une fois, en conséquence on aura une table comme souhaité contenant toutes les dates entre deux variables définies au début du script :

Figure 27 : Apercu du script de la table Temps

II. Réalisation du reporting

CHAPITRE 5 : RÉALISATION

Page 62: Rapport PFE

62

Tables : Dim_serveur, Dim_utilisateur, Dim_action, Dim_catégorie, Dim_type-Serveur, Dim_profil, Dim_typeAutorisation

Ces tables sont chargées une seule fois et après chaque changement au niveau du référentiel. Le chargement se fait à partir de la base de données Référentiel. Ce flux de données forme le package Référentiel.

Table de fait : Fait_Supervision

Le deusieme package charge les données à partir de la base de données Audit vers la table de fait Fait_Supervision. Les transformations de trie et de jointure permettent de spécifier les dimension de l’action. Chaque ligne inséré dans la table de fait présente une action qui a été faite par un utilisateur.

(page suivante)

Figure 28 : flux de travail du chargement des dimensions

CHAPITRE 5 : RÉALISATION

Page 63: Rapport PFE

63

Figure 29 : chargement réussis de la table de fait

CHAPITRE 5 : RÉALISATION

Page 64: Rapport PFE

64

Ce chargement doit se faire d’une façon périodique, on l’a planifié chaque jours à 3 heures de nuit grâce l’agent SQL Server :

Figure 30 : configuration du chargement sur l’agent SQL Server

Figure 31 :Planification du chargement

CHAPITRE 5 : RÉALISATION

Page 65: Rapport PFE

65

2. Déploiement du cube

Tel que expliqué dans le chapitre précédent, SSAS permet de créer et de gérer des structures multidimensionnelles. Dans la figure ci-dessus, le cube est représenté « Su-pervision DW ».

3. Reporting

Tous les rapports développés sont disponible à partir de l’application web Quest Knowledge Portal.

Des dizaines de rapports standards avec des niveaux de détails sont disponible grâce à InTrust, nous avons ajouté les rapports personnalisés que nous avons dévelop-pé grâce à notre application décisionnelle.

Les rapports personnalisés ont été développé avec l’outil Microsoft SSRS présenté dans le chapitre précédent.

Nous allons exposer les réalisations des rapports standards et personnalisées :

la figure suivante présente un apercu du Knowledge Portal :

Figure 32 : cube de Supervision

Figure 33 : Apercu du Knowledge portal

CHAPITRE 5 : RÉALISATION

Page 66: Rapport PFE

66

RapportdetouteslesactivitésduprofiladministrateurWindows

Rapportdetoutel’activitéduprofileCFT

Ce rapport présente toutes les actions qui ont été réalisé par le profile administrateurs windows.

il décrit pour chaque utilisateur du profil l’action exacte, la date de début et de fin , et le domaine sous lequel l’action a été réalisé.

Ce rapport présente toutes les actions qui ont été réalisé par le profileCFT

Figure 34 : Rapport d’activité 1

Figure 35 : Rapport d’activité 2

CHAPITRE 5 : RÉALISATION

Page 67: Rapport PFE

67

Rapportquantitatifdesprofils

Ce rapport décrit la quantité des actions déviantes, autorisées, refusées et con-sidérées tentative d’être déviante pour chaque profil :

Rapport qualitatif des actions :

Ce rapport décrit le nombre de chaque type d’action par utilisateur, il présente en diagramme la qualité des actions.

Figure 36 : Rapport quantitatif des profils

Figure 37 : Rapport qualitatif

CHAPITRE 5 : RÉALISATION

Page 68: Rapport PFE

68

Rapport:Matricedeconfiguration

La matrice de configuration présente pour chaque profil la liste de ses utilisateurs, et pour chaqu’un la liste de ses actions avec des niveaux de détails passant par le type et le serveur allant jusqu’à l’action et le nombre de fois que l’action a eu lieux.

Figure 38 : matrice de configuration

CHAPITRE 5 : RÉALISATION

Page 69: Rapport PFE

69

Conclusion

Au terme de ce rapport, je rappelle qu’il s’agit d’un projet de fin d’études que j’ai effectué au sein de FinaTech Group pendant une durée de six mois. Ma mission consistait à étudier, concevoir et mettre en place une solution de corrélation de log et d’audit d’administrateurs à haut privilèges.

le projet se découpe en 3 modules :

• La corrélation de log en utilisant la solution InTrust, cette solution nécessite une mise en place de serveurs et d’agents, ainsi que la création et la configuration des entités permettant le chargement des données.

• L’application de gestion du référentiel qui sert à créer une solution pour l’affectation d’un type d’événement à une action selon certains paramètres : profil, type de serveur et la catégorie de l’action.

• L’application de gestion des rapports sert à donner de la performance au traitement des rapports personnalisés dont la source de données est la base de données du référentiel (2eme module) et la BD Audit où Intrust stock toutes les informations sur les événements.

Le projet m’ a permis de cumuler des connaissances diverses dans plusieurs champs : l’informatique décisionnelle, le développement web sous les technologies Microsoft, de nouveau frameworks tel que Bootstrap.. beaucoup de pratiques sur l’administration windows. J’ai eu également l’occasion de pratiquer les méthodes agiles pour la gestion du projet et d’acquérir l’expérience d’autonomie.

Page 70: Rapport PFE

70

Bibliographie Microsoft SQL Server 2014 Business Entelligence

Development

Packt entreprise

Manning Learn SQL Server Administration in a Month of Lunches (2014)

DON JONES

Webographie

http://www.codeproject.com/Articles/155829/SQL-Server-Integration-Services-SSIS-Part-Basics

http://www.codeproject.com/Articles/621332/Building-Your-First-SSRS-Report

http://www.codeproject.com/Questions/700728/how-to-create-Grid-View-in-MVC-cshtml-page

http://www.codeproject.com/Articles/482546/Creating-a-custom-user-login-form-with-NET-Csharp

http://taslimanka.developpez.com/tutoriels/projetbi/