Une identité pour les personnes et les agents : qui peut quoi

Un jeudi après-midi, le compte bancaire d’un fournisseur change dans les données de référence. Le règlement du vendredi utilise le nouveau compte. Le mardi suivant, le fournisseur appelle pour demander où est l’argent, et l’équipe finance ouvre le journal d’audit pour voir qui a fait la modification.

Le journal dit : INTEGRATION_SVC. Ce compte appartient au middleware. Par lui passent la synchronisation de la boutique en ligne, le connecteur de l’entrepôt, un script de nettoyage planifié et, depuis le printemps, deux agents qui mettent à jour les données de référence quand un document confirmé le demande. Six processus, un nom, un mot de passe stocké à trois endroits. La modification a été faite par l’un d’eux, pour le compte de quelqu’un, pour une raison, et l’enregistrement ne peut dire ni lequel, ni pour qui, ni pourquoi.

Ce n’est pas une faille de sécurité. Chaque processus a fait ce pour quoi il était configuré. C’est un problème d’identité : l’entreprise a donné à ses logiciels un seul visage commun, et on ne peut pas interroger un visage commun. Dès que les agents se mettent à agir, le nombre d’actions prises par ce visage se multiplie, et chacune d’elles est anonyme par construction.

Ce qu’un compte de service partagé cache

L’acteur. Six processus derrière un seul nom : le journal consigne que quelque chose s’est produit, pas ce qui l’a fait. L’erreur d’une personne, le bug d’un script et la mauvaise appréciation d’un agent se ressemblent trait pour trait, et se corrigent de la même manière : lentement.

Le mandant. Un agent qui met à jour un fournisseur le fait parce que le rôle d’une personne l’a demandé ou parce qu’un processus l’a permis. Le compte de service ne garde aucune trace de cette chaîne, donc la question « pour qui cela a-t-il été fait » n’a pas de réponse non plus.

Le périmètre. Un compte de service accumule des droits. Chaque intégration avait besoin d’une table de plus, d’un point d’accès de plus, et personne n’a retiré ceux qui ne servent plus. L’agent ajouté l’an dernier en a hérité tous, y compris le droit de modifier un compte bancaire dont il n’a jamais eu besoin.

Le temps. Le compte est valide depuis sa création. L’accès d’une personne s’arrête quand elle part ; une tâche déléguée s’arrête quand elle est finie. Le compte partagé ne s’arrête jamais, et un identifiant fuité une fois est un identifiant fuité pour de bon.

La frontière entre lecture et écriture. Le compte qui lit les commandes pour un rapport est le même que celui qui écrit un fichier de paiement. Un script compromis, un prompt mal configuré, et le chemin de lecture devient un chemin d’écriture. Pourquoi l’écriture est la moitié dangereuse est développé dans un agent qui écrit dans l’ERP.

Des permissions attachées aux tables. Les rôles de base de données donnent accès à une table, pas à un client. Un agent autorisé à lire la table des commandes lit toutes les commandes, y compris celles du groupe de clients que son rôle ne devrait jamais voir. L’écran les masquait ; l’agent ne passe pas par l’écran.

À quoi doit ressembler l’identité d’un agent

Son propre nom. Chaque agent est un principal dans l’annuaire, comme une personne et à la différence d’un mot de passe dans un fichier de configuration. Le journal nomme alors l’agent, et un changement contesté peut être rattaché à un processus plutôt qu’à un lot de six.

Déléguée par une personne ou un rôle. Un agent n’a pas de droits propres ; il agit pour quelqu’un. L’agent achats agit sous le rôle achats, dans les limites de ce que ce rôle peut faire, et l’enregistrement montre l’agent et le rôle ensemble. Si la personne derrière le rôle part, la délégation s’arrête avec elle.

Des périmètres qui expirent. Une délégation vaut pour une tâche, un domaine et une période. Lire les factures ouvertes pendant les trente prochains jours est un périmètre ; tout lire pour toujours est un compte de service sous un autre nom. Quand le périmètre expire, l’agent redemande, et la demande est consignée.

Des permissions sur les objets métier, pas sur les tables. C’est ici que l’ontologie gagne sa place. Le modèle définit un client, une commande, un fournisseur, un compte bancaire, et les actions qui existent sur chacun : lire, proposer, modifier, approuver. Une permission dit alors que l’agent de service peut lire les réclamations des clients d’une région et proposer des réponses, et non qu’il peut sélectionner dans trois tables. La même règle s’applique aux personnes, de sorte qu’une personne et un agent dans le même rôle voient exactement la même chose.

Appliquée sur le serveur, lisible par tous. La permission vit sous l’agent, dans la couche qui vérifie chaque requête, pas dans les instructions de l’agent. Un prompt ne peut pas s’octroyer un accès, et une personne qui lit le modèle voit ce que chaque agent peut faire sans lire une ligne de code.

La même réponse pour une personne et pour un agent. « Qui a fait cela, pour qui, sur quels éléments, et qui l’a approuvé » reçoit la même réponse que l’acteur soit un employé ou un processus. Si l’enregistrement sait répondre pour le personnel et pas pour les agents, les agents sont un trou dans l’audit, pas une partie de l’audit.

Un test à faire dès aujourd’hui

Ouvrez le journal d’audit de votre ERP ou de votre logiciel comptable et filtrez le dernier mois sur les comptes techniques : l’utilisateur d’intégration, l’utilisateur API, tout ce qui porte « svc », « sync » ou « system » dans son nom. Comptez les modifications. Prenez-en ensuite cinq au hasard et essayez de répondre, pour chacune, quel processus a fait la modification et pour quelle personne ou quel rôle.

Si vous ne pouvez pas répondre en quelques minutes à partir du seul enregistrement, sans interroger l’équipe informatique, chacune de ces modifications est anonyme. Listez maintenant les processus qui partagent chaque compte technique et les droits que ce compte détient. L’écart entre ce dont chaque processus a besoin et ce que le compte possède est la surface d’attaque avec laquelle vous fonctionnez depuis le début, et c’est la surface qu’un agent hériterait dès le premier jour.

Dans Hurukan, chaque requête arrive au serveur avec une identité : une personne, un agent agissant pour une personne ou un processus, ou le système lui-même. Les permissions y sont vérifiées, sur le serveur, au regard des rôles et des règles que l’ontologie définit sur les objets métier, et chaque changement est consigné avec le type de son auteur, ce qui a changé et sur quelle approbation. C’est ce qui rend un agent responsable dans la même phrase qu’un membre du personnel, et c’est la couche de base de Hurukan, décrite dans la souveraineté est un choix d’architecture.