Poświadczenia sandbox, które nie spalają debetu Live

Poświadczenia sandbox istnieją, by engineering mógł wysyłać ruch testowy bez dotykania ledgeru prepaid. Debet Live z klucza sandbox musi być niemożliwy — to nie miękkie ostrzeżenie w README, którego nikt nie czyta podczas incydentu.

IOSOR traktuje sandbox jako osobną postawę kredytową: testowe OTP i alerty mogą przechodzić w torze sandbox, podczas gdy portfel pozostaje płaski. Jeśli hold lub debit pojawi się z klucza oznaczonego sandbox, poświadczenie ma zły scope i trzeba je unieważnić przed kolejnym CI.

Oddziel klucze sandbox od holdów Live

Utwórz w Developers klucz sandbox, który nie otwiera holdu prepaid. Udowodnij, że testowe OTP w torze sandbox kończy się sukcesem przy zerowym debecie portfela i zerowym MRC w tej samej minucie. Wyeksportuj ledger tego okna i trzymaj dowód obok id klucza.

Jeśli pojawi się wiersz hold — natychmiast unieważnij klucz i traktuj to jako defekt poświadczenia, nie niestabilny test. Wydaj ponownie poprawnie scopowany klucz sandbox i powtarzaj dowód, aż ledger zostanie płaski.

Podłącz CI i staging tylko do scope’ów sandbox

Zmienne continuous integration i staging wskazują wyłącznie na poświadczenia sandbox. Nigdy nie wklejaj klucza Live do sekretu GitHub, docker-compose, .env laptopa do demo ani wspólnego folderu menedżera haseł z etykietą „test”.

Rotuj każdy klucz Live, który pojawił się w harnessie testowym. Zapisz czas rotacji, by finanse mogły zestawić zbłąkany debit z oknem wycieku. Hosty staging, które po rotacji nadal trzymają sekret Live, obalają kolejną bramkę deploy.

Udowodnij izolację debetu przed pierwszym pilotem

Wyeksportuj ledger okna wysyłki sandbox przed zaproszeniem hosta pilotażowego. Potwierdź: brak holdu, brak debetu, brak ścieżki Live z klucza sandbox. Udokumentuj dowód obok id klucza na audyt finansów.

Powtórz eksport po pierwszym tygodniu CI, by drift nie wrócił cicho z kluczem Live przez zapomnianą zmienną workflow.

Nawyki cutover zostają pod Developers

Przy promocji buildu idź za checklistą Live-cutover w Developers — nowy klucz Live, odwołanie sandbox z hostów produkcyjnych, smoke świeżości vault przed zielonym runway. Nie używaj sekretu sandbox jako tymczasowego klucza Live „tylko na pilota”.

Cutover to zmiana poświadczeń plus kontrola ledgeru, nie flip flagi w konfiguracji. Trzymaj cele webhook i id kluczy w tym samym środowisku, które deklarujesz na runway board.

Powiązane ścieżki ops

Trzymaj cutover i uczciwość coverage obok siebie, by zespoły nie wymyśliły trzeciej historii kluczy:

• przejście z sandbox na produkcję
• Weryfikacja różnic w zasięgu między środowiskiem sandbox a produkcją
• Tydzień pilotażowy portfela: blokady i obciążenia na żywo

Zacznij z IOSOR

W Developers wydaj klucz sandbox, wyślij jedno OTP na uzgodniony testowy E.164 i wyeksportuj ledger tej minuty. Potwierdź zero hold i zero debit. Przypnij CI do tego id klucza. Dopiero potem żądaj klucza Live dla hosta pilotażowego i odwołuj sandbox z każdego hosta, który poniesie ruch Live.

Podsumowanie IOSOR

O «Poświadczeniach sandbox, które nie spalają debetu Live»: izolacja jest produktem. Klucz sandbox, który może otworzyć hold, to defekt, nie wygoda. Trzymaj CI na scope’ach sandbox, udowodnij płaski ledger przed pilotem i traktuj cutover jako zmianę poświadczeń plus kontrolę ledgeru pod Developers — nigdy nie używaj sekretu sandbox jako tymczasowego Live.