Pourquoi supprimer les comptes de service partagés

Un compte partagé est une identité technique ou applicative dont le même mot de passe est connu de plusieurs personnes. Ce n’est pas un compte orphelin après un départ, ni une identité machine automatisée : le problème existe tant que les personnes sont présentes, actives et parfaitement autorisées.

→ Lire l’explication complète de la marmotte

Le compromis du compte partagé : vitesse locale contre responsabilité absente

L’équipe crée généralement ce compte pour trois raisons : un outil ancien n’accepte qu’un utilisateur, une opération urgente doit démarrer avant la création des accès nominaux, ou la gestion individuelle paraît trop chère. Ces raisons expliquent la décision. Elles ne la rendent pas saine.

Le gain est immédiat : une seule configuration, un secret à distribuer, un accès prêt en quelques minutes. Le coût est différé, puis cumulé : plus aucune action ne peut être attribuée de manière fiable à une personne, chaque départ impose une rotation collective, et la moindre compromission impose de considérer tous les détenteurs du secret comme suspects ou potentiellement exposés.

Un journal qui contient login=svc-production prouve qu’un secret a été présenté. Il ne prouve pas qui l’a utilisé. L’adresse réseau, l’horaire ou le poste d’administration peuvent aider une enquête, mais restent des indices contextuels. Ils ne restaurent pas une preuve d’identité lorsque plusieurs humains possèdent le même moyen d’authentification. Une adresse peut être partagée, une session peut être reprise, un poste peut être administré à distance. Le journal devient un roman policier écrit par un routeur.

La distinction avec les identités machine compte. Une identité machine sert à un processus, avec un secret non humain, stocké et renouvelé par automatisation. Un compte partagé sert à des humains sous un nom unique. Mettre le mot de passe dans un gestionnaire de secrets ne le transforme pas magiquement en identité machine. Le coffre améliore l’attente, pas le modèle d’autorisation.

La recommandation est nette : interdire la création de nouveaux comptes partagés pour des usages humains, sauf dérogation bornée, documentée et assortie d’une date de suppression. Une dérogation sans échéance est une permission permanente avec une moustache postiche.

Ce que casse une identité commune lors d’un incident

L’attribution individuelle est la première propriété perdue. Dans une investigation, on doit pouvoir répondre à quatre questions : quelle identité a effectué l’action, quel humain contrôlait cette identité, quelle autorisation justifiait l’action, et depuis quel contexte d’exécution elle a été réalisée. Un compte partagé ne répond qu’à la première, et encore avec une identité collective.

Cette absence d’attribution casse la corrélation entre l’authentification, l’autorisation et l’audit. Les journaux applicatifs, les journaux système et les alertes de sécurité peuvent indiquer le même compte. Ils ne permettent pas de distinguer une action légitime d’un abus commis avec le même secret. La séparation des tâches devient déclarative : deux personnes censées valider des étapes distinctes peuvent utiliser le même compte. Le contrôle existe sur une slide, ce lieu où les détails vont parfois mourir.

La révocation individuelle est la seconde propriété perdue. Quand une personne change d’équipe, perd son habilitation ou devient suspecte, retirer son accès exige de changer le mot de passe du compte pour tous. L’alternative consiste à ne rien changer, donc à maintenir l’accès de l’ancienne personne. C’est une dette à intérêt variable : elle paraît gratuite jusqu’au premier incident.

La rotation devient elle aussi une opération organisationnelle. Il faut changer le secret, mettre à jour le coffre, prévenir les détenteurs légitimes, vérifier les sessions et identifier les intégrations qui auraient réutilisé ce même compte. Si le secret est saisi manuellement dans des scripts, des tâches planifiées ou des connexions enregistrées, la rotation casse des traitements. Ce n’est pas un défaut du mécanisme de rotation : c’est le symptôme d’une identité utilisée simultanément par des humains et des automatisations.

Enfin, un mot de passe partagé élargit mécaniquement la surface d’attaque. Chaque poste, navigateur, gestionnaire local, terminal et canal de transmission utilisé par un détenteur devient un emplacement possible de fuite. Un secret connu par huit personnes ne possède pas huit fois plus de risque de fuite de manière strictement linéaire, car les expositions ne sont pas indépendantes. Il possède néanmoins huit chemins humains supplémentaires vers une fuite, ce qui suffit largement à gâcher une semaine.

Pré requis d’une sortie vers des identités fédérées

La cible doit être une identité fédérée nominative par personne. Une identité fédérée est un compte personnel authentifié par un fournisseur d’identité central, qui transmet ensuite une preuve d’authentification à l’outil cible. Le fournisseur applique les règles d’accès, notamment l’authentification multifacteur, c’est-à-dire la vérification par au moins deux preuves distinctes, par exemple un mot de passe et une clé matérielle.

Cette cible exige un inventaire préalable. Il faut identifier le propriétaire métier du compte partagé, les personnes qui l’utilisent, les systèmes accessibles, les droits effectifs, les flux automatisés, les procédures d’urgence et les journaux disponibles. Inventorier seulement les groupes d’annuaire est insuffisant : un droit local, un compte embarqué dans un connecteur ou une base de données d’administration échappent souvent à cette vue.

Quand l’outil supporte la fédération, créer un groupe d’accès nominatif et attribuer les droits au groupe. L’authentification reste individuelle, tandis que l’autorisation s’administre collectivement. Cette séparation est la bonne granularité : on retire une personne du groupe sans modifier les autres accès ni partager de nouveau secret.

Pour une action sensible, préférer une élévation temporaire. L’utilisateur s’authentifie avec son identité personnelle, demande un rôle privilégié limité dans le temps, puis réalise l’action sous cette identité traçable. L’élévation doit être limitée par durée, portée et approbation lorsque le risque le justifie. Une session privilégiée permanente est seulement un compte partagé avec davantage de boutons.

Le contrôle d’accès basé sur les rôles doit rester lisible. Un rôle correspond à une fonction opérationnelle, pas à une personne ni à une accumulation historique de droits. Une revue périodique doit vérifier les membres, les droits accordés et les usages réels. Les principes détaillés de séparation, de gouvernance et de preuve d’accès relèvent aussi de la gouvernance.

Exemple de migration avec groupe nominatif et élévation temporaire

L’exemple suivant utilise un groupe local Linux pour illustrer le principe. Il ne remplace pas une fédération centralisée, mais montre la différence essentielle : chaque commande privilégiée reste liée à l’identité Unix personnelle dans les journaux, tandis que le droit est accordé via un groupe.

# Créer le groupe correspondant à la fonction d'exploitation.
sudo groupadd exploitants-applicatifs

# Ajouter une personne nominativement au groupe.
sudo usermod -aG exploitants-applicatifs alice

# Autoriser le groupe à exécuter uniquement la commande d'administration prévue.
# Le journal sudo conservera l'identité personnelle d'alice.
echo '%exploitants-applicatifs ALL=(root) /usr/local/sbin/recharger-application' \
  | sudo tee /etc/sudoers.d/exploitants-applicatifs

# Retirer l'accès d'une seule personne sans changer un mot de passe collectif.
sudo gpasswd -d alice exploitants-applicatifs

En production, l’ajout et le retrait ne doivent pas être exécutés manuellement sur chaque hôte. La source d’autorité doit être le référentiel d’identités, synchronisé vers les environnements cibles ou interrogé par fédération. Le journal doit contenir au minimum l’identifiant individuel, le rôle activé, la cible, l’action, l’heure et le résultat. Sans horodatage synchronisé entre systèmes, la reconstruction d’une séquence d’incident devient hasardeuse.

L’élévation temporaire nécessite aussi une expiration appliquée par le système, pas rappelée dans une procédure. Une date inscrite dans un ticket ne désactive aucun droit. Le système doit retirer le rôle à échéance, y compris si l’opérateur oublie, part en congé ou rencontre un incident au pire moment, ce que les systèmes font avec une régularité presque artistique.

Coffre-fort de mots de passe : mesure transitoire, pas destination

Certains outils anciens ne supportent ni fédération ni comptes multiples. Dans ce cas, un coffre-fort de mots de passe avec emprunt individuel est le minimum acceptable pendant une migration. Le coffre authentifie chaque personne avec son identité personnelle, délivre le secret après contrôle d’accès, journalise l’emprunt et force sa rotation après restitution ou après une durée maximale.

Cette approche rétablit une partie de la traçabilité : on sait qui a demandé le secret et quand. Elle ne prouve pas qui a exécuté chaque action après révélation du mot de passe. Une personne peut communiquer le secret pendant la fenêtre d’emprunt, ouvrir plusieurs sessions ou laisser une session active. Le coffre réduit la zone d’incertitude, il ne la supprime pas.

Le mode préférable est la connexion proxifiée ou injectée par le coffre, lorsque l’outil le permet. Le secret n’est alors pas affiché à l’opérateur, et la session peut être associée à l’identité individuelle. Si l’outil ne permet qu’une saisie manuelle, imposer une durée d’emprunt courte, une rotation automatique après usage et une justification liée à une demande d’intervention.

La sauvegarde du coffre et de ses clés de chiffrement est une condition d’exploitation, pas un détail d’achat. Tester la restauration dans un environnement isolé, vérifier la conservation des journaux et définir qui peut ouvrir le mécanisme de récupération. Un coffre indisponible peut bloquer une exploitation ; un mécanisme de secours sans trace recrée immédiatement le problème sous une autre coiffure.

La migration doit enfin séparer les usages humains des usages automatisés. Chaque script ou intégration qui utilise le compte partagé doit recevoir une identité dédiée, des droits limités et un secret géré par une solution de gestion de secrets. La rotation, la supervision des échecs d’authentification et l’alerte sur les emprunts hors horaires attendus deviennent alors exploitables. Pour les mécanismes de secret, de rotation et de stockage, consulter aussi les ressources de cryptographie appliquée.

🐝 Ce qui arrive si on s’en passe

Sans identités nominatives, la détection perd sa ligne de base : un profil comportemental agrégeant huit opérateurs ne distingue plus l’horaire inhabituel de l’usage normal, et les alertes sur connexion anormale deviennent du bruit toléré. Le verrouillage après échecs répétés se retourne en déni de service collectif, ce qui pousse à désactiver ce garde-fou. L’authentification multifacteur perd son sens dès que le second facteur est lui aussi mutualisé. En cas de contestation, aucune trace n’est opposable à une personne : toute action reste répudiable. Le périmètre d’un incident devient indéterminable, obligeant à traiter chaque détenteur du secret comme exposé, donc à réinitialiser, notifier et auditer largement. Enfin, la crainte de casser des traitements liés au même secret repousse indéfiniment la rotation, laissant vieillir un mot de passe dont la liste réelle des détenteurs n’est plus connue.

🦫 Explication de la marmotte 🍫

Un compte partagé utilise le même nom et le même mot de passe pour plusieurs personnes. Quand une personne se connecte, le système voit seulement ce compte commun. Il enregistre que le compte a réalisé une action, mais il ne peut pas distinguer la personne qui était derrière l’écran. En cas d’erreur, de fuite ou d’action interdite, l’enquête ne peut donc pas attribuer les faits avec certitude.

Le problème continue quand une personne perd son droit d’accès. Pour empêcher cette personne de revenir, il faut changer le mot de passe commun. Toutes les autres personnes doivent alors recevoir le nouveau mot de passe. Si ce changement est retardé, l’ancienne personne peut encore se connecter. Si le mot de passe était aussi utilisé dans un programme automatique, ce programme peut arrêter de fonctionner après le changement.

La meilleure correction consiste à donner un compte personnel à chaque personne. Le système conserve alors le nom de la personne dans ses journaux. Les droits sont accordés par fonction et peuvent être retirés à une seule personne. Pour les opérations dangereuses, un droit plus puissant peut être donné pour une courte durée, puis supprimé automatiquement.

Quand un ancien outil refuse les comptes personnels, un coffre de mots de passe peut limiter les dégâts. Il enregistre qui demande le mot de passe et oblige à le changer souvent. Cela reste temporaire : dès qu’une personne voit le mot de passe, elle peut l’utiliser sans que chaque action soit attribuable.

Pages voisines

La citent

Pourquoi supprimer les comptes de service partagés

Elle cite

: les deux pages se citent l’une l’autre.

Pourquoi supprimer les comptes de service partagés

Pourquoi supprimer les comptes de service partagés

Le compromis du compte partagé : vitesse locale contre responsabilité absente

Ce que casse une identité commune lors d’un incident

Pré requis d’une sortie vers des identités fédérées

Exemple de migration avec groupe nominatif et élévation temporaire

Coffre-fort de mots de passe : mesure transitoire, pas destination

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines