Pular para o conteúdo
NoSqlStudio
Documentação

DataMask

Mascare dados de produção para dev/staging sem perder integridade referencial. Seeds determinísticas derivadas por KMS (fallback HKDF), detecção PII baseada em ML, preview dry-run, verificação k-anonymity, e handshake de audit assinado em Ed25519.

O que é

Um workspace + engine que roda um job de masking grau LGPD de source para target. Campos sensíveis são detectados via um classificador 3-signal (regex + heurística + ML), depois transformados com funções determinísticas (HKDF-derived per field) para que o mesmo valor source sempre mape para o mesmo valor mascarado — integridade referencial é preservada entre collections.

Quando usar

Rode antes de refresh de dev / staging a partir de produção. Qualquer um com acesso ao target mascarado pega o mesmo schema e distribuição estatística da produção, mas toda coluna PII é substituída — DPO / ANPD / times de dev externos podem usar os dados sem uma violação LGPD.

Como abrir

  1. No app desktop do NoSqlStudio, abra o menu Tools → Migrate and Diff → Data Mask, ou pressione Ctrl+Alt+K.
  2. Uma tab de workspace abre com o picker source / target no topo, o editor de policy de fields no centro, e o preview de dry-run à direita.
  3. Escolha as conexões source e target, depois escolha o database e as collections para mascarar.

Construindo um plano de mask

  1. Scanner — clique em "Scan source" para rodar o detector PII numa sample. A saída é uma classificação per-field: not_sensitive / personal_low / personal_medium / personal_high / checksum_match.
  2. Policy — para cada field flaggado, o engine propõe um transform (hash / shuffle / format-preserving / nullify / leave). Você pode overrider per field.
  3. Audit handshake — para tiers que requerem, o engine dispara um handshake license-server-signed (Ed25519). O token assinado é embarcado em cada linha de audit para que um auditor externo possa verificar o run criptograficamente.
  4. Dry-run — clique em "Preview" para mascarar 100 sample documents em memória e renderizar before/after lado a lado. Nada foi escrito no target ainda.
  5. k-anonymity — defina um k mínimo. O engine se recusa a aplicar a mask se qualquer combinação de quasi-identifiers (zipcode + age + gender) produz um grupo menor que k.
  6. Justificativa — para fields sensíveis, o engine requer uma justificativa free-text armazenada no audit log.
  7. Apply — clique em "Start mask". O engine escreve os documents mascarados no target com progress bar, throughput, e resume-on-failure built in. O audit log registra o fingerprint de policy, namespaces target, e outcome.

Seeds derivadas por KMS

Para mascaramento determinístico, todo field usa um seed per-field derivado de um secret root via HKDF. O secret root pode ficar em HashiCorp Vault, AWS KMS, Azure Key Vault, ou GCP KMS — configurado uma vez na workstation. Sem KMS, o engine cai para um seed HKDF local (ainda determinístico, mas rotação requer substituição manual de key).

Executor Right-to-be-Forgotten

Um sub-workflow separado para requisições de erasure LGPD Art. 18. Veja a doc do Wizard RTBF para o fluxo completo — o engine DataMask é o substrate que de fato apaga.

Limitações (v1)

  • Providers KMS são opcionais. Sem um, o seed HKDF local fica em userData e rotação é manual. Tier-gated.
  • Detecção de schema-drift só pega mudanças desde o último snapshot. Se o schema source mudou entre scan e apply, o engine avisa; não auto-evolui a policy.
  • Check k-anonymity é sample-based (default 10k docs). Para garantias ironclad defina k alto e revise o relatório per-bucket.