Que restaure-t-on après le vol d'un identifiant ?

Remarquez à quel point votre réponse est assurée pour presque tout le reste. Un disque tombe en panne, vous restaurez depuis la sauvegarde. Un rançongiciel frappe, vous basculez sur la réplique. Toute la discipline de la reprise après sinastre existe pour rendre la panne surmontable, et pour les données, cela fonctionne — RAID n'est pas une sauvegarde, donc vous conservez une sauvegarde, et vous êtes couvert dans les deux cas.

Puis vous en arrivez à l'identifiant, et trente ans de cet arsenal n'ont rien à vous proposer. Il n'existe pas de copie propre de la confiance à restaurer. Une fois qu'une clé est emportée, vous ne revenez pas en arrière sur la compromission — vous révoquez, vous réémettez, et vous reconstruisez le tissu de confiance à partir de zéro. Et pendant que vous faites cela, tout ce qui s'authentifie via ces identifiants est à l'arrêt avec eux : la paie, les déploiements, les bases de données auxquelles vos propres applications accèdent, les agents que vous avez mis un an à déployer.<br>L'activité ne ralentit pas — elle s'arrête. Vous pouvez sauvegarder des données. Vous ne pouvez pas sauvegarder la confiance. La réponse honnête à la question posée au départ est donc celle qui dérange : rien. On ne se sort pas d'une telle situation en restaurant.

Ce qui s'est réellement passé

2026 rend cette distinction coûteuse. Une nouvelle famille d'attaques Linux — Copy Fail, DirtyClone, pedit COW — s'installe sur une machine sans modifier le moindre fichier sur le disque. Elle empoisonne la copie d'un binaire système de confiance qui réside en mémoire dans le noyau, et exécute celle-ci. Le fichier sur le disque n'est jamais touché : votre moniteur d'intégrité en calcule l'empreinte, la trouve identique à celle d'hier, et affiche vert ; votre antivirus analyse le disque et n'y trouve rien d'anormal, parce que rien sur le disque n' est anormal. L'attaquant dispose d'un shell root alors que chaque instrument dont vous disposez certifie que la machine est saine — et un redémarrage efface les preuves, puisqu'elles n'ont jamais existé qu'en mémoire.

Vos outils ne sont pas défaillants. Ils surveillent les octets au repos sur le disque, ce qui était le bon endroit à surveiller pendant vingt ans, à l'époque où modifier le comportement d'un programme signifiait modifier son fichier. C'est le terrain qui a bougé sous l'hypothèse, pas l'outil. Gardez-les — mais soyez clairs sur ce qu'ils sont : un mur, jugé sur sa capacité à tenir.

La question que nous évitons

Depuis trente ans, nous évaluons la sécurité sur une seule chose : les avez-vous tenus à l'écart ? Pare-feu, EDR, moniteur d'intégrité — tout cela relève de la prévention, et la prévention est une question légitime. C'est simplement une question sur laquelle on ne peut plus miser une entreprise, parce que lorsqu'une intrusion peut être invisible, ne laisser aucune trace et survivre à vos meilleurs outils qui signalent que tout est propre, « les tenir à l'écart » cesse d'être une stratégie pour devenir un espoir.

La question que nous évitons est celle qui détermine à quel point la journée est réellement mauvaise : lorsqu'ils entrent — et ils entreront — que peuvent-ils emporter ? Et quoi que ce soit, la première règle est celle que le stockage nous a enseignée : vous ne pouvez pas en faire une sauvegarde. Vous ne récupérez pas la confiance.

Conçu pour cela, délibérément

La démarche n'a donc jamais été de trouver une sauvegarde pour vos identifiants. Il n'en existe pas — c'est tout l'enjeu. La démarche consiste à faire en sorte que, lorsque le mur tombe, il n'y ait derrière lui rien qui vaille la peine d'emporter.

Un identifiant émis à la manière de Clavitor ne se trouve jamais au repos sur la machine que l'attaquant vient de passer en root. Il est lié à cette machine unique : une copie récupérée ailleurs ne vaut rien. Il est limité à une seule tâche et il expire, si bien que même root — même un root invisible et sans trace — n'obtient qu'un jeton de courte durée pour une tâche, et non les clés de l'ensemble. Et le journal de ce qu'il a touché vit en dehors de la machine, dans le coffre, sous forme de chaînage par hachage, là où quelqu'un qui possède la machine ne peut pas réécrire discrètement l'historique. L'intrusion réussit toujours. Le braquage ne ramène rien, et le seul journal auquel ils n'ont pas accès a déjà consigné ce qui s'est passé.

Rien de tout cela ne vous rend inviolable, et quiconque vend cela vous ment. Cela rend la compromission surmontable — cela retire de la table le seul scénario dont vous ne pouvez pas revenir, la confiance que vous ne pouvez pas restaurer. Collez vous-même une clé principale de longue durée dans un fichier sur cette machine, et root le lira ; rien ne vous protège si vous remettez en place précisément la chose que ce dispositif existe pour supprimer. Une sauvegarde n'empêche pas non plus le rançongiciel. Elle signifie seulement que le rançongiciel ne vous met pas fin.

La leçon n'est pas « acheter un mur plus solide »

Alors peut-être que l'examen de sécurité ne devrait pas s'ouvrir sur la question que nous posons depuis trente ans. Pas « est-ce sécurisé » — tout le monde répond oui, et tout le monde finit par avoir tort. Posez celle que le stockage a déjà appris à poser : lorsque cela échoue, est-ce grave ? Vous y avez répondu pour vos données le jour où vous avez compris que RAID ne suffisait pas et avez conservé une sauvegarde. Vos identifiants, eux, n'auront pas de sauvegarde. Il ne reste donc qu'une réponse : faire en sorte qu'il n'y ait rien à perdre.

Nous avons consigné les règles qu'un outil de gestion d'identifiants doit respecter pour le jour où le mur tombera.

Clavitor (@clavitorai) est le coffre d'identifiants conçu pour les agents d'IA, et contre eux. clavitor.ai

Sources

[1] Unit 42 (@Unit42_Intel) — Copy Fail (CVE-2026-31431) : ce qu'il faut savoir. Une écriture dans le cache de pages corrompt la copie en mémoire d'un binaire privilégié tel que /usr/bin/su sans toucher au fichier sur le disque ; touche presque toutes les distributions, noyaux 2017 et ultérieurs.

[2] The Hacker News (@TheHackersNews) — La nouvelle faille Linux pedit COW permet d'obtenir les droits root en empoisonnant les binaires en cache (CVE-2026-46331). Elle empoisonne le /bin/su mis en cache ; les contrôles d'intégrité des fichiers reviennent propres.

[3] The Hacker News (@TheHackersNews) — La nouvelle faille du noyau Linux DirtyClone permet à un utilisateur local d'obtenir les droits root via des paquets clonés (CVE-2026-43503). La modification n'existe qu'en mémoire ; aucune trace d'audit, et un redémarrage restaure le binaire d'origine.