Part ofProtection and Enforcement

Dynamic Data Masking

Protected Results Without Changing Stored Data

Conceal sensitive values in live database results while applications continue to receive usable data.

Book a Demo Explore Integrations

User and Application Context
Request or Response Masking
Built-in and Custom Methods

Product overview

What this product covers

Dynamic Data Masking gives teams real-time control over how sensitive information appears across live database workflows. It keeps data useful for legitimate work while reducing unnecessary exposure to users and applications.

A policy can consider who is requesting the data, which application they use, what operation they run, and which field they access. Security teams decide when to show the original value, when to return masked data, and what the protected result should look like.

Live masking path

From a Live Request to a Protected Result

The masking rule runs between the request and the returned data.

Request
Request the data

A user or application asks the database for data through DataSunrise.
Mask
Apply the masking rule

DataSunrise matches the request to a policy and masks the configured values.
Result
Return protected data

The user or application receives the protected result.

The original value in the database remains unchanged.

Product evidence

See the workflow in DataSunrise

Product screens show how policy, evidence, and protection appear in practice.

DataSunrise Dynamic Masking Rules list showing policies for TiDB, MSSQL, Elasticsearch, and PostgreSQL with target instance, Mask action, and rule type — **Dynamic Masking rule inventory** The rule inventory identifies each database type, target instance, action, and rule type. These examples use Mask Columns, Mask Fields, and Mask Data policies across several documented database paths.

DataSunrise Dynamic Masking Rule Details for a PostgreSQL TestDB instance with a wizard-generated fixed-string GDPR policy — **Rule identity and target instance** Rule Details establish the policy name, database type, and target instance before session, operation, object, and masking conditions are configured.

DataSunrise Masking Settings tree with Mask Columns selected for public customer fields including names, email, address, location, and IP values — **Masking scope by database column** Masking Settings scope the rule to specific database objects and columns. The example selects customer name, email, address, location, and IP fields in the public schema.

1 / 3

Dynamic masking workflow

Explore Dynamic Data Masking

1 / 4

Decide When a Rule Applies

Rule input	How it is used
Database and instance	Choose the connection to protect
User and session	Apply rules by database user, application user, client, host, or application
Operation	Apply rules to selected requests or statement types
Object and field	Target schemas, tables, columns, or available NoSQL objects and fields
Information Type	Mask values that match a sensitive-data definition
Condition	Use row, value, expression, or session conditions

When an application passes its user identity to DataSunrise, Application-User Attribution can apply policies to the individual user behind a shared database account.

Choose What the User Sees

Choose a masking method based on how much of the original value the user needs to see.

Outcome	Methods	When to use it
Fixed replacement	Fixed strings, nulling, or deterministic constants	Remove the clear value when realistic data is unnecessary
Partial visibility	Partial masks and reveal rules	Keep approved fragments such as the last digits of an identifier
Realistic variation	Random, date, identity-specific, or data-type-aware methods	Keep results usable without exposing the original value
Pattern preservation	Regular expressions, format preservation, tokenization, and cryptographic methods	Maintain a required shape or stable reference
Custom behavior	Functions, Lua, and unstructured-data methods	Apply organization-specific logic
Visibility control	Hide rows, fields, or NoSQL objects	Prevent selected data from being returned

Works Across Your Data Environment

DataSunrise applies Dynamic Data Masking across databases, analytics services, NoSQL systems, and object storage while the original data remains unchanged.

Environment	What Dynamic Data Masking protects
Databases and analytics	Live results across PostgreSQL, MySQL and MariaDB, Oracle, Microsoft SQL Server, Redshift, Snowflake, Athena, and other supported platforms
NoSQL systems	Selected fields in MongoDB, DynamoDB, and Elasticsearch, with object-level visibility controls for MongoDB and DynamoDB
Object storage	Sensitive content in CSV, XML, JSON, and unstructured files stored in Amazon S3 and compatible object storage

Explore integrations to see how DataSunrise fits the technologies in your environment.

Test and Review the Rule

Dynamic Masking Events show which rule matched. Before rollout, test the queries, prepared statements, functions, stored procedures, data types, privileges, and application behavior used by the database.

After rollout, review matching events and adjust the policy when the application or data handling changes.

FAQ

Frequently Asked Questions

When should I use Static Data Masking instead?

Use Static Data Masking when you need a de-identified copy for development, testing, or analytics. Dynamic Data Masking protects live results without writing a copy.

Can Dynamic Data Masking block a database operation?

Dynamic Data Masking changes the request or result. Use Database Firewall when a policy must block the operation.

How are Salesforce and Generative AI masked?

Salesforce Dynamic Data Masking and Generative AI Data Masking use dedicated integrations rather than the database proxy workflow described on this page.

Map the right workflow

See how DataSunrise works with your technology stack

View Integration Examples