About Masking Rules
Published 19 March 2018
A masking set can (and usually does) implement a variety of different types of Masking rules. Each type of rule has a different purpose which makes it suitable for a specific masking requirement. Typically a masking set will implement a number of Masking rules in order to achieve the desired effect. Rules are added to a masking set using the New Rule button on the Data Masker Rules In Set tab.
How to Create a New Masking Rule
The types of Masking rules are summarized below. Please click on the link to read a detailed discussion of each rule type.
Rule Controller
A Rule Controller contains login information. Rule Controllers tell their dependent masking rules which server and database they should connect to in order to perform their actions. All other types of masking rule must have a parent Rule Controller and every masking set must contain at least one Rule Controller.
Masking Rules
Substitutes the data in the column of a table. As substitution data this type of rule can use any of the supplied datasets or User Defined Datasets appropriate to the column type. This type of rule can also substitute based on a user supplied Where condition.
Shuffles the data in the column of a table (like a deck of cards) and leaves the other columns untouched. This type of rule can also shuffle based on a user supplied WHERE condition.
Inserts new rows into table columns. This type of rule can use as insertion data any of the available datasets appropriate to the column type.
Search and replace values in free format text fields. This type of rule can use four different search operations, and replace with values from available datasets. A user supplied Where condition can also be applied.
Mask data stored in XML format. This type of rule can search XML contents by XPath and replace with values from available datasets. A user supplied Where condition can also be applied.
Mask data stored in JSON format. This type of rule can search JSON contents by JSONPath and replace with values from available datasets. A user supplied Where condition can also be applied.
Overview of Masking Rules at Redgate University
The Masking Rules module demonstrates where in the GUI you can find each of these different types of rules, and how to use them to mask data in the columns in a table, or move it around, so that it is protected.
Synchronization Rules
Synchronization rules ensure that scrambled data correlates (or synchronizes) with other data. Synchronization rules are necessary because it is very rare for database information to be stored in a fully normalized way. Usually, there is a requirement for data masked in one area to be masked in an identical way in another area. For example, an employee name may be held in several tables. It is desirable (usually essential) that if the name is masked in one column then the other tables in which the information is held are also updated with an identical value. There are three basic types of synchronization and a specialized rule type to support each one.
Row-Internal Synchronization Rules
A Row-Internal Synchronization Rule updates a field in a row with a combination of values from the same row.
Table-Internal Synchronization Rules
A Table-Internal Synchronization Rule updates columns in groups of rows within a table to contain identical values.
Table-To-Table Synchronization Rules
A Table-To-Table Synchronization Rule uses a join condition to update columns in another table to contain identical values.
Overview of Synchronization Rules at Redgate University
The Row-Internal, Table-Internal and Table-to-Table modules offer simple examples of how to define and run each of these types of rules, in turn.
Special Function Rules
This type of rule is used to run user defined T-SQL or PL/SQL statements within the target database.
This type of rule is used to run user defined T-SQL or PL/SQL statements in a different database, instance and database type.
This type of rule is used to copy data from a source table to a target table in a diffferent database, instance and database type.
This type of rule is used to synchronise data between a source table and a target table in a diffferent database, instance and database type.
Utility Rules
Enables foreign keys in the target database. Each foreign key can be individually marked for enable. Usually used after a Foreign Key Disable Rule has run.
Disables foreign keys in the target database. Usually followed by a Foreign Key Enable Rule after the other masking rules have run.
Enables triggers in the target database. Each trigger can be individually marked for enable. Usually used after a Trigger Disable Rule has run.
Disables triggers in the target database. Usually followed by a Trigger Enable Rule after the other masking rules have run.
Enables indexes in the target database. Each index can be individually marked for enable. Usually used after a Index Enable Rule has run.
Disables indexes in the target database. Usually followed by a Index Enable Rule after the other masking rules have run.
Refresh Rules
Dynamically downlaod the indexes from the database and refresh the Index Manager rules in the Rule Controller.
Dynamically downlaod the triggers from the database and refresh the Trigger Manager rules in the Rule Controller.
Dynamically downlaod the foreign keys from the database and refresh the FK Manager rules in the Rule Controller.
Dynamically download the count of rows in all of the tables in the Rule Controller schema from the database and will refresh the display.
The Masking Process
Once added to the masking set, the rule is ready to modify the data in the target database. However, no changes to the table contents will take place until the rules are executed by the Data Masker software. To run a masking set and execute the rules within it click on the Run Masking Set button on the right hand side of the main Data Masker display. It is also possible to only run one rule or a group of selected rules by right click the rule and run from the menu shown.
The Data Masker software can execute multiple rules simultaneously. Some rules will require other rules to complete before it is appropriate for them to begin. Read the Rule Blocks and Dependencies help page to understand how to explicitly control the execution order of the masking rules.
The progress of the masking set run and information about each rules state can be viewed on the Rule Statistics and Run Statistics tabs.
Operationally, rule execution is quite straight forward. The effect is exactly what the rule and its options state. For example, a Substitution rule using the Random Last Names dataset applied to the EMPLOYEE table on the EMPLOYEE_LASTNAME column would generate and substitute random last names in place of the existing last names. The substitution would continue until all rows in the table (or a subset if a Where clause option was specified) were updated with the new data.
Important Note: Once a rule has been run it is not possible to recover the previous data by running another rule. For example, once a Substitution rule has been run, the data will be thoroughly masked and there is no way of "un-substituting" it. To retrieve the original data the usual database restore procedures would have to be implemented.
