Une plateforme d’analyse des fichiers logs

Une plateforme d’analyse des fichiers logs

Analyse et spécification des besoins

Introduction
Dans ce chapitre, nous détaillons les besoins fonctionnels, non fonctionnels et architecturaux afin de bien démarrer notre projet. Enfin, nous ajouterons la modélisation des besoins de l’application ainsi que les diagrammes de cas d’utilisation.

Spécification des besoins

Les besoins fonctionnels
Les besoins fonctionnels doivent répondre aux exigences de notre future application en termes de fonctionnalités, et comme notre projet consiste à développer une application d’investigation, cette application doit couvrir les besoins fonctionnels suivants:
 La gestion d’accès à la plateforme d’investigation via un login et mot de passe,
 L’inscription dans la plateforme,
 La déclaration d’un incident,
 La gestion d’investigateur et de client,
 La gestion de profil utilisateur,
 La gestion d’organisme, d’incident, de dictionnaire d’attaque et de rapport
 Analyser un incident.
 Validation de rapport analysé,
 Consulter statistique,
 Télécharger rapport,
 Upload fichier log.

Les besoins non fonctionnels

A part les besoins fondamentaux, notre future application doit répondre aux critères suivants :
 La sécurité au niveau de session de l’utilisateur : Les informations concernant l’identité de la personne connectée sont cryptées.
 La compatibilité de la plateforme avec n’importe quel navigateur web ou système d’exploitation.
 La disponibilité de la plateforme 24h/24 et 7 jours / 7.
 L’intégrité des données : Il y a certains traitements pour les mauvaises entrées des données, tel ue les alertes immédiates pour l’utilisateur en cas d’erreur.
 La convivialité : la future application doit être facile à utiliser. En effet, les interfaces utilisateurs doivent être conviviales c’est-à-dire simples, ergonomiques et adaptées à l’utilisateur.

Les besoins architecturaux

Nous devons savoir qu’il existe plusieurs types d’architectures. Parmi ces architectures, nous pouvons citer :
Architecture centralisée
Cette architecture se compose d’un unique serveur, dont le but est de recenser les fichiers proposés par les différents clients. Il dispose principalement de deux types d’informations : celles sur le fichier (nom, taille, …), et celles sur l’utilisateur (nom utilisé, IP, nombre de fichiers, type de connexion, …) Du côté du client, rien de plus simple : une fois connecté grâce au logiciel spécifique, il peut faire des recherches comme avec un moteur classique. On obtient alors une liste d’utilisateurs disposant de la ressource désirée. Il suffit alors de cliquer sur le bon lien pour commencer le téléchargement.
Les avantages de cette architecture sont :
 Simplicité d’utilisation.
 Facilité de recherche.
Les inconvénients sont les suivantes :
 Faible sécurité : si le serveur est supprimé, le réseau est hors service
 Pas d’anonymat : chaque utilisateur est identifié sur le serveur [10]

Architecture client/serveur

L’architecture client/serveur est subdivisée entre deux entités client et serveur qui coopèrent ensemble via des requêtes. Nous distinguons plusieurs types de cette architecture :
 Architecture 2-tiers :
Une architecture 2-tiers est composée de deux éléments, un client et un serveur qui se contente de répondre aux requêtes du client. Ce type d’application permet d’utiliser toute la puissance des ordinateurs présents sur le réseau et permet de fournir à l’utilisateur une interface riche, tout en garantissant la cohérence des données qui restent gérées de façon centralisée.
La gestion des données est prise en charge par un SGBD centralisé sur un serveur dédié. On interroge ce serveur à travers un langage de requête, le plus courant étant SQL.

Guide du mémoire de fin d’études avec la catégorie Nouvelles Technologies des Télécommunications

Étudiant en université, dans une école supérieur ou d’ingénieur, et que vous cherchez des ressources pédagogiques entièrement gratuites, il est jamais trop tard pour commencer à apprendre et consulter une liste des projets proposées cette année, vous trouverez ici des centaines de rapports pfe spécialement conçu pour vous aider à rédiger votre rapport de stage, vous prouvez les télécharger librement en divers formats (DOC, RAR, PDF).. Tout ce que vous devez faire est de télécharger le pfe et ouvrir le fichier PDF ou DOC. Ce rapport complet, pour aider les autres étudiants dans leurs propres travaux, est classé dans la catégorie Réseaux où vous pouvez trouver aussi quelques autres mémoires de fin d’études similaires.

Le rapport de stage ou le pfe est un document d’analyse, de synthèse et d’évaluation de votre apprentissage, c’est pour cela rapport gratuit propose le téléchargement des modèles gratuits de projet de fin d’étude, rapport de stage, mémoire, pfe, thèse, pour connaître la méthodologie à avoir et savoir comment construire les parties d’un projet de fin d’étude.

Table des matières

Introduction générale
Chapitre 1 : Etat de l’art
I. Présentation de l’organisme d’accueil
II. Etude théorique
1. Les fichiers journaux
2. Les types de fichiers journaux
3. Format de fichier journal
4. Code de réponse de serveur
5. Dictionnaire d’attaques
III. Présentation de projet
1. Problématique
2. Etude de l’existant
3. Critique de l’existant
4. Solution proposée
IV. Méthodologie à adopter
V. Choix de méthodologie à adopter
VI. Choix de langage de modélisation
Analyse et spécification des besoins
I. Spécification des besoins
1. Les besoins fonctionnels
2. Les besoins non fonctionnels
3. Les besoins architecturaux
a. Architecture centralisée
b. Architecture client/serveur
II. Modélisation des besoins
1. Les acteurs
2. Diagramme de cas d’utilisation
a. Cas d’utilisation «gérer investigateur » pour administrateur
b. Cas d’utilisation «gérer incident » pour administrateur
c. Cas d’utilisation «gérer profil » pour utilisateur
d. Cas d’utilisation «analyser incident » pour investigateur
e. Cas d’utilisation «gérer rapport » pour investigateur
1. Description des cas d’utilisation
a. Description du cas d’utilisation : « S’authentifier »
b. Description du cas d’utilisation : « Afficher les statistiques des attaques »
c. Description du cas d’utilisation : « Inscrire à la plateforme »
d. Description du cas d’utilisation : «Affecter investigateur à un incident »
e. Description du cas d’utilisation : « Analyser incident »
f. Description du cas d’utilisation : « Déclarer incident »
Conception
I. Architecture de système
II. Déploiement
III. Conception
1. Diagramme de classe
a. Représentation des classes
b. Conception de la base de données
2. Diagramme de séquence
a. Diagramme de séquence de cas d’utilisation « s’authentifier »
b. Diagramme de séquence de cas d’utilisation «inscrire à la plateforme »
c. Diagramme de séquence de cas d’utilisation «Déclarer incident »
d. Diagramme de séquence de cas d’utilisation «affecter investigateur à un incident »
e. Diagramme de séquence de cas d’utilisation «analyser incident »
f. Diagramme de séquence de cas d’utilisation « afficher statistiques des attaques »
Réalisation
I. Environnement matériel
II. Environnement logiciel
III. Présentation des interfaces
1. Interface d’inscription
2. Interface d’authentification
3. Interface de déclaration
4. Interface de travail
5. Interface de gestion des incidents
6. Interface d’affectation un investigateur à un incident
7. Interface de consultation un dictionnaire d’attaque
8. Interface de statistique
Conclusion générale
Webographie