La non-répudiation garantit que personne ne peut nier un acte qu'il a réellement commis. Quand un système sait, de façon indéniable, 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 cet enregistrement infalsifiable. Cette page définit ces notions avec des exemples du quotidien, sans aucun prérequis technique, et montre comment elles prolongent la triade CIA.
Ce que vous allez apprendre
Section intitulée « 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 indéniables).
- 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 ou des horloges mal réglées.
- Relier ce concept à la triade CIA et au modèle de menaces SOCLE, qui traduisent ces propriétés en contrôles concrets.
Qu'est-ce que la non-répudiation
Section intitulée « 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 ne peut pas se défausser en disant « ce n'était pas moi » ou « je n'ai jamais autorisé ça ». La preuve tient toute seule, même face à un déni.
L'analogie la plus parlante est celle du reçu signé. Quand vous signez un bon de livraison en recevant un colis, le transporteur détient la preuve que vous l'avez bien reçu. Vous ne pouvez plus prétendre le contraire : votre signature vous engage. Le recommandé avec accusé de réception fonctionne de la même façon : la Poste conserve la trace datée que le pli a été remis, et à qui. Ces deux mécanismes existent pour une seule raison : rendre un fait indéniable après coup.
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 impossible à 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 indéniable, 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 incontestable.
Le lien avec la triade CIA
Section intitulée « Le lien avec la triade CIA »La sécurité informatique repose historiquement sur trois propriétés que résume la triade CIA : la confidentialité (seules les bonnes personnes voient les données), l'intégrité (les données restent exactes et non falsifiées) et la disponibilité (le service répond quand on en a besoin). Ces trois piliers décrivent ce qu'un système doit protéger, mais ils ne disent rien de qui agit ni de comment le prouver.
C'est précisément le trou que comble la traçabilité. De nombreux professionnels étendent donc la triade classique en y ajoutant l'imputabilité et la non-répudiation. On parle alors de « CIA + traçabilité », ou parfois du modèle élargi qui inclut l'authenticité et la non-répudiation. L'idée reste simple : protéger les données ne suffit pas, il faut aussi pouvoir retracer et prouver chaque action menée sur ces données.
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. Les deux propriétés se renforcent mutuellement : 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
Section intitulée « 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 indéniable. 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 ce qu'on appelle 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. Une signature numérique est un procédé cryptographique qui prouve l'origine d'une donnée et garantit qu'elle n'a pas été modifiée depuis sa création. Concrètement, l'auteur appose une marque mathématique calculée avec une clé privée que lui seul détient ; n'importe qui peut ensuite vérifier cette marque avec la clé publique correspondante. Si le contenu change d'un seul caractère, la vérification échoue. C'est la signature qui fait passer une trace de « enregistrée » à « indéniable ».
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.
Un scénario concret
Section intitulée « 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 impossible à 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. Personne ne peut ni se faire passer pour l'éditeur, ni nier avoir publié une version signée de sa clé. C'est exactement 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
Section intitulée « 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 dernier 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.
À retenir
Section intitulée « À retenir »-
Non-répudiation = preuve indéniable : l'auteur d'une action ne peut plus nier l'avoir commise.
-
Traçabilité et non-répudiation diffèrent : enregistrer une action ne suffit pas, il faut aussi rendre cet enregistrement incontestable.
-
L'imputabilité identifie l'auteur : rattacher chaque action à une personne exige un compte par personne, jamais de compte partagé.
-
Trois briques combinées : journalisation horodatée, signature numérique, et protection des journaux contre l'altération.
-
La signature fait la différence : c'est elle qui transforme une trace enregistrée en preuve infalsifiable.
-
Des journaux modifiables ne prouvent rien : append-only et centralisation sur un serveur séparé sont indispensables.
-
Passez du modèle aux menaces réelles : le modèle de menaces SOCLE montre, domaine par domaine, quelles attaques cherchent à effacer les traces et quels contrôles les couvrent.