Logs

Jump to: navigation, search

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
  1. Fichier texte (2.4M)
  2. Base de données (2.8M)
  3. Fichier XML (6.8M)
  • Traitement des données
  1. Base de données (0.04s)
  2. Fichier texte (0.4s)
  3. Fichier XML (5.8s)
  • Reprise en cas de problème
  1. Fichier texte
  2. Fichier XML
  3. 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 Champ valeur
booking ID a
booking START_DATE b
booking END_DATE c
booking AIRCRAFT_NUM d
booking MEMBER_NUM e
booking SLOT_TYPE f
booking INST_NUM g
booking FREE_SEATS h
booking comments i

Table journal :

login num_log date_log rights action
w x y z record_book

Table log :

num_log action table_name field_name field_value
x insert booking ID a
x insert booking START_DATE b
x insert booking END_DATE c
x insert booking AIRCRAFT_NUM d
x insert booking MEMBER_NUM e
x insert booking SLOT_TYPE f
x insert booking INST_NUM g
x insert booking FREE_SEATS h
x insert booking comments i
Modification résa record_book
Table Champ valeur
booking START_DATE a
booking END_DATE b
booking AIRCRAFT_NUM c
booking MEMBER_NUM d
booking SLOT_TYPE e
booking INST_NUM f
booking FREE_SEATS g
booking comments h

Table journal :

login num_log date_log rights action
w x y z record_book

Table log :

num_log action table_name field_name field_value
x booking ID id
x update booking START_DATE a
x update booking END_DATE b
x update booking AIRCRAFT_NUM c
x update booking MEMBER_NUM d
x update booking SLOT_TYPE e
x update booking INST_NUM f
x update booking FREE_SEATS g
x update booking comments h
Suppression résa delete_book
Table Champ valeur
booking ID
booking START_DATE
booking END_DATE
booking AIRCRAFT_NUM
booking MEMBER_NUM
booking SLOT_TYPE
booking INST_NUM
booking FREE_SEATS
booking comments

Table journal :

login num_log date_log rights action
w x y z delete_book

Table log :

num_log action table_name field_name field_value
x delete booking ID a

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