Logs
From Openflyers
Contents |
Introduction
Le but des logs est double :
- tracer toutes les modifications en base de données
- pouvoir facilement effectuer des recherches sur les logs pour :
- déterminer qui a fait quoi
- établir des statistiques comportementales
- faire ressortir des failles de sécurité (IDS)
Pour ce faire, le stagiaire devra retenir la solution la plus adaptée pour stocker les logs, parmi les solutions suivantes :
- fichier XML
- table en base de données
- un fichier texte 'simple' (plain text)
A priori, la solution la moins coûteuse en ressource et répondant le mieux aux besoins consisterait à créer deux tables :
- une table qui identifie chaque modification de la base avec simplement l'ID de la personne ayant fait la saisie et un numéro de log
- une table qui pour chaque numéro de log contienne une ou plusieurs lignes définissant les champs/tables affectées.
Une fois la structure déterminée, il devra créer une classe en PHP permettant de remplir la structure.
Plus
- mettre en place une interface de consultation/recherche dans les logs
- mettre en place une interface établissant des statistiques comportementales
- Intrusion Detection System en fonction des droits des individus
Ordonnancement
- 1ère semaine : étude des solutions de stockage des logs
- présentation de cette étude sur le wiki comprenant :
- les solutions de stockage (fichier texte brut, fichier xml, base de données, autre ?)
- les avantages et inconvénients (taille, accessibilité (vitesse, charge serveur), etc.)
- 2e à 4e semaine : mise en place d'une solution pour OpenFlyers
Cahier des charges
Premier temps
- sauver toutes les actions sur la base de données
- les logs doivent se suffire à eux-même : il doit être possible d'en extraire toutes les informations demandées ci-dessous sans avoir à se référer à une table de la base de données
- être capable d'interroger en temps réel les logs pour en extraire des informations
- Cette interrogation doit pouvoir se faire pour répondre à ce genre de questions :
- quelles ont été toutes les actions sur une réservation en particulier
- quelles ont été les réservations effectuées par telle personne
- quelles ont été toutes les actions effectuées par telle personne
- quelles sont les personnes qui ont fait telle action (par exemple : création d'un compte)
Ces interrogations doivent pouvoir être effectuées à l'aide d'un formulaire accessible côté admin.
Second temps
Il devra être possible, côté cahier, d'afficher l'historique des opérations sur une réservation en particulier. Pour cela il suffira alors d'utiliser une classe déjà créée dans le cadre du formulaire.
Un second type d'interrogation doit pouvoir être effectué sur les logs dans le but de la deuxième partie du stage (audit sûreté) dans le but de créer un IDS (intrusion detection system). Voici les interrogations qui doivent être possibles :
- lister toutes les actions d'un certain type (par exemple création d'un compte) effectuées par un utilisateur qui ne possédait pas le droit adéquat au moment de l'opération
- lister toutes les résas qui ont été supprimées alors qu'au moment de la suppression la date de début était obsolète.
Troisième temps
Il devra être possible de faire ressortir des statistiques des logs, comme par exemple :
- graphique représentant la répartition du nombre de résas en fonction de la différence entre le moment où est effectué la résa et le début de la résa
- graphique représentant la répartition du nombre d'annulations en fonction de la "distance" au début de la résa
- graphique représentant la répartition du nombre d'annulations en fonction de la "distance" entre la création de la résa et son annulation
Ces graphiques devront pouvoir être restreints à une population donnée ou à une personne donnée.
Etude des solutions de stockage des logs
D'après le cahier des charges, chaque "entrée" dans les logs doit contenir:
- la date de l'opération
- le login de la personne ayant effectué l'opération
- les droits de la personne au moment de l'opération
- l'intitulé de l'opération effectuée (création_compte, création_réservation, suppression_réservation, etc...)
- les tables concernées par l'opération
- les champs qui ont été modifiés et leur nouvelle valeur le cas échéant
Fichier texte
C'est le format de log le plus basique : une ligne de texte par entrée contenant toutes les informations utiles.
date login droits operation table1.champ1=valeur1 table1.champ2=valeur2 table2.champ1=valeur3...
- avantages :
- le fichier ne contient pas d'informations superflues, donc sa taille est réduite
- en cas de plantage du système, le fichier peut être lu sans problème et il suffit d'écrire à la suite du fichier pour continuer la journalisation
- inconvénients :
- la récupération et le traitement des informations prend beaucoup de temps étant donné qu'il faut parcourir le fichier en entier
Test de la solution fichier texte
Fichier XML
On peut stocker les entrées dans un fichier XML ayant une structure du type :
<logs> <log> <date>date</date> <login>login</login> <droits>droits</droits> <operation>operation</operation> <tables> <tab id=table1> <champ id=champ1>valeur1</champ> <champ id=champ2>valeur2</champ> </tab> <tab id=table2> <champ id=champ1>valeur3</champ> </tab> </tables> </log> </logs>
- avantages :
- la récupération et le traitement des informations est plus pratique que pour le fichier texte grace à la structure arborescente du fichier XML
- inconvénients :
- la taille du fichier est plus importante car chaque entrée est accompagnée d'un certain nombre de balises XML
- en cas de plantage du système, il se peut qu'une entrée n'ait été écrite que partiellement. Il faut alors vérifier tout le fichier pour s'assurer que toutes les balises sont bien refermées avant de pouvoir écrire d'autres entrées
Test de la solution fichier XML
Table en base de données
Les logs peuvent être stockés dans la base de données même dans une structure du type :
- une table "journal" contenant le login de la personne ayant effectué l'opération et le numéro de l'entrée dans les logs correspondante
Table journal :
| nom du champ | type | description |
|---|---|---|
| login | VARCHAR(255) | identifiant de la personne |
| num_log | INTEGER | auto increment - numéro du log |
| date_log | DATETIME | date de l'opération |
| rights | TEXT | droits de la personne |
| action | TEXT | intitulé de l'opération |
- une table "log" contenant le detail de l'opération effectuée
Table log :
| nom du champ | type | description |
|---|---|---|
| num_log | INTEGER | clé étrangère vers la table journal |
| action | TEXT | opération effectuée sur le champ (insert, update, etc...) |
| table_name | TEXT | nom de la table |
| field_name | TEXT | nom du champ |
| field_value | TEXT | nouvelle valeur du champ |
- avantages :
- la taille prise par les informations est plus importante que pour le fichier texte, mais moins que pour le fichier XML
- la récupération et le traitement des données est extrêmement rapide
- inconvénients :
- en cas de plantage du système, ou du système de gestion de base de données, les informations peuvent être extrêmement difficiles à récupérer
Test de la solution base de données
Résumé
Tests efféctués sur des logs contenant 30000 entrées.
Classement des solutions selon les différents critères :
- Taille
- Fichier texte (2.4M)
- Base de données (2.8M)
- Fichier XML (6.8M)
- Traitement des données
- Base de données (0.04s)
- Fichier texte (0.4s)
- Fichier XML (5.8s)
- Reprise en cas de problème
- Fichier texte
- Fichier XML
- Base de données
Le traitement des données étant une partie importante du cahier des charges, le fichier texte ne semble pas être la solution adéquate étant donné le parcours de tout le fichier nécessaire à chaque requète. La meilleure solution semblerait donc être la base de données, qui permet de traiter les données extrèmement efficacement sans prendre énormement de place pour autant. La vitesse de la base de données compense l'inconvénient de stocker les logs dans la base de données qu'ils doivent "surveiller".
Mise en place d'une solution pour Openflyers
Actions sur les réservations
| Action de l'utilisateur | Commande Openflyers | Conséquences sur la base | Conséquences sur les logs | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Création résa | record_book |
|
Table journal :
Table log :
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Modification résa | record_book |
|
Table journal :
Table log :
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Suppression résa | delete_book |
|
Table journal :
Table log :
|
Requete sur les réservations
Ce qui nous interesse ici est la requete suivante :
Trouver toutes les annulations de réservation ayant été effectuées au plus un jour avant la date effective de la réservation pour tel pilote.
Script de remplissage des tables journal et logs avec des valeur d'exemple et test de la requete : Script requete
