Sandbox e produção separados: chaves, webhooks e storage por ambiente

Todo fornecedor sério de verificação de identidade oferece um sandbox, e já tratamos em outro artigo de por que testar nele antes de ir para produção. Este artigo cuida do problema seguinte, que aparece justamente em quem usa bem o sandbox: manter os dois ambientes separados de verdade, do primeiro dia da integração até muito depois do go-live.

A mistura de ambientes quase nunca nasce de incompetência. Nasce de pressa em dia de entrega: a variável de configuração apontada para o lugar errado, a credencial copiada "só para reproduzir o bug", o endpoint de teste que sobrou numa configuração de produção. Cada um desses deslizes é pequeno, e é exatamente por isso que a separação não pode depender de atenção; precisa estar no desenho, de forma que o erro humano esbarre numa parede antes de virar incidente.

O custo da mistura é assimétrico e sempre desagradável. Evento de teste processado como real movimenta o que não devia. Dado real copiado para teste espalha dado pessoal por onde ele não devia existir. E credencial de produção em ambiente frouxo é a receita clássica de vazamento.

Os acidentes de ambiente misturado

Três acidentes cobrem a maior parte dos casos reais. O primeiro é a credencial trocada: a chave de produção colada no ambiente de desenvolvimento, commitada no repositório junto com o código de teste, e a partir daí exposta a todo mundo que lê o repositório. O segundo é o evento que atravessa: o webhook de produção configurado no fluxo de teste, e o sistema real creditando, liberando ou notificando por causa de uma simulação. O terceiro é o dado que desce: a cópia de produção usada como massa de teste, porque "precisava de dado realista".

O terceiro merece nome próprio: dado pessoal real em ambiente de teste continua sendo tratamento de dado pessoal. A Lei Geral de Proteção de Dados, a Lei 13.709/2018, não tem cláusula de exceção para ambiente de homologação: as medidas de segurança do artigo 46 valem lá também, e o princípio da necessidade do artigo 6º, inciso III, pergunta o que o teste realmente exigia. Quando dado sintético bastava, e em teste de integração ele quase sempre basta, o dado real é tratamento sem necessidade, num ambiente tipicamente menos protegido que o de origem.

Credencial que declara o ambiente

A primeira parede é a credencial que carrega o ambiente de forma explícita e legível. Quando a chave de teste e a chave de produção são visualmente distintas, o erro aparece no olho durante o code review e, mais importante, pode ser bloqueado em código: a aplicação de produção recusa subir com chave de teste, e o ambiente de teste recusa chave de produção. É uma verificação de uma linha que transforma o deslize silencioso em erro barulhento de inicialização.

A metodologia The Twelve-Factor App, publicada pela equipe da Heroku, formaliza o princípio que sustenta isso: configuração que muda entre ambientes vive no ambiente, nunca no código. Credencial em variável de ambiente, com valores distintos por ambiente, é o que permite o mesmo código rodar nos dois lugares sem nenhum "if de ambiente" espalhado, e é o que impede a chave de ir parar no repositório.

Webhook e mídia: a separação desce até o fim

A segunda parede é a segregação dos canais de saída. Webhook se configura por ambiente: o endpoint que recebe eventos de teste é um, o que recebe eventos de produção é outro, e evento de um ambiente jamais alcança o endpoint do outro. Sem isso, o dia de testes de alguém vira ruído, ou prejuízo, no sistema real. O mesmo vale na direção inversa: o consumidor de produção deve tratar como anomalia grave qualquer evento que se identifique como teste, se um dia chegar.

A terceira parede é a menos lembrada: os dados em repouso. Base de dados separada é o óbvio; o storage de mídia é onde a mistura se esconde. Selfies e documentos enviados no ambiente de teste não devem morar no mesmo espaço lógico que a mídia de produção, porque rotina de limpeza, política de retenção e controle de acesso são diferentes entre ambientes, e um balde compartilhado acaba aplicando a política errada a alguém. Os cuidados de upload seguro de mídia valem para os dois ambientes; a segregação garante que um não herde os riscos do outro. Na UNIFOKAL, por exemplo, a chave de API declara o ambiente, o webhook é configurado por ambiente, o sandbox responde de forma determinística e a mídia de cada ambiente fica separada também no storage.

Dado sintético é melhor massa de teste

A tentação de copiar produção para teste vem de uma necessidade legítima: cenários realistas. A resposta melhor é o sandbox determinístico: cenários nomeados que produzem sempre o mesmo resultado, aprovação, recusa, revisão, erro de captura, permitem automatizar a suíte de integração sem depender de sorte nem de dado de gente real. Determinismo é, inclusive, um critério de avaliação de fornecedor: sandbox que responde de forma aleatória não sustenta teste repetível.

É a paridade entre ambientes que a The Twelve-Factor App recomenda, obtida por contrato igual, nunca por dado compartilhado. Com dado sintético, o ambiente de teste deixa de ser um cofre mal trancado com joias de verdade dentro. O que vazar de lá não expõe ninguém, e a conversa com o encarregado de dados fica mais curta.

O corte do go-live

O momento de maior risco de mistura é a virada para produção, porque é quando as duas configurações coexistem nas mãos das mesmas pessoas. O corte limpo é um checklist curto, executado de uma vez e conferido por uma segunda pessoa, na linha do que um checklist de homologação mais amplo já organiza:

• trocar todas as credenciais da aplicação para as de produção, sem reaproveitar nenhuma de teste;
• apontar o webhook de produção e confirmar a assinatura dos eventos no endpoint real;
• varrer a configuração de produção em busca de qualquer URL, chave ou flag de teste que tenha sobrado;
• rodar um teste de fumaça com um caso real controlado, de ponta a ponta, antes de abrir o funil;
• revogar acessos de teste que não devem existir em produção.

Depois do corte, a disciplina é contínua: credencial nova sempre nasce no ambiente certo, e qualquer reprodução de bug com dado real acontece no próprio ambiente de produção, com o acesso controlado de lá, nunca por cópia para baixo. Ambiente separado não é burocracia de gente grande; é o que faz o erro de terça-feira à noite custar um susto, e não um incidente.

Fontes citadas

• Lei 13.709/2018, Lei Geral de Proteção de Dados, artigos 6º, III (princípio da necessidade) e 46 (medidas de segurança), no portal do Planalto: planalto.gov.br
• The Twelve-Factor App, metodologia publicada pela equipe da Heroku, fatores de configuração no ambiente e de paridade entre desenvolvimento e produção, citada por nome.