Une capacité n’est pas une autorisation

La plupart des incidents de sécurité ne viennent pas d’un système qui ne pouvait pas faire quelque chose. Ils viennent d’un système qui le pouvait, et l’a fait, sans que personne n’ait décidé qu’il le devait. La leçon est ancienne, et elle a un énoncé compact : une capacité technique n’est jamais une autorisation.

Les deux choses que l’on confond

« Cela peut-il s’exécuter ? » et « Cela doit-il s’exécuter ? » sont deux questions distinctes, avec des responsables distincts. La première est un fait sur le logiciel. La seconde est une décision qui appartient à une personne ou à une politique. Lorsqu’une conception laisse la première réponse tenir lieu de la seconde, elle a discrètement remis l’autorité à ce qui se trouve capable d’agir — un modèle, un agent, un résultat importé, un plugin.

Une porte, pas une case à cocher

Séparer les deux signifie que toute action conséquente doit passer une chaîne explicite de contrôles avant de s’exécuter : une identité authentifiée, la permission exacte pour l’action, un droit d’usage signé valide, une portée autorisée, une classification de risque, l’approbation humaine que ce risque exige, et le contrôle de la destination réseau. La chaîne est conjonctive — tout doit passer — et fail-closed — un contrôle manquant ou illisible est un refus, non une autorisation par défaut.

Pourquoi le fail-closed est l’essentiel

Une porte qui échoue en position ouverte n’est pas une porte ; c’est un ralentisseur. La valeur de la conception réside précisément dans ce qu’elle refuse lorsqu’une chose est ambiguë. Une action dont le risque ne peut être classé est traitée comme à risque élevé et refusée. Un constat dont la preuve ne peut être re-vérifiée reste une piste. L’honnêteté du système vit dans les cas où il refuse d’avancer.