Partage de liens sécurisé pour les développeurs

Pour un ingénieur, le partage de secrets se présente en général à trois moments : l’onboarding, la transmission à un fournisseur et la réponse aux incidents. Voici, du point de vue d’un développeur, quand utiliser un lien à usage unique, quand s’en passer, et comment le créer par script sans laisser fuiter le secret dans l’historique du shell. Pour tester d’abord le principe, le générateur de liens secrets à usage unique gratuit fonctionne sans compte.

Quand un développeur doit-il utiliser un lien à usage unique ?

Quand une personne se trouve à au moins un bout de la transmission et que la valeur ne doit être conservée nulle part ensuite. Les cas habituels :

• Remettre à un nouvel ingénieur son premier jeu d’identifiants.
• Partager un mot de passe administrateur temporaire pendant un incident.
• Remettre à un fournisseur ou à un prestataire un jeton qui n’a pas sa place dans votre coffre-fort.
• Renouveler un identifiant dont l’ancienne valeur doit disparaître rapidement.
• Envoyer à un client la clé API que vous lui avez créée.

Quand ne pas utiliser de lien à usage unique

• Les secrets échangés entre machines. Les variables d’environnement de la CI (les secrets GitHub Actions, par exemple), les Secrets Kubernetes et les identifiants dynamiques de Vault sont la bonne brique dans ce cas. Le lien sert à la transmission humaine vers ces systèmes.
• Les identifiants d’équipe durables. Leur place est dans un gestionnaire de mots de passe.
• La configuration publique. Ne déguisez pas une configuration non secrète en secret. Utilisez un lien ordinaire.

La ligne de partage : si les deux bouts du transfert sont des machines, utilisez le gestionnaire de secrets de votre plateforme. Si au moins un bout est une personne, un lien à usage unique est en général la brique la plus propre.

Le script

LinkPilot dispose d’une API REST (disponible sur tous les forfaits, Free compris). Créer un secret depuis un script ressemble à ceci :

LP_KEY=lp_live_...

URL=$(curl -sS https://api.uselinkpilot.com/v1/secrets \
  -H "Authorization: Bearer $LP_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "payload": "'"$NEW_DB_PASSWORD"'",
    "expires_in": 3600,
    "burn_after_read": true,
    "passphrase": "'"$ONBOARDING_PASSPHRASE"'"
  }' | jq -r '.url')

echo "Secret link: $URL"

Transmettez ensuite cette URL par le canal de remise que vous utilisez déjà : message privé Slack, e-mail, webhook de votre outil d’onboarding.

Garder le contenu hors de la liste des processus

L’extrait ci-dessus a un défaut classique : insérer le contenu dans -d le place sur la ligne de commande de curl, où n’importe quel utilisateur local peut le lire via ps pendant la requête. Construisez plutôt le JSON avec jq et envoyez-le sur stdin avec l’option -d @- de curl :

set -euo pipefail

jq -n --arg payload "$NEW_DB_PASSWORD" \
      --arg pass "$ONBOARDING_PASSPHRASE" \
      '{payload: $payload, expires_in: 3600,
        burn_after_read: true, passphrase: $pass}' |
curl -sS https://api.uselinkpilot.com/v1/secrets \
  -H "Authorization: Bearer $LP_KEY" \
  -H "Content-Type: application/json" \
  -d @- | jq -r '.url'

Trois habitudes à rendre automatiques :

• Les valeurs arrivent par des variables d’environnement ou par la CLI d’un gestionnaire de secrets, jamais saisies dans un shell interactif où elles finissent dans l’historique.
• Le script affiche le lien, jamais le contenu.
• set -euo pipefail, pour qu’un appel d’API en échec ne transmette pas en silence une URL vide à l’étape suivante.

Modèle d’onboarding

Un schéma qui fonctionne bien pour les nouveaux ingénieurs le premier jour :

1. Le script d’onboarding crée les comptes et récupère des identifiants à usage unique.
2. Le script crée un lien secret par identifiant, avec une expiration au bout de 4 heures et une phrase de passe commune.
3. Le script envoie un e-mail contenant tous les liens et un message privé Slack contenant la phrase de passe.
4. L’ingénieur ouvre chaque lien et copie l’identifiant dans son gestionnaire de mots de passe.
5. Tout ce qui n’est pas lu en fin de journée est révoqué, puis renvoyé à son rythme.

Pourquoi ces paramètres : l’expiration au bout de 4 heures couvre une première matinée normale sans laisser d’identifiants actifs pendant la nuit ; la phrase de passe passe par un second canal, si bien qu’un e-mail transféré ou mal adressé est sans danger ; la destruction après lecture fait que la boîte de réception de l’ingénieur ne contient plus, le soir, que des URL inutilisables.

Dites-le clairement à la nouvelle recrue : « chaque lien ne fonctionne qu’une fois, enregistrez la valeur dans votre gestionnaire de mots de passe avant de fermer l’onglet. » L’échec le plus courant à l’onboarding est celui d’un destinataire qui lit le secret, ferme l’onglet et croit pouvoir y revenir plus tard.

Une procédure de renouvellement

Renouveler un mot de passe de base de données partagé, avec un prestataire ou un collègue comme destinataire :

1. Générez le nouveau mot de passe et appliquez-le dans le système source (base de données, console cloud, là où se trouve la valeur de référence).
2. Mettez d’abord à jour vos propres consommateurs (coffre de la CI, secret K8s, configuration de l’application) pour que rien ne casse pendant la transmission humaine.
3. Créez un lien à usage unique pour la nouvelle valeur : destruction après lecture, expiration au bout de 1 heure, phrase de passe.
4. Remettez le lien et la phrase de passe par des canaux différents.
5. Vérifiez l’événement d’ouverture dans l’historique d’audit. Aucune ouverture avant l’expiration ? Révoquez et renvoyez un nouveau lien, ne renvoyez jamais le même.
6. Vérifiez que l’ancien identifiant est désactivé à la source.

Chaque renouvellement a son propre lien. Les liens sont indépendants par conception : c’est un avantage pour la remise et une lacune pour la gouvernance, donc le calendrier de renouvellement se trouve dans votre gestionnaire ou votre procédure, pas dans l’outil de liens.

Réponse aux incidents

Pendant un incident, il faut souvent renouveler un identifiant et distribuer rapidement le nouveau à quelques intervenants. Ne le collez pas dans le canal de l’incident : ce canal est enregistré pour le post-mortem, et le secret finirait dans l’export, dans le document de rétrospective et dans tous les systèmes d’archivage en aval.

• Renouvelez l’identifiant dans le système source.
• Créez un lien secret qui expire au bout de 30 minutes.
• Déposez le lien dans le canal ; envoyez la phrase de passe en message privé.
• Après l’incident, vérifiez que le lien est détruit ou révoqué.

Le post-mortem contient alors une URL inutilisable au lieu d’un mot de passe administrateur actif, et l’historique d’audit fournit en prime à la personne qui relit la chronologie une trace exacte du type « identifiant renvoyé à 14:32, lu à 14:33 ».

Une remarque sur les aperçus de liens : les applications de messagerie chargent les URL collées pour afficher un aperçu. Un lien secret bien conçu y résiste, car le chargement de l’aperçu est un GET et l’affichage du secret un POST explicite. Le fonctionnement complet est décrit dans les scanners de liens et les secrets à usage unique. Si vous évaluez un outil, testez ce point avant un incident, pas pendant.

Que vous apprend la piste d’audit ?

Si un secret a été lu, quand, et à peu près d’où, et si quelqu’un a essayé une mauvaise phrase de passe. Chaque secret LinkPilot porte un historique d’événements : created, viewed, failed_passphrase, burned, expired, revoked. Chaque ouverture est enregistrée avec un horodatage, une géolocalisation approximative quand elle est disponible, le user agent et une adresse IP hachée (SHA-256 avec un sel renouvelé chaque jour ; l’adresse IP brute n’est jamais stockée). Concrètement, vous obtenez trois réponses sur lesquelles scripts et procédures peuvent s’appuyer :

• La confirmation de remise : un événement viewed signifie que la transmission a eu lieu.
• La détection d’anomalies : une rafale de failed_passphrase ou une ouverture que vous ne reconnaissez pas vous signale qu’il faut renouveler l’identifiant immédiatement.
• Une trace nette pour les revues : « remis une fois, lu une fois, détruit » est une phrase qui plaît aux auditeurs.

Limites : ce que les liens ne règlent pas

• Ce n’est pas un coffre-fort. Un lien à usage unique ne gère ni les accès dans la durée, ni les calendriers de renouvellement, ni l’inventaire de qui détient quoi.
• Le lien est la clé. LinkPilot chiffre le texte dans votre navigateur et ne reçoit jamais la clé, mais cette clé voyage dans la partie du lien située après le # : toute personne qui obtient le lien complet peut donc lire le secret, et un lien perdu rend le secret irrécupérable. Les pièces jointes sont chiffrées de la même manière, mais pas leur nom ni leur taille. Une expiration courte et la destruction après lecture restent importantes. Mise à jour du 29 septembre 2026 : ce point indiquait auparavant « ils ne sont pas chiffrés de bout en bout », ce qui était exact jusqu’à cette date. Les détails figurent sur la page architecture de sécurité.
• Ils ne règlent pas la dispersion des secrets dans le code. Les clés écrites en dur dans les dépôts demandent une analyse et un renouvellement, pas un meilleur moyen de remise.
• Ils ne protègent pas l’autre bout. Dès qu’une personne a lu la valeur, considérez qu’elle se trouve partout où cette personne l’a mise.

À lire aussi

• Comment partager des clés API en toute sécurité
• Liens qui expirent : pourquoi les délais courts comptent
• Architecture de sécurité de LinkPilot

Références

• GitHub Docs, Using secrets in GitHub Actions.
• Kubernetes, Secrets.
• jq, Manual.
• curl, Manual page, -d, --data.