If you have just installed the Data Masker software you will want to see how it works and begin to use it. To assist you with your evaluation and ease you gently along the learning curve we suggest you read the items below. We at Redgate are happy to provide assistance. If you have any questions regarding the Data Masker software or need advice on how to accomplish a specific masking task please email us at: Support@DataMasker.com

Note: If you are waiting for an evaluation key you have requested, you can still read some background information (see the steps below). We apologize for any delay - the evaluation key should be with you shortly.

Basic concepts to understand before you start

1. There is no "Undo" ability in Data Masker. If you use the Data Masker tool to modify the data in an Oracle database it stays modified. There is no magic button which can put it back the way it was. Consequently, you should never use Data Masker to modify any production data. The Data Masker software is intended and solely licensed for use on test, development and training systems.
2. The Data Masker software runs on a Windows PC and it can connect to local or remote Oracle databases as required. The Oracle SQL Net v8 (or greater) net working software is required on the PC. Oracle database versions 9i, 10g, 11g and 12c are supported on every platform on which those databases run.
3. The actions in the Data Masker software which modify the data in the Oracle database are implemented as rules (called masking rules). Each rule is designed to perform one specific task and most masking operations will require multiple rules to achieve the desired result. It is up to you to build these rules to suit your requirements. Don't worry though, building masking rules with the Data Masker software is pretty easy. The Data Masker software includes extensive examples - just read on to see how it is done.
4. A collection of masking rules, along with the connection information and schema structure is called a masking set. Masking sets are built and maintained using the point-and-click GUI interface in Data Masker software. After the build of the rules is complete, running a masking set is a simple process. The fundamental concept behind masking sets is that you should be able to use them to repeatedly launch a sequence of known, documented and tested masking operations with minimal operator involvement. Depending on the complexity of your requirements, there may be some effort involved in building a set of masking rules - but once done, the run process is very straightforward.
5. The Data Masker software requires an audit table and two Types to be created in each Oracle schema it is to be run against. These objects are usually created automatically as part of the build of a new masking set or manually using the various options within the Data Masker software.
6. The data in the Oracle schemas which modified by the Data Masker software is modified in-situ. No actual data, other than ROWID numbers, is transmitted from the database to the Data Masker software on the client.

Getting Started

1. Learn about the various types of masking rule. All operations performed by the Data Masker software are configured as masking rules. It is important to understand the difference between the types of rules, how to configure them and when they are appropriate to use.

• Rule Controllers are rules which contain login information. Rule Controllers tell their dependent masking rules which Oracle 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.
  • Action: Read about Rule Controllers and how to create them.
• Substitution Rules are rules which replace the existing information in Oracle tables with realistic looking information of a similar type. The replacement information used by the Substitution Rules is contained in datasets which are supplied with the Data Masker software. The datasets are located in the DataSets subdirectory below the Data Masker installation directory. Datasets for just about everything are included and you can make up your own if you need to do so.
  • Action: Read about Substitution Rules and how to create them.
• Shuffle Rules are rules which take the existing information in a table column and move it randomly between the various rows. This is the equivalent of a substitution rule which uses the columns existing data as a dataset.
  • Action: Read about Shuffle Rules and how to create them.
• Command Rules are rules which can run any valid PL/SQL statement. Think of them as a way to embed a user defined command or action at an appropriate point in the masking set.
  • Action: Read about Command Rules and how to create them.
• Synchronization Rules are rules which 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. There are three basic types of synchronization: Row-Internal, Table-Internal and Table-To-Table. Synchronization is something of an advanced topic and it is probable you will need this sort of operation. However, if you are just starting out with the Data Masker software, you might wish to skip this topic and return to it when you get to step 7 below.
  • Action: Read about Row-Internal Synchronization Rules and how to create them.
  • Action: Read about Table-Internal Synchronization Rules and how to create them.
  • Action: Read about Table-To-Table Synchronization Rules and how to create them.

2. Have a look at the pre-built masking sets. Sample masking sets for the standard Oracle Scott and HR demo schemas are supplied with every installation of Data Masker.

• Action: Start the Data Masker client, open the Scott.MaskSet sample set (it is in the Masking Sets folder) and have a look at the masking rules it contains. Read through the rules in the masking set, noting the various types and how they operate. The first part of the Scott Masking Set Rules page discusses the existing rules in detail. An entity relationship diagram for the Scott schema is also available in the Masking Sets directory.
• Action: Open the HR.MaskSet sample set (it is in the Masking Sets folder) and have a look at the masking rules it contains. Read through the rules in the masking set, noting the various types and how they operate. The first part of the HR Masking Set Rules page discusses the existing rules in detail. An entity relationship diagram for the HR schema is also available in the Masking Sets directory.

3. Try running the sample masking sets. Choose a test Oracle instance containing the Scott and/or HR schemas.

• Action: Run the Scott.MaskSet and HR.MaskSet sample masking sets. You will need to edit the rule controllers in each masking set (double click on them) so that the masking operations are conducted on the correct Oracle instance - take care to get this right. It is a good idea to examine the contents of the schema tables before and after the masking operations so that you can see the changes which have been made.

4. Build a new masking set.

• Action: Build a new masking set for the Scott schema. Create the basic structure of the masking set using the New Masking Set Wizard button and then add rules which are copies of the rules already in place in the sample Scott.MaskSet masking set. Note: it is possible to open two instances of the Data Masker software if you wish to compare your masking set to the sample Scott.MaskSet.
• Action: Build a new masking set for the HR schema. As with the Scott schema above, create the basic structure and then add rules to create a copy of the supplied HR.MaskSet.

5. Try adding more rules to the sample masking sets. Adding new rules to the existing masking set will enable you to get some practice with making decisions regarding the table columns to mask and the best type of masking rule to use on them. When you run the rules, be sure to observe the before and after effect of the masking operations on the data.

• Action: Add some extra rules to the Scott.MaskSet sample masking set. If you would like suggestions for additional rules, please have a look at the bottom part of the Scott Masking Set Rules page. A useful ER diagram for Scott is available.
• Action: Add some extra rules to the HR.MaskSet sample masking set. If you would like suggestions for additional rules, please have a look at the bottom part of the HR Masking Set Rules page. A useful ER diagram for HR is available.

6. Examine the advanced rules in the DMTest masking set. These rules involve synchronization of data within tables and also the use of Rule Blocks and Dependencies to control the execution order of masking rules.

Note: Synchronization, Rule Blocks and Dependencies are important new concepts - do not skip this step.

• Action: Use the scripts in the Sample Schema directory to build and populate the Data Masker sample tables in a test schema of your choice. View the Readme.txt file in the Sample Schema for more information about how to run the sample schema files.
• Action: Read the Rule Blocks and Dependencies help page to understand how to explicitly control the execution order of the masking rules.
• Action: Review the rules in the DMTest.MaskSet sample masking set and run it if you wish. Be sure to read the DMTest Masking Set Rules page which discusses the existing rules in detail. As with the Scott and HR databases, a useful ER diagram for DMTest is available.
• Action: Build a new masking set for the DMTest schema. Make decisions about which columns in the DMTest schema should be masked and the techniques you wish to use to mask them. Rebuild the existing rules and add new ones. Suggestions for possible masking rules can be found towards the bottom of the DMTest Masking Rules page.
• Action: Run the newly created masking set. Observe the before and after effect of the masking rules on the test data.

7. Build masking sets for your own databases. You are now in a position to build a set of masking rules for the schemas in your own Oracle databases. We suggest you take the following steps:

• Action: Before you mask any data, think about the schema structure and make a plan: which tables and columns need to be masked, which datasets should be used, do the masked columns require synchronization? Are there any other issues which need to be taken into consideration? We highly recommend reading the Data Masking: What You Really Need To Know white paper. It discusses numerous, non-obvious and subtle factors which must be taken into consideration.
• Action: Build a new masking set for your schema.
• Action: Add some masking rules. Carefully test the new rules, add some more, test again and repeat until the masking set is complete.
• Action: Test the masked schema.

Thank you for taking the time to read the Data Masker Quick Start Guide. Hopefully your experience with the Data Masker software will be an enjoyable one. We at Redgate are happy to provide assistance. Please do email us at the following address if you have any questions or need more information: Support@DataMasker.com