Audit 1.0.2

Presentation

Présentation

Ce module active un système d'audit permettant d'enregistrer tous les changements apportés à la plateforme et à ses contenus. Il permet de retracer les actions pour retrouver l'origine d'une modification ainsi que son auteur. Une option permet d'enregistrer avec les données avant et après modifications.

Les données sont enregistrées dans une table du serveur SQL et sont présentées par un portlet dans la Digital Workplace.

En termes de performances, un petit impact est à prévoir en raison de l'enregistrement de données en base après chaque action. La charge rajoutée est proportionelle au nombre de changements / publications effectuées par les utilisateurs. L'activation de l'audit de l'activité admin est également un facteur de charge car l'activité interne de la DWP est loggée également.

En fonction de l'activité, la table en base de données peut se remplir rapidement. Un traitement batch de purge est intégré dans le module pour éviter une saturation. Paramétrez la rétention en connaissance de cause : plus l'historique est long et plus les utilisateurs sont actifs : plus la base de données se remplira.

Ce module n'audite pas les accès aux données, seuls les changements sont enregistrés. Cela limite l'impact sur les performances qu'engendre le module : la seule charge système ajoutée est l'instruction "insert" qui sert à tracer les données dans la base.

Quand utiliser ce module ?

Ce module est utile lorsqu'il est nécessaire de pouvoir retrouver l'origine d'un changement de contenu ou de paramétrage réalisé sur une Digital Workplace.

Fonctionnement

Ce module se base sur deux parties : une partie d'audit composée de classes Java qui vont surveiller les changments et d'une partie front pour la restitution et le téléchargement des données. Une série de classes techniques interceptent les modifications apportées et enregistrent directement dans la base de données tout le contexte : date, heure, utilisateur, ressource, action effectuée, adresse IP, etc.

Les délégations sont enregistrées et les actions effectuées sous délégation retracent les deux utilisateurs délégataires et délégués.

Deux adresses IP sont enregistrées : l'adresse de la requête et celle envoyée par le header x-forwarded-for.

Actions enregistrées :

login
delegation
create
update
clone
merge
delete
deep_delete
purge

Ressources surveillées :

Publications
Membres
Groupes
Espaces de travail
Demandes de création d'espace
Catégories
AccessControlList
Transitions de workflows

Données enregistrées :

Date et heure
Membre à l'origine de l'action
Id de l'élément affecté
Id de l'espace de travail
Adresse IP de l'utilisateur (directe et forwardée)
Valeur avant changement
Valeur après changement

Portlet de consultation :

Ce portlet est prévu pour être placé dans un JPortal en pleine page, sans colonne et avec marges.

La modale de détail indique les changements réalisés sur l'objet ainsi que les valeurs avant et après changements. Un diff permet de voir immédiatement les changements apportés, les données sont manipulées au format XML.

Conformité RGPD :

Ce module collecte l'identité du membre ainsi que ses adresses IP qui sont considérées comme des données personnelles : la mise en oeuvre du module doit donc être documentée dans le cadre de la conformité RGPD.

Il est possible de désactiver l'enregistrement des adresses IP afin de limiter la quantité de données collectées et le mécanisme de purge permet d'en définir la rétention.

Contrôle d'intégrité

Avec chaque ligne de la base de données, un hash est stocké : il permet de vérifier si la ligne a été altérée après enregistrement.

A l'affichage dans le portlet, le hash de chaque enregistrement est comparé avec un nouveau hash calculé pour voir si les données ont été modifiées. Si c'est le cas, une icône associée à une couleur rouge met cela en avant.

Il sera surement remarqué que quelqu'un ayant des droits d'admin et de DBA pourra modifier les données de l'audit pour le manipuler, rendant caduque toute la traçabilité. Cela doit être traité en utilisant les principes de séparation des responsabilités : le DBA ne doit pas être admin de la DWP et l'admin de la DWP ne doit pas être DBA.