LGPD Compliance — Engineering Playbook (v6.6.0)

LGPD Compliance — Engineering Playbook (v6.6.0)

Baseado no Guia Avançado de LGPD para Engenharia de Software (ANPD/Lei 13.709/2018) e nas Recomendações de Cookies e Ferramentas de Rastreamento da ANPD.

Esta skill é obrigatória no harness para qualquer feature que processa dados pessoais de cidadãos brasileiros. Aplicada por: backend agent (ao implementar endpoint com PII), lgpd-officer (auditoria fim de sprint), security (revisão profunda).

---

1. Privacidade como Requisito de Engenharia (não conformidade tardia)

LGPD não é checklist ao fim do projeto. É requisito não funcional desde o desenho. Art. 46: medidas técnicas + administrativas + de segurança contra acessos não autorizados, destruição, perda, alteração, comunicação ou tratamento inadequado.

Implicação prática:

• Modelagem de dados começa com minimização (não coleta "caso precise")
• Arquitetura é desenhada com superfície de ataque mínima
• Decisões de stack consideram residência de dados (LGPD art. 33)
• Toda feature com PII passa por DPIA (Relatório de Impacto à Proteção de Dados Pessoais) antes de ir pra produção

Checklist do engenheiro antes de começar:

• Qual a base legal dessa coleta? (consentimento, execução de contrato, legítimo interesse, etc — art. 7º)
• Os dados são estritamente necessários para a finalidade declarada?
• Por quanto tempo esses dados serão retidos? (e há alerta de inatividade?)
• Quem tem acesso (privilégio mínimo)?
• Como o titular exerce os direitos do art. 18?
• Onde os dados moram? Servidor no Brasil? Subprocessador no exterior?

---

2. SDLC (Secure Software Development Life Cycle) e Open Source

LGPD permeia todas as fases do SDLC. Não dá pra "adicionar segurança" no fim.

Integração no pipeline

[Desenho]  →  [Codificação]  →  [Build]  →  [Test]  →  [Deploy]  →  [Produção]
     ↓              ↓                ↓            ↓            ↓
   DPIA          SAST          SCA scan       DAST      Validação    Monitoramento
   minimização   linter        licencias     pen-test   contratos    SIEM
   base legal    secrets       vulns         OWASP      subprocess.  alertas

Análise de Composição de Software (SCA)

Open source acelera entrega mas introduz riscos. Toda dependência nova precisa passar por SCA antes de ir pra package.json.

Ferramentas recomendadas:

Política de equipe:

# Rodar em CI em todo PR
npm audit --audit-level=high
pip-audit --strict
snyk test --severity-threshold=high
npx license-checker --failOn 'GPL;AGPL;SSPL'

Falha em qualquer um = PR bloqueado. Não merge com // @ts-ignore também.

Segurança White Box

White box (ou "chapéu branco") = profissionais com acesso ao código-fonte fazendo auditoria. Presença obrigatória no time se a aplicação trata dados sensíveis (saúde, financeiro, crianças).

White box faz:

• Revisão de código focada em fluxo de dados sensíveis
• Identificação de falhas de lógica (ex: bypass de autorização)
• Modelagem de ameaças contínua (STRIDE, PASTA)
• Capacitação dos devs sobre vulnerabilidades recentes

---

3. Autenticação, Controle de Acesso e Sessão

Primeira linha de defesa. Parâmetros inegociáveis:

Política de senhas (mínimo absoluto)

senha:
  tamanho_minimo: 12 caracteres        # NIST 800-63B recomenda 8+, mas pra PII vai além
  complexidade:
    - maiusculas: 1+
    - minusculas: 1+
    - numeros: 1+
    - simbolos: 1+
  blacklist:
    - "12345678", "password", "qwerty"  # top 100 senhas vazadas
    - variações do nome do usuário
    - variações do email
  expiracao: 90 dias                   # apps normais; menos para apps críticos
  historico: nao repetir ultimas 5 senhas
  lockout: 5 tentativas em 15 min      # rate limit
  hash_algoritmo: argon2id            # NUNCA md5, sha1, bcrypt (depreciado)
  hash_params:
    memory: 64MB                       # ajuste conforme hardware
    iterations: 3
    parallelism: 4

Migração de senhas em sistemas legados

❌ Errado (comum): "a gente importou as senhas antigas e todo mundo terá que redefinir no primeiro login".

✅ Certo:

1. Senha temporária aleatória (16+ chars) gerada server-side
2. Enviada por canal seguro (e-mail com link de ativação, MFA, ou SMS confirmado)
3. Hash novo (argon2id) no momento do primeiro login — NUNCA preservar hash antigo se for fraco
4. Flags must_change_password: true + password_set_at: <agora>
5. Bloqueia features sensíveis até a troca

Cookies e sessão

Logout destrói sessão no servidor, não só no cliente. Session store precisa de método revoke(sessionId).

Tabela técnica completa (do guia)

---

4. Banners de Consentimento (Front-End)

A ANPD publicou diretrizes específicas. Resumo técnico:

Estrutura de 2 níveis (obrigatória)

Banner de 1º nível (primeira visita):

┌─────────────────────────────────────────────────────────┐
│ Este site usa cookies                                    │
│                                                          │
│ Usamos cookies para segurança, analytics e personalização.│
│ Você pode aceitar todos, rejeitar ou gerenciar.          │
│                                                          │
│ [Aceitar Todos]  [Rejeitar Todos]  [Gerenciar Opções]   │
│                                                          │
│ Política de Cookies →                                    │
└─────────────────────────────────────────────────────────┘

Requisitos:

• Os 3 botões com idêntico destaque visual (sem hierarquia tendenciosa)
• "Rejeitar Todos" deve ser tão fácil quanto "Aceitar Todos" (mesmo nº de cliques)
• Link direto pra Política de Cookies
• Idioma do usuário (não só em inglês)

Banner de 2º nível (após clicar em "Gerenciar Opções"):

┌─────────────────────────────────────────────────────────┐
│ Preferências de Cookies                                  │
│                                                          │
│ ☑ Essenciais        (sempre ativos, segurança)           │
│ ☐ Analíticos        (Google Analytics, Hotjar)            │
│ ☐ Funcionais        (preferências de UI)                  │
│ ☐ Publicidade       (ads comportamentais)                 │
│                                                          │
│ [Salvar Preferências]  [Aceitar Todos]  [Rejeitar Todos]│
└─────────────────────────────────────────────────────────┘

Requisitos:

• Essenciais vêm marcados e bloqueados (não dá pra desmarcar)
• Todos os outros vêm desmarcados por padrão (privacy by default)
• Mudança requer ação afirmativa do usuário

Dark patterns PROIBIDOS (ANPD)

❌ Cor chamativa só no botão "Aceitar" ❌ Esconder/disfarçar o botão "Rejeitar" ❌ Cookie wall (bloqueia conteúdo se rejeitar) ❌ Política em idioma estrangeiro ❌ Slider pré-posicionado em "aceitar tudo" ❌ Pré-checked boxes em analytics ❌ "Ao continuar navegando você aceita" (consentimento não é implícito)

CMPs (Consent Management Platforms)

Recomendado usar uma CMP certificada. Líderes de mercado:

• OneTrust — enterprise, multi-jurisdicional
• Cookiebot — SaaS, bom custo-benefício
• Osano — open-core, foco em GDPR/LGPD
• Iubenda — popular em PMEs italianas/brasileiras
• Termly — bom para sites simples

A CMP:

• Detecta e classifica cookies automaticamente (scan periódico)
• Bloqueia tags de analytics/marketing antes do consentimento
• Gera log auditável de consentimento (registro legal pra ANPD)
• Suporta API padrão (IAB TCF v2.2) pra integração com adtech

Implementação:

// Integração típica com CMP
import { onConsentChange } from "@cmp/sdk";

onConsentChange((consent) => {
  if (consent.analytics) enableAnalytics();
  if (consent.marketing) enableMarketingTags();
  // log auditável
  auditLogger.log({
    type: "consent.change",
    userId: hashUserId(currentUser.id),
    choices: consent,
    timestamp: new Date().toISOString(),
    ip: hashIp(req.ip),
  });
});

---

5. Anonimização vs Pseudonimização (Distinção Crítica)

Não confunda. ANPD é explícita: as duas têm consequências jurídicas totalmente diferentes.

Tabela técnica completa (ANPD)

⚠️ Hash NÃO é sinonimo de anonimização

SHA-256 sem salt é vulnerável a ataque de dicionário (rainbow tables públicas cobrem bilhões de CPFs e emails). Para ser seguro:

import { randomBytes, createHash } from "node:crypto";

// ❌ ERRADO: hash sem salt
const hash = createHash("sha256").update(cpf).digest("hex");

// ✅ CERTO: hash com salt único persistido
const salt = randomBytes(16).toString("hex");
const hash = createHash("sha256").update(salt + cpf).digest("hex");
// Armazena { salt, hash } — sem o salt, reidentificar é inviável

Argumento ainda mais forte: prefira HMAC com segredo do servidor (rotacionado periodicamente), que invalida hashes antigos quando o segredo muda.

⚠️ Anonimização NÃO deve ser 100% automatizada

A ANPD recomenda: especialista humano revisa o output do algoritmo. Por quê? Ataques de reidentificação evoluem. Um dataset "anonimizado" hoje pode ser reidentificável amanhã via join com data leaked em outro vazamento.

Protocolo:

1. Rodar técnica automatizada (k-anonimity, l-diversity, t-closeness)
2. Especialista avalia risco residual
3. Se aceitável, certifica e versiona o dataset
4. Reavalia periodicamente (a cada 6-12 meses)

---

6. Ciclo de Vida dos Dados: Soft Delete, Hard Delete e Descarte

Padrão comum de soft delete (marcar is_deleted=true) NÃO atende LGPD art. 18, VI (eliminação dos dados). Titular tem direito à remoção permanente.

Protocolo de 3 fases

Fase 1 — Janela de carência (30 dias típicos)

-- Dia 0: usuário pede exclusão
UPDATE users SET
  is_deleted = true,
  deleted_at = NOW(),
  scheduled_hard_delete_at = NOW() + INTERVAL '30 days',
  account_state = 'pending_deletion'
WHERE id = $1;

• Conta fica desativada, sem acesso, sem marketing
• Permite reverter em caso de arrependimento
• Email automático: "Sua conta será excluída em X dias. Cancele aqui: [link]"

Fase 2 — Ciclo de dormência (recomendado ANPD-like)

Login válido nos últimos 23 meses?  ──sim──→  OK (não toca)
                       │
                       não
                       │
                       ▼
        Enviar email de alerta de inatividade
        (link pra reativar em 30 dias)
                       │
        30 dias depois, sem reativação?
                       │
                       ▼
        Soft delete + iniciar carência de 30 dias
                       │
        30 dias de carência sem reverter?
                       │
                       ▼
        Hard delete (Fase 3)

Fase 3 — Expurgo definitivo (hard delete)

-- Após 30 dias de carência
DELETE FROM users WHERE id = $1;
DELETE FROM user_sessions WHERE user_id = $1;
DELETE FROM user_pii WHERE user_id = $1;
-- ... demais tabelas

Rodar em cron job diário, não on-demand (consistência).

Anonimização na exclusão (preserva integridade referencial)

❌ DELETE em cascata quebra FK de tabelas analíticas/faturamento.

✅ UPDATE que substitui por valores genéricos:

-- Em vez de DELETE FROM users
UPDATE users SET
  name = 'Usuário Removido',
  email = CONCAT('removed_', id, '@deleted.local'),
  cpf = NULL,
  phone = NULL,
  -- mantém id (FK) e created_at (auditoria)
  anonymized_at = NOW()
WHERE id = $1;

Mantém integridade do banco + remove PII.

Expurgo em subprocessadores e IA

Subprocessadores (analytics, email marketing, CRM):

// Webhook ao subprocessador
await fetch("https://api.subprocessador.com/v1/users/delete", {
  method: "POST",
  body: JSON.stringify({ userId: hashUserId(userId) }),
  headers: { Authorization: `Bearer ${process.env.SUB_TOKEN}` },
});

Modelos de ML treinados com dados do titular:

• Botão/API de "untrain expression" (desfaz associação nos embeddings)
• Rerun de feature extraction excluindo o titular
• Re-treino do modelo (se a associação era crítica) — caro mas correto
• Documentar no model-card.md quais titulares foram excluídos

---

7. Logs de Auditoria — Imutabilidade e Cadeia Criptográfica

Logs em arquivo de texto mutável não servem como prova. Atacante com acesso admin pode editar, deletar, alterar timestamps.

Requisitos de infraestrutura

Sincronismo de tempo (NTP):

• Todos servidores sincronizam com ≥ 2 fontes NTP estáveis
• Timestamps sempre em UTC (independente do fuso local)
• Drift máximo aceitável: 50ms

Cadeia de hashes (hash chain):

H_i = SHA-256(Log_i || H_{i-1})

Cada log inclui o hash do anterior. Qualquer adulteração invalida a cadeia a partir do ponto modificado. Implementação no harness já existe em plugins/audit-logger.ts (campo prevHash).

Eventos críticos obrigatórios (tabela ANPD-like):

Storage WORM (Write Once Read Many):

• AWS S3 Object Lock (Compliance mode)
• Azure Blob Immutable Storage
• Google Cloud Storage Bucket Lock
• On-prem: NetApp SnapLock, Veeam, etc

Logs antigos com PII devem ser eliminados após período de retenção (LGPD art. 16 — eliminação segura).

---

8. Shadow AI — O Risco Mais Novo

Engenheiros integrando LLMs (OpenAI, Anthropic, Gemini) sem aprovação do DPO. O harness USA LLM extensivamente, então este risco é diretamente aplicável a nós.

4 riscos fundamentais (do guia)

Risco 1: Transferência internacional indevida (art. 33)

Prompt com CPF/nome vai pra servidor nos EUA → viola LGPD mesmo se "estamos em cloud brasileira" (telemetria global).

Risco 2: Perda de finalidade + falta de transparência

Provedor pode usar prompts pra retreinar modelos. Quebra a finalidade informada ao titular.

Risco 3: Shadow AI (sem inventário)

Dev integra secretamente uma LLM não homologada. Multa de até 2% do faturamento bruto anual por infração.

Risco 4: Explicabilidade (art. 20)

LLM tomou decisão automatizada (negou crédito, barrou usuário) → LGPD exige revisão clara dos critérios. Natureza probabilística complica.

Estratégias de mitigação (do guia)

Estratégia 1: Modelos soberanos / VPC nacional

infra:
  vpc: privada, em região BR
  modelo: self-hosted (Llama, Mistral) OU provider BR homologado
  telemetria: desabilitada
  logs: armazenados em storage nacional
  retention: automatizada por política

Estratégia 2: Pipeline de sanitização de prompts

Microsserviço que intercepta prompt antes de enviar pro LLM:

1. Detecta PII (regex + NLP local)
2. Substitui por placeholder ou hash
3. LLM processa prompt sanitizado
4. Resposta volta com placeholders
5. Reversão: substitui placeholders pelos valores reais

Implementação de referência: tools/lgpd-sanitizer.ts (neste pacote).

---

9. DevSecOps — Integração Contínua de Segurança

Pipeline mínimo

# .github/workflows/security.yml
name: Security
on: [pull_request]

jobs:
  sast:
    steps:
      - uses: github/codeql-action/analyze
      - uses: semgrep/semgrep-action

  secrets:
    steps:
      - uses: gitleaks/gitleaks-action

  deps:
    steps:
      - run: npm audit --audit-level=high
      - run: pip-audit --strict
      - uses: snyk/actions/test

  sca:
    steps:
      - run: npx license-checker --failOn 'GPL;AGPL'

  dast:
    # Roda contra staging
    - uses: zaproxy/action-baseline

Ferramentas por categoria

---

10. Higiene Operacional do Engenheiro

Você (humano) é também vetor de ataque. LGPD considera isso.

Política mínima (do guia)

• ❌ Nunca compartilhar login/senha de staging ou prod
• ❌ Nunca post-it com credencial na mesa
• ❌ Nunca deixar workstation desbloqueada (mesmo "rapidinho")
• ✅ Lock screen automático em 5 min de inatividade
• ✅ Senha única por ambiente (dev ≠ staging ≠ prod)
• ✅ MFA obrigatório em tudo que toca produção
• ✅ Phishing: reportar emails suspeitos via canal oficial
• ✅ Documentos físicos com PII: trancar em armário ou triturar

Capacitação contínua

• OWASP Top 10 atualizado anualmente
• Treinamento de phishing simulado (trimestral)
• Revisão de incidentes recentes (post-mortem compartilhado)
• LGPD updates da ANPD (newsletter, RSS)

Canal de relato de incidentes

Estabelecer fluxo sem punição pra reportar:

• Bug encontrado em código
• Suspeita de vazamento
• Comportamento anômalo observado
• Dependência vulnerável esquecida

LGPD art. 48: notificação à ANPD em 2 dias úteis ao tomar ciência do incidente. Quanto antes souber, antes comunica.

---

11. Checklist de Auto-Auditoria (rodar antes de merge)

## LGPD Self-Audit (pre-merge)

### Privacidade desde o design
- [ ] Base legal identificada pra cada coleta (consentimento, contrato, etc)
- [ ] Dados coletados são estritamente necessários (minimização)
- [ ] DPIA atualizado (se aplicável)
- [ ] Política de privacidade reflete a feature

### Autenticação e acesso
- [ ] Senhas com política robusta (argon2id, 12+ chars, blacklist)
- [ ] Cookies Secure + HttpOnly + SameSite
- [ ] Sessão com expiração adequada
- [ ] Logout destrói sessão no servidor
- [ ] MFA habilitado pra funções sensíveis

### PII em código e logs
- [ ] Nenhum PII em log (mask aplicado)
- [ ] Nenhum secret em código (.env, package.json)
- [ ] Anonimização em ambiente de dev/test
- [ ] Criptografia em repouso pra colunas sensíveis

### Soft/hard delete
- [ ] Soft delete + carência de 30 dias
- [ ] Hard delete via cron job
- [ ] Webhook pra subprocessadores
- [ ] Untrain expression se envolve ML

### Auditoria
- [ ] Eventos críticos logados (acesso, modificação, exclusão)
- [ ] Hash chain configurado
- [ ] Storage remoto (não-local) com WORM
- [ ] Retenção definida e automatizada

### Shadow AI
- [ ] Nenhum LLM third-party sem aprovação do DPO
- [ ] Pipeline de sanitização de prompts (se LLM em uso)
- [ ] Modelo soberano OU provider BR homologado
- [ ] Telemetria de LLM desabilitada

### UI de consentimento
- [ ] Banner 1º nível: 3 botões equivalentes (aceitar/rejeitar/gerenciar)
- [ ] Banner 2º nível: preferências granulares desmarcadas por default
- [ ] Zero dark patterns (botão rejeitar visível, sem cookie wall)
- [ ] CMP integrada e funcionando

---

12. Resumo das Referências Legais e Técnicas

---

13. Ferramentas Fornecidas pelo Harness

---

14. Anti-patterns (revisão rápida)

• ❌ Coletar "caso precise" (viola minimização)
• ❌ Soft delete sem hard delete posterior
• ❌ Cookie wall
• ❌ Botão "rejeitar" escondido
• ❌ Hash sem salt
• ❌ Anonimização 100% automatizada sem revisão humana
• ❌ Logs in arquivo mutável local
• ❌ LLM third-party sem aprovação do DPO
• ❌ Prompt com PII indo direto pra API global
• ❌ Compartilhar login de prod
• ❌ Hardcoded secret em código
• ❌ MFA desabilitado em produção

---

15. Quando Carregar Esta Skill

Sempre carregue ANTES de implementar. Prevenção é 10x mais barata que remediação.