Piste d'audit de workflow : quoi enregistrer, et pourquoi

Les trois questions

Tôt ou tard, quelqu'un pose des questions sur un dossier : un client qui conteste une décision, un auditeur interne, un régulateur, ou votre propre équipe qui cherche à comprendre un échec. Les questions sont presque toujours les mêmes :

1. Quelles données sont entrées dans le processus ?
2. Qu'est-ce qui les a modifiées, et quand ?
3. Qui a pris chaque décision, et sur quelle base ?

Une piste d'audit de workflow existe pour répondre vite à ces trois questions, à partir de traces plutôt que de mémoire.

L'historique du moteur n'est pas une piste d'audit

Camunda garde un historique : quelles instances ont tourné, par quelles étapes elles sont passées, quelles variables elles portaient. C'est précieux, mais c'est le point de vue du moteur. Il ne couvre pas tout ce que les gens font autour du processus : qui a modifié un mapping de formulaire, qui a donné des droits d'administration, qui a réattribué une tâche, qui a relancé un incident.

Une piste d'audit couvre les actions des personnes, sur toute la plateforme, pas seulement les étapes du moteur.

Quoi enregistrer

Pour chaque action :

• qui : la personne (ou le système) qui a agi ;
• quoi : l'action, et ce sur quoi elle a porté (un dossier, une tâche, un utilisateur, une connexion) ;
• quand : un horodatage exact ;
• le résultat : réussite ou échec.

Pour chaque dossier :

• les données entrées à chaque étape, dès la première soumission de formulaire ;
• chaque modification de ces données, avec l'étape qui l'a faite.

Enregistrez aussi les échecs. Une connexion refusée ou une permission rejetée est souvent exactement ce qu'un auditeur veut voir.

La rendre consultable

Une piste d'audit que personne ne peut interroger n'est qu'un fichier de logs. Les questions viennent dans deux sens : « qu'a fait cette personne le mois dernier ? » et « qu'est-il arrivé à ce dossier ? ». Les deux doivent trouver une réponse rapide.

La garder assez longtemps, et pas plus

Décidez combien de temps les traces sont conservées, écrivez-le, et assurez-vous que le système l'applique. Trop court, et vous ne pouvez pas répondre sur l'an dernier ; trop long, et vous gardez des données personnelles dont vous n'avez plus besoin. Les dossiers terminés ont aussi besoin d'une place : une fois un processus ou un moteur retiré, son historique doit rester lisible.

Les accès font partie de la piste

Une piste d'audit ne vaut que par les règles d'accès qui l'entourent. Enregistrez qui a quel rôle, vérifiez les permissions sur le serveur pour chaque action, et alertez les administrateurs des événements sensibles (un compte verrouillé, des droits d'administration accordés, des identifiants de connexion modifiés).

Liste de contrôle

• Qui, quoi, quand et résultat pour chaque action
• Des variables suivies par dossier dès la première soumission
• Une recherche par personne et par dossier
• Une conservation définie et appliquée
• Des dossiers terminés lisibles après le retrait du processus
• Des événements sensibles signalés, pas seulement enregistrés

Dans Bridge

Chaque action dans Bridge est enregistrée avec qui, quoi, quand et le résultat, se recherche par personne ou par objet concerné, et est conservée pendant la durée fixée par votre offre. Chaque variable de chaque soumission de formulaire est capturée au moment de son entrée, horodatée et rattachée à l'instance de processus, et la relecture des jetons montre n'importe quel dossier étape par étape.

Les instances terminées restent consultables dans l'archive historique, y compris l'historique Camunda 7 après une migration. Les permissions sont vérifiées sur le serveur, et les administrateurs sont prévenus quand un compte est verrouillé, une adresse bloquée, des droits d'administration accordés ou les identifiants d'une connexion modifiés.