Un canal de contrôle infalsifiable : TOFU + signature asymétrique
Lorsqu'un système peut envoyer des commandes aux machines des clients, la question la plus importante est : qui est réellement autorisé à les envoyer ? La réponse intuitive — « un mot de passe interne secret » — est plus faible qu'il n'y paraît. Voici pourquoi nous avons choisi quelque chose de plus solide.
L'idée intuitive : un secret partagé
L'idée évidente : il existe un « mot de passe interne » que seul le système connaît, et chaque commande est vérifiée contre lui. Si quelque chose d'étranger tentait d'injecter une commande — il ne connaît pas le secret, donc il échoue. Cela paraît raisonnable.
Mais il y a ici une faiblesse : pour vérifier une commande, le secret doit être présent au point de vérification. Si notre cloud ou la machine est compromis — le secret est lisible, et l'attaquant forge des commandes à volonté. Un secret partagé (même à rotation) se brise à l'instant où quelqu'un le voit.
Ce que nous avons choisi : la signature asymétrique
Au lieu d'un secret partagé, nous avons utilisé une paire de clés asymétriques. L'opérateur possède une clé privée qui ne le quitte jamais, et chaque commande est signée avec elle. L'agent sur la machine ne détient que la clé publique — qui peut vérifier une signature, mais ne peut en forger une.
La différence est fondamentale : une compromission totale à la fois de notre cloud et de la machine du client ne peut forger une commande, car la clé privée n'est tout simplement présente à aucun de ces endroits. Notre cloud ne fait que relayer la commande signée — il ne vérifie ni n'exécute quoi que ce soit.
Deuxième durcissement : TOFU — l'épinglage de clé
Mais que se passe-t-il si un attaquant qui a compromis notre cloud remplace la clé publique par la sienne ? Il pourrait alors signer lui-même. Pour fermer cette porte, nous avons ajouté TOFU (Trust On First Use) : l'agent épingle la clé de l'opérateur une seule fois, lors du premier enrôlement. À chaque vérification ultérieure, il confirme que la clé présentée par le cloud est identique à celle épinglée — et sinon, il refuse.
Faire tourner la clé est donc une action délibérée hors bande, et non un écrasement silencieux depuis le cloud. Un attaquant ayant pris le contrôle de notre cloud ne peut remplacer la clé épinglée — l'agent n'acceptera tout simplement pas le remplacement.
Troisième durcissement : pas de shell libre
Même si une signature valide était d'une manière ou d'une autre produite, nous voulions borner les dégâts possibles. Les actions sont donc une liste d'autorisation finie et paramétrique (comme redémarrer ou relancer un service) — et il n'y a aucune action « exécuter une commande arbitraire ». Nous avons délibérément supprimé tout chemin qui passe une chaîne à un shell. Même une signature valide n'atteint jamais un shell root.
Comment nous avons testé
Nous avons vérifié le modèle dans le comportement, et pas seulement en théorie : nous avons simulé le scénario où le cloud présente une clé différente de celle épinglée, et confirmé que l'agent refuse effectivement (rc=2) et n'exécute rien. Ce motif — épingler → vérifier → refuser — est le cœur de notre résilience face à la chaîne d'approvisionnement.
Comment nous continuons de l'améliorer — un contrôle qualité continu
La confiance n'est pas « configurer et oublier ». Chaque commande est écrite dans un journal d'audit immuable (qui, quand, quoi, quelle signature), de sorte que toute action peut être reconstituée après coup. Les prochaines étapes déjà prévues : l'anti-rejeu (nonce + horodatage dans la forme canonique, pour qu'une ancienne commande ne puisse être rejouée), un jeton par serveur au lieu d'un jeton partagé, et un « coupe-circuit » au niveau du client. Nous nous attaquons aussi nous-mêmes (purple-team autorisée) pour prouver que les défenses tiennent vraiment. Cette couche ne cesse de se renforcer.
Cet article décrit le modèle de confiance au niveau des principes — et c'est en réalité une force que de le publier, car savoir comment fonctionne la défense n'aide pas un attaquant (la clé privée n'est pas exposée). Il n'y a ici ni clés, ni secrets, ni détails d'implémentation sensibles.
← Tous les billets