Stratégies de journalisation d'audit

Question

J'essaie de décider de la meilleure méthode pour la journalisation d'audit au sein de mon application. La principale raison du journal est de signaler la séquence d'événements (modifications).

J'ai une hiérarchie d'objets, je dois créer des rapports lorsque quelque chose change sur une partie de cette hiérarchie, à une date ultérieure.

Je pense que j'ai trois options:

1. Ayez un journal pour chaque table et correspond donc à la hiérarchie des objets, puis créez une vue pour le rapport.
2. Aplatissez la hiérarchie et dénormalisez la table, ce qui facilite la création de rapports - instruction de sélection simple.
3. Disposer d'une table de journal et d'un enregistrement pour chaque modification, ce qui rend les rapports plus difficiles mais plus souples.

Je suis actuellement penché vers l'option 1.

Answer 1

Un journal d’audit est essentiellement une liste chronologique des événements survenus, des auteurs de ces événements et de leur nature.

Je pense qu'une vue à plat serait préférable car elle peut être facilement commandée et interrogée. Donc, je me penche plus vers votre option # 2 / # 3.

Incluez des éléments tels que le type de transaction, l'heure, l'ID utilisateur, une description des modifications apportées et d'autres informations pertinentes relatives à votre produit.

Vous pouvez également ajouter des éléments à votre produit au fil du temps sans avoir à modifier en permanence votre module de journal d'audit.

Answer 2

Je dois parler de ce sujet même s’il est vieux.

C’est généralement une mauvaise idée de n’avoir qu’une seule table d’audit, car vous allez créer des problèmes de verrouillage dans la base de données, car tout se trouve dans cette table. Utilisez des tables d'audit distinctes pour chaque table.

C’est également une mauvaise idée que l’application fasse l’audit. L'audit doit être effectué au niveau de la base de données, sinon vous risquez de perdre une partie de l'information. Les données ne changent pas uniquement à partir des applications de la plupart des bases de données; personne ne modifiera les prix de tous ses produits, un par un, à partir de l'interface utilisateur, si vous avez besoin d'une augmentation de 10% sur 10 000 000 d'entre eux. L'audit doit capturer tous les changements et pas seulement certains d'entre eux. Cela devrait être fait par un déclencheur dans la plupart des bases de données (SQL Server 2008 a une fonction d'audit intégrée). Certains des pires changements potentiels (employés frauduleux ou voulant détruire de manière malveillante des données) proviennent souvent d’endroits autres que l’application, en particulier si vous autorisez un accès au niveau de la table aux utilisateurs (ce que vous ne devriez pas faire dans une base de données financière ou qui contient informations personnelles). Audit de l'application ne va pas attraper cela. Les développeurs oublient souvent qu'en protégeant leurs données, les sources extérieures ne constituent pas la seule menace.

Answer 3

Si c’est à des fins d’audit, j’utiliserais un véritable média qui ne comprend que des appendices plutôt que des tables dans la même base de données.

Vous suggérez que c'est à des fins d'historique des modifications. Dans ce cas, je restructurerais votre application / base de données pour enregistrer les événements réels au lieu de l'état actuel.

Answer 4

Je voudrais aller avec (2) et (3): créer une seule table pour toutes les entrées d'audit.

Une vue à plat est bonne, à condition que le travail supplémentaire ne soit pas affecté par les performances.

Answer 5

Vous pouvez examiner un cadre AOP pour vous aider à cet égard. Cela vous permettrait d'injecter une fonctionnalité de journalisation au début ou à la fin de n'importe laquelle des méthodes. Si vous choisissez cette option, cela vous aidera peut-être à définir ce qui serait judicieux pour stocker les données du journal.