Mersal Registre d'audit inaltérable
Le problème
La plupart des systèmes ont un journal d'activité. Très peu en ont un qui survit à la personne aux privilèges les plus élevés décidant qu'il devrait dire autre chose. Quand un honoraire, une échéance ou une instruction est contesté, un journal qu'un administrateur aurait pu modifier ne prouve rien.
Comment Mersal y répond
Le registre de Mersal est en ajout seul dans la base de données, pas dans l'application. Des déclencheurs rejettent la modification et la suppression des enregistrements d'audit pour tout rôle, y compris les administrateurs et le rôle de service sous lequel l'application elle-même s'exécute. Aucun écran, aucun script, aucune procédure d'assistance ne modifie une entrée passée, parce que la base la refuse.
Comment cela fonctionne
Imposé là où l'on ne peut le contester
La garantie vit dans la base de données, pas dans un code qu'un autre chemin pourrait contourner. Un déclencheur lève une exception à toute tentative de modifier ou de supprimer une ligne d'audit, quel que soit le demandeur. L'application ne détient aucun privilège qui la lève.
Écrit à mesure que le travail se fait
Les entrées sont produites par le travail lui-même — un dossier ouvert, un conflit écarté, une facture émise, un paiement enregistré, un accès accordé — de sorte que rien n'est à reconstruire ensuite de mémoire.
Les échecs sont capturés, pas avalés
Si une écriture d'audit échoue, l'événement est capturé plutôt que perdu, et une réconciliation nocturne le rejoue. Un registre qui laisse tomber des entrées en silence sous la charge n'est pas un registre ; le chemin d'échec est donc traité avec autant de soin que celui de réussite.
Ce que cela évite
- Un utilisateur privilégié qui amende l'histoire en silence
- « Le système a dû le perdre » comme explication
- Reconstruire une chronologie de mémoire, des mois plus tard
Le plus rapide pour juger reste de le voir tourner sur votre propre façon de travailler.