About Masking Rules
Published 22 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.
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.
This type of rule is used to run user defined SQL or PL/SQL statements within the target database.
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.
Specialized Rules
A Rule Controller contains login information. Rule Controllers tell their dependent masking rules which database and schema 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.
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.
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.
The Masking Process
Once added to the masking set the rule is ready to modify the data in the target schema. 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.
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. Commits happen at user configurable intervals (every 5000 rows is the default).
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.
