Après une fuite de variables d'environnement, pourquoi la nouvelle clé ne doit pas retourner dans le chat

Fin août 2026, la plateforme de déploiement cloud Zeabur a publié un incident intitulé « Unauthorized Access to Project Environment Variable Data ». La page de statut officielle indique que l'attaquant a utilisé un identifiant administratif AWS interne divulgué, a atteint la base principale, puis a lancé des requêtes et des exports ciblés sur les Variables des projets. La cible déclarée : des clés API de services d'IA et d'autres identifiants utilisables immédiatement.

La même page liste des noms de clés exposés, dont OPENAI_API_KEY, ANTHROPIC_API_KEY, OPENROUTER_API_KEY, DATABASE_URL, AWS_ACCESS_KEY_ID, ainsi que des formes courantes JWT, Stripe et GitHub. Les noms de variables personnalisés ont été comptés comme exposés dès que la valeur correspondait à ces formats d'identifiants. Zeabur a demandé aux utilisateurs concernés de révoquer et de remplacer les identifiants listés, puis de contrôler l'usage et les factures chez les tiers. Une capture circulant d'un « jeu de données complet à vendre » est traitée comme non vérifiée : la page de statut dit que les preuves en leur possession ne soutiennent pas cette affirmation, et cet article ne la tient pas pour un fait établi.

Face à ce type d'incident, la trousse de premiers soins est toujours la même : révoquer l'ancienne clé, contrôler l'usage, en tourner une nouvelle. Le premier tour a déjà eu lieu chez l'hébergeur. Vous ne pouvez pas retirer une chaîne des mains de quelqu'un d'autre. L'étape que les équipes sautent est le second tour : une fois que la console du fournisseur affiche une nouvelle clé, il faut encore la donner à un collègue, la coller sur une autre machine, ou la déposer dans un ticket temporaire. Si ce saut passe par une fenêtre de chat, le « texte en clair tout juste tourné » est écrit dans un enregistrement que l'on peut chercher, synchroniser, et qu'un administrateur peut exporter.

Le nom de la plateforme ne sert ici qu'à ancrer une date et un document public. La conclusion vaut pour tout travail « tourner, puis transmettre » : mot de passe de base, jeton CI, mot de passe SSH temporaire. Le danger n'est pas que le collègue voie le secret. Le danger, c'est que chaque saut puisse garder une copie complète en clair. Cet article ne reconstruit pas le plan de durcissement d'un hébergeur, et il ne présente pas UsePwd comme un coffre qui aurait pu empêcher la lecture côté plateforme.

Collez une chaîne qui commence par sk- dans un canal, et plusieurs copies apparaissent d'un coup. Le corps du message entre dans l'historique de l'espace de travail. Le client bureau et le téléphone gardent chacun un cache. Beaucoup de produits envoient aussi le texte dans un index de recherche côté serveur, pour qu'on puisse taper « openai » trois mois plus tard et le récupérer. Les exports d'administrateur, les conservations légales, et l'étape « emballer l'archive de chat » au départ d'un collègue emportent ce texte en clair avec eux. Supprimer une bulle n'efface en général ni la notification déjà lue chez l'autre, ni une bibliothèque client déjà téléchargée, ni l'image qu'un outil de capture a déjà enregistrée.

Ce n'est pas le même problème que « je fais confiance à mon collègue ». Le collègue a besoin de la nouvelle clé pour relancer le service. Le canal, par défaut, stocke un enregistrement de travail consultable, pas un secret qui ne devrait exister que le temps d'être lu. Écrire « nouvelle clé ci-dessous » dans un canal, c'est aussi prévenir tous ceux qui pourront le chercher plus tard : les personnes invitées le trimestre suivant, quiconque a un droit d'export d'audit, et celui qui pourra atteindre une sauvegarde dans le futur. Les guides de secrets-scanning traitent cela comme un chemin d'éparpillement connu ; un rappel français sur secret compromis insiste d'abord sur la révocation, puis sur la rotation — coller la nouvelle clé dans le même canal indexé, c'est rouvrir une fenêtre d'exposition juste après l'avoir fermée. Le guide 2026 de gestion des secrets range d'ailleurs le « partage en clair via Slack, e-mail ou ticket Jira » parmi les anti-patterns récurrents.

Étalez une runbook d'urgence typique sur la table : le danger n'est pas « se connecter à la console du fournisseur et créer une nouvelle clé ». Ce sont les étapes autour de ce clic. Quelqu'un capture l'ancienne clé et demande à un collègue « c'est bien celle-là ». Quelqu'un photographie toute la page de console, si bien que la barre d'adresse, d'autres noms de projet et un chiffre de facturation atterrissent ensemble dans Photos. Quelqu'un crée la nouvelle clé, le collègue n'est pas à son bureau, et le canal reçoit « utilise ça pour l'instant ». Les trois transforment le texte en clair en un objet qu'on va conserver.

Les disques partagés et Git sont plus faciles à rater. Un .env brut déposé dans un dossier d'équipe, ou un commit d'exemple qui contient encore une clé, est une autre copie. La synchro cloud écrit ce fichier sur chaque appareil déjà connecté. Changer le fichier plus tard n'efface pas la chaîne des anciens commits Git. Une sauvegarde locale d'un fichier unique jusqu'à 5 GB devrait d'abord être transformée en texte chiffré dans l'onglet actuel, au lieu d'envoyer un .env en clair comme un document ordinaire. Chiffrer un fichier de UsePwd fait un chiffrement local en flux avec AES-256-GCM et écrit .lock / .enc. Le fichier n'est pas envoyé par défaut. C'est « garder soi-même un fichier chiffré », pas « fourrer la clé dans le chat ».

Une fenêtre de chat remet du texte en clair. Copier est facile des deux côtés. Le coût, c'est que l'espace de travail, l'index de recherche et les sauvegardes tiennent chacun une copie. Les pièces jointes d'e-mail fonctionnent de la même façon : une fois un .env ou un fichier bloc-notes joint, le serveur de messagerie et les deux clients ont le fichier entier.

Un lien chiffré à usage unique remet « un identifiant de texte chiffré plus un matériau de déchiffrement qui reste sur l'appareil ». Burn-Link de UsePwd chiffre le texte dans l'onglet actuel avec Web Crypto et AES-256-GCM, puis n'envoie au serveur que le texte chiffré. La clé de déchiffrement est accrochée après # dans s.html?id={id}#{key}. Création et lecture s'ouvrent tout de suite — aucun des deux côtés ne s'inscrit. Le serveur stocke le texte chiffré, une durée en heures et un nombre de lectures. Il ne voit pas le texte en clair, et il n'existe pas de comptes pour « le retrouver par utilisateur ».

Placer la clé après # vise les journaux d'accès de l'hébergeur et la ligne de requête HTTP : le navigateur n'envoie pas le fragment comme partie de la requête. Cette couche est détaillée dans Pourquoi le fragment # d'une URL n'apparaît pas dans les journaux serveur. Cet article traite la couche suivante. Même si la clé n'entre jamais dans une ligne de requête UsePwd, coller le lien complet dans le chat stocke toute l'adresse dans ce produit de chat. Quiconque a l'URL entière peut ouvrir la page de lecture et déchiffrer tant que le nombre de lectures n'est pas épuisé. Burn-Link limite la durée de vie du texte chiffré sur le serveur, et le nombre de lectures. Il n'empêche pas le destinataire de faire une capture ou de transférer le lien.

Si le secret doit être conservé longtemps, synchronisé entre plusieurs appareils, ou retrouvé plus tard, n'utilisez pas Burn-Link, et ne traitez pas l'historique de chat comme un coffre. C'est le travail d'un gestionnaire de mots de passe. UsePwd ne fournit ni compte ni coffre. Lectures épuisées ou lien perdu : il ne peut pas restaurer le secret pour vous.

Si le secret est une clé maître de grande valeur, un certificat racine, ou une phrase de récupération de portefeuille capable de déplacer des fonds, ni un lien ni un canal de chat ne suffisent. Dites-le en personne, utilisez un support hors ligne, ou restez dans un canal de bout en bout déjà établi. Un schéma à fragment n'arrête ni une machine déjà compromise, ni une extension de navigateur qui peut lire la page actuelle, ni une URL complète projetée sur le mur d'une salle de réunion.

La sauvegarde de fichier est un autre chemin : transformez un .env en clair en .lock / .enc sur cette machine, puis placez le texte chiffré sur un disque. Passez le mot de passe de déverrouillage par un canal qui n'est pas le fichier lui-même. Ne fusionnez pas les deux outils en une seule promesse. Burn-Link gouverne le nombre de lectures d'un secret court. Chiffrer un fichier gouverne un fichier chiffré que vous gardez.

Revenons à la question. Après le vol de variables d'environnement sur une plateforme cloud, les anciennes clés doivent être révoquées. Il n'y a pas de raccourci. La nouvelle clé ne doit pas retourner dans une fenêtre de chat, parce que le chat, par défaut, stocke du texte en clair consultable, et que le sens de la rotation est de faire mourir tout de suite l'ancienne chaîne — vous ne devriez pas, dans la même minute, fabriquer une copie qui vivra plus longtemps. Quand un collègue en a besoin une fois, utilisez Burn-Link : chiffrement local, ouvert tout de suite. Quand vous avez besoin d'une sauvegarde que vous gardez vous-même, utilisez Chiffrer un fichier. Les deux pages, comme cet article, n'ont à droite de la barre supérieure qu'un sélecteur de langue. Il n'y a pas de connexion.