Non-répudiation et traçabilité : prouver qui a fait quoi

La non-répudiation vise à ce que personne ne puisse nier un acte qu'il a réellement commis. Quand un système sait, de façon difficilement contestable, qui a fait quoi et quand, l'auteur d'une action ne peut plus prétendre « ce n'était pas moi ». Cette propriété repose sur deux briques : la traçabilité, qui consiste à enregistrer chaque action dans un journal horodaté, et la signature numérique, qui rend toute modification de cet enregistrement détectable. Cette page définit ces notions avec des exemples du quotidien, sans aucun prérequis technique, et montre où elles se rangent : dans le critère Preuve du sigle DICP, présenté dans la leçon sur la triade CIA.

Ce que vous allez apprendre

Les mots non-répudiation, traçabilité et imputabilité désignent des idées proches mais distinctes. Cette page les clarifie une par une. Concrètement, vous saurez :

• Distinguer la traçabilité (enregistrer les actions) de la non-répudiation (les rendre difficiles à contester).
• Placer la non-répudiation par rapport à la triade CIA, au critère Preuve de DICP et à la fonction de traçabilité du modèle AAA.
• Comprendre pourquoi un journal seul ne suffit pas et ce que la signature numérique apporte.
• Identifier les briques concrètes : journalisation horodatée, audit trail, protection des journaux contre l'altération.
• Repérer les pièges classiques, comme des journaux modifiables, des horloges mal réglées ou des comptes partagés.
• Relier ce concept au modèle de menaces SOCLE, qui décrit les attaques visant à effacer les traces.

Qu'est-ce que la non-répudiation

La non-répudiation est la propriété qui empêche l'auteur d'une action de nier l'avoir commise. Le mot vient du verbe « répudier », qui signifie renier ou désavouer. Un système non-répudiable produit une preuve si solide que la personne concernée a du mal à se défausser en disant « ce n'était pas moi » ou « je n'ai jamais autorisé ça ». La preuve tient d'elle-même, tant que les clés et les journaux n'ont pas été compromis.

La traçabilité enregistre chaque action de façon horodatée et signée. Comme un reçu signé, elle prouve l'usage de la clé de l'auteur : tant que cette clé et le journal ne sont pas compromis, il peut difficilement nier l'opération. Cette preuve relève du critère Preuve (DICP). Source · SVG

Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 % − Ajuster + Fermer

Cette solidité repose sur un mécanisme précis, la signature numérique. L'auteur signe son action avec une clé privée que lui seul détient ; n'importe qui peut vérifier la signature avec la clé publique correspondante, sans jamais pouvoir la produire. Toute modification ultérieure du contenu signé invalide la signature. C'est cette asymétrie qui fait la preuve : elle ne repose pas sur la parole d'un administrateur ni sur la bonne tenue d'un fichier, mais sur une propriété mathématique. Attention : elle prouve l'usage d'une clé, pas directement une personne (voir les pièges plus bas).

Deux notions se cachent derrière cette idée, et il faut les séparer clairement. La traçabilité consiste à enregistrer les actions : qui s'est connecté, quel fichier a été modifié, à quelle heure. C'est le fait de garder une trace. La non-répudiation va plus loin : elle rend cette trace très difficile à contester, généralement à l'aide d'une signature. Vous pouvez tracer sans obtenir la non-répudiation, par exemple si votre journal reste modifiable par n'importe qui. Tracer, c'est nécessaire ; rendre la trace difficile à contester, c'est l'étape qui fait la différence.

Un troisième mot revient souvent : l'imputabilité (parfois appelée accountability en anglais). Elle désigne la capacité à rattacher chaque action à une personne identifiée. Sans imputabilité, un journal peut dire « le fichier a été supprimé à 14h03 », mais pas par qui. La non-répudiation combine les trois : identifier l'auteur, enregistrer son acte, et rendre cet enregistrement difficile à contester.

Le lien avec la triade CIA

La triade CIA décrit ce qu'un système doit protéger : la confidentialité, l'intégrité et la disponibilité. Elle ne dit rien de qui agit ni de comment le prouver. Les praticiens comblent ce manque avec trois vocabulaires voisins, qu'il vaut mieux ne pas confondre, car aucun ne fait de la non-répudiation un quatrième pilier de la triade.

Le premier est DICP, le sigle français qui ajoute à la triade le critère Preuve (disponibilité, intégrité, confidentialité, preuve). Ce n'est pas un sigle de l'ANSSI, dont la méthode EBIOS Risk Manager parle de traçabilité comme besoin de sécurité. La non-répudiation se range dans ce critère, avec la traçabilité : la trace enregistre, la non-répudiation la rend difficile à contester. Le deuxième est le modèle AAA, où Accounting désigne la fonction qui enregistre les actions (traçabilité, ou imputabilité) : c'est un mécanisme qui fournit la preuve, pas une propriété à protéger. La leçon sur la triade CIA détaille ces deux premiers vocabulaires.

Le troisième vient des certifications. L'objectif 1.2 du programme CompTIA Security+ SY0-701 liste la non-répudiation à part, à côté de la triade CIA et de AAA : les candidats la rencontrent donc comme un concept distinct, même si la plupart des cadres français la rattachent à la preuve. Retenez que les mots changent selon la source, la démarche reste la même : savoir retrouver l'auteur et l'instant d'une action, sans pouvoir être contredit.

Le lien avec l'intégrité est particulièrement fort. Prouver qu'un fichier n'a pas été modifié (intégrité) et prouver qui l'a modifié et quand (non-répudiation) reposent souvent sur les mêmes outils, notamment la signature numérique. Un système qui garantit l'intégrité de ses journaux obtient, du même coup, une bonne partie de sa non-répudiation.

Comment l'obtenir

Rendre un système non-répudiable ne tient pas à un seul outil magique. C'est l'assemblage de plusieurs briques qui, ensemble, transforment une simple activité en preuve difficile à contester. Voici les principales.

La première brique est la journalisation horodatée. Un journal (souvent appelé log) est un fichier où le système inscrit chaque événement important : une connexion, une suppression, un changement de configuration. Horodater, c'est associer à chaque événement la date et l'heure précises où il s'est produit. Sans horodatage, impossible de reconstituer un enchaînement. L'ensemble de ces journaux forme une piste d'audit (ou audit trail en anglais), c'est-à-dire la trace complète et ordonnée de tout ce qui s'est passé sur le système.

La deuxième brique est la signature numérique, dont le principe (clé privée pour signer, clé publique pour vérifier) vient d'être décrit. Elle s'applique à ce qu'on veut rendre difficile à contester : un journal, une action sensible, une version publiée d'un logiciel. Elle prouve l'origine de la donnée, et si le contenu change d'un seul caractère, la vérification échoue. C'est elle qui fait passer une trace de « enregistrée » à « difficile à contester ».

La troisième brique est la protection des journaux contre l'altération. Un journal qui peut être réécrit ne prouve rien : un attaquant effacerait simplement les traces de son passage. Deux techniques répondent à ce risque. Le mode append-only (« ajout uniquement ») autorise à écrire de nouvelles lignes dans le journal, mais interdit de modifier ou supprimer les lignes déjà présentes. La centralisation des journaux consiste à les envoyer, au fil de l'eau, vers un serveur séparé que l'auteur d'une attaque ne contrôle pas : même s'il efface le journal local, la copie centrale subsiste.

Trois questions à réflexe

Face à une action sensible, posez-vous ces trois questions : est-elle enregistrée quelque part (traçabilité) ? Sait-on qui l'a menée (imputabilité) ? Cette preuve résiste-t-elle à une tentative de trafiquer les journaux (non-répudiation) ? Si une réponse manque, vous tenez votre point faible.

Un scénario concret

Prenons une équipe qui gère l'infrastructure d'une boutique en ligne. Un matin, une configuration critique a changé pendant la nuit et le site est tombé. La question fuse aussitôt : qui a modifié ce fichier, et quand ?

Sans traçabilité, l'enquête tourne court. Personne ne se souvient, les accès ne sont pas enregistrés, et chacun peut nier de bonne foi. Avec une piste d'audit correctement tenue, le résultat est tout autre : le journal centralisé montre qu'à 2h47, un compte précis s'est connecté et a modifié le fichier. L'action est imputée à une personne, horodatée, et très difficile à effacer puisque le journal réside sur un serveur séparé en mode append-only. L'équipe ne cherche plus un coupable, elle lit une preuve.

La non-répudiation joue aussi un rôle central dans la chaîne logicielle. Quand une équipe publie une nouvelle version d'un logiciel, on parle d'une release. Une release signée porte la signature numérique de son auteur : quiconque l'installe peut vérifier qu'elle vient bien de l'éditeur officiel et qu'elle n'a pas été trafiquée en cours de route. Sans la clé privée de l'éditeur, personne ne peut se faire passer pour lui ; et l'éditeur ne peut guère nier avoir publié une version signée de sa clé, tant que celle-ci n'a pas été compromise. C'est ce que permettent des outils de signature comme Sigstore, et des cadres d'attestation comme in-toto, qui prouvent l'origine de chaque étape de fabrication.

Pièges courants

La non-répudiation est facile à énoncer, mais quelques erreurs récurrentes la vident de sa substance. Les connaître évite de croire son système à l'épreuve d'un déni alors qu'il ne l'est pas.

Le piège le plus fréquent est de conserver des journaux modifiables. Un journal stocké sur la même machine que le service surveillé, sans protection, peut être réécrit par la personne même qui a fait la bêtise, ou par un attaquant qui efface ses traces. Une trace effaçable ne prouve rien. Le mode append-only et la centralisation sur un serveur distinct sont la parade.

Le deuxième piège concerne les horloges non synchronisées. Si chaque machine affiche une heure légèrement différente, corréler des événements devient un casse-tête, et un horodatage faux peut disculper à tort ou accuser à tort. La bonne pratique est de synchroniser toutes les horloges sur une même référence de temps, afin que « 2h47 » signifie la même chose partout.

Le troisième piège est de ne jamais vérifier les signatures. Signer une release ou un journal ne sert à rien si personne ne contrôle la signature au moment de l'utiliser. Une signature non vérifiée offre une fausse assurance : elle donne l'impression d'une preuve, sans en apporter aucune. La vérification doit être une étape systématique, idéalement automatisée.

Le quatrième piège est d'oublier l'imputabilité. Des comptes partagés (« le compte admin » utilisé par cinq personnes) rendent impossible de rattacher une action à un individu. Le journal dira « admin a supprimé la base », sans jamais permettre de savoir lequel des cinq. Un compte par personne est la condition de base pour que la non-répudiation ait un sens.

Le dernier piège est de croire que la signature prouve la personne et non la clé. Si une clé privée est volée ou prêtée, une signature valide ne désigne plus son propriétaire. La preuve vaut donc ce que vaut la protection de la clé : stockée à l'abri, jamais partagée, et révoquée dès qu'un doute apparaît.

À retenir

1. Non-répudiation = preuve difficile à contester. L'auteur d'une action ne peut guère nier l'avoir commise, tant que les clés et les journaux qui portent la preuve restent protégés.

2. Traçabilité et non-répudiation diffèrent. Enregistrer une action ne suffit pas, il faut aussi rendre cet enregistrement difficile à contester.

3. Elle relève du critère Preuve. Dans DICP, la non-répudiation et la traçabilité se rangent dans la Preuve ; dans AAA, l'Accounting fournit la trace.

4. L'imputabilité identifie l'auteur. Rattacher chaque action à une personne exige un compte par personne, jamais de compte partagé.

5. Trois briques se combinent. La journalisation horodatée, la signature numérique et la protection des journaux contre l'altération.

6. Des journaux modifiables ne prouvent rien. Le mode append-only et la centralisation sur un serveur séparé sont indispensables.

7. Une signature vaut ce que vaut sa clé. Une clé privée volée ou partagée ruine la preuve ; il faut la protéger et la révoquer au moindre doute.

8. Passez du modèle aux menaces réelles. Le modèle de menaces SOCLE montre, domaine par domaine, quelles attaques cherchent à effacer les traces.

Contrôle de connaissances

Six questions tirées sur huit : la différence entre traçabilité et non-répudiation, la signature numérique, la protection des journaux et les limites d'une preuve.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

×

📖 Voir la documentation →