MyZapp protège ses journaux de sécurité contre la modification : le journal d'audit, le journal des refus d'accès, le journal des appels d'API, le journal des accès aux données sensibles et le journal des connexions. Chaque ligne est chaînée à la précédente par une empreinte calculée par la base de données au moment où elle est écrite. Une ligne de ces journaux ne peut être ni modifiée ni supprimée depuis l'application, et une modification faite directement dans la base est détectée par le contrôle.
Contrôle d'intégrité
L'écran Intégrité des journaux est dans le menu Administration › Instance et exploitation › Audit. Il est réservé aux Administrateurs par défaut.
Il affiche le dernier contrôle (date, tâche planifiée ou lancement à la main, résultat), puis une ligne par journal :
- État : Intact, Intact, lignes antérieures en cours de chaînage, Rompu, Non chaîné ou Contrôle impossible ;
- Lignes chaînées : lignes écrites depuis la mise en place de la protection ;
- Lignes antérieures chaînées après coup et Lignes antérieures encore à chaîner : lignes qui existaient avant la mise en place de la protection, chaînées par lots par la tâche de contrôle ;
- Première ligne en défaut : son numéro et la nature du défaut (ligne supprimée ou insérée, contenu modifié, lien rompu avec la ligne précédente, détail modifié, détail effacé sans trace d'effacement, protection de la table retirée ou désactivée, ligne écrite en contournant la protection).
Vérifier maintenant lance un contrôle complet et affiche son résultat. La tâche planifiée AuditIntegrityCheck fait le même contrôle chaque nuit ; elle est en échec quand un journal est rompu, et le défaut est aussi écrit en erreur dans le journal de l'application.
Un journal rompu ne se répare pas depuis l'application : la ligne signalée a été modifiée en dehors d'elle. Conservez l'état de la base et signalez-le au responsable de la sécurité.
Détail effacé
Quand les données personnelles d'une personne sont effacées, le détail des lignes du journal d'audit qui la concernent est vidé. L'empreinte de ce détail reste dans la ligne : la chaîne reste vérifiable. Le détail de la ligne affiche alors Détail effacé le suivi de la date, et l'effacement est lui-même consigné.
Ancres externes
Quand l'exploitant l'a réglé, MyZapp exporte régulièrement la dernière empreinte de chaque journal hors de la base, vers un stockage qui ne peut pas être effacé. Ces ancres ne contiennent que des empreintes et des identifiants, aucune donnée personnelle. Elles protègent contre ce que le contrôle seul en base ne voit pas : la suppression des dernières lignes d'un journal, ou sa réécriture complète par une personne ayant tous les droits sur la base.
La section Ancres externes de l'écran indique :
- Correspond à la base et le nombre d'Ancres comparées ;
- Une ancre ne correspond pas à la base, avec le journal, la position et la cause : le journal a été réécrit, ou des lignes ont été supprimées. Conservez l'état de la base et signalez-le au responsable de la sécurité ;
- que les ancres n'ont pas pu être lues : la comparaison n'a pas été faite, ce qui n'est pas un défaut du journal ;
- qu'aucune ancre n'est réglée : un avertissement apparaît aussi dans l'état de santé de l'instance ;
- le Dernier export, et s'il est En échec.
Chez un hébergeur, c'est souvent son propre outil qui compare les ancres à la base, pour que votre instance n'ait jamais accès aux ancres des autres clients. L'écran indique alors Comparé par l'hébergeur, avec la date de sa dernière comparaison. S'il n'a encore rien déposé, l'écran le signale ; sans comparaison récente, un avertissement apparaît dans l'état de santé de l'instance.
Après la restauration d'une sauvegarde, les ancres plus récentes que cette sauvegarde ne correspondent plus : l'exploitant les écarte par le réglage Audit:Anchor:NotBefore.
Conservation
Par défaut, aucune ligne de ces journaux n'est supprimée. L'exploitant de l'instance peut fixer une durée de conservation par catégorie (opérations d'administration, connexions et refus d'accès, accès aux données sensibles, appels d'API). Chaque nuit, les lignes plus anciennes sont alors purgées, toujours en commençant par les plus anciennes, et la purge laisse une trace : la chaîne reste vérifiable et l'écran indique, pour chaque journal, le nombre de lignes purgées et la date de la dernière purge. Une ligne de moins d'un jour n'est jamais purgée.
Export signé
La carte Export signé télécharge un journal sur une période (sans dates : les 7 derniers jours) sous forme d'archive. Elle contient une ligne par entrée avec ses empreintes, jamais le contenu du détail, une signature par la clé de cette instance et la clé publique qui permet de la vérifier, ainsi qu'un fichier qui décrit l'export et donne la commande de vérification. Toute modification d'une ligne de l'export rend la signature invalide. L'export est inscrit au journal des accès aux données sensibles. Il est refusé si l'instance n'a pas de clé d'identité utilisable, ou si la période contient trop de lignes : réduisez-la.
Envoi au SIEM
Quand l'exploitant l'a réglé, les nouvelles lignes de ces journaux et les alertes de sécurité partent chaque minute vers l'outil de supervision de la sécurité (SIEM) de l'établissement. La carte Envoi au SIEM indique, pour chaque journal, le nombre de lignes en attente, la date du dernier envoi et la plus ancienne ligne en attente. Si l'outil est injoignable, l'envoi reprend là où il s'était arrêté, sans perdre de ligne.