DataMask
Enmascare datos de producción a dev/staging sin perder integridad referencial. Seeds determinísticas derivadas por KMS (fallback HKDF), detección PII basada en ML, preview dry-run, verificación k-anonymity, y handshake de audit firmado en Ed25519.
Qué es
Un workspace + engine que corre un job de masking grado LGPD de source a target. Campos sensibles son detectados vía un clasificador 3-signal (regex + heurística + ML), luego transformados con funciones determinísticas (HKDF-derived per field) para que el mismo valor source siempre mape al mismo valor enmascarado — integridad referencial es preservada entre collections.
Cuándo usar
Corra antes de refresh de dev / staging desde producción. Cualquiera con acceso al target enmascarado obtiene el mismo schema y distribución estadística de producción, pero cada columna PII es reemplazada — DPO / ANPD / equipos de dev externos pueden usar los datos sin una violación LGPD.
Cómo abrirlo
- En el app desktop del NoSqlStudio, abra el menú Tools → Migrate and Diff → Data Mask, o presione Ctrl+Alt+K.
- Un tab de workspace abre con el picker source / target arriba, el editor de policy de fields en el centro, y el preview de dry-run a la derecha.
- Elija las conexiones source y target, luego elija el database y las collections para enmascarar.
Construyendo un plan de mask
- Scanner — haga clic en "Scan source" para correr el detector PII en una sample. La salida es una clasificación per-field: not_sensitive / personal_low / personal_medium / personal_high / checksum_match.
- Policy — para cada field flaggado, el engine propone un transform (hash / shuffle / format-preserving / nullify / leave). Puede override per field.
- Audit handshake — para tiers que requieren, el engine dispara un handshake license-server-signed (Ed25519). El token firmado es embebido en cada línea de audit para que un auditor externo pueda verificar el run criptográficamente.
- Dry-run — haga clic en "Preview" para enmascarar 100 sample documents en memoria y renderizar before/after lado a lado. Nada ha sido escrito al target aún.
- k-anonymity — defina un k mínimo. El engine se rehúsa a aplicar la mask si cualquier combinación de quasi-identifiers (zipcode + age + gender) produce un grupo menor que k.
- Justificación — para fields sensibles, el engine requiere una justificación free-text almacenada en el audit log.
- Apply — haga clic en "Start mask". El engine escribe los documents enmascarados al target con progress bar, throughput, y resume-on-failure built in. El audit log registra el fingerprint de policy, namespaces target, y outcome.
Seeds derivadas por KMS
Para enmascaramiento determinístico, cada field usa un seed per-field derivado de un secret root vía HKDF. El secret root puede vivir en HashiCorp Vault, AWS KMS, Azure Key Vault, o GCP KMS — configurado una vez en la workstation. Sin KMS, el engine cae a un seed HKDF local (todavía determinístico, pero rotación requiere reemplazo manual de key).
Ejecutor Right-to-be-Forgotten
Un sub-workflow separado para requisiciones de erasure LGPD Art. 18. Vea la doc del Wizard RTBF para el flujo completo — el engine DataMask es el substrate que de hecho borra.
Limitaciones (v1)
- Providers KMS son opcionales. Sin uno, el seed HKDF local vive en userData y rotación es manual. Tier-gated.
- Detección de schema-drift solo agarra cambios desde el último snapshot. Si el schema source cambió entre scan y apply, el engine avisa; no auto-evoluciona la policy.
- Check k-anonymity es sample-based (default 10k docs). Para garantías ironclad defina k alto y revise el reporte per-bucket.