Les comptes de service oubliés

Éditorial

Les identités non humaines (comptes de service, jetons d'API, clés de déploiement, identités de charge de travail) sont plus nombreuses que les personnes et n'ont souvent aucun propriétaire. Tant qu'on les gère comme des mots de passe qu'on aurait prêtés à une machine, on accumule des accès éternels ; il faut leur donner un cycle de vie, et préférer des identités fédérées de courte durée à des secrets qui ne meurent jamais.

Mis à jour le 25 septembre 2026~23 min de lecture13 sections

papy cyber

→ Lire l’explication complète de la marmotte

La population invisible

Tout système d’information abrite deux peuples. Le premier est bruyant, il a un visage, une date d’embauche, un responsable, un badge, un pot de départ. On le recense, on le forme, on le sensibilise, on lui fait signer des chartes qu’il ne lit pas. Le second est silencieux. Il n’a ni visage ni date de naissance connue, il travaille la nuit, ne prend jamais de congés, ne demande pas d’augmentation, et personne ne lui a jamais fait signer quoi que ce soit. Il s’appelle svc_backup, deploy-prod, api-integration-2019, test-jenkins-NE-PAS-SUPPRIMER. Il est plus nombreux que le premier. Souvent de beaucoup.

On dit « identités non humaines », expression qui a la froideur administrative d’un recensement de bétail et qui, pour une fois, est exacte. Elle regroupe les comptes de service des annuaires, les comptes techniques des bases de données, les jetons d’API des services en ligne, les clés d’accès des fournisseurs de nuage, les clés SSH de déploiement, les jetons des chaînes d’intégration continue, les certificats des services, et désormais les identités des agents logiciels qui lisent, écrivent et exécutent à notre place. Les éditeurs de solutions spécialisées publient volontiers des ratios spectaculaires entre ce peuple et le nôtre ; je ne les reprendrai pas, faute d’en connaître la méthode. Il suffit de faire le compte chez soi pour que l’ordre de grandeur se passe de commentaire.

Ce qui caractérise ce peuple n’est pas son nombre, c’est son statut orphelin. Un compte humain a un propriétaire évident : la personne qui l’utilise. Quand elle part, un processus (imparfait, mais existant) désactive son compte. Un compte de service a été créé par quelqu’un, pour un projet, à une date donnée. Le quelqu’un a changé de poste, le projet a été abandonné ou absorbé, la date a été oubliée. Le compte, lui, fonctionne toujours. Il ne sait pas qu’il est orphelin, et c’est bien là le drame : il n’y a personne pour s’apercevoir qu’il ne sert plus, et personne pour s’apercevoir qu’il sert à quelqu’un d’autre.

La thèse de cet éditorial tient en une phrase : tant qu’on fabrique des identités de machine comme on fabriquait des mots de passe pour les humains dans les années quatre-vingt-dix, on accumule des accès éternels, et l’inventaire ne suffira jamais à les rattraper. Il faut inverser la logique et fabriquer des identités qui meurent d’elles-mêmes.

Comment naît un compte de service

Il est instructif d’assister à la naissance d’un compte de service, à la manière d’un documentaire animalier : avec respect, sans intervenir, en chuchotant.

Un mardi, une équipe doit faire parler une application à une base de données. Il faut une identité. On en crée une, on lui donne un nom qui paraît clair sur le moment, on lui génère un mot de passe ou une clé, on le colle dans un fichier de configuration ou une variable d’environnement, et on lui accorde des droits. Quels droits ? Ceux qui permettent que ça marche. Comme on est mardi et que la mise en production est jeudi, on n’a pas le temps d’identifier le strict nécessaire ; on accorde un peu plus, « temporairement », mot qui, dans un système d’information, est le synonyme poli de « pour toujours ».

Le compte fonctionne. On passe à autre chose. Personne n’a noté qui en est responsable, puisque c’est évident : c’est l’équipe. Personne n’a noté quand il doit expirer, puisqu’il ne doit pas expirer : la production en dépend. Personne n’a noté où est stocké le secret, puisqu’on sait où il est : dans le fichier. Trois évidences qui, dans dix-huit mois, seront trois énigmes.

Plus tard, le secret est copié. Dans un deuxième environnement, parce qu’on a cloné le premier. Dans le poste d’un développeur, pour déboguer. Dans un ticket, pour qu’un collègue puisse reproduire. Dans un canal de discussion, parce que c’était plus rapide. Dans une sauvegarde, parce que tout va dans la sauvegarde. Dans l’historique d’un dépôt de code, parce qu’un fichier de configuration a été versionné une fois, par erreur, et qu’une erreur versionnée est une erreur éternelle. Chacune de ces copies a sa propre durée de vie, ses propres lecteurs, et aucune n’est connue de l’inventaire.

Encore plus tard, l’application est décommissionnée. On supprime les serveurs, parfois la base. On oublie le compte, parce que sa suppression n’était sur aucune liste. Il continue d’exister, avec ses droits, et avec toutes les copies de son secret. Il a survécu à la raison pour laquelle il existait, comme ces fonctionnaires d’un ministère aboli qu’on n’a jamais pensé à réaffecter.

Pourquoi on ne les supprime pas

On pourrait croire qu’un compte inutile se supprime. C’est méconnaître la psychologie de l’administrateur, et je parle en connaisseur de la mienne.

Supprimer un compte de service, c’est prendre un risque asymétrique. Si le compte ne servait à rien, sa suppression n’apporte aucun bénéfice visible : rien ne change, personne ne remercie. S’il servait à quelque chose, même rarement (un traitement de fin d’année, une synchronisation trimestrielle, un rapport que la direction financière consulte une fois par an en mars), sa suppression provoque une panne dont l’auteur est parfaitement identifiable. Le coût de l’erreur tombe sur celui qui agit ; le coût de l’inaction ne tombe sur personne, jusqu’au jour où il tombe sur tout le monde. Dans ces conditions, ne rien faire n’est pas de la paresse, c’est de la rationalité individuelle, ce qui est pire, parce que la paresse se corrige.

S’y ajoute l’ignorance des dépendances. Un compte de service est utilisé par des processus dont personne n’a la carte complète. Les journaux pourraient le dire, s’ils étaient conservés assez longtemps pour couvrir le traitement annuel, s’ils enregistraient le compte utilisé, et si quelqu’un avait le temps de les lire. Trois conditions rarement réunies.

Enfin, il y a le nom. svc_app01 ne dit rien. backup-temp ment probablement sur les deux plans. NE-PAS-SUPPRIMER impose un respect superstitieux qui survit à toutes les réorganisations : personne ne sait pourquoi il ne faut pas le supprimer, mais personne ne veut être celui qui a vérifié. Il y a là quelque chose de religieux, au sens étymologique : ce qui relie les générations d’administrateurs, c’est la crainte commune d’un compte dont aucun ne connaît la fonction.

Ce que l’attaquant y trouve

Du point de vue de l’attaquant, le compte de service oublié réunit des qualités rares, qu’aucun compte humain n’offre à la fois.

Il a des droits étendus. Accordés « pour que ça marche », jamais réduits, parfois augmentés au fil des besoins. Un compte humain voit ses droits revus, au moins en théorie, lors d’un changement de poste. Un compte de service ne change pas de poste.

Il a un secret qui ne tourne pas. Tourner le secret d’un compte de service, c’est modifier en même temps tous les endroits où il est configuré, sans en oublier un, sous peine de panne. Comme personne ne connaît la liste de ces endroits, personne ne tourne le secret. La page Exploiter les clés : rotation, KMS et secrets décrit comment tourner sans perdre la capacité de lire ; encore faut-il savoir qui lit.

Il n’a pas de second facteur. Une machine ne sort pas son téléphone. Le compte de service s’authentifie avec un secret unique, statique, qui vaut preuve complète. Tout ce que l’on a construit pour les humains (second facteur, passkeys, liaison à l’origine) ne le concerne pas.

Il n’a pas de comportement « normal » connu. Les outils de détection apprennent ce qu’est une connexion ordinaire pour un humain : ses horaires, ses lieux, ses appareils. Un compte de service qui travaille la nuit, depuis un centre de données, sans navigateur, est normal. Un attaquant qui l’utilise la nuit, depuis un centre de données, sans navigateur, l’est aussi.

Personne ne remarquera son usage. C’est la qualité suprême. Un humain dont le compte est utilisé à son insu finit parfois par s’en apercevoir : une notification, un courriel étrange, une session qu’il ne reconnaît pas. Un compte orphelin n’a personne pour s’étonner.

Les chemins par lesquels l’attaquant obtient ces secrets sont connus et prosaïques : un dépôt de code où une clé a été versionnée, un fichier de configuration lisible sur un serveur compromis, une variable d’environnement exposée par une page de diagnostic, un service de métadonnées de nuage interrogé à travers une faille de requête côté serveur (mécanisme détaillé dans la page SSRF vers IMDS et vol d’identifiants IAM). Une fois le secret en main, la persistance est d’une simplicité désarmante, et la page Détecter la persistance IAM dans AWS montre à quel point une clé d’accès dormante se réactive discrètement.

L’inventaire, travail de Sisyphe utile

La première réponse, évidente, est de faire l’inventaire. Elle est nécessaire, et elle a la particularité d’être à la fois indispensable et insuffisante, ce qui est la condition ordinaire des tâches administratives nobles.

L’inventaire doit répondre, pour chaque identité non humaine, à cinq questions. Qui en est propriétaire, au sens d’une personne ou d’une équipe nommément désignée, et non d’un service disparu ? À quoi sert-elle, en une phrase ? Quels droits a-t-elle, et sont-ils les droits nécessaires ou les droits accumulés ? Où est son secret, et combien de copies en existe-t-il ? Quand a-t-elle servi pour la dernière fois, et quand doit-elle expirer ?

La dernière question est la plus productive, parce que les plateformes y répondent souvent sans effort. Voici quelques commandes en lecture seule qui donnent un premier état, à adapter à ce que l’on exploite réellement.

# AWS : rapport d'identifiants du compte (lecture seule). Le rapport liste,
# pour chaque utilisateur IAM, l'âge et la dernière utilisation des clés d'accès.
aws iam generate-credential-report
aws iam get-credential-report --query Content --output text | base64 -d > credential-report.csv

# AWS : dernière utilisation d'une clé d'accès précise.
aws iam get-access-key-last-used --access-key-id AKIA...

# Google Cloud : comptes de service d'un projet, puis clés gérées par l'utilisateur
# (les clés exportées, celles qui peuvent traîner ailleurs).
gcloud iam service-accounts list --project MON-PROJET
gcloud iam service-accounts keys list \
  --iam-account svc@MON-PROJET.iam.gserviceaccount.com --managed-by=user

# Kubernetes : comptes de service de tous les espaces de noms, et droits effectifs
# de l'un d'eux.
kubectl get serviceaccounts --all-namespaces
kubectl auth can-i --list --as=system:serviceaccount:mon-ns:mon-compte

# GitHub : clés de déploiement d'un dépôt.
gh api repos/MON-ORG/MON-DEPOT/keys

# Active Directory : comptes dont le mot de passe n'expire jamais, avec la date
# du dernier changement et de la dernière connexion répliquée (lecture seule).
Get-ADUser -Filter 'PasswordNeverExpires -eq $true' `
  -Properties PasswordLastSet, LastLogonTimestamp, Description |
  Select-Object Name, PasswordLastSet,
    @{n='DerniereConnexion';e={[DateTime]::FromFileTime($_.LastLogonTimestamp)}},
    Description

L’inventaire a cependant un défaut structurel : il photographie une population qui se reproduit. Le jour où il est terminé, de nouveaux comptes ont été créés, par des équipes qui ne l’ont pas lu. Si l’on ne change pas la manière dont les identités naissent, l’inventaire devient un rituel annuel, dont le compte rendu dit chaque année la même chose avec des chiffres légèrement plus grands. C’est le rocher de Sisyphe, à ceci près que Sisyphe, lui, savait ce qu’il poussait.

Un cycle de vie, enfin

La deuxième réponse consiste à donner aux identités non humaines ce que les humains ont depuis longtemps : un cycle de vie. Naissance déclarée, propriétaire désigné, revue périodique, départ organisé.

À la naissance, aucune identité non humaine ne devrait être créée sans trois attributs obligatoires : un propriétaire nommé (une personne, avec une équipe en suppléance), une description de sa fonction, une date de revue ou d’expiration. Ces attributs peuvent vivre dans des étiquettes, dans la description du compte, dans un référentiel ; l’endroit importe moins que l’obligation. Une identité sans propriétaire ne naît pas. C’est simple à écrire et pénible à tenir, ce qui est la marque des règles utiles.

Pendant la vie, le propriétaire est sollicité à intervalles réguliers pour confirmer que l’identité sert encore et que ses droits sont les bons. Sans réponse, l’identité est désactivée. C’est brutal, et c’est la seule manière de renverser l’asymétrie décrite plus haut : le coût de l’inaction doit tomber sur le propriétaire, pas sur la sécurité. Les droits se réduisent à ce que les journaux montrent réellement utilisé, ce que la plupart des fournisseurs de nuage savent aujourd’hui suggérer.

Au départ du propriétaire, ses identités non humaines sont transférées explicitement à quelqu’un, ou désactivées. Le processus de départ d’un salarié qui désactive son compte personnel et oublie les douze comptes de service qu’il a créés n’est pas un processus de départ, c’est un processus d’abandon d’enfants.

À la fin du projet, les identités sont supprimées avec lui, et leurs secrets invalidés partout où ils ont été copiés, ce qui suppose de savoir où. On revient à l’inventaire, mais cette fois il se tient à jour tout seul, parce qu’il est alimenté à la naissance plutôt qu’à la chasse.

La rubrique Identités, accès et habilitations range cette gouvernance, celle des humains et celle des machines, sous le même toit. C’est la bonne intuition : un compte de service n’est pas un objet technique, c’est un acteur du système d’information, et un acteur sans responsable est un acteur hors-la-loi.

La rotation, et ses limites

La troisième réponse classique est la rotation : changer régulièrement les secrets, pour que les copies volées perdent leur valeur. C’est une bonne pratique, et je la défends. Je voudrais seulement montrer pourquoi elle ne suffit pas, et pourquoi elle est souvent une manière élégante de ne pas résoudre le problème.

La rotation a deux prérequis. Il faut savoir où le secret est utilisé, pour le changer partout en même temps ; c’est l’inventaire, qu’on n’a pas. Il faut que les consommateurs du secret puissent recharger le nouveau sans interruption ; cela suppose qu’ils le lisent dans un gestionnaire de secrets plutôt que dans un fichier figé. Un coffre à secrets centralisé, qui distribue les secrets à la demande et journalise qui les lit, remplit ce second prérequis et facilite le premier. C’est un progrès considérable, et souvent la première étape raisonnable.

Mais la rotation a une limite de principe. Elle réduit la durée de validité d’un secret volé ; elle ne change pas la nature de l’identité, qui reste un secret partagé. Entre deux rotations, le secret vaut preuve complète, où qu’il se trouve. Et chaque rotation est une opération à risque, qu’on espace d’autant plus qu’elle a déjà provoqué une panne. Une rotation annuelle, dans ces conditions, est une rotation qui laisse onze mois et demi à l’attaquant. La rotation est un remède à la chronicité du secret ; elle ne guérit pas le fait qu’il y ait un secret.

Les mécanismes de gestion automatique de mots de passe pour les comptes de service (dans les annuaires qui les proposent, par exemple les comptes de service gérés d’Active Directory) vont un cran plus loin : le secret change sans intervention humaine et n’est connu d’aucun administrateur. C’est très bien là où cela s’applique. L’étape suivante consiste à se passer du secret stocké.

Des identités qui meurent d’elles-mêmes

La réponse de fond, celle qui change la nature du problème, est de remplacer les secrets de longue durée par des identités fédérées de courte durée. L’idée est simple : au lieu de donner à la machine un secret qu’elle garde, on lui permet de prouver ce qu’elle est à un émetteur de confiance, qui lui délivre un jeton valable quelques minutes ou quelques heures. Le jeton expire de lui-même. Il n’y a rien à tourner, rien à oublier, et presque rien à voler qui vaille la peine d’être volé.

Le mécanisme repose sur une chaîne de confiance entre plateformes. Prenons le cas d’une chaîne d’intégration continue qui déploie vers un fournisseur de nuage. Autrefois, on stockait une clé d’accès longue durée dans les secrets du projet, et elle y restait des années. Aujourd’hui, les principales plateformes d’intégration continue savent émettre, pour chaque exécution, un jeton OIDC signé qui atteste : « ce travail s’exécute pour tel dépôt, telle branche, tel environnement ». Le fournisseur de nuage, configuré pour faire confiance à cet émetteur, échange ce jeton contre des identifiants temporaires, à condition que les revendications correspondent à ce qui a été autorisé. Le secret stocké a disparu. Ce qui reste, c’est une relation de confiance déclarée entre deux systèmes, et une politique qui dit précisément qui a le droit de quoi.

Le même principe s’applique ailleurs. Dans Kubernetes, les comptes de service reçoivent des jetons projetés, liés à une audience et à une durée, plutôt que des jetons permanents stockés dans des secrets ; ces jetons peuvent à leur tour être fédérés auprès d’un fournisseur de nuage. Pour les communications entre services, des cadres comme SPIFFE et son implémentation SPIRE attribuent à chaque charge de travail une identité vérifiable, attestée par la plateforme qui l’exécute, sous forme de certificats ou de jetons à courte durée de vie ; l’authentification mutuelle qui en résulte relève du mTLS. Sur les machines virtuelles de nuage, le rôle attaché à l’instance fournit des identifiants temporaires par le service de métadonnées, au lieu d’une clé déposée sur le disque.

Il faut mesurer ce que ce changement déplace, parce que, comme toujours, il déplace quelque chose.

Le risque se déplace vers la politique de confiance. Une fédération mal configurée est pire qu’une clé : si le fournisseur de nuage accepte n’importe quel jeton émis par la plateforme d’intégration continue, sans vérifier le dépôt, la branche ou l’environnement, alors n’importe quel projet de cette plateforme peut obtenir les droits prévus pour le vôtre. La précision des conditions (quel émetteur, quelle audience, quel sujet exact) devient la sécurité. Elle mérite d’être relue par quelqu’un qui n’a pas écrit la configuration, et de préférence un jour où il n’a pas de mise en production jeudi.

Le risque se déplace vers l’émetteur. Celui qui compromet la plateforme d’intégration continue, ou qui peut modifier une chaîne de construction autorisée, obtient des jetons légitimes. On n’a pas supprimé la confiance, on l’a concentrée. C’est généralement une bonne affaire, pour les raisons développées à propos des passkeys dans l’éditorial Les passkeys, et ce qui se déplace : moins de cibles, mieux défendues. Mais il faut défendre celle qui reste.

Le risque se déplace vers l’exécution. Un jeton de courte durée, volé pendant sa validité, sert pendant sa validité. Si la durée est de quelques minutes, la fenêtre est étroite ; si l’on a choisi douze heures « pour être tranquille », on a reconstitué une clé à peine plus éphémère que l’ancienne.

Malgré ces déplacements, le bilan n’est pas équilibré : il est nettement favorable. Une identité qui expire d’elle-même ne peut pas être oubliée, et c’est précisément le défaut que cet éditorial poursuit. L’oubli devient sans conséquence.

Le meilleur argument contre cet éditorial

La position adverse existe, et elle se défend bien, avec le calme de ceux qui ont une production à faire tourner.

La fédération ne couvre pas tout. Un nombre considérable d’identités non humaines vivent dans des systèmes qui ne savent rien de l’OIDC : progiciels anciens, équipements industriels, services en ligne qui n’offrent que des clés d’API statiques, bases de données qui attendent un mot de passe, partenaires externes qui livrent un fichier par un transfert authentifié par clé. Pour ces systèmes, le discours sur les identités éphémères est un luxe. On peut y mettre un coffre à secrets devant, tourner ce qui peut l’être, et c’est tout. Prétendre le contraire, c’est écrire pour les architectures des présentations de conférence plutôt que pour celles qui existent.

La complexité est un risque en soi. Une chaîne de fédération fait intervenir plusieurs systèmes, des politiques de confiance subtiles, des revendications dont la syntaxe varie d’une plateforme à l’autre. Une erreur de configuration y est plus difficile à voir qu’une clé mal rangée, et ses conséquences peuvent être plus larges. Une petite équipe qui maîtrise parfaitement la rotation de trois clés statiques est peut-être plus en sécurité qu’une équipe qui a déployé une fédération qu’elle ne comprend qu’à moitié.

Je trouve ces deux arguments justes, et ils m’obligent à préciser la thèse. La fédération n’est pas un objectif en soi ; c’est le meilleur outil pour ce qu’elle couvre, et elle couvre une part croissante des cas qui comptent : déploiements, charges de travail en nuage, communications entre services modernes. Pour le reste, le cycle de vie et le coffre à secrets restent la réponse, et ce n’est pas une réponse honteuse. Ce qui est honteux, en revanche, c’est de n’avoir ni l’un ni l’autre, et de découvrir un compte de service à l’occasion d’un incident, dans la chronologie reconstituée de l’attaquant plutôt que dans son propre inventaire.

Ce que je ne sais pas

Je ne connais pas le ratio réel entre identités humaines et non humaines. Il varie évidemment d’une organisation à l’autre, et les chiffres qui circulent proviennent pour l’essentiel d’éditeurs qui vendent la solution au problème qu’ils mesurent. Je ne dis pas qu’ils mentent ; je dis que je ne sais pas les vérifier, et que chacun peut, avec les commandes de cet éditorial, obtenir un chiffre plus pertinent que le leur : le sien.

Je ne sais pas comment gouverner les identités des agents logiciels. Les agents qui lisent des dépôts, exécutent des commandes et appellent des services pour le compte d’un humain sont une nouvelle espèce d’identité non humaine, à mi-chemin entre le compte de service et l’utilisateur. Faut-il leur donner l’identité de la personne qui les lance, une identité propre, ou une identité dérivée et restreinte ? Les pratiques ne sont pas stabilisées, et l’éditorial Ce qu’on garde se terminait déjà sur le constat que ces acteurs n’ont pas encore de nom dans nos modèles. Je n’ai pas avancé depuis, et je préfère le dire que de feindre.

Je ne sais pas si l’on peut atteindre un inventaire complet. Les copies de secrets dans l’historique des dépôts, les sauvegardes, les tickets et les postes de travail rendent l’exhaustivité illusoire. Les outils de détection de secrets aident ; ils ne garantissent rien. C’est une raison de plus pour préférer les identités qui expirent : elles rendent l’exhaustivité moins nécessaire.

Je ne sais pas quelle durée de jeton est la bonne. Quelques minutes pour un déploiement, quelques heures pour un traitement long : c’est une question d’arbitrage entre fenêtre d’exposition et robustesse aux pannes de l’émetteur, et elle dépend de chaque contexte. Toute valeur universelle serait une superstition de plus, et cet éditorial en a déjà combattu assez.

Ce qui reste

Les comptes de service oubliés ne sont pas une faute de quelqu’un. Ils sont le produit normal d’une organisation qui crée des identités plus vite qu’elle ne les gouverne, parce que la création est urgente et la gouvernance ne l’est jamais. Chaque compte a été raisonnable le jour de sa naissance ; c’est leur accumulation qui ne l’est pas.

Trois choses me paraissent tenir. Que toute identité non humaine doit avoir un propriétaire nommé et une date de fin, sans quoi elle ne naît pas, et qu’il faut faire tomber le coût de l’inaction sur ce propriétaire plutôt que sur la sécurité. Que la rotation traite la durée du secret, pas son existence, et qu’elle reste indispensable partout où l’on ne peut pas mieux faire. Et que la réponse de fond est de fabriquer des identités qui expirent d’elles-mêmes, par fédération et jetons de courte durée, en reportant l’effort de sécurité sur la politique de confiance, qui devient alors la seule chose à relire.

Il y a une forme de sagesse à accepter qu’on oubliera. Les humains oublient, les équipes changent, les projets meurent, et aucun processus n’y changera rien. La seule question est de savoir si ce que nous oublions reste ouvert derrière nous, ou se referme tout seul. On ne demande pas à un vieil homme de se souvenir de tout ; on lui demande de fermer la porte en sortant. Pour les machines, on peut faire mieux : fabriquer des portes qui se ferment seules.

🐝 Ce qui arrive si on s’en passe

Laisser prospérer les comptes de service sans propriétaire complique surtout le jour de l’incident. Quand un compte partagé par plusieurs applications apparaît dans les journaux, rien ne permet de distinguer l’action d’un traitement légitime de celle d’un intrus, puisque tous deux présentent le même nom et le même secret. Le couper en urgence arrête des traitements dont personne n’a la liste ; le laisser actif prolonge l’accès de l’attaquant. Et faute de savoir où le secret a été copié, le changer déclenche des pannes découvertes une à une, au rythme des traitements qui l’utilisaient, y compris le rapport annuel du mois de mars, qui se manifestera avec onze mois de retard.

🦫 Explication de la marmotte 🍫

Dans un système informatique, des programmes doivent souvent se connecter à d’autres programmes : une application à sa base de données, un outil de mise en ligne à un serveur. On leur crée pour cela un compte, appelé compte de service, protégé par un secret, par exemple un mot de passe ou une clé. Ce compte reçoit des droits, souvent plus larges que nécessaire pour que tout fonctionne vite. Le secret est ensuite recopié à plusieurs endroits : fichiers de configuration, postes de développeurs, tickets, sauvegardes, historique du code. Quand le projet s’arrête ou que son créateur change de poste, le compte continue d’exister avec ses droits, car personne n’est chargé de le supprimer et la suppression risque de casser un traitement rare. Un attaquant qui trouve une copie du secret peut alors se connecter sans deuxième preuve d’identité, et son activité ressemble à celle, habituelle, d’un programme. Trois réponses existent. L’inventaire note pour chaque compte son responsable, son usage, ses droits, l’emplacement du secret et sa dernière utilisation. Le changement régulier du secret réduit la durée pendant laquelle une copie volée reste utile. La réponse la plus solide supprime le secret stocké : le programme prouve son identité à un service de confiance, qui lui remet un jeton valable quelques minutes ou quelques heures. La sécurité dépend alors des règles qui décident à qui ce service accepte de remettre un jeton.

Pages voisines

La citent

Les comptes de service oubliés

Elle cite

Les comptes de service oubliés

La population invisible

Comment naît un compte de service

Pourquoi on ne les supprime pas

Ce que l’attaquant y trouve

L’inventaire, travail de Sisyphe utile

Un cycle de vie, enfin

La rotation, et ses limites

Des identités qui meurent d’elles-mêmes

Le meilleur argument contre cet éditorial

Ce que je ne sais pas

Ce qui reste

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines