Introduction to Data Masking

New Feature: Different masks for different logins.

DbDefence 7.7 introduces a data masking feature. Data masking allows you to selectively mask sensitive fields in tables. Selected users or applications see the original unmasked data, while others see masks instead of data.

In Masking mode, DbDefence encrypts a whole database transparently and selectively masks fields.

This feature is available only for SQL Server 2008 R2, 2012, 2014, 2016, 2017, 2019 on X64 platform. Please contact for more information.

How it is different from Microsoft's data masking?

DbDefence's data masking is always combined with complete database encryption. Unmasked values NEVER appear in database or log file and backups.


Let's suppose we have a table with some sensitive information.

The goal is to protects fields selectively:

field cardholder -mask completely.
field cardnumber -mask partially, leave the last 4 digits.
field cvc -mask completely with 3 zeroes.

Step 1. Creating rules.

We need to prepare a text file with masking rules. Start Notepad and create the following file:

In this screenshot you can see a rule file for masking 3 fields: cardholder, cardnumber, cvc.

Lines starting from '--' are comments and or empty lines are just ignored. The first line of the rule is a table name without quotes or [ ]. In this example, the table name is cards. The second line is the name of the field. In this example it is cardholder. The third line is a mask -the value shown to unauthorized users. This is a value for SQL Server and it may contain functions as shown for cardnumber.

Step 2. Encryption

You can setup masking rules in the GUI

In this example we use command line tool

dbencrypt64.exe -S .\sqlexpress -d test -p SecurePassword123 -a rules.txt -F

The tool can be found in the API folder of the DbDefence installation folder.

-a specifies rules file, -F stands for "Forcibly close existing connections".

You may apply masking to an already encrypted database. However, in the current version, you can't change masking for the object that already has a masked field.

Step 3. Verification

Let's see how it affects the table. Some unauthorized users (no matter whether it is DBA or not) select from the table:

On the contrary, someone who knows the password unlocks the database.

IMPORTANT: In this example we unlock access manually. In real life you may unlock access by SQL login or by selecting applications.

and selecting rows:

All users may simultaneously access the table. Unauthorized users will see masked data, while authorized users see real values.


  • INSERT and UPDATE work well when access is unlocked. When a table shows masked values (locked mode), INSERT and UPDATE may fail. Please contact us if you need assistance with this.
  • If you plan to use the database in locked and unlocked mode, you need to test it. Some applications may behave unpredictably when they see masked data.
  • BACKUP doesn't store masking rules. You need to store/deploy .dbd_key files manually.
  • The table can't be renamed or deleted in locked mode. If an object is renamed in unlocked mode, masking will not work correctly.