First published on MSDN on Nov 02, 2018
Understanding Dynamic Data Masking.
When dynamic data masking is applied, the main objective is to limit the exposure of confidential information to users who do not have the necessary privileges to observe confidential information.
Once the masking is done in a column that shares tables and different queries are made using the
command, the masking will be reflected in both tables. We can observe the following scenario where the environment was replicated.
In the following screenshot you will see the creation of the primary table.
In the following screenshot you will see the table that has the
column linked using the
command to create the new table.
When run SELECT * FROM Person, you will observe the data in Person table.
When run: Select * from Student, you will see the Student table created with the two shared columns of the first table.
Once having the tables created with the column that is going to be masked, we go to the azure portal.
In Add Mask we create the masking rule and click on Save.
Once the column is masked users who do not have privilege to view masking will not be able to visualize the data.
Execute SELECT * FROM Person, in PersonId you will notice the data encrypted.
When we execute the following query Select * from Student, you will see the PersonID data since not masked in this table.
When I finally execute the two queries followed by a
, both tables will be masked.
The observed behavior is by design, data masking works by observing the output columns for a query and determining which columns of physical origin are used to produce the output data for that column. If any of those columns of physical origin has a mask, then that output column for the query will have its data masked. In the example provided, the query has two output columns. The sources for the first output column are Person.PersonID (which has a mask defined) and Student.PersonID, so all the output data for that column will be masked.