Por que cópias de produção são um risco
Cada cópia de produção num ambiente de teste é mais um lugar por onde dados de clientes podem vazar. Sistemas de teste costumam ter acesso mais amplo e controles mais leves que a produção.
Mascarado durante a cópia, não depois
O dbSlice lê a origem, aplica as suas regras de mascaramento a cada linha e só então grava no destino. Não existe uma cópia intermediária sem máscara para limpar depois. Funciona entre bancos diferentes — por exemplo, de um banco de produção em SQL Server para um banco de teste em PostgreSQL.
As chaves ficam intactas, então a aplicação continua funcionando
Uma cópia mascarada só serve se a aplicação conseguir rodar nela. O dbSlice nunca mascara chaves primárias, chaves estrangeiras nem a coluna-chave da operação. Os pedidos continuam apontando para os seus clientes, as notas para os seus pedidos, e os joins devolvem as mesmas linhas que em produção.
Por padrão, todas as outras colunas são mascaradas pelo tipo. Depois você escolhe, coluna a coluna, o que manter e como mascarar o resto.
Opções de mascaramento, por coluna
| Opção | Exemplo | Use para |
|---|---|---|
| Mascarar pelo tipo (padrão) | Johnson → Jo****; números → 0; datas → 1900-01-01 | Tudo o que você ainda não revisou |
| Manter o original | sem mudança | Colunas não sensíveis (status, código do produto) |
| Vazio | NULL | Colunas que o teste nunca lê |
| Manter os primeiros caracteres | keep:4,* → 5511******** | Prefixos de telefone, referências parciais |
| Valor fixo | fixed:Test customer | Observações em texto livre |
| Modelo com a chave da linha | template:user{key}@example.com | E-mails ou logins únicos e legíveis |
| Hash | hash: → mesma entrada, mesmo código de 16 caracteres | Colunas usadas para agrupar ou fazer join que não são chaves estrangeiras |
| Hash com segredo | hash:your-secret (HMAC-SHA256) | O mesmo, sem um código que qualquer um consiga recalcular |
| Esconder os dígitos | 123.456.789-09 → ***.***.***-** | Números de documento que precisam manter o formato |
maria.silva@company.com → ma****@company.com | Manter o domínio para testes de roteamento |
Uma linha de amostra mostra o resultado de cada regra antes de você rodar qualquer coisa. O hash: simples, sem segredo, pode ser recalculado por quem tiver uma lista de valores prováveis (números de documento, por exemplo); use hash:secret nesses casos.
Consistente e difícil de reverter
O tratamento por hash sempre transforma o mesmo valor no mesmo código; então um e-mail ou um número de documento mascarado continua batendo entre tabelas. Acrescente um segredo e o dbSlice usa HMAC-SHA256: sem o segredo, ninguém consegue reconstruir um CPF ou um telefone tentando todos os valores possíveis.
Um job por tabela, rodados em ordem — atualize toda noite
O mascaramento é definido por tabela: monte um job de sincronia para cada tabela que guarda dados pessoais, com o seu mapa de mascaramento, e salve. Rode os jobs primeiro as tabelas pais, depois as filhas, pela CLI ou pelo Agendador de Tarefas do Windows, toda noite ou antes de cada ciclo de testes. O mapa é salvo com o job; então as mesmas regras valem toda vez. O mesmo mapa também funciona quando você exporta para um arquivo (CSV, JSON, SQL, Excel e outros) em vez de copiar para um banco.
Tabelas sem nada sensível (catálogo de produtos, status, tabelas de apoio) podem passar pelo Replicador, que copia uma lista de tabelas numa execução, as pais antes das filhas. Numa atualização completa, ele esvazia as tabelas de homologação na ordem das chaves estrangeiras e se recusa antes de excluir qualquer coisa se a lista estiver incompleta. O Replicador copia os valores como estão: ele não aplica mascaramento; então deixe fora dele as tabelas com dados pessoais.
Escolha a fatia com um filtro WHERE em cada tabela (últimos 90 dias, uma região, um cliente). Os filtros são por tabela: garanta que as tabelas filhas sejam filtradas de forma coerente com as pais, ou as chaves estrangeiras na homologação vão apontar para linhas que você não copiou.
Precisa de dados que nunca existiram?
Quando até os dados de produção mascarados são demais, o gerador de dados sintéticos cria linhas fictícias que seguem os tipos e as chaves estrangeiras da tabela: nomes, e-mails, cidades, telefones, datas numa faixa, valores de uma lista. Veja Dados sintéticos de teste.
Entre bancos diferentes
Produção em SQL Server e homologação em PostgreSQL? Produção em Oracle e um SQLite local para o notebook de um desenvolvedor? A cópia mascarada funciona em qualquer par entre SQL Server, PostgreSQL, Oracle, MySQL, MariaDB, Firebird, SQLite e InterSystems Caché/IRIS.
A sua responsabilidade, dita com clareza
O dbSlice aplica as regras que você define. Ele não decide sozinho quais colunas são dados pessoais, e usá-lo não torna um processo conforme por si só. O mascaramento reduz o que sai da produção; a sua equipe de segurança e privacidade continua decidindo quais colunas são dados pessoais segundo as leis e os contratos que se aplicam a vocês. Revise o mapa de mascaramento com quem responde pela proteção de dados na sua empresa, e guarde as definições dos jobs onde possam ser auditadas. O dbSlice não envia os seus dados para lugar nenhum: ele roda na sua máquina Windows e conecta direto nos seus bancos.
Copiar com mascaramento grava no destino; por isso, exige uma licença Desktop ou Server. Preços