Guia LGPD + DevOps
Como garantir conformidade com a LGPD em ambientes de teste?
O caminho mais limpo é substituir dados reais por dados sintéticos gerados matematicamente - assim seu ambiente de teste sai do escopo da LGPD (art. 5 I). As outras rotas (mascaramento, anonimização de produção) funcionam mas exigem controles adicionais e LIA documentado. Guia com 3 estratégias comparadas, 6 controles obrigatórios e checklist auditável.
TL;DR
- 🥇 Melhor rota: dado sintético 100% gerado. Sai do escopo LGPD, zero fricção, custo baixo.
- 🥈 Rota do meio: mascaramento irreversível de dado real. Ainda cai em LGPD mas com risco baixo.
- 🥉 Rota mais arriscada: cópia direta de produção com controles. LIA obrigatório + acesso restrito + log.
- 🚨 Nunca: copiar produção pra staging aberto ao time inteiro sem controle. Isso vira multa ANPD.
3 estratégias comparadas
Estratégia 1 - Recomendada
Dados sintéticos
- Gera via algoritmo (mod-11, Luhn)
- Não corresponde a pessoa real
- Sai do escopo LGPD
- Zero fricção pra devs
Custo: ~R$29-99/mês com FakeForge ou equivalente
Estratégia 2 - Aceitável
Mascaramento
- Copia produção + mascara campos
- CPF vira "XXX.XXX.XXX-XX"
- Ainda cai em LGPD (reduziu risco)
- Requer LIA documentado
Custo: engenharia + controles operacionais
Estratégia 3 - Arriscada
Cópia direta de produção
- Staging = mesmo dado de prod
- Acesso ao time inteiro = risco alto
- LGPD art. 46 (segurança) exige controles
- Multa ANPD até R$50M em vazamento
Só justifica pra time pequeno + isolamento forte
Os 6 controles obrigatórios (qualquer rota)
Documentar base legal + finalidade
Registre por escrito qual base legal do art. 7 LGPD cobre o tratamento em teste (interesse legítimo é o padrão). Descreva finalidade específica: "popular staging pra teste de regressão do checkout." DPO precisa dessa documentação.
Restringir acesso ao ambiente de teste
Staging que contém dado real (mesmo mascarado) precisa mesmo controle de acesso da produção: SSO, MFA, IP whitelist, log de sessão. Staging aberto ao time inteiro sem controle = vulnerabilidade LGPD.
Política de retenção curta
Dado copiado de prod pra staging tem que ter TTL: máximo 30 dias, idealmente 7. Reset periódico do banco staging + reload de dado sintético ou mascarado fresh. Documente o cron no runbook.
Log de acesso e auditoria
Todo acesso a banco de teste com dado real logado: quem, quando, qual query, quantas rows retornadas. Retenção do log 6 meses mínimo. Vai ser pedido em auditoria ANPD ou LGPD assessment.
Não commitar dado em repositório
Fixtures de teste com CPF/email/telefone nunca vão pro Git público. Use fixture local + .gitignore, secrets manager pra keys de acesso ao SDK/API do gerador, ou regenere em CI on-the-fly.
Plano de resposta a incidente
Se dado de teste vazar (repo público acidental, S3 mal configurado, backup roubado), tem que ter runbook: notificar DPO em 4h, avaliar risco, notificar ANPD em 72h se necessário (art. 48). Sem esse plano, multa dobra.
Checklist auditável (imprimível pra DPO)
Exemplo: substituição total por sintético
Rota mais limpa: descartar cópia de produção e gerar 100% sintético via SDK do FakeForge no CI.
# .github/workflows/staging-refresh.yml
name: Reset staging with synthetic data
on:
schedule:
- cron: "0 3 * * *" # Todo dia 3h AM (política retention)
workflow_dispatch:
jobs:
refresh:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Truncate staging
run: psql $STAGING_URL -c "TRUNCATE users, orders CASCADE;"
- name: Generate synthetic data via FakeForge
env:
FAKEFORGE_KEY: ${{ secrets.FAKEFORGE_KEY }}
run: |
npm install fakeforge-br
node scripts/seed-staging.jsVantagem: staging sempre com dado fresh e 100% sintético. Zero base legal LGPD necessária. Zero log de acesso obrigatório pra staging (não é dado pessoal). DPO fica feliz.
FAQ
Copiar banco de produção pra staging é permitido pela LGPD?+
Não é proibido, mas exige base legal (interesse legítimo geralmente cobre) + controles: acesso restrito ao mesmo nível de produção, log de acesso, retention curta (idealmente <30 dias), e mascaramento dos campos sensíveis LGPD art. 5 II. A prática recomendada é substituir por dados sintéticos pra evitar toda essa complexidade regulatória.
O que é dado sintético e por que resolve o problema LGPD?+
Dado sintético é gerado matematicamente (via algoritmos como mod-11 pra CPF ou Luhn pra cartão) sem corresponder a pessoa real. Como não identifica pessoa natural, sai completamente do escopo LGPD (art. 5 I). Você pode gerar, distribuir e usar sem base legal, sem consentimento, sem log de acesso. Ferramentas como FakeForge produzem esses dados.
Mascaramento (data masking) é suficiente pra LGPD?+
Depende do método. Mascaramento reversível (tokenização com chave) ainda é dado pessoal pela LGPD - só reduz risco de vazamento. Mascaramento irreversível (hash sem chave, ou substituição por dado sintético) tira do escopo. Para testes, prefira substituição total por dado sintético.
Preciso do consentimento pra usar dado real em ambiente de teste?+
Se usar dado real, precisa de base legal. Consentimento específico pra teste é impraticável. Interesse legítimo pode cobrir se você fizer LIA (Legitimate Interest Assessment) documentado + controles proporcionais. Mais simples: use dado sintético e sai do problema.
E dado sensível LGPD art. 5 II (saúde, financeiro, biometria)?+
Regras mais rígidas. Consentimento específico ou base legal do art. 11 obrigatório. Em teste, jamais use dado real - sempre gere sintético. FakeForge não gera dado de saúde/biometria, mas gera CPF/CNPJ/PIX/cartão sintéticos que não caem em art. 5 II.
ANPD já aplicou multa por dado real em staging?+
Sim. Casos documentados envolvem: (1) banco de dev exposto no S3 público, (2) empresa que compartilhou staging com fornecedor sem DPA (Data Processing Agreement), (3) log de acesso ausente em vazamento. Multa até 2% do faturamento (máximo R$50M por infração).
Próximos passos
Este guia é informativo e não substitui parecer jurídico. Consulte DPO/advogado se sua operação envolver dado de saúde, financeiro regulado BACEN, biometria ou dado sensível LGPD art. 5 II. Última atualização: setembro/2026.