Data Masker

A rule controller is a container for rules working against a single database and schema. Rule controllers store schema information for their connection, so you are able to add rules without a connection to the database.

Masking sets require at least one Rule Controller and can contain as many as needed. Masking rules must always have a parent Rule Controller.

Core concepts

SQL Connection

One of the responsibilities of rule controller is provide database schema connection to work on. Data masker provide various different type of authentication to your database - read more about it in advanced concepts.

Offline schema

All schema information is kept in masking set and you can explore it from Tables tab. There's no automatic mechanism to detect change in schema, so controllers must be refreshed after changes to the database are made. This can be done through the Tools tab of the rule controller.

Hint: After refreshing data, please remember to save progress by clicking Update rule controller button.

Controller as an container for rules

Multiple controllers are run one by one (in series). By default each rule added into controller has assigned rule number which is by default run in parallel. The Data Masker can run up to 16 rules in parallel. It is common to have a situation in which certain rules cannot run simultaneously and must run sequentially one after the other as a chain.

The execution order of the masking rules is controlled through the use of rules blocks and dependencies. See the Rule Blocks and Dependencies help page to understand how to explicitly control the execution order of the masking rules.

A Rule Controller (and hence its dependent masking rules) with a lower rule block will always be run before a Rule Controller with a higher rule block. Two Rule Controllers with the same rule block may run in arbitrary order.

Rule Controllers are independent of each other. If there are multiple Rule Controllers defined for a masking set, each Rule Controller can be configured to connect to the same database or entirely different ones.

Advanced concepts

SQL authentication

The login panel on the left hand side of the form is used to configure the Oracle/SQL Server login for the Rule Controller.

Rule Controllers can be configured to use windows authentication or SQL Server authentication and standard Microsoft ADO connection technologies are used to connect to the Sql Server instance.

Server Name

This is the name of the target SQL Server and instance to which the Rule Controller should connect. Note that there are no leading backslash characters used on the server name.

Use Windows Authentication and Use SQL Server Authentication

These two options determine the authentication method the Rule Controller will use when connecting to the target database. If SQL Server Authentication mode is used, a valid login name and password must be supplied.

Rule Controllers can be configured to connect via the standard Oracle SQL*Net using TNSNames or directly to the database via TCP/IP. If the TNSNames method is used, the PC must have Oracle SQL*Net version 9 (or higher) installed. In general if it is possible to connect to the target schema with a TNSName via an Oracle Utility such as SQL*Plus then the Data Masker software should not have any difficulties connecting.

Connect via TNSNames and Connect via TCP/IP

These two options determine the method the rules will use when connecting to the target schema. The TNSNames mode requires a valid Oracle TNSName identical to that which would be used in an SQL*Plus session. The TCP/IP mode requires the host name, port and SID of the database. Setting direct mode allows Data Masker to work with Oracle directly through TCP/IP protocol without involving the Oracle Client software.

Optional Proxy Configuration

Usually the Login Name field references the schema that contains the tables to be masked - however the Login Name can be a proxy schema which only has select and update access to the real target schema. If the Login Name is a proxy schema, the name of the schema that actually owns the tables should be entered in this panel. The only real benefit to using a proxy schema is that it can contain the server side audit table that the Data Masker software uses to record the masking rule actions. This enables the audit table to be held separately from the target schema.

Table definitions about rule progress

Data masker during rules execution gather data through tables on given connection about progress of the rules and used tables in masking:

with suffix TSTATS and it records the affected tables with the corresponding rules.
with suffix RSTATS and it records the rules as they execute.

You can define common prefix for these tables by default it is DMSSTAT_ or DMOSTAT_

To read more about internal representation of these two tables read it here.

You are able to create, drop and view mentioned tables through controller form.

Plan import/export (SQL Server only)

You are able to import and export or reset sensitivity plan through Tools tab of controller, which will occur in Tables tab on main from. Sensitivity plan allows you to mark columns as sensitive so you can create rules for sensitive columns faster and easier. To read more about plan check it here.