Pourquoi mettre en place des tables de journalisation ?
La sécurité d’un système d’information informatisé (SII) de gestion est lié à la fiabilité des traitements supportés et à la pérennité des données mises en œuvre. La fiabilité des traitements et la pérennité des données doivent être garantis pour que les organismes aient confiance en leurs SII.
La pérennité des données implique des mécanismes de reconstitution des données enregistrées sur supports informatiques en cas de défaillances.
La littérature et la pratique mettent en évidence deux risques de défaillances majeurs:
- les pertes de données dues à des problèmes au niveau du matériel ou des logiciels de base ;
- les pertes de données dues à des problèmes au niveau des bases de données.
Les deux risques ci-dessus sont abondamment traités et pris en compte par la communauté informatique ; les constructeurs de matériels et éditeurs de logiciels fournissent de multiples moyens d’éviter ou de pallier à la perte de données. Ainsi, ces risques sont relativement bien maîtrisés par les organismes:
- les ingénieurs systèmes disposent de multiples moyens pour pallier à des défaillances matérielles ou de logiciels de base : sauvegarde et restauration de fichiers, redondances de systèmes matériels...
- les administrateurs de bases de données (DBA) disposent de divers journaux de transactions permettant de revenir à un état antérieur si une erreur est détectée.
Les moyens que nous venons d’énumérer permettent d’éviter une perte de données grâce à des systèmes redondants ou de restaurer des données à partir d’un état antérieur supposé fiable.
La restauration de données à un instant t, à partir d’une sauvegarde réalisée à un instant antérieur t-n, n’a d’intérêt que si et seulement si aucune manipulation de données n’a été effectuée par les utilisateurs dans cet intervalle de temps.
A notre sens, cette contingence de restauration de données est applicable pour des défaillances matérielles et de bases de données qui ont souvent comme manifestation externe de bloquer les utilisateurs. Un troisième risque, peu traité par les éditeurs de logiciels, est lié aux erreurs des développeurs et utilisateurs qui altèrent les données sans manifestation visible ; une sorte de cancer des données.
Il est évident que ce risque ne peut être assuré par un mécanisme de restauration ; les utilisateurs perdraient le travail de traitement de données effectué depuis la sauvegarde prise en compte pour la restauration.
Pour réduire les effets sournois de ce troisième risque, nous associons une table de journalisation à chaque table du modèle relationnel. Chaque manipulation de la table de base (ajout, modification, suppression) est tracée dans la table de journalisation.
En cas d'incident lié au 3ème risque, la lecture du contenu des tables de journalisation fournit une trace des manipulations effectuées précisément dans chacune des tables du modèle relationnel. A partir de ces traces, il est possible de corriger le contenu des tables du modèle relationnel.
Lectures complémentaires
