Encrypting SQL Server: Dynamic Data Masking

SQL Server 2016 introduced dynamic data masking (DDM) as a way to prevent unauthorized users from viewing certain types of sensitive information. The database engine masks the data when it is retrieved from the database, based on masking rules defined on the column schema. The data stored within the database remains unchanged.

When a user queries the database, the database engine determines whether that user account has the permissions necessary to access the data in its unmasked state. If the account does not, the engine applies the masking rules to the data when it is returned as part of the query. In this way, you can mask all or part of sensitive data such as national identification numbers, credit card numbers, birth dates, phone numbers, or other types of information.

To implement DDM, you define masking rules on the columns that contain the data you want to protect. For each column, you add the MASKED WITH clause to the column definition, using the following syntax:

MASKED WITH (FUNCTION = '<em><function></em>(<em><arguments></em>)')

You start by replacing the <function> placeholder with one of four functions: default , email , random , or partial . For the random and partial functions, you must also provide parameter values, as specified by the <arguments> placeholder. We’ll get into the specifics of how all this works as we go through the examples.

You can add the MASKED WITH clause to your column definition when you create a table or afterwards by using an ALTER TABLE statement. It does not matter whether the column already contains data. There are some limitations, however. For example, you cannot apply DDM to computed columns or Always Encrypted columns.

While we’re on the topic of Always Encrypted, it’s worth noting that this is the fourth article in a series related to SQL Server encryption. The following links point to the first three articles.

Encrypting SQL Server: Using an Encryption Hierarchy to Protect Column Data Encrypting SQL Server: Transparent Data Encryption (TDE) SQL Server Encryption: Always Encrypted

I’ve included DDM in this series because Microsoft documentation ( SQL Server Encryption ) implies that DDM is a type of SQL Server encryption. It is not. The feature simply masks data for non-privileged users upon querying a protected column. No data is being encrypted at rest or in motion. The database engine merely replaces the sensitive data with non-identifying characters. Even Microsoft admits that “unprivileged users with ad-hoc query permissions can apply techniques to gain access to the actual data.”

Although DDM is not really encryption, it still seems worth including it in this series, if for no other reason than to be complete. The DDM feature is easy to implement and requires no changes to the queries themselves. You need only update your column definitions and perhaps tweak the permissions on certain accounts. But keep in mind that DDM should be used only as part of a much larger strategy for protecting data, a strategy that will likely include real encryption.

Applying a default mask

The first DDM function we’ll tackle is default . When you use this function to mask data, and a user with read-only privileges queries that data, the database engine masks the entire value and returns a replacement value. The exact nature of the replacement value depends on the column’s data type.

It is important to note that the default function does not take any arguments. Microsoft’s documentation is a bit confusing in this regard because it suggests otherwise, but you need only specify the function name and an empty set of parentheses.

To demonstrate how this works, we’ll start by creating a table and populating it with data from the AdventureWorks2014 database. When creating the table, we’ll use the default function to mask four of the columns, as shown in the following T-SQL script:

USE master; GO CREATE DATABASE EmpData4; GO USE EmpData4; GO CREATE TABLE EmpInfo( EmpID INT PRIMARY KEY, FirstName NVARCHAR(50) NOT NULL, LastName NVARCHAR(50) MASKED WITH (FUNCTION = 'default()') NOT NULL, Birthdate DATE MASKED WITH (FUNCTION = 'default()') NOT NULL, CurrentFlag BIT MASKED WITH (FUNCTION = 'default()') NOT NULL, SalesLastYear MONEY MASKED WITH (FUNCTION = 'default()') NOT NULL, EmailAddress NVARCHAR(50), SickLeave INT, SalesYTD MONEY, NatID NVARCHAR(15), PhoneNumber NVARCHAR(25)); GO INSERT INTO EmpInfo SELECT e.BusinessEntityID, sp.FirstName, sp.LastName, e.BirthDate, e.CurrentFlag, sp.SalesLastYear, sp.EmailAddress, e.SickLeaveHours, sp.SalesYTD, e.NationalIDNumber, sp.PhoneNumber FROM AdventureWorks2014.HumanResources.Employee e INNER JOIN AdventureWorks2014.Sales.vSalesPerson sp ON e.BusinessEntityID = sp.BusinessEntityID WHERE sp.CountryRegionName = 'United States';

The table includes a number of extra columns, which we’ll be using in subsequent examples. For now, let’s focus on the four DDM columns.

The definition for each of these columns includes the MASKED WITH clause, which must come before the NULL or NOT NULL option. Within the clause, we specify the DDM function, in this case, default , enclosed in single quotes.

With our table in place and populated, let’s query the masked columns, using the same privileged account we used to create the table:

SELECT TOP 5 EmpID, FirstName, LastName, Birthdate, CurrentFlag, SalesLastYear FROM EmpInfo;

Because we’re running the query under a privileged account, we have full access to the data, despite having implemented the masking rules. For this reason, the SELECT statement will return the same results (shown in the following table) that we would get if the masking rules had not been added to the column definitions.

EmpID FirstName LastName Birthdate CurrentFlag SalesLastYear 274 Stephen Jiang 1951-10-17 1 0.00 275 Michael Blythe 1968-12-25 1 1750406.4785 276