IOSOR Guias
Tráfego sandbox não deve bater na carteira
Uma chave Live em harness de teste é incidente. Detecte vazamento, congele holds e rotacione antes do volume piloto.
Tráfego sandbox nunca deve abrir um prepaid hold. Se uma chave Live vaza para um harness de teste, trate como incidente — não como atalho para «ver DLR real mais rápido» antes da semana piloto.
A IOSOR espera que as faixas de teste fiquem planas na carteira. Uma credencial Live vazada transforma o CI em motor de gasto: retries, jobs de carga e scripts de demo debitam como tráfego piloto. Pare o vazamento antes de debater por que o staging «precisava» de alcance de produção para um print. Mantenha o relógio do incidente curto: cada hora de Live no CI é prepaid que não volta após rotate. Nomeie o dono da chave no ticket antes do primeiro comentário financeiro.
Detecte chaves Live em caminhos de teste
Varra secrets de CI, hosts de staging e .env locais em busca de prefixos Live em ritmo fixo. Qualquer acerto abre ticket de incidente: revogue, rotacione e confirme no mesmo dia que não há hold aberto dessa chave.
Inclua runners compartilhados e containers cron esquecidos — eles guardam secrets antigos mais tempo que laptops. Publique o dono do scan para o ticket não saltar entre developers e fraud ops o turno inteiro.
Congele holds gerados por tráfego Live vazado
Se jobs de teste já abriram holds na carteira, pause-os e exporte as linhas travadas com timestamps. Não deixe o harness continuar a retentar para débito Live enquanto investiga o caminho do segredo.
Mapeie cada hold travado ao job id que o gerou. Esse mapa é o que o financeiro precisa quando perguntar se o débito foi «piloto real» ou chave vazada queimando prepaid.
Separe picos de abuso de erros sandbox
Um pico de abuso para sem falso sucesso. Uma chave Live em testes parece semelhante no ledger — ambos exigem parada dura. Rotule o incidente para que fraud ops e developers não falem paralelo: abuso vs vazamento de credencial vs staging mal vinculado.
Rótulos errados queimam um dia de chat enquanto holds envelhecem na carteira. Coloque o rótulo no título do ticket antes do primeiro status update para o financeiro.
Reprove o isolamento após a rotação
Após revoke e rotate, rode de novo a prova OTP sandbox só com a chave sandbox. Exporte zero hold na janela. Só então restaure automação de staging e secrets de CI que apontam para credenciais sandbox.
Se a prova ainda mostra hold — pare: sobrou outro segredo Live no caminho. Não reabra volume até o ledger voltar plano e o scan limpo.
Caminhos operacionais relacionados
- corte de sandbox para produção
- Incidente de carteira: uma retenção travada não é um segundo débito
- Pico de abuso: interrupção sem falso sucesso
Comece com a IOSOR
Varra cada host de teste em busca de chaves Live. Revogue qualquer vazamento, exporte holds abertos e religue o CI só ao sandbox. Envie um OTP sandbox e prove que o ledger ficou plano antes de reiniciar a automação — e deixe o scan na checklist ops semanal.
Conclusão IOSOR
Chave Live no harness de teste é incidente, não recurso. Faixas sandbox devem manter a carteira plana: detecte e rotacione, congele holds e prove isolamento com OTP sandbox de zero hold. Não restaure automação de CI nem use «só para ver o DLR» como desculpa para deixar Live no harness.
Este guia foi útil?
Guias relacionados
- Credenciais sandbox que não queimam débito Live
Emita chaves API sandbox que nunca retêm nem debitam a carteira pré-paga. Mantenha chaves Live fora do CI e prove o cutover em Developers.
- Alcance sandbox não é cobertura de produção
Destinos sandbox são só para testes. Nunca os cite como zonas Live numa folha financeira ou num score de runway.