Quatre niveaux de vérification

Pourquoi une sauvegarde ne suffit pas

En construisant Zekura, nous avons constaté qu'un dépôt qui semble parfaitement sain sur la machine source peut être illisible sur une machine neuve : le cache local masque le problème. C'est pourquoi Zekura vérifie comme une restauration, pas comme la source. Chaque vérification se fait sur une machine séparée, le vérificateur, jamais sur votre serveur.

Les quatre niveaux

Niveau	Quoi	Fréquence
L1 Intégrité	le vérificateur se connecte avec un cache vide, relit chaque objet de l'instantané et contrôle toutes les sommes de contrôle	après chaque exécution
L2 Échantillon	un échantillon de fichiers est restauré et comparé par sha256 à l'original sur la source	quotidien
L3 Application	une base de données est chargée dans une instance jetable et recomptée par rapport aux métriques de l'exécution ; Nextcloud est démarré et scanné ; pour les fichiers, vous pouvez définir votre propre contrôle de santé	hebdomadaire
L4 Démarrage	une VM Proxmox est restaurée comme nouvelle VM et démarrée ; le temps jusqu'à la réponse de l'agent invité est mesuré	mensuel

Sur la page d'une tâche, vous voyez les trois points L1, L2, L3 et, pour les VM, aussi L4. Dans le score, une vérification plus profonde pèse plus lourd : L1 compte 0,5, L2 0,7, L3 0,9 et L4 1,0.

Ce que vous voyez sur la page d'une exécution

En haut, la durée, la quantité de nouvelles données, le nombre de fichiers et l'enregistrement de chaîne. En dessous, par chemin ou composant, le nombre de fichiers, la taille logique et nouvelle et le nombre d'erreurs. Puis l'instantané avec manifeste, objet racine et signature de l'agent. Et enfin les vérifications, avec par niveau le verdict, le vérificateur, l'heure de début, les éléments de preuve (objets lus, durée, version du moteur) et l'enregistrement de chaîne.

Si une exécution ou une vérification échoue, c'est également signé et consigné. Le registre ne cache rien.

Les freins anti-rançongiciel

• Détection d'anomalies. Si la part de nouvelles données dans une exécution bondit soudain par rapport aux précédentes, c'est à cela que ressemble un chiffrement par rançongiciel. Zekura le signale, l'inscrit dans la chaîne et place un blocage sur la tâche : plus rien n'est nettoyé jusqu'à ce que vous leviez le blocage, de sorte que les instantanés d'avant le chiffrement sont garantis de subsister.
• L'agent ne peut rien effacer. Sa clé ne permet que d'ajouter. Le nettoyage est fait par un worker séparé, et sous object lock même ces suppressions ne sont que des marqueurs jusqu'à la fin de la durée de conservation.
• Surveillance des marqueurs de suppression. Chaque jour, Zekura compte les marqueurs de suppression sous chaque destination et compare avec ce que la chaîne justifie. Des marqueurs inexpliqués déclenchent une alerte critique ; les données elles-mêmes ne sont pas encore perdues.
• Délai de 72 heures pour tout changement qui affaiblit votre protection.

Pour voir comment cela a été testé : lab/attack-sim.sh dans le dépôt joue un attaquant avec root sur un hôte client et la clé de l'agent, puis récupère les données via l'objet racine de la chaîne.