Les identifiants de connexion passent sans cesse d’une équipe à l’autre. L’équipe plateforme remet une clé de déploiement à une équipe produit, le support reçoit l’accès administrateur d’un portail fournisseur, la finance transmet le jeton de l’API bancaire à l’ingénierie pour une intégration. Chaque transmission est routinière, et c’est à chacune d’elles qu’un identifiant finit le plus souvent dans un fil Slack, pour toujours.
Mettre en place une transmission sécurisée des identifiants entre équipes tient moins à un outil astucieux qu’à une règle claire pour choisir entre deux outils, plus quelques habitudes autour. Ce guide expose cette règle et ces habitudes : limiter le périmètre de l’identifiant, le remettre sans le mettre dans un message, désigner un responsable et retirer l’identifiant à temps.
La seule décision qui compte : coffre-fort ou lien à usage unique
Tout le reste découle de l’usage que l’équipe destinataire fera de l’identifiant.
| L’équipe destinataire va | Utiliser | Pourquoi |
|---|---|---|
| S’en servir durablement, à plusieurs, sans date de fin | Un coffre partagé dans votre gestionnaire de mots de passe ou de secrets | Accès nominatif, révocation et renouvellement au même endroit |
| S’en servir une fois, ou une seule personne en a besoin brièvement | Un lien secret à usage unique | Le message ne contient qu’un lien, la copie est détruite dès la première ouverture |
| L’utiliser depuis du code ou la CI | Un gestionnaire de secrets avec des identités machine | Aucun humain ne voit jamais la valeur |
Le coffre-fort est le système de référence. Si l’identifiant doit vivre au-delà de la transmission, il a sa place dans un coffre partagé qui appartient à l’équipe destinataire, avec des membres ajoutés nommément. La plupart des gestionnaires de mots de passe professionnels et des outils comme Vault ou AWS Secrets Manager le font bien.
Le lien à usage unique sert au moment de la transmission quand le coffre-fort ne convient pas : le destinataire n’a pas accès à votre coffre, l’identifiant est temporaire, ou vous devez transmettre une valeur à une personne tout de suite. Le secret est chiffré dans votre navigateur, la copie stockée est détruite à la première ouverture du lien, et le lien lui-même cesse de fonctionner à son expiration si personne ne l’ouvre. Liens secrets ou gestionnaires de mots de passe passe en revue les cas limites.
Jamais par e-mail, messagerie, document partagé ou ticket. Tous gardent des copies, tous se synchronisent sur des appareils que vous ne contrôlez pas, et tous sont consultables par la prochaine personne qui accède au compte.
Limiter le périmètre de l’identifiant avant de le transmettre
Un bon canal ne rattrape pas un identifiant aux droits trop étendus.
- Créez un compte distinct pour l’équipe ou la personne destinataire au lieu de prêter un compte rattaché à quelqu’un. Les identités partagées ne peuvent pas être auditées et ne peuvent pas être retirées proprement.
- Accordez les droits dont la tâche a besoin. Une équipe qui lit des rapports n’a pas besoin d’un accès en écriture. Une équipe qui déploie n’a pas besoin de la facturation.
- Renouvelez d’abord si la valeur a circulé. Si la clé existante a été collée un peu partout, émettez-en une nouvelle pour la transmission au lieu de diffuser l’ancienne encore plus loin.
- Passez au crible les documents liés au travail. Tickets, procédures d’exploitation, exemples de configuration et scripts joints contiennent souvent l’identifiant même que vous vous apprêtez à transmettre. Retirez-le avant la transmission, sinon la transmission sera le moindre de vos risques d’exposition.
La transmission elle-même
- Vérifiez le destinataire par un canal en lequel votre organisation a déjà confiance : le ticket, un responsable connu, un appel vidéo. Les adresses qui ressemblent à la bonne et les noms remplis automatiquement sont la cause habituelle d’un secret qui part au mauvais endroit.
- Remettez-le avec l’outil choisi. Coffre-fort : ajoutez la personne à la collection partagée. Lien : collez la valeur dans l’outil de création de liens secrets à usage unique, réglez l’expiration sur la fenêtre réelle (une heure si la personne attend, une journée entre fuseaux horaires), limitez à une seule ouverture, ajoutez une phrase de passe avec un compte Pro pour tout ce qui est sensible, et envoyez le lien.
- Envoyez le contexte séparément. Le nom d’utilisateur, l’hôte et ce à quoi l’identifiant donne accès partent dans un message ordinaire, jamais avec le lien. Un seul message qui fuit ne doit jamais contenir les deux moitiés.
- Consignez la transmission dans votre système de référence, sans le secret : destinataire, objet, système, responsable, date de fin.
- Demandez une confirmation d’accès, pas de la valeur. « Pouvez-vous vous connecter ? » est la bonne question. « Renvoyez-moi la clé pour vérifier » ne l’est pas.
Pour une équipe qui fait cela souvent, l’application Slack de LinkPilot transforme un mot de passe collé en lien à usage unique sans quitter le canal : l’habitude ne dépend plus de la mémoire de chacun pour ouvrir un autre outil.
Désigner un responsable, puis réviser à intervalles réguliers
Les identifiants sans responsable ne sont jamais renouvelés ni retirés. L’équipe destinataire doit désigner une personne qui répond de la valeur : qui la détient, qui d’autre en a besoin et quand elle disparaît.
- Le moindre privilège par rôle, avec des rôles ou des groupes quand ils simplifient l’administration, pour qu’un départ ne signifie pas une réinitialisation par système.
- L’authentification multifacteur sur le coffre-fort, car c’est désormais lui qui vaut la peine d’être attaqué.
- Un rythme de révision adapté à la sensibilité : tous les trimestres pour la plupart des identifiants partagés, à chaque changement d’équipe pour les accès à la production.
- Auditez les transmissions. Un coffre-fort montre qui a consulté quoi. Un compte LinkPilot Pro affiche un historique d’audit pour chaque lien secret : vous voyez quand l’ouverture unique a eu lieu et pouvez la rapprocher de la confirmation du destinataire.
Expiration, renouvellement et exposition
Décidez de la fin de vie de l’identifiant avant qu’elle ne commence.
- L’accès temporaire prend fin à la date convenue. Supprimez le compte ou l’appartenance au coffre, et révoquez tout lien à usage unique qui n’a jamais été ouvert.
- Le renouvellement suit le risque, pas seulement le calendrier : après un départ, après un changement de fournisseur, après tout soupçon d’exposition, et à intervalles réguliers pour tout ce qui dure.
- Une fuite soupçonnée est une fuite jusqu’à preuve du contraire. Renouvelez l’identifiant dans le système qui l’accepte, prévenez le responsable et mettez à jour les tâches et services qui dépendaient de l’ancienne valeur. Le guide sur les clés API contient une liste de contrôle pour la rotation qui s’applique à la plupart des types d’identifiants.
Deux outils, une règle pour choisir entre eux, et un responsable pour chaque valeur. C’est tout le système, et il résiste à bien plus de transmissions que n’importe quelle politique de sécurité que plus personne ne lit.