340 comptes de service pour 11 usages réels — les 7 étapes que j’aurais aimé connaître avant notre premier audit d’identités machines

La réunion a duré vingt minutes de plus que prévu à cause d’une seule ligne de tableur. Un compte nommé svc-integration-prod, créé en mars 2021, disposant de droits d’écriture sur la base de facturation, dont le mot de passe n’avait jamais été changé. Personne dans la salle — huit personnes, dont le directeur technique et le responsable infrastructure — ne savait à quoi il servait.

Il servait à quelque chose. Le désactiver aurait cassé une chaîne de facturation. Personne ne savait laquelle. Nous avons mis onze jours à le déterminer.

Ce compte faisait partie des 340 identités machines que nous avons dénombrées sur ce parc de 180 personnes. Onze correspondaient à un usage vivant, documenté et rattaché à une personne. Voici la méthode qui est sortie de ce chantier, dans l’ordre où elle doit être appliquée.

Étape 1 — Inventorier par l’authentification, jamais par la déclaration

Ne demandez pas aux équipes la liste de leurs comptes de service. Vous obtiendrez une liste sincère et fausse : les gens déclarent ce qu’ils utilisent, pas ce qui existe. Sur notre parc, la liste déclarative comportait 47 entrées pour 340 comptes réels.

La bonne source est l’authentification elle-même. Quatre endroits à regarder, et ils suffisent pour couvrir plus de 90 % du périmètre :

• Votre annuaire d’entreprise : tous les comptes dont le nom ne correspond pas à une personne physique, ou qui ne se sont jamais connectés interactivement.
• Vos bases de données : la liste des comptes existants et, surtout, les connexions actives observées sur trente jours.
• Votre console d’hébergement : rôles applicatifs, clés d’accès, comptes de service gérés.
• Vos applications tierces : jetons d’intégration, connecteurs, applications autorisées sur votre fournisseur d’identité.

Une colonne obligatoire dans ce tableau, et c’est celle que tout le monde oublie : la date de dernière authentification réussie. Elle transforme un inventaire ingérable en trois piles très différentes, et elle fait à elle seule la moitié du travail de tri de l’étape 3.

Étape 2 — Attribuer un propriétaire humain à chaque compte, avant toute autre décision

C’est l’étape qui détermine si votre chantier tiendra dans dix-huit mois ou s’il faudra le refaire. Elle est administrative, ingrate, et elle vaut plus que n’importe quel outil.

Pour chaque compte, une seule question : « si cette personne quitte l’entreprise demain, qui hérite de ce compte ? ». Le propriétaire doit être une personne nommée, pas une équipe et pas un service. Une équipe ne signe pas et ne répond pas à un courriel de revue.

Vous allez découvrir une proportion inconfortable de comptes sans propriétaire possible. Sur notre parc, 211 comptes sur 340 n’ont trouvé personne. C’est une information exploitable et non un échec : un compte que personne ne revendique après une relance écrite est un candidat direct à l’étape 3.

Inscrivez dès maintenant la vérification des comptes de service dans votre procédure de départ, au même titre que la restitution du badge. C’est une ligne de checklist, et c’est ce qui empêche l’inventaire de se dégrader dès le premier trimestre.

Étape 3 — Trier en trois piles et traiter la plus facile d’abord

L’inventaire brut est décourageant. Le tri le rend traitable, et il repose entièrement sur la colonne de dernière authentification.

Pile 1 — jamais authentifiés. Comptes créés puis oubliés, souvent lors d’une expérimentation. Sur notre parc, 186 sur 340. Ils se suppriment en une matinée avec un risque quasi nul. Faites-les en premier : le chiffre passe de 340 à 154 en une demi-journée, et cela change complètement la perception du chantier en interne.

Pile 2 — dormants depuis plus de 180 jours. 84 comptes. Ne supprimez pas directement : désactivez et attendez trente jours. Une intégration trimestrielle ou une clôture annuelle peut légitimement dormir six mois. La désactivation est réversible en trente secondes, la suppression ne l’est pas.

Pile 3 — actifs. 70 comptes, dont 11 documentés et 59 sans propriétaire. C’est ici que se concentre tout le risque, et c’est le seul travail qui demande vraiment de la réflexion. Traitez cette pile en dernier, mais traitez-la : c’est elle qui justifie le chantier.

Étape 4 — Réduire les droits en partant de l’usage observé, pas de la discussion

Pour les 70 comptes actifs, la question devient : de quels droits ont-ils réellement besoin ? Une conversation avec l’équipe qui les exploite ne donnera jamais la réponse, parce que personne ne s’en souvient.

La méthode qui fonctionne est l’observation. Activez la journalisation détaillée des actions du compte pendant trente jours, puis construisez le nouveau jeu de droits à partir de ce qui a effectivement été fait. Sur notre parc, un compte disposant de droits d’administration complets sur la base n’exécutait en réalité que des lectures sur quatre tables.

Trois règles pour la réduction, à appliquer sans exception :

• Un compte par usage. Le compte mutualisé entre trois intégrations est indéboulonnable : personne n’ose y toucher parce que personne ne sait ce qui casserait.
• Lecture seule par défaut. L’écriture se justifie usage par usage, par écrit.
• Restriction par source. Un compte de service n’a presque jamais de raison de pouvoir s’authentifier depuis n’importe quelle adresse. C’est la mesure la moins coûteuse et la plus efficace du lot : même un identifiant volé devient inutilisable hors de votre infrastructure.

Étape 5 — Sortir les secrets du code et de la configuration

Maintenant seulement, le coffre à secrets. Pas avant, et la raison est simple : un coffre déployé sur un parc non inventorié range proprement des accès que personne ne comprend. Vous aurez dépensé un budget et gagné une fausse sensation de maîtrise.

L’ordre de traitement est dicté par l’exposition, pas par la facilité. D’abord les secrets présents dans un dépôt de code, y compris dans l’historique — un secret retiré d’un fichier mais présent dans un commit ancien reste lisible. Ensuite ceux des chaînes d’intégration continue, qui s’exécutent sur des machines partagées. Puis les fichiers de configuration sur les serveurs. Enfin les documents partagés — tableurs, notes, messageries — qui sont statistiquement le premier endroit où l’on retrouve un mot de passe d’administration.

Un point de méthode qui évite un faux sentiment de sécurité : un secret déplacé vers un coffre mais déjà présent dans un historique de dépôt doit être considéré comme compromis et changé. Le déplacement ne le révoque pas. La démarche complète côté chaîne de livraison est détaillée dans notre méthode de gestion des secrets en CI/CD.

Étape 6 — Mettre en place une rotation qui survit à l’enthousiasme initial

Tout le monde connaît le principe. Presque personne ne le tient au-delà du deuxième trimestre, et la cause est toujours la même : une rotation manuelle est une tâche pénible sans échéance externe, donc elle est reportée jusqu’à disparaître.

Trois arbitrages rendent la rotation durable.

Distinguez ce qui est automatisable de ce qui ne l’est pas. Un identifiant émis par votre plateforme d’hébergement se renouvelle tout seul : configurez-le une fois et n’y pensez plus. Un mot de passe de compte de service dans une application tierce sans interface de renouvellement demandera toujours une intervention humaine. Ne mélangez pas les deux dans un même processus, car le second finira par bloquer le premier.

Adaptez la fréquence à l’exposition, pas au calendrier. Un compte lisant des données sensibles depuis Internet mérite une rotation trimestrielle. Un compte interne en lecture seule sur des données peu sensibles peut tourner une fois par an sans que cela pose problème. Une politique uniforme trop stricte n’est pas appliquée du tout ; c’est le pire des deux mondes.

Prévoyez la double validité. La cause première des incidents de rotation est la coupure : on change le secret, on oublie un consommateur, quelque chose s’arrête. Émettez le nouveau secret, laissez les deux valides pendant une fenêtre définie, vérifiez que plus rien n’utilise l’ancien, puis révoquez.

Étape 7 — Surveiller l’écart, pas les comptes

Dernière étape, et celle qui rend le chantier permanent au lieu d’en faire un projet ponctuel. Surveiller chaque compte de service produit un bruit que personne ne lira. Surveillez plutôt quatre écarts, qui tiennent sur un tableau de bord d’une page.

• Comptes sans propriétaire. Cible : zéro. Toute apparition est une anomalie de processus, pas un incident de sécurité — mais elle se traite avant de devenir l’un des deux.
• Comptes dont le secret dépasse la durée prévue. Cible : zéro. C’est l’indicateur qui montre le plus tôt qu’une rotation a été abandonnée.
• Authentifications depuis une source inattendue. Un compte de service qui se connecte depuis une adresse jamais vue est le signal le plus fort que vous obtiendrez. Peu de faux positifs quand l’étape 4 a été faite.
• Comptes créés hors du processus. Cible : zéro. Un compte apparu sans demande révèle une faille de gouvernance qui recréera l’inventaire de 340 lignes en dix-huit mois.

Une revue trimestrielle de trente minutes suffit, à condition qu’elle soit tenue par une personne nommée et qu’elle figure au calendrier. C’est le même principe que pour la maîtrise des élévations de privilèges dans l’annuaire : la valeur vient de la régularité, pas de la profondeur.

Ce que les agents d’IA changent à ce chantier

Un mot sur une évolution qui rend ce sujet plus urgent qu’il ne l’était il y a deux ans. Les agents d’intelligence artificielle déployés en entreprise sont, du point de vue de la sécurité, des identités machines dotées de droits particulièrement larges.

Un agent qui consulte votre gestionnaire de tickets, lit votre documentation et écrit dans votre outil de suivi détient trois accès applicatifs distincts. Ils sont posés par une équipe produit, souvent avec des droits confortables « pour commencer », et ils n’apparaissent dans aucun inventaire d’identités machines parce que personne ne les range dans cette catégorie.

Les sept étapes ci-dessus s’appliquent à eux sans modification. La seule différence est le rythme : un parc d’agents croît beaucoup plus vite qu’un parc de comptes de service classiques. Les équipes de Plug-Tech documentent régulièrement la conception de ces permissions côté applicatif, et le volet chaîne de développement — secrets dans les dépôts, dépendances, postes d’ingénierie — est traité par nos confrères de D-Open.

Budget et séquencement réalistes

Pour une PME de 50 à 250 personnes, comptez 8 à 14 jours-homme répartis sur un trimestre. Les six premières étapes ne demandent aucune licence : elles utilisent ce dont vous disposez déjà. Seule l’étape 5 peut justifier un outil dédié, et encore, pas systématiquement en dessous de cent identités.

Le séquencement qui fonctionne est celui du gain visible rapide : inventaire et suppression de la pile 1 en semaine 1, ce qui fait chuter le chiffre de plus de la moitié et rend le reste du chantier finançable en interne. Attribution des propriétaires en semaines 2 et 3. Réduction des droits sur les comptes actifs pendant le mois suivant. Coffre et rotation au trimestre suivant, une fois que l’inventaire est stable.

Si votre organisation relève de la directive NIS2, la maîtrise des accès techniques est explicitement attendue et fait partie des points examinés : notre audit de périmètre NIS2 couvre l’articulation entre ce chantier et vos obligations.

Questions fréquentes