Vous êtes sur la page 1sur 70

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

Mohamed Ramdani
HAFID Oussama
Oumar Traoré

2014/2015

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

HAFID Oussama
Avant Intitulé du travail

Propos Corrélation de logs et audit des ac-


tions des administrateurs à haut priv-
ilèges

Société d’accueil
Finatech Group
Casablanca, 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 TRAORE
TECHNICAL MANAGER

Encadrant pédagogique
Mr. Mohamed RAMDANI
Professeur enseignant à l’EMSI

Date de début et de fin du stage :


Du 01 Mars au 01 Septembre 2015 (6 mois)

2
À 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

Dédicace
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.

3
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
Remerciement 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.

4
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

5
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

6
‫ﻣﻠﺨﺺ‬
‫عندما بنى الصينيون سور الصين العظيم‪ ..‬اعتقدوا بأنه ال يوجد من يستطيع تسلقه‬
‫لشدة علوه‪ ،‬ولكن خالل المئة سنة األولى بعد بناء السور تعرضت الصين للغزو ثالث مرات‬
‫! حيث كانت جحافل العدو البرية تدفع للحارس الرشوة ثم يدخلون عبر الباب ‪ -‬المهدي‬
‫المنجرة‬
‫مشكل حرس القصر‪ ،‬حاضر كذلك في أنظمة المعلومات‪ ،‬كل سيرفر يكون مراقبا من قبل‬
‫إداريين ذوو امتياز عالي‪ ،‬لكن المشكل يكمن‪ ،‬كما في حراس القصر‪ ،‬حول من سيقوم‬
‫بحراسة هؤالء اإلداريين ؟‬
‫عالم الشركات يعرف حاليا تغيتار هامة‪ ،‬الشركات تتعرض لمخاطر مثل الهجمات الموجهة‬
‫‪.‬و المستمرة‬
‫كنتيجة لذلك‪ ،‬اغلب الشركات تنفذ وظائف مثل جمع جميع االحداث التي قام بها اإلداريون و‬
‫المستعملون لنظام المعلومات‪ ،‬استخراج االحداث المعنية بأمر الخطر‪ ،‬إطالق رسائل إنذار و‬
‫‪.‬العرض التوضيحي إلحترام المتطلبات التنظيمية‬
‫في هذا السياق يتجلى مشروع نهاية الدراسة هذا‪ ،‬والذي يهدف إلى إتقان و ظبط أمن‬
‫أنظمة المعلومات لمؤسسة بنكية‪ ،‬وذلك بوضع مخطط لمتابعة تحركات اإلداريين ذوو اعلى‬
‫‪ :‬رتبة امتياز‪ ،‬الشيء الذي سيمكن من‬
‫ ‬ ‫_ تقليص خطر التالعب بمصادر المعلومات‬
‫ ‬ ‫_ تركيز إدارة آثار تحركات اإلداريين و المحافظة عليها‬
‫من أجل تطبيق هذا‪ ،‬نلجأ إلى حلول إدارة األحداث و المعلومات‪ ،‬إال أن المتطلبات المعبر عنها‬
‫ال تغطى كلها عبر هاته الحلول‪ ،‬فهاته األخيرة ال تسمح بتمييز طبيعة األحداث حسب رؤية‬
‫‪.‬المؤسسة البنكية‪ ،‬و هذا ما يدفعنا إلى إضافة و تطوير وحدات إضافية‬
‫الوحدات المضافة تتجلى في حلين إثنين‪ ،‬األول هو تطبيق إلدارة مستودع لألحداث‪ ،‬والثاني‬
‫هو تطبيق إلنتاج تقارير حول أحداث اإلداريين‬

‫‪7‬‬
Terminologie
A S
AD : Active directory SI : Système d’information
API : Application Programming Interface SIEM : Security Information Event Manage-
ment
ASP : Active Server Pages
SGBD : Système de Gestion de Bases de
Données
B
BI : Business intelligence SID : Surrogate ID (ID de
substitution)
BD : Base de données
SPI : Service de production
C informatique
CPT : cahier des prescriptions techniques SSI : Service de sécurité informatique

D U
DC : Domaine controller (contrôleur de
domaine) UML : United Modeling Language
DBA : administrateur de base de données
DOSI : Direction de l’Organisation et des
Systèmes d’’Information
DM : Datamart
DWH : DataWarehouse

E
EMSI : Ecole Marocaine des Sciences de
l’ingénieur
ETL : Extract-Transform-Load

O
OU : Unité organisationnelle
OS : Système d’exploitation
OLAP : On Line Analytical Processing
OLTP : On Line Transactional Processing

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

Tableau 1 : matrice de conformité 22


Tableau 2 : description des phases 26
Tableau 3 : Matrice des risques 27
Tableau 4 : liste des technologies web 41

9
Sommaire
Avant-propos
Dédicace
Remerciement
Résumé
Abstract
‫ﻣﻠﺨﺺ‬
Terminologie
Liste des figures
Liste des tableaux
Sommaire
Introduction générale

Chapitre I : Contexte générale du projet 13


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.Présentation du projet :
2)Historique :

1)Problématique :
2)Etude de l’éxistant :
3)Objectifs
4)Démarche
5)Matrice de conformité

CHAPITRE 2 : Analyse organisationnelle 26


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 35


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

10
Sommaire
Chapitre 4 : Analyse, conception et modélisation 45
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 55
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

11
Introduction
Gé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.

12
ID

Chapitre1 Chapitre 2 Chapitre 3 Chapitre 4 Chapitre 5

CONTEXTE GÉNÉRALE
DU PROJET
Chapit re 1

D ans 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


13
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.

Figure 1 : domaines de Finatech Group

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).

CHAPITRE 1 :CONTEXTE GÉNÉRALE DU PROJET


14
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


15
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


16
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


17
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


18
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


19
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 :

Figure 2 : Classement des outils SIEM Selon Gartner

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.

CHAPITRE 1 :CONTEXTE GÉNÉRALE DU PROJET


20
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


21
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


22
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 :


Log-
Fonctionnalités InTrust EnVision Arcsight
Rhythm
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é

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).

Figure 3 : Classement des outils SIEM

CHAPITRE 1 :CONTEXTE GÉNÉRALE DU PROJET


23
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

Figure 4 : schématisation globale de la 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 5 : schématisation de la solution SIEM

CHAPITRE 1 :CONTEXTE GÉNÉRALE DU PROJET


24
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)

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

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 7 : Schématisation de la solution décisionnelle

CHAPITRE 1 :CONTEXTE GÉNÉRALE DU PROJET


25
ID

Chapitre1 Chapitre 2 Chapitre 3 Chapitre 4 Chapitre 5

ANALYSE
ORGANISATIONNELLE
Chapit re 2

D ans ce chapitre, nous allons étudier les


démarches à suivre pour organiser notre projet de
bout en bout et garantir son bon déroulement.

N ous 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


26
1) Description des phases
Notre 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 :

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

Cahier de charges
Lancement et planifica-
CPS cahier des charges validé, le travail est
tion
planifié.
La solution est
Description
Spécification de la solu- choisie et les mod-
des solutions matrice de conformité
tion ules complémentaires
disponibles
sont définis
Définition fonction-
Analyse, conception et Dossier d’architecture
Néant nelle et technique de
modélisation fonctionnelle
la solution
Création des maquettes Néant Liste des maquettes Maquettes validées
_Dossier de déploie-
Liste des ment
Développement de l’ap- L’application de ges-
actions Win-
plication web de gestion _guide de déploiement tion de référentiel est
dows et leurs
du référentiel _cahier de recettes disponible
ID

Mise en place du
Développement du pro- Accès aux
Dossier d’ETL Datamart alimenté
cessus ETL données
par le processus ETL
Mise en place des
Dossier de tableaux
Reporting et tableaux de tableaux de bords
Néant de bords réalisés et du
bord réalisés et leur vali-
cube
dation
Tableau 2 : description des phases
2) Matrice des risques
L’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.

CHAPITRE 2 : ANALYSE ORGANISATIONNELLE


27
Tableau 3 : Matrice des risques

3) Cycle de vie
Dans 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.

CHAPITRE 2 : ANALYSE ORGANISATIONNELLE


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

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 9 : cycle de vie de l’application de gestion des rapports personnalisés

CHAPITRE 2 : ANALYSE ORGANISATIONNELLE


29
4) Gestion du projet
Le 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.

Figure 10 : méthode 2TUP


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.

CHAPITRE 2 : ANALYSE ORGANISATIONNELLE


30
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


31
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 projet
Consiste à 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


32
Figure 11 : diagramme de Gant prévisionnel

CHAPITRE 2 : ANALYSE ORGANISATIONNELLE


33
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


34
ID

Chapitre1 Chapitre 2 Chapitre 3 Chapitre 4 Chapitre 5

NOTIONS, TECHNIQUES
ET TECHNOLOGIES
Chapit re 3

D ans 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)

N ous 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


35
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 global
InTrust 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 InTrust


CHAPITRE 3 : NOTIONS, TECHNIQUES ET TECHNOLOGIES
36
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
37
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


38
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.

Figure 15 : Fonctionnalités de l’agent InTrust


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.

CHAPITRE 3 : NOTIONS, TECHNIQUES ET TECHNOLOGIES


39
4. Fonctionnement

Figure 16 : Fonctionnement détaillé de InTrust


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).

CHAPITRE 3 : NOTIONS, TECHNIQUES ET TECHNOLOGIES


40
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


41
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-
C#
mation
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


42
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


43
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


44
ID

Chapitre1 Chapitre 2 Chapitre 3 Chapitre 4 Chapitre 5

ANALYSE, CONCEPTION
ET MODÉLISATION
Chapit re 4

D ans 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.

C ette 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


45
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’ :

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


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.

CHAPITRE 4 :ANALYSE, CONCEPTION ET MODÉLISATION


46
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
47
Maquette représentant l’ajout d’une entité (utilisateur/ serveur/ action)

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

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).

CHAPITRE 4 :ANALYSE, CONCEPTION ET MODÉLISATION


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

Figure 21 : description fonctionnelle de l’application web

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

Figure 22 : diagramme global


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é.
CHAPITRE 4 :ANALYSE, CONCEPTION ET MODÉLISATION
49
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

Figure 23 : 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).

CHAPITRE 4 :ANALYSE, CONCEPTION ET MODÉLISATION


50
Scénarios de gestion de l’application :

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

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.
CHAPITRE 4 :ANALYSE, CONCEPTION ET MODÉLISATION
51
Figure 25 : diagramme de classe du Référentiel

CHAPITRE 4 :ANALYSE, CONCEPTION ET MODÉLISATION


52
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


53
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


54
ID

Chapitre1 Chapitre 2 Chapitre 3 Chapitre 4 Chapitre 5

RÉALISATION
Chapit re 5

D ans 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.

N ous 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


55
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
56
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.

Figure 28 : Page de gestion des utilisateurs


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 29 : Page d’insertion d’un nouvel utilisateur


CHAPITRE 5 : RÉALISATION
57
Dans le cas où on ne remplie pas correctement une case obligatoire, un message
d’érreur apparait.

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

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 31 : page d’ajout d’une autorisation

CHAPITRE 5 : RÉALISATION
58
5. Modification d’une entité
La page suivante présente la modification d’une entité :

Figure 32 : page de 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 33 : page de détails sur une entité

CHAPITRE 5 : RÉALISATION
59
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
60
II. Réalisation du reporting
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

CHAPITRE 5 : RÉALISATION
61
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.

Figure 28 : flux de travail du chargement des dimensions


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)

CHAPITRE 5 : RÉALISATION
62
Figure 29 : chargement réussis de la table de fait
CHAPITRE 5 : RÉALISATION
63
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
64
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 ».

Figure 32 : cube de Supervision


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 33 : Apercu du Knowledge portal

CHAPITRE 5 : RÉALISATION
65
Rapport de toutes les activités du profil administrateur Windows

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é.

Figure 34 : Rapport d’activité 1

Rapport de toute l’activité du profile CFT


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

Figure 35 : Rapport d’activité 2


CHAPITRE 5 : RÉALISATION
66
Rapport quantitatif des profils
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 :

Figure 36 : Rapport quantitatif des profils


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 37 : Rapport qualitatif


CHAPITRE 5 : RÉALISATION
67
Rapport : Matrice de configuration
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
68
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.

69
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/

70

Vous aimerez peut-être aussi