Skip to content

Add data masking framework for dataset fields - #1813

Open
medhwu wants to merge 1 commit into
opendatadiscovery:mainfrom
medhwu:feature/data-masking-framework
Open

Add data masking framework for dataset fields#1813
medhwu wants to merge 1 commit into
opendatadiscovery:mainfrom
medhwu:feature/data-masking-framework

Conversation

@medhwu

@medhwu medhwu commented Jun 26, 2026

Copy link
Copy Markdown

What

Implements a lightweight data masking framework for dataset fields, enabling organizations to protect sensitive metadata in compliance with GDPR, PIPL, HIPAA, PCI-DSS.

7 Built-in Masking Rules

Rule Type Example Input Masked Output
Show Last 4 SHOW_LAST_4 6222021234567890 ************7890
Show First 4 SHOW_FIRST_4 13812345678 1381*******
SHA-256 Hash HASH_SHA256 test@example.com a7ffc6f8... (64 hex)
Full Redaction REDACT Sensitive Data **************
Email Mask EMAIL_MASK john@example.com j***@example.com
Phone Mask PHONE_MASK 13812345678 138****5678
ID Card Mask ID_CARD_MASK 310101199001011234 310**********1234

New REST API (/api/masking/*)

Method Path Description
GET /rules List all masking rules
GET /dataset-fields/{fieldId} Get masking config for a field
GET /datasets/{datasetId} Get all masking configs for a dataset
POST /dataset-fields/{fieldId}?ruleId= Apply a masking rule
DELETE /dataset-fields/{fieldId} Remove masking

New Permissions

DATA_MASKING_RULE_MANAGE and DATA_MASKING_FIELD_MANAGE added to MANAGEMENT permissions.

Why

ODD Platform currently has zero data masking capabilities. Organizations handling PII, financial data, or healthcare data have no way to protect sensitive column names or sample values in the data catalog. This blocks adoption in regulated industries.

How

Database V0_0_103: masking_rule table + dataset_field_masking table with foreign keys to dataset_field(id) and owner(id).

Backend: Full layered architecture -- DTOs (MaskingRuleDto, DatasetFieldMaskingDto, MaskingRuleType), Repository (reactive JOOQ with soft-delete), Service (7 masking algorithms), Controller (5 REST endpoints).

Design: Display-only masking (original data untouched), reusable rules, per-field granularity, raw JOOQ DSL.field()/DSL.table() to avoid compile-time dependency.

Checklist

  • New tables with partial unique index and foreign keys
  • 7 preset masking rules with ON CONFLICT DO NOTHING
  • Permission enum and policy JSON schema extended
  • No changes to existing tables or APIs

Implements a lightweight data masking (data desensitization) framework:

7 built-in masking rules:
- SHOW_LAST_4 / SHOW_FIRST_4: partial reveal
- HASH_SHA256: one-way cryptographic hash
- REDACT: full character replacement
- EMAIL_MASK: j***@example.com
- PHONE_MASK: 138****1234
- ID_CARD_MASK: 310**********1234

New REST API under /api/masking:
- GET /rules, GET /dataset-fields/{id}, GET /datasets/{id}
- POST /dataset-fields/{id}?ruleId=, DELETE /dataset-fields/{id}

New permissions: DATA_MASKING_RULE_MANAGE, DATA_MASKING_FIELD_MANAGE

Database (V0_0_103):
- masking_rule: rules with type, replacement, pattern
- dataset_field_masking: per-field binding, UNIQUE(field_id)

Design: display-only masking (original data untouched), reusable rules,
per-field granularity. Uses raw JOOQ DSL.field()/DSL.table() throughout
to avoid compile dependency on generated table classes.
@medhwu
medhwu requested a review from a team as a code owner June 26, 2026 09:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant