Comprendre l'horodatage sur blockchain

Les journaux d'audit présentent une faiblesse structurelle : ils sont généralement écrits, stockés et administrés par la même organisation dont ils enregistrent les comportements. L'horodatage sur blockchain est une réponse à ce problème, mais il est plus ciblé et moins coûteux que son nom ne le laisse supposer.

Le problème

Un journal d'audit est censé répondre à la question « qu'est-il arrivé, et quand ? ». Il fonctionne tant que personne n'a accès à la base de données avec l'intention de le modifier.

Les atténuations classiques aident sans combler entièrement cette faille. Le stockage en écriture unique conserve toujours un administrateur. L'envoi des logs vers un tiers déplace la confiance plutôt qu'il ne la supprime. La chaîne cryptographique — chaque entrée hachant la précédente — rend la falsification détectable au sein du journal, mais quelqu'un capable de réécrire le journal peut recalculer la chaîne.

Ce qui manque, c'est une ancre : une valeur publiée quelque chose que le propriétaire du journal ne peut pas atteindre.

Ce qu'est réellement l'horodatage sur blockchain

Non, dans aucune conception sensée, il ne s'agit d'écrire chaque ligne de log sur une blockchain. Ce serait absurdement coûteux et publierait des données que vous ne souhaitez presque certainement pas rendre publiques.

Le modèle pratique :

1. Les logs sont écrits normalement, chaque entrée hachant la précédente.
2. Selon un calendrier — horaire, quotidien — le hash actuel (tête de chaîne) est écrit sur une blockchain publique.
3. Cette transaction constitue un engagement : toutes les entrées précédentes sont désormais figées.

Modifier une entrée après la publication de son ancre nécessite de changer chaque hash subséquent, qui ne correspondrait plus à la valeur enregistrée sur la chaîne. La falsification devient visible pour quiconque vérifie, y compris pour les personnes extérieures à l'organisation.

Le coût est d'une transaction par période, et non par entrée.

Ce que cela apporte et ce que cela n'apporte pas

Deux limites méritent d'être soulignées. Tout ce qui suit la dernière ancre n'est pas protégé, de sorte que l'intervalle d'ancrage constitue votre fenêtre d'exposition. Et une ancre ne dit rien sur la précision d'une entrée au moment où elle a été écrite — seulement qu'elle n'a pas changé depuis.

Quand cela vaut la peine

Vaut la peine lorsque le journal doit être cru par quelqu'un ayant une raison de vous mettre en doute : tenue de registres réglementés, conservation de preuves, dossiers de chaîne de traçabilité, systèmes critiques pour la sécurité, arrangements multipartites où chaque partie tient son propre journal.

Ne vaut pas la peine pour la journalisation opérationnelle ordinaire. Les sorties de débogage n'ont pas besoin de preuve d'altération, et ajouter de la cérémonie à cet égard ne sert à rien.

Le test consiste à savoir si un tiers devra jamais faire confiance au journal. Si la réponse est non, la chaîne cryptographique seule suffit amplement.

Le faire sans équipe blockchain

Le mécanisme est suffisamment simple pour ne pas nécessiter d'être un projet à part entière. Calculez le hash de tête selon votre calendrier, horodatez cette valeur unique, et conservez le certificat aux côtés de l'archive des logs. Cela représente un fichier par période, et c'est la même opération que l'horodatage de tout autre document — la seule différence réside dans ce que vous lui soumettez.

La même approche couvre des cas connexes : une exportation de base de données nocturne, un manifeste de build, une version signée, un instantané de configuration. Partout où vous souhaitez pouvoir affirmer « ceci était exactement dans cet état à cette heure » et permettre à un tiers de le vérifier.

Voir comment horodater une version logicielle pour la version de cette méthode destinée aux artefacts de build, et chaîne de traçabilité pour fichiers numériques pour le cadre probatoire.