Existe uma suposição confortável de que dados de teste PCI DSS são um assunto menor, porque em desenvolvimento não há dinheiro envolvido. A norma não pensa assim, e o motivo é prático: um número de cartão real copiado para um banco de dados de desenvolvimento continua sendo um dado de cartão real, com o mesmo potencial de fraude e, quase sempre, com menos controle de acesso do que o ambiente de produção.
O ambiente de teste entra no escopo
O conjunto de requisitos de segurança do setor de cartões, hoje na versão 4.x, não se limita aos sistemas que cobram. Ele alcança todo ambiente que armazena, processa ou transmite dados de cartão — inclusive os de teste e homologação, desde que contenham dados reais.
Essa é a chave da questão. A obrigação não nasce do ambiente, e sim do dado. Se o banco de dados de desenvolvimento tem números reais de portadores, ele é tratado como qualquer outro sistema no escopo, com as mesmas exigências de proteção, registro e controle.
Uma consequência frequente é o efeito colateral de uma cópia de produção: alguém restaura um backup para investigar um defeito, e sem perceber traz para o ambiente de teste uma massa de dados que jamais deveria estar ali.
Por que a cópia de produção é o pior cenário
Copiar a base de produção para testar parece eficiente, e é a origem mais comum de problemas. Três fatores se somam:
- O volume de dados reais cresce de uma vez, multiplicando a exposição.
- O ambiente de teste costuma ter menos monitoramento, acessos mais amplos e credenciais compartilhadas.
- Backups de teste raramente seguem a mesma política de retenção e descarte do ambiente principal.
O resultado é um conjunto de dados sensível em um lugar onde ninguém está olhando. É por isso que a orientação geral é substituir dados reais por dados sintéticos ou tokenizados antes de qualquer cópia.
Dados sintéticos, dados tokenizados e mascaramento
As três abordagens resolvem o mesmo problema por caminhos diferentes:
| Abordagem | Como funciona | Quando faz sentido |
|---|---|---|
| Dados sintéticos | Números fabricados que respeitam o formato, sem vínculo com contas | Testes funcionais, demonstrações, suítes automatizadas |
| Tokenização | O número real é trocado por uma referência mantida pelo provedor | Fluxos que precisam simular o mesmo cliente ao longo do tempo |
| Mascaramento | O dado real é parcialmente oculto na exibição e no armazenamento | Interfaces internas e relatórios que só precisam identificar o cartão |
Nenhuma delas é excludente. Um time pode usar dados sintéticos na maior parte dos testes, tokens para cenários que exigem continuidade e mascaramento nas telas administrativas.
Dados sintéticos têm a vantagem de serem descartáveis: se vazarem, não há nada a proteger. É a opção mais simples para desenvolvimento, e a página sobre números de cartão de crédito de teste explica por que eles passam nas validações de formato sem pertencer a ninguém.
Um detalhe prático: quando é necessário exibir um número de cartão em uma tela interna, a prática comum é mostrar apenas os primeiros dígitos e os últimos, ocultando o miolo. O critério costuma ser os seis primeiros e os quatro últimos, que já permitem identificar a bandeira e distinguir dois cartões do mesmo cliente.
O mascaramento precisa valer para a exibição e para o que é gravado em registros de auditoria. Um número completo em um arquivo de log tem o mesmo efeito de um vazamento, ainda que ninguém o veja na tela.
Vale lembrar que o código de segurança tem regra própria e mais rígida: ele não é armazenado após a autorização em nenhuma hipótese, nem mascarado, nem em ambiente de teste com dados reais. Esse ponto está detalhado na página sobre o que é CVV.
Posso usar dados reais se o ambiente for interno?
Não. O fato de o ambiente não ser acessível pela internet muda o nível de risco, mas não altera a classificação do dado. Um conjunto de números reais em uma rede interna continua exigindo os mesmos controles, e a maioria dos times que tenta justificar essa exceção não mantém segregação de funções, registro de acesso e política de descarte no mesmo nível do ambiente principal.
A pergunta útil não é se o ambiente é interno, e sim se existe alguma razão legítima para usar o dado real. Na esmagadora maioria dos casos, a resposta é não: o objetivo do teste é verificar comportamento, e comportamento não depende de o número pertencer a alguém.
O que a norma pede do armazenamento?
Além da proibição de guardar dados de autenticação sensíveis, a norma trata do que pode ser armazenado: dados de conta só podem ser mantidos quando existe necessidade de negócio, precisam estar protegidos e, na exibição, precisam aparecer mascarados.
Para ambientes de teste, a orientação prática é mais direta — não use dados reais. Se não há dado real, não há o que proteger, o que reduz de forma significativa o esforço de conformidade do desenvolvimento.
Este texto é um panorama e não substitui a leitura do documento oficial nem a avaliação de um profissional qualificado. Os requisitos exatos dependem do seu fluxo de pagamento e do seu nível de exposição.
Gerando conjuntos sintéticos
Para não depender de dados reais em nenhuma etapa, você precisa de números bem formados e descartáveis. O gerador de cartão virtual desta página monta número, validade e código de segurança coerentes para a bandeira escolhida, em qualquer quantidade. Os valores são estruturalmente válidos, mas nunca foram emitidos por nenhuma instituição, então não servem para uma cobrança real e não criam obrigação de conformidade alguma.
Para quem desenvolve: isolamento entre ambientes
Alguns cuidados que evitam levar dados reais para o lugar errado:
- Trate a cópia de produção como proibida por padrão, e exija substituição por dados sintéticos ou tokens antes de qualquer restauração.
- Configure o mascaramento na camada de exibição e nos registros, não apenas na interface visível.
- Separe credenciais e chaves entre teste e produção, para que um teste não acesse o ambiente real por engano.
- Defina retenção e descarte para os dados de teste. Dado esquecido em um ambiente antigo continua sendo um risco.
- Verifique o que o seu provedor de pagamento exige para o uso de tokens, como sugere o texto sobre cartões de teste do Stripe.
- Inclua a verificação de exposição de dados na revisão que precede a publicação.
Próximos passos
Se você ainda copia produção para desenvolvimento, substitua essa etapa por dados sintéticos na próxima janela de manutenção; é a mudança de maior impacto e menor custo. Para montar a base de teste agora, use o gerador de cartão virtual e, para revisar o fluxo completo, siga o checklist de teste de formulário de pagamento.