IOSOR Guides

Le trafic sandbox ne doit pas frapper le portefeuille

Une clé Live dans un banc de test est un incident. Détectez la fuite, gelez les holds et rotaez avant le volume pilote.

Le trafic sandbox ne doit jamais ouvrir un prepaid hold. Si une clé Live fuit dans un banc de test, traitez-le comme un incident — pas comme un raccourci pour « voir un vrai DLR plus vite » avant la semaine pilote.

IOSOR attend que les voies de test restent plates sur le portefeuille. Une crédential Live fuitée transforme le CI en moteur de dépense : retries, jobs de charge et scripts de démo débitent comme du trafic pilote. Stoppez la fuite avant de débattre pourquoi le staging « avait besoin » d'une portée production pour une capture. Gardez l'horloge d'incident courte : chaque heure de Live dans le CI est du prepaid irrécupérable après rotation.

Détecter les clés Live sur les chemins de test

Scannez les secrets CI, les hôtes staging et les .env locaux pour des préfixes Live à cadence fixe. Tout hit ouvre un ticket d'incident : révoquez, rotaez et confirmez le même jour qu'aucun hold ouvert ne vient de cette clé.

Incluez les runners partagés et les conteneurs cron oubliés — ils gardent de vieux secrets plus longtemps que les laptops.

Geler les holds nés du trafic Live fuité

Si des jobs de test ont déjà ouvert des holds sur le portefeuille, mettez-les en pause et exportez les lignes coincées avec horodatage. Ne laissez pas le banc continuer à retenter vers un débit Live pendant l'enquête sur le chemin du secret.

Mappez chaque hold coincé à l'id de job qui l'a créé. Cette carte est ce dont la finance a besoin pour savoir si le débit était un « vrai pilote » ou une clé fuitée brûlant du prepaid.

Séparer pics d'abus et erreurs sandbox

Un pic d'abus s'arrête sans faux succès. Une clé Live dans les tests ressemble sur le ledger — les deux exigent un arrêt dur. Étiquetez l'incident pour que fraud ops et developers ne se parlent pas à côté : abus vs fuite de crédential vs staging mal lié.

De mauvaises étiquettes brûlent une journée de chat tandis que les holds vieillissent sur le portefeuille. Mettez l'étiquette dans le titre du ticket avant le premier status update finance.

Re-prouver l'isolation après rotation

Après révocation et rotation, relancez la preuve OTP sandbox avec la clé sandbox seulement. Exportez zéro hold pour cette fenêtre. Seulement alors restaurez l'automatisation staging et les secrets CI pointant vers des crédentials sandbox.

Si la preuve montre encore un hold, stoppez : un autre secret Live reste sur le chemin. Ne rouvrez pas le volume tant que le ledger n'est pas à nouveau plat et le scan propre.

Chemins ops associés

Commencez avec IOSOR

Parcourez chaque hôte de test pour des clés Live. Révoquez toute fuite, exportez les holds ouverts et re-liez le CI au sandbox seulement. Envoyez un OTP sandbox et prouvez que le ledger est resté plat avant de relancer l'automatisation — puis gardez le scan dans la checklist ops hebdomadaire.

À retenir — IOSOR

Une clé Live dans le banc de test est un incident, pas une fonctionnalité. Les voies sandbox doivent laisser le portefeuille plat : détectez et rotaez, gelez les holds, puis prouvez l'isolation avec un OTP sandbox à zéro hold. Ne restaurez pas l'automatisation CI et n'utilisez pas « juste pour voir le DLR » comme excuse pour laisser Live dans le banc.

Ce guide vous a-t-il aidé ?

Guides associés