Sécuriser un système dont on ne peut pas lister les gestes
La sécurité d’un agent pose un problème que les méthodes habituelles ne traitent pas directement, et pour deux raisons cumulées. Ses entrées sont du texte que personne ne contrôle : un courriel, un document, une page qu’il lit pour faire son travail, et ce texte peut être rédigé par quelqu’un qui cherche à infléchir son comportement. Et l’espace de ses comportements ne s’énumère pas, si bien qu’aucune liste de scénarios testés ne démontre quoi que ce soit. La conséquence est qu’il faut renoncer à la question habituelle, celle de savoir ce que le système fera, et la remplacer par une autre, beaucoup plus solide : que lui est-il matériellement possible de faire avec les droits qu’on lui a donnés. Une équipe capable de répondre à cette seconde question est mieux protégée qu’une équipe qui a écrit cent scénarios d’attaque, parce que la réponse reste vraie face à une situation que personne n’avait imaginée, ce qui est la seule situation qui compte en sécurité.
Pourquoi la consigne cède
Dire à un système de ne pas faire quelque chose est un contrôle qui repose entièrement sur son interprétation. Il fonctionne dans les cas prévus, et les cas prévus ne sont pas ceux qui posent problème.
Restreindre une habilitation est un contrôle d’une autre nature. Il ne dépend d’aucune interprétation : si le jeton ne permet pas d’écrire, aucun raisonnement, aucune formulation habile et aucune situation inédite ne permettra d’écrire.
Cette différence gouverne toute la conception. Les consignes gardent leur utilité pour orienter la qualité des réponses ; elles n’ont aucune valeur comme barrière. Une équipe qui confond les deux usages croit avoir une protection alors qu’elle n’a qu’une préférence exprimée.
Séparer ce qui lit de ce qui agit
C’est la mesure la plus efficace et la moins coûteuse. Un agent qui lit du contenu non fiable ne porte pas les habilitations qui permettent d’agir. Il produit une proposition, et une étape distincte, écrite et prévisible, décide de l’exécuter ou non selon des règles que personne ne peut infléchir par du texte.
Cette séparation supprime la classe d’incidents la plus grave : celle où un contenu extérieur obtient d’un système qu’il agisse contre l’intérêt de son propriétaire. Elle ne supprime pas le risque qu’une proposition soit mauvaise, qui reste un problème de qualité et se traite par la mesure.
Son coût de conception est faible quand elle est prévue dès le départ, et élevé quand il faut la rétrofitter sur un système où les outils ont été ajoutés un par un. C’est une raison supplémentaire de traiter le premier outil qui écrit comme un moment de revue.
Les droits, aussi étroits que la tâche le permet
Chaque outil reçoit l’habilitation minimale qui permette sa fonction, et cette discipline demande d’être précise. Un accès en lecture à une base entière n’est pas la même chose qu’un accès aux dossiers d’un client donné, et la différence se voit le jour où quelque chose se passe mal.
Trois questions cadrent utilement cet exercice. Sur quels objets l’outil agit-il, et peut-on restreindre cet ensemble. Peut-il écrire, et si oui peut-on remplacer l’écriture directe par une proposition. Et que se passe-t-il si l’outil est appelé mille fois, ce qui arrive quand un agent boucle.
Cette dernière question est la plus négligée. Un outil parfaitement sûr appelé en boucle produit un incident d’un autre genre, qu’un plafond d’étapes et une limitation de débit traitent simplement.
Le contenu lu est une entrée, pas une instruction
Le réflexe de conception qui protège le mieux consiste à traiter tout ce que le système lit comme une donnée et jamais comme un ordre. Un document, un courriel, une page, un champ de formulaire : ce sont des choses à analyser, pas des choses à obéir.
Techniquement, cela se traduit par une séparation nette entre ce que l’organisation a écrit, qui oriente le comportement, et ce qui vient de l’extérieur, qui est le sujet du travail. La frontière doit être explicite dans la construction de ce qu’on envoie au modèle, et non supposée par la mise en page.
Cette discipline ne garantit rien à elle seule, et c’est précisément pourquoi elle s’accompagne des contrôles structurels décrits plus haut. Elle réduit la fréquence des incidents ; la séparation des droits réduit leur gravité. Les deux ensemble donnent un système dont on peut répondre, là où chacune prise isolément laisse une brèche connue.
Ce qu’il faut pouvoir dire après un incident
La sécurité d’un agent ne se juge pas seulement à ce qu’il empêche, mais à ce qu’on peut reconstituer quand quelque chose est arrivé. Trois éléments doivent exister avant la mise en service, parce qu’aucun ne se fabrique après.
La trace des actions : quelle action, sur quel objet, avec quels droits, à quel moment, sur la base de quelle décision. Sans elle, un incident ne se referme pas, il s’oublie.
Le moyen d’arrêter le système immédiatement, qui doit être connu de l’équipe d’exploitation et non du seul constructeur, et testé une fois avant d’en avoir besoin.
Et la liste, à jour, de ce que le système peut atteindre. C’est le document qui répond à la première question posée après un incident, et une organisation qui ne peut pas le produire passera ses premières heures à établir ce qu’elle aurait dû savoir d’avance.
