Mot de passe partagé en équipe et risques réels

Mot de passe partagé en équipe et risques réels

Un mot de passe partagé résout un problème immédiat : plusieurs personnes doivent accéder au même système sans bloquer le travail. Il crée aussi une dette de sécurité précise : dès que le secret circule, l’identité de l’auteur d’une action, la révocation et la preuve d’accès deviennent approximatives.

Explication de la marmotte

Un mot de passe partagé ressemble à une clé unique que plusieurs personnes gardent dans leur poche pour ouvrir la même réserve. Cela évite d’attendre le détenteur officiel, mais personne ne peut ensuite prouver qui est entré, qui a copié la clé ou qui l’a encore après son départ.

→ Lire l’explication complète de la marmotte

Compromis : continuité d’équipe contre responsabilité individuelle

Le gain est réel : un accès commun élimine une dépendance à une personne, accélère une intervention et contourne les limites d’un produit incapable de gérer plusieurs comptes. Le prix est tout aussi réel : l’authentification n’identifie plus un individu, elle identifie un groupe indifférencié. Un journal indiquant admin ne démontre rien sur l’auteur réel de l’action.

La règle est nette : ne jamais partager le mot de passe d’un compte humain. Un compte humain doit être nominatif, protégé par une authentification multifacteur (MFA, Multi-Factor Authentication) propre à son titulaire, et supprimable sans toucher aux autres accès. Le partage d’un mot de passe de messagerie, d’administration cloud ou de portail fournisseur est une erreur d’architecture, même si le coffre-fort à mots de passe affiche un joli cadenas vert.

Le seul cas acceptable est un secret technique imposé par une dépendance qui ne supporte pas les identités individuelles : compte de service ancien, équipement réseau sans fédération, accès de secours, compte fournisseur temporaire. Dans ce cas, le secret n’est pas une identité partagée : c’est une exception documentée, enfermée dans un coffre, avec une date de sortie et une rotation après chaque changement de population.

Une équipe gagne de la disponibilité, mais paie en attribution, en révocation et en surface d’exfiltration. Ce compromis reste valable uniquement si le service cible ne peut pas faire mieux et si l’accès au secret est lui-même individualisé. Sinon, il faut remplacer le mot de passe par une fédération d’identité ou des comptes distincts. La page sur les identités et mécanismes d’authentification fournit le cadre pour sortir proprement de ce bricolage durable, cette spécialité industrielle qui survit mieux que les plantes vertes.

Surface d’attaque du secret partagé

Un coffre-fort partagé limite la diffusion du mot de passe, il ne le rend pas non copiable. Toute personne autorisée peut le voir, l’exporter, le coller dans un terminal, le stocker dans l’historique du navigateur ou le retranscrire. L’attaquant n’a pas besoin de casser le chiffrement du coffre si un poste déverrouillé, une session de navigateur ou une extension compromise lui donne le secret en clair.

Le premier risque est le départ d’un membre. La révocation de son accès au coffre empêche une nouvelle lecture, mais ne retire pas les copies déjà faites. La réponse est la rotation immédiate du secret cible, pas une désactivation différée du compte dans le gestionnaire de mots de passe. Une rotation qui attend la prochaine fenêtre de maintenance est une révocation décorative.

Le deuxième risque est la confusion entre contrôle d’accès au coffre et traçabilité sur le système cible. Le coffre peut journaliser que l’identité [email protected] a consulté un élément à 09:14. Le serveur distant verra néanmoins le même compte partagé pour Alice, Bruno ou un attaquant ayant volé leur session. Les deux journaux se recoupent, ils ne se substituent pas. Une consultation de secret n’est pas une preuve d’utilisation.

Le troisième risque concerne la MFA. Partager un code à usage unique, un téléphone ou une clé matérielle annule le facteur individuel. Une boîte de réception commune qui reçoit les codes de connexion n’est pas une MFA collective, c’est un mot de passe partagé avec une étape supplémentaire et une meilleure capacité à gâcher une astreinte. Pour un accès humain, la MFA doit être liée à une identité nominative. Pour un compte technique, elle doit être remplacée par un mécanisme d’identité de charge de travail ou un accès interactif strictement exceptionnel.

Enfin, le mot de passe partagé favorise les attaques par réutilisation. Un secret choisi manuellement finit trop souvent recyclé entre une console, un portail et un équipement ancien. La compromission d’un seul fournisseur devient alors une tentative de connexion ailleurs. Les mots de passe techniques doivent être générés aléatoirement, uniques par cible et d’une longueur compatible avec le produit, sans composition mémorisable. Un secret mémorisable est généralement un secret réutilisable, avec tout le folklore qui l’accompagne.

Architecture : coffre partagé, accès nominatif et sortie de secours

La recommandation est de stocker les secrets d’équipe dans un gestionnaire dédié, mais de ne jamais partager son compte maître. Chaque personne accède au coffre avec son identité propre, une MFA propre et des droits fondés sur les rôles (RBAC, Role-Based Access Control). Le coffre doit journaliser l’accès, interdire l’export par défaut lorsque le produit le permet, et exiger une réauthentification pour révéler les secrets sensibles.

Le gestionnaire de secrets ne doit pas être l’unique point de contrôle. Le système cible doit aussi réduire le rayon d’explosion : restriction par adresse réseau ou bastion, droits minimaux, comptes séparés entre lecture et administration, expiration des sessions, et journalisation distante. Les principes de sécurité réseau et d’identité s’appliquent ici sans mystère : protéger le chemin d’accès compte autant que protéger le secret.

Pour les applications, préférer une identité de charge de travail à un mot de passe statique. Une application peut obtenir un jeton court auprès d’un fournisseur d’identité, puis lire uniquement le secret nécessaire. L’accès est alors lié à une charge de travail, à un environnement et à une durée. Cette architecture demande plus qu’une slide sur le zéro confiance, notamment un inventaire des services et des dépendances. C’est précisément la partie que les slides évitent avec une remarquable régularité.

Un compte de secours, souvent appelé break-glass, reste parfois nécessaire quand le fournisseur d’identité ou le réseau d’administration est indisponible. Il doit être distinct des comptes ordinaires, limité à une action de reprise, protégé par une MFA matérielle dédiée et surveillé. Son usage doit déclencher une alerte, une revue et une rotation. Le compte de secours qui sert chaque vendredi n’est pas un secours, c’est un raccourci avec une étiquette.

Exemple : politique OpenBao pour un secret d’équipe

OpenBao permet de distribuer l’accès à un secret sans diffuser un identifiant de coffre collectif. Les prérequis sont une instance OpenBao version 2.1 ou ultérieure, un annuaire ou fournisseur d’identité capable d’authentifier chaque opérateur, un stockage persistant chiffré et une destination de journaux séparée de l’instance. Le compte exécutant ces commandes doit disposer des droits d’administration OpenBao.

# Active un moteur de secrets versionné sous le chemin "equipe".
bao secrets enable -path=equipe kv-v2

# Crée une politique limitée à la lecture d'un seul secret.
cat > lecture-api-prod.hcl <<'EOF'
path "equipe/data/production/api-fournisseur" {
  capabilities = ["read"]
}
EOF

# Charge la politique. Les identités humaines reçoivent ensuite ce droit
# via un groupe, jamais via un compte OpenBao partagé.
bao policy write lecture-api-prod lecture-api-prod.hcl

# Enregistre le secret. Ne pas saisir une valeur réelle dans un historique
# shell : utiliser une variable protégée ou une interface d'administration.
bao kv put equipe/production/api-fournisseur \
  mot_de_passe="$(openssl rand -base64 32)"

Cette configuration améliore la traçabilité de consultation : chaque lecture est associée à l’identité ayant ouvert une session OpenBao. Elle ne transforme pas le compte distant api-fournisseur en identité nominative. Si le fournisseur permet des comptes individuels ou des jetons par application, cette politique doit être une transition, pas le point final.

L’audit OpenBao doit être activé avant la distribution du secret. Les journaux doivent partir vers un système distinct, avec une rétention cohérente avec les enquêtes internes. Une journalisation locale sur le même disque que le coffre ne protège rien contre la compromission de l’hôte. C’est un parachute rangé dans l’avion qui vient de perdre ses ailes.

Rotation, sauvegarde et conditions d’exploitation

Chaque secret partagé doit avoir un propriétaire de service, une finalité, une liste de consommateurs, une date de dernière rotation et une procédure de remplacement. Sans ces cinq données, la rotation devient une recherche archéologique dans des pipelines d’intégration continue et de déploiement continu (CI/CD, Continuous Integration and Continuous Delivery), avec des erreurs de production en guise de documentation.

La rotation doit être testée par une procédure en deux phases lorsque le service le permet : créer un second secret, déployer les consommateurs vers ce nouveau secret, vérifier les accès, puis révoquer l’ancien. Une rotation atomique casse les services qui chargent leur configuration au démarrage et ne la relisent jamais. Les redémarrages imprévus ont souvent une mémoire excellente pour ce type de détail.

Le coffre nécessite des sauvegardes chiffrées, testées en restauration, avec séparation des droits entre administration du coffre et accès aux sauvegardes. La clé de chiffrement de sauvegarde ne doit pas résider uniquement dans le même environnement que les données. Un module matériel de sécurité (HSM, Hardware Security Module) peut protéger cette clé lorsque le niveau de risque le justifie, mais il ne corrige ni les droits excessifs ni les secrets exportés.

La supervision doit détecter les lectures inhabituelles, les exports, les échecs répétés de MFA, les ajouts de membres à des groupes sensibles et les usages du compte de secours. Une alerte sans procédure de réponse reste un bruit de fond coûteux. Définir à l’avance qui peut faire tourner le secret, qui valide l’incident et comment rétablir le service sans rediffuser le mot de passe dans une conversation d’urgence.

🐝 Ce qui arrive si on s’en passe

Sans identités nominatives ni rotation pilotée, les mécanismes de détection perdent leur référence : un compte unique utilisé depuis plusieurs postes, plusieurs adresses et plusieurs horaires rend inopérantes les règles de connexion improbable, de géolocalisation incohérente ou de volumétrie anormale. Une session volée se fond alors dans le trafic légitime de l’équipe. En cas d’incident, l’analyse ne peut ni écarter ni désigner un poste compromis, ce qui oblige à traiter l’ensemble des machines ayant consulté le secret comme suspectes, avec le coût de réinstallation correspondant. La responsabilité devient collective par défaut, et aucune preuve d’action ne résiste à une contestation. Enfin, faute d’inventaire des consommateurs, toute tentative de changement de secret se solde par des pannes découvertes en production, ce qui repousse indéfiniment la rotation et prolonge la validité d’un accès déjà diffusé.

🦫 Explication de la marmotte 🍫

Un mot de passe partagé est une même information secrète utilisée par plusieurs personnes pour entrer dans un système. Chaque personne peut donc ouvrir ce système, mais le système ne sait pas distinguer laquelle a réalisé une action. Il voit toujours le même nom de compte.

Un gestionnaire de mots de passe peut stocker ce secret et autoriser seulement certains membres de l’équipe à le consulter. Chaque membre se connecte alors au gestionnaire avec son propre compte et une vérification supplémentaire. Le gestionnaire peut enregistrer qui a affiché le secret et à quel moment. Cependant, après affichage, une personne peut le copier. Retirer cette personne du gestionnaire ne supprime pas les copies déjà récupérées.

Quand une personne quitte l’équipe, quand un ordinateur est compromis ou quand un accès paraît suspect, il faut changer le mot de passe du système concerné. Il faut aussi modifier les programmes et services qui utilisent cet ancien mot de passe, sinon ils cessent de fonctionner.

La meilleure solution consiste à donner un compte distinct à chaque personne. Les actions sont alors attribuables, et retirer un accès ne gêne pas les autres. Pour les programmes, il faut préférer des autorisations temporaires et limitées plutôt qu’un mot de passe permanent. Le mot de passe partagé reste une exception pour les systèmes incapables de gérer plusieurs identités.

À lire aussi

• Onboarding sécurité : règles à retenir dès l’arrivéeOnboarding sécurité : ce qu'un nouvel arrivant doit vraiment retenir pour protéger identités, postes, secrets et accès.
• Laisser une équipe se tromper sans casser la productionLaisser une équipe se tromper est un risque pédagogique à encadrer par des limites techniques, des données contrôlées et une exploitation préparée.
• Pourquoi le moindre privilège échoue en productionDossier d'enquête sur l'écart entre le principe du moindre privilège enseigné et l’octroi réel de droits excessifs pour accélérer l’exploitation.
• Comment écrire un rapport de vulnérabilité corrigéMéthode pour écrire un rapport de vulnérabilité qui déclenche une correction vérifiable, exploitable et suivie.

Pages voisines

La citent

• Principes de sécurité, identité et cryptographie utile au réseau
• Sécuriser les postes développeurs avec secrets de production
• Vault PAM et enregistrement des sessions admin

Mot de passe partagé en équipe et risques réels

Elle cite

• ⇄Lien dans les deux sens :Pourquoi supprimer les comptes de service partagés
• Comment auditer les comptes orphelins après un départ
• Mettre en place la fédération d’identité de charge

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