Robots logiciels et sécurité : comptes, secrets, traces
Un robot logiciel travaille vite, sans relâche, avec les droits qu'on lui a donnés. Mal encadré, il devient le compte le plus puissant et le moins surveillé du système d'information. Trois sujets à régler avant de multiplier les automatisations.
L’erreur la plus fréquente ne se voit pas dans les démonstrations : le robot tourne sous le compte de la personne qui l’a créé. Il hérite de ses droits, de son mot de passe enregistré dans un fichier de configuration, et ses actions se confondent avec les siennes dans les journaux. Le jour où cette personne change de poste, l’automatisation s’arrête, ou continue sous un compte qui aurait dû être fermé. Entre automatisation et sécurité, le lien tient en trois mots : comptes, secrets, traces. Ce guide les prend dans l’ordre.
Pourquoi les robots changent l’équation
Un robot logiciel, qu’il automatise une interface comme le font les outils de RPA, qu’il enchaîne des appels d’interfaces de programmation ou qu’il s’agisse d’un agent fondé sur un modèle de langage, a trois caractéristiques qui en font un sujet de sécurité à part entière. Il agit vite et en volume : une erreur de droits se répète des milliers de fois avant d’être remarquée. Il traverse plusieurs applications, donc concentre des accès qu’aucune personne n’a d’habitude en même temps. Et personne ne le regarde travailler : ses anomalies ne se voient que si on les cherche.
Pour une organisation soumise à la directive NIS 2, la gestion des accès et l’hygiène informatique font partie des mesures attendues. Les robots n’y échappent pas : ce sont des identités du système d’information, au même titre que les personnes.
Les comptes : une identité par robot, des droits au plus juste
Chaque robot a son propre compte, identifié comme tel (une convention de nommage suffit à le reconnaître dans l’annuaire), rattaché à un responsable humain et à une description de sa fonction. Ses droits se limitent à ce que son processus exige : lecture seule là où il ne fait que consulter, écriture limitée aux dossiers ou aux tables qu’il modifie, aucun droit d’administration sauf nécessité démontrée.
Deux règles complètent la première. Un robot n’ouvre pas de session interactive avec les droits d’un administrateur pour « simplifier » son travail. Et un compte de robot ne sert qu’à un robot : la tentation de réutiliser un compte existant pour une nouvelle automatisation, parce qu’il « a déjà les bons accès », est la manière la plus sûre de perdre le contrôle de qui fait quoi.
Les comptes techniques ne se prêtent pas toujours à l’authentification multifacteur conçue pour les personnes. On compense : authentification par certificat ou par jeton à durée de vie courte, restriction des machines, des adresses et des horaires d’où le compte peut se connecter, alerte sur toute connexion hors de ce cadre.
Les secrets : dans un coffre, jamais dans un script
Mots de passe, clés d’interfaces de programmation, certificats : un robot en manipule souvent plusieurs. On les retrouve, dans les automatisations construites vite, en clair dans un fichier de configuration, un script, une feuille de calcul de paramètres ou l’historique d’un outil de gestion de versions. Les recommandations de l’OWASP sur la gestion des secrets résument la règle : un secret est stocké dans un coffre dédié, distribué au moment de l’exécution, renouvelé régulièrement, et jamais écrit dans le code.
| Pratique risquée | Conséquence | Mesure |
|---|---|---|
| Mot de passe dans un fichier de configuration | Lisible par quiconque accède au serveur ou à une sauvegarde | Coffre de secrets, lecture à l’exécution |
| Clé d’API dans le code source | Exposée dans l’historique des versions, même après suppression | Coffre de secrets, analyse automatique des dépôts |
| Secret jamais renouvelé | Une fuite ancienne reste exploitable | Rotation planifiée, durée de vie courte |
| Même secret pour plusieurs robots | Impossible de savoir lequel a fuité ou agi | Un secret par robot et par système |
| Secrets transmis par messagerie | Copies incontrôlées | Accès au coffre par rôle, jamais de transmission en clair |
Les plateformes d’automatisation du marché intègrent souvent un coffre ou savent se raccorder à celui de l’organisation. Ce raccordement est à exiger dès le cahier des charges.
Les traces : savoir ce qu’a fait le robot, longtemps après
Un robot doit pouvoir rendre compte de son travail. Ses journaux enregistrent, pour chaque exécution, le début et la fin, les systèmes consultés et modifiés, les volumes traités, les erreurs, les interventions humaines et la version du processus exécutée. Ils sont centralisés avec les autres journaux de sécurité, protégés contre la modification, et conservés selon une durée définie.
Choisissez une opération réalisée par un robot il y a trois mois, une écriture dans une base ou un document créé, et essayez de répondre : quel robot l’a faite, à quelle exécution, sur quelle donnée d’entrée, avec quelle version de son processus ? Si la réponse demande plus d’une heure, les traces sont insuffisantes.
Pour les agents fondés sur un modèle de langage, la trace s’étend aux instructions reçues, aux outils appelés et aux validations humaines obtenues pour les actions sensibles. Un agent qui décide lui-même d’une partie de ses actions demande une traçabilité plus fine qu’un robot qui exécute un scénario fixe.
Le cycle de vie d’un robot
Les robots s’accumulent. Celui qui a été créé pour une campagne ponctuelle tourne encore deux ans plus tard, avec ses droits intacts, sans que personne ne sache s’il sert à quelque chose. Un inventaire tenu à jour, avec pour chaque robot son responsable, sa fonction, ses comptes, ses secrets et sa date de dernière revue, permet de réviser les droits périodiquement et d’arrêter proprement ceux qui ne servent plus : désactivation du compte, révocation des secrets, archivage des journaux.
- Chaque robot a son propre compte, identifiable comme tel et rattaché à un responsable.
- Ses droits sont limités à son processus et revus au moins une fois par an.
- Aucun secret n’apparaît en clair dans un script, un fichier ou un dépôt de code.
- Les secrets sont propres à chaque robot et renouvelés selon un calendrier.
- Les journaux sont centralisés, protégés et permettent de reconstituer une exécution.
- L’inventaire des robots est à jour, avec une procédure d’arrêt documentée.
Ces règles se posent mieux avant le dixième robot qu’après le centième. Le dossier sur l’automatisation des processus aide à choisir entre RPA, interfaces de programmation et agents ; notre produit Gouvernance traite les identités des agents logiciels et le journal de leurs actions, et notre expertise automatisation des processus intègre ces exigences dès la conception.
- ANSSI, Guide d’hygiène informatique.
- OWASP, Secrets Management Cheat Sheet.
- NIST, Special Publication 800-53 Rev. 5, familles de mesures « Access Control » et « Audit and Accountability ».
Questions fréquentes
Un robot logiciel peut-il utiliser le compte de l'agent qui l'a créé ?
Il ne le devrait pas. Le compte d'une personne porte ses droits, souvent plus larges que ce dont le robot a besoin, et ses actions deviennent impossibles à distinguer de celles de la personne. Si celle-ci quitte l'organisation, le robot cesse de fonctionner ou, pire, continue avec un compte qui aurait dû être fermé. Chaque robot a son propre compte, nominatif pour le robot et non pour une personne.
Comment un robot peut-il franchir une authentification multifacteur ?
Les comptes techniques ne se prêtent pas toujours à l'authentification multifacteur conçue pour les personnes. On compense par d'autres mesures : authentification par certificat ou par jeton à durée de vie courte, restriction des adresses et des horaires de connexion, droits strictement limités et surveillance renforcée. Désactiver l'authentification forte sans compensation est à proscrire.
Que faut-il journaliser pour un robot ?
Au minimum : le début et la fin de chaque exécution, les systèmes consultés et modifiés, les données traitées en volume, les erreurs et les interventions humaines. Les journaux doivent permettre de répondre, longtemps après, à la question « qu'a fait ce robot tel jour, et sur quelle instruction ? ».
Les mêmes règles s'appliquent-elles aux agents d'IA ?
Oui, et avec plus d'exigence encore. Un agent d'IA décide lui-même d'une partie de ses actions : ses droits doivent être bornés, ses actions sensibles soumises à validation humaine, et sa trace doit inclure les instructions reçues et les outils utilisés.