Fonctionnalité #10498
fermé[Intégrité] Migration cryptographique
Description
Suite à relecture de la 42-013-2, la prise en charge des potentielles migrations d'empreintes numériques des éléments conservés a été évoquée.
Cette fonctionnalité fait suite à l'exigence fonctionnelle du chapitre 6.4.5.1 : Évolution des formats d'empreinte utilisés pour démontrer l'intégrité :
FCT.3.Exigence : Lorsque l'empreinte utilisée n'est plus suffisamment robuste, le SAE doit calculer une nouvelle empreinte plus robuste, unitairement et pour chaque archive concernée (journaux archivés compris), ajouter cette nouvelle empreinte aux métadonnées techniques de l'archive électronique et journaliser cet événement.
Ainsi, le SAE doit être en mesure de calculer une nouvelle empreinte, sous un nouveau format défini par l'administrateur, d'intégrer cette nouvelle métadonnée technique aux méta de l'archive, de la journaliser, et de réaliser ensuite les vérification d'intégrité non pas sur l'ancienne mais sur la nouvelle empreinte intégrée. Si bordereaux, ils devraient comporter potentiellement les deux empreintes, avec le suivi de la modifications (pourquoi, quand, qui).
Mis à jour par Elodie SOME-BLAD il y a plus de 5 ans
- Statut changé de A traiter à R&D - A étudier
Mis à jour par Emmanuel DILLARD il y a plus de 3 ans
- Projet changé de 252 à Backlog RM
- Version cible changé de Product Backlog à Inscription Backlog
- Fonction
Contrôle d'intégritésupprimé
Mis à jour par Emmanuel DILLARD il y a plus de 3 ans
- Priorité changé de 1-Majeur à 2-Sérieux
Mis à jour par Cyril VAZQUEZ il y a environ 2 ans
- Assigné à mis à Cyril VAZQUEZ
- Priorité changé de 2-Sérieux à 0-Bloquant
- Version cible changé de Inscription Backlog à 2.9.3
- Tags RM 2.9.X ajouté
Mis à jour par Cyril VAZQUEZ il y a plus d'un an
- Statut changé de R&D - A étudier à A traiter
Mis à jour par Cyril VAZQUEZ il y a plus d'un an
- Sujet changé de [Journalisation] Migration d'empreinte à [Intégrité] Migration cryptographique
- Statut changé de A traiter à R&D - En cours
- Tags RM
2.9.Xsupprimé
Mis à jour par Cyril VAZQUEZ il y a plus d'un an
- Assigné à changé de Cyril VAZQUEZ à Jérôme BOUCHER
Reste à faire :
- procédure de migration par lot, avec durée maximale d'exécution (voir ce qui a été fait sur contrôle d'exhaustivité)
- utiliser le hash présent dans l'événement de versement OU de dernière migration crypto pour le contrôle d'intégrité via les journaux
Bug dans fonctionnement actuel pour retrouver l'événement dans le journal CSV.
Il faudrait ouvrir un incident et modifier la procédure pour lire les événements (dépôt, migration crupto) dans la base de données et utiliser la date du du dernier événement pour retouver le journal CSV et la ligne qui contient le hash.
Mis à jour par Jérôme BOUCHER il y a plus d'un an
- Statut changé de R&D - En cours à R&D - En test
À tester sur branche feat/10498_migration_cryptographique
Nouveau script ajouté dans batch pour réaliser des migrations en masse (nouvelle commande également ajouté dans le planificateur de tâches)
Mis à jour par Jérôme BOUCHER il y a plus d'un an
- Assigné à changé de Jérôme BOUCHER à Cyril VAZQUEZ