| Oracle® Database Real Application Testing User's Guide 11g Release 2 (11.2) Part Number E16540-05 |
|
|
PDF · Mobi · ePub |
| Oracle® Database Real Application Testing User's Guide 11g Release 2 (11.2) Part Number E16540-05 |
|
|
PDF · Mobi · ePub |
This chapter provides conceptual information about the components that comprise Oracle Data Masking, and procedural information about performing the task sequence, such as creating masking formats and masking definitions. Topics discussed include:
Enterprises run the risk of breaching sensitive information when copying production data into non-production environments for the purposes of application development, testing, or data analysis. Oracle Data Masking helps reduce this risk by irreversibly replacing the original sensitive data with fictitious data so that production data can be shared safely with non-production users. Accessible via Oracle Enterprise Manager, Oracle Data Masking provides end-to-end secure automation for provisioning test databases from production in compliance with regulations.
Data masking (also known as data scrambling and data anonymization) is the process of replacing sensitive information copied from production databases to test non-production databases with realistic, but scrubbed, data based on masking rules. Data masking is ideal for virtually any situation when confidential or regulated data needs to be shared with non-production users. These users may include internal users such as application developers, or external business partners such as offshore testing companies, suppliers and customers. These non-production users need to access some of the original data, but do not need to see every column of every table, especially when the information is protected by government regulations.
Data masking enables organizations to generate realistic and fully functional data with similar characteristics as the original data to replace sensitive or confidential information. This contrasts with encryption or Virtual Private Database, which simply hides data, and the original data can be retrieved with the appropriate access or key. With data masking, the original sensitive data cannot be retrieved or accessed.
Names, addresses, phone numbers, and credit card details are examples of data that require protection of the information content from inappropriate visibility. Live production database environments contain valuable and confidential data—access to this information is tightly controlled. However, each production system usually has replicated development copies, and the controls on such test environments are less stringent. This greatly increases the risks that the data might be used inappropriately. Data masking can modify sensitive database records so that they remain usable, but do not contain confidential or personally identifiable information. Yet, the masked test data resembles the original in appearance to ensure the integrity of the application.
Masked data is a sensible precaution from a business security standpoint, because masked test information can help prevent accidental data escapes. In many cases, masked data is a legal obligation. The Enterprise Manager Data Masking Pack can help organizations fulfill legal obligations and comply with global regulatory requirements, such as Sarbanes-Oxley, the California Database Security Breach Notification Act (CA Senate Bill 1386), and the European Union Data Protection Directive.
The legal requirements vary from country to country, but most countries now have regulations of some form to protect the confidentiality and integrity of personal consumer information. For example, in the United States, The Right to Financial Privacy Act of 1978 creates statutory Fourth Amendment protection for financial records, and a host of individual state laws require this. Similarly, the U.S. Health Insurance Portability and Accountability Act (HIPAA) created protection of personal medical information.
The following types of users participate in the data masking process for a typical enterprise:
Application database administrator or application developer
This user is knowledgeable about the application and database objects. This user may add additional custom database objects or extensions to packaged applications, such as the Oracle E-Business suite.
Information security administrator
This user defines information security policies, enforces security best practices, and also recommends the data to be hidden and protected.
Besides data masking, Oracle offers the following security products:
Virtual Private Database or Oracle Label Security — Hides rows and data depending on user access grants.
Transparent Data Encryption — Hides information stored on disk using encryption. Clients see unencrypted information.
DBMS_CRYPTO — Provides server packages that enable you to encrypt user data.
Database Vault — Provides greater access controls on data.
Data Masking supports Oracle Database 9i and newer releases. If you have a version prior to 11.1, you can use it by implementing the following work-around.
Replace the following file...
AGENT_HOME/sysman/admin/scripts/db/reorg/reorganize.pl
... with this file:
OMS_HOME/sysman/admin/scripts/db/reorg/reorganize.pl
The list of supported data types varies by release.
Grid Control 10g Release 5 (10.2.0.5) and Database 11g Release 2 (11.2)
Numeric Types
The following Numeric Types can use Array List, Delete, Fixed Number, Null Value, Post Processing Function, Preserve Original Data, Random Decimal Numbers, Random Numbers, Shuffle, SQL Expression, Substitute, Table Column, Truncate, and User Defined Function formats:
NUMBER
FLOAT
RAW
BINARY_FLOAT
BINARY_DOUBLE
String Types
The following String Types can use Array List, Delete, Fixed Number, Fixed String, Null Value, Post Processing Function, Preserve Original Data, Random Decimal Numbers, Random Digits, Random Numbers, Random Strings, Shuffle, SQL Expression, Substitute, Substring, Table Column, Truncate, and User Defined Function formats:
CHAR
NCHAR
VARCHAR2
NVARCHAR2
Date Types
The following Date Types can use Array List, Delete, Null Value, Post Processing Function, Preserve Original Data, Random Dates, Shuffle, SQL Expression, Substitute, Table Column, Truncate, and User Defined Function formats:
DATE
TIMESTAMP
To mask data, the Data Masking Pack provides two main features:
The format library contains a collection of ready-to-use masking formats. The library consists of format routines that you can use for masking. A masking format can either be one that you create, or one from the list of Oracle-supplied default masking formats.
As a matter of best practice, organizations should create masking formats for all commonly regulated information so that the formats can be applied to the sensitive data regardless of which database the sensitive data resides in. This ensures that all sensitive data is consistently masked across the entire organization.
A masking definition defines a data masking operation to be implemented on one or more tables in a database. Masking definitions associate table columns with formats to use for masking the data. They also maintain the relationship between columns that are not formally declared in the database using related columns.
You can create a new masking definition or use an existing definition for a masking operation. To create a masking definition, you specify the column of the table for which the data should be masked and the format of masked data. If the columns being masked are involved in unique, primary key, or foreign key constraints, data masking generates the values so that the constraints are not violated. Masking ensures uniqueness per character using decimal arithmetic. For example, a 5-character string generates a maximum of only 99999 unique values. Similarly, a 1-character string generates a maximum of only 9 unique values.
You would typically export masking definitions to files and import them on other systems. This is important when the test and production sites reside on different Oracle Management Systems or on entirely different sites.
See Also:
"Creating a Data Masking Definition" in the Enterprise Manager online help as well as the help for each Data Masking page
Figure 13-1 shows that the production database is cloned to a staging region and then masked there. During the masking process, the staging and test areas are tightly controlled like a production site.
Data masking is an iterative and evolving process handled by the security administrator and implemented by the database administrator. When you first configure data masking, try out the masking definition on a test system, then add a greater number of columns to the masking definition and test it to make sure it functions correctly and does not break any application constraints. During this process, you should exercise care when removing all imbedded references to the real data while maintaining referential integrity.
After data masking is configured to your satisfaction, you can use the existing definition to repeatedly mask after cloning. The masking definition, however, would need to evolve as new schema changes require new data and columns to be masked.
After the masking process is complete, you can distribute the database for wide availability. If you need to ship the database to another third-party site, you are required to use the Data Pump Export utility, and then ship the dump file to the remote site. However, if you are retaining the masked data in-house, see "Data Masking Task Sequence".
The task sequence in this section demonstrates the data masking workflow and refers you to additional information about some of the tasks in the sequence. Before reviewing this sequence, note that there are two options for completing this process:
Exporting/importing to another database
You can clone the production database to a staging area, mask it, then export/ import it to another database before delivering it to in-house testers or external customers. This is the most secure approach.
Making the staging area the new test region
You can clone the production database to a mask staging area, then make the staging area the new test region. In this case, you should not grant testers SYSDBA access or access to the database files. Doing so would compromise security. The masked database contains the original data in unused blocks and in the free list. You can only purge this information by exporting/importing the data to another database.
The following basic steps guide you through the data masking process, with references to other sections for supporting information.
Review the application database and identify the sources of sensitive information.
Define mask formats for the sensitive data. The mask formats may be simple or complex depending on the information security needs of the organization.
For more information, see "Creating New Masking Formats" and "Using Oracle-supplied Predefined Masking Formats".
Create a masking definition to associate table columns to these mask formats. Data masking determines the database foreign key relationships and adds foreign key columns to the mask.
For more information, see "Creating a Masking Definition" .
Optionally declare dependent columns not defined in the database, but enforced by the applications. Masking assumes it should perform the masking to honor these additional constraints.
This requires knowledge of the application schema. Consult the application documentation to identify the relationship between the tables and the columns containing sensitive data to ensure complete coverage of your application data.
For more information, see "Adding Dependent Columns" .
Save the masking definition and generate the masking script.
Verify if the masked data meets the information security requirements. Otherwise, refine the masking definition, restore the altered tables, and reapply the masking definition until the optimal set of masking definitions has been identified.
Clone the production database to a staging area, selecting the masking definition to be used after cloning. Note that you can clone using Enterprise Manager, which enables you to add masking to the Enterprise Manager clone workflow. However, if you clone outside of Enterprise Manager, you must initiate masking from Enterprise Manager after cloning is complete. The cloned database should be controlled with the same privileges as the production system, because it still contains sensitive production data.
After cloning, be sure to change the passwords as well as update or disable any database links, streams, or references to external data sources. Back up the cloned database, or minimally the tables that contain masked data. This can help you restore the original data if the masking definition needs to be refined further.
For more information, see "Cloning the Production Database" .
After masking, test all of your applications, reports, and business processes to ensure they are functional. If everything is working, you can export the masking definition to keep it as a back-up.
After masking the staging site, make sure to drop any tables named MGMT_DM_TT before cloning to a test region. These temporary tables contain a mapping between the original sensitive column value and the mask values, and are therefore sensitive in nature.
During masking, Enterprise Manager automatically drops these temporary tables for you with the default "Drop temporary tables created during masking" option. However, you can preserve these temporary tables by deselecting this option. In this case, you are responsible for deleting the temporary tables before cloning to the test region.
After masking is complete, ensure that all tables loaded for use by the substitute column format or table column format are going to be dropped. These tables contain the mask values that table column or substitute formats will use. It is recommended that you purge this information for security reasons.
For more information, see "Deterministic Masking Using the Substitute Format" .
Clone the database to a test region, or use it as the new test region. When cloning the database to an external or unsecured site, you should use Export or Import. Only supply the data in the database, rather than the database files themselves.
As part of cloning production for testing, provide the masking definition to the application database administrator to use in masking the database.
A masking definition requires one or more masking formats for any columns included in the masking definition. When adding columns to a masking definition, you can either create masking formats manually or import them from the format library. It is often more efficient to work with masking formats from the format library.
This section describes how to create new masking formats using Enterprise Manager.
To create a masking format in the format library:
From the Schema menu, select Data Masking Format Library.
The Format Library appears with predefined formats that Oracle Enterprise Manager provides.
Click Create.
The Create Format page appears, where you can define a masking format.
Tip:
For information on page user controls, see the online help for the Format page.Provide a required name for the new format, select a format entry type from the Add list, then click Go.
A page appears that enables you to provide input for the format entry you have selected. For instance, if you select Array List, the subsequent page enables you to enter a list of values, such as New York, New Jersey, and New Hampshire.
Continue adding additional format entries as needed.
When done, provide an optional user-defined or post-processing function (see "Providing User-defined and Post-processing Functions"), then click OK to save the masking format.
The Format Library page reappears with your newly created format displayed in the Format Library table.
Tip:
For information on page user controls, see the online help for the Format Library and Create Format pages.If desired, you can provide user-defined and post-processing functions on the Create Format page. A user-defined choice is available in the Add list, and a post-processing function field is available at the bottom of the page.
User-defined functions
To provide a user-defined function, select User Defined Function from the Add list, then click Go to access the input fields.
A user-defined function passes in the original value as input, and returns a mask value. The data type and uniqueness of the output values must be compatible with the original output values. Otherwise, a failure occurs when the job runs. Combinable, a user-defined function is a PL/SQL function that can be invoked in a SELECT statement. Its signature is returned as:
Function udf_func (rowid varchar2, column_name varchar2, original_value varchar2) returns varchar2;
rowid is the min (rowid) of the rows that contain the value original_value 3rd argument.
column_name is the name of the column being masked.
original_value is the value being masked.
That is, it accepts the original value as an input string, and returns the mask value.
Both input and output values are varchar2. For instance, a user-defined function to mask a number could receive 100 as input, the string representation of the number 100, and return 99, the string representation of the number 99. Values are cast appropriately when inserting to the table. If the value is not castable, masking fails.
Post-processing functions
To provide a post-processing function, enter it in the Post Processing Function field.
A post-processing function has the same signature as a user-defined function, but passes in the mask value the masking engine generates, and returns the mask value that should be used for masking, as shown in the following example:
Function post_proc_udf_func (rowid varchar2, column_name varchar2, mask_value varchar2) returns varchar2;
rowid is the min (rowid) of the rows that contain the value mask_value.
column_name is the name of the column being masked.
mask_value is the value being masked.
After you have created at least one format, you can use the format definition as a template in the Create Format page, where you can implement most of the format using a different name and changing the entries as needed, rather than needing to create a new format from scratch.
To create a new format similar to an existing format, select a format on the Format Library page and click Create Like. The masking format you select can either be one you have previously defined yourself, or one from the list of out-of-box masking formats. You can use these generic masking format definitions for different applications.
For instructional details about the various Oracle-supplied predefined masking format definitions and how to modify them to suit your needs, see "Using Oracle-supplied Predefined Masking Formats".
The Create Like button on the Format Library page enables you to implement a format under a different name and change the entries as needed, rather than having to create a new format from scratch. The format you select can either be one you have previously defined yourself, or one from the list of predefined formats supplied out-of-box with Enterprise Manager. All predefined formats and built-in formats are random.
The following sections discuss the various Oracle-supplied format definitions and how to modify them to suit your needs:
Tip:
For information on installing the DM_FMTLIB package so that you can use the predefined masking formats, see "Installing the DM_FMTLIB Package".All of the format definitions adhere to these typical patterns:
Generate a random number or random digits.
Perform post-processing on the above-generated value to ensure that the final result is a valid, realistic value.
For example, a valid credit card number must pass Luhn's check. That is, the last digit of any credit card number is a checksum digit, which is always computed. Also, the first few digits indicate the card type (MasterCard, Amex, Visa, and so forth). Consequently, the format definition of a credit card would be as follows:
Generate random and unique 10-digit numbers.
Using a post-processing function, transform the values above to a proper credit card number by adding well known card type prefixes and computing the last digit.
This format is capable of generating 10 billion unique credit card numbers.
The following sections discuss different categories of these definitions:
By default, these mask formats are also available in different format styles, such as a hyphen ( - ) format. If needed, you can modify the format style.
Out of the box, the format library provides many different formats for credit cards. The credit card numbers generated by these formats pass the standard credit card validation tests by the applications, thereby making them appear like valid credit card numbers.
Some of the credit card formats you can use include:
MasterCard numbers
Visa card numbers
American Express card numbers
Discover Card numbers
Any credit card number (credit card numbers belong to all types of cards)
You may want to use different styles for storing credit card numbers, such as:
Pure numbers
'Space' for every four digits
'Hyphen' ( - ) for every four digits, and so forth
To implement the masked values in a certain format style, you can set the DM_CC_FORMAT variable of the DM_FMTLIB package. To install the package, see "Installing the DM_FMTLIB Package" .
Out of the box, you can generate valid U.S. Social Security (SSN) numbers. These SSNs pass the normal application tests of a valid SSN.
You can affect the format style by setting the DM_SSN_FORMAT variable of the DM_FMTLIB package. For example, if you set this variable to '-', the typical social security number would appear as '123-45-6789'.
Using the format library, you can generate either 10-digit or 13-digit ISBN numbers. These numbers adhere to standard ISBN number validation tests. All of these ISBN numbers are random in nature. Similar to other format definitions, you can affect the "style" of the ISBN format by setting values to DM_ISBN_FORMAT.
Using the format library, you can generate valid UPC numbers. They adhere to standard tests for valid UPC numbers. You can affect the formatting style by setting the DM_UPC_FORMAT value of the DM_FMTLIB package.
Using the format library, you can generate valid Canadian Social Insurance Numbers (SINs). These numbers adhere to standard tests of Canadian SINs. You can affect the formatting style by setting the DM_CN_SIN_FORMAT value of the DM_FMTLIB package.
Out of the box, the format library provides various possible U.S. and Canadian phone numbers. These are valid, realistic looking numbers that can pass standard phone number validation tests employed by applications. You can generate the following types of numbers:
Any North American phone numbers
Any Canadian phone number
Any U.S.A. phone number
The predefined masking formats use functions defined in the DM_FMTLIB package. This package is automatically installed in the DBSNMP schema of your Enterprise Manager repository database. To use the predefined masking formats on a target database (other than the repository database), you must manually install the DM_FMTLIB package on that database.
To install the DM_FMTLIB package:
Locate the following scripts in your Enterprise Manager installation:
$ORACLE_HOME/sysman/admin/emdrep/sql/db/latest/masking/dm_fmtlib_pkgdef.sql $ORACLE_HOME/sysman/admin/emdrep/sql/db/latest/masking/dm_fmtlib_pkgbody.plb
Copy these scripts to a directory in your target database installation and execute them using SQL*Plus, connected as a user that can create packages in the DBSNMP schema.
After the DM_FMTLIB package is installed, you can use the predefined masking formats in your masking definition.
When you create a masking definition ("Creating a Masking Definition"), you will be either importing a format or selecting one from the available types in the Define Column Mask page. Format entry options are as follows:
Array List
The data type of each value in the list must be compatible with that of the masked column. Uniqueness must be guaranteed if needed. For example, for a unique key column that already has 10 distinct values, the array list should also contain at least 10 distinct values.
Delete
Deletes the specified rows as identified by the condition clauses. If a column includes a delete format for one of its conditions, a foreign key constraint or a dependent column cannot refer to the table.
Fixed Number
The type of column applicable to this entry is a NUMBER column or a STRING column. For example, if you mask a column that has a social security number, one of the entries can be Fixed Number 900. This format is combinable.
Fixed String
The type of column applicable to this entry is a STRING column. For example, if you mask a column that has License Plate Number, one of the entries can be Fixed String CA. This format is combinable.
Null Value
Masks the column using a value of NULL. The column must be nullable.
Post-Processing Function
This is a special function that you can apply to the mask value that the masking engine generates. This function takes the mask value as input and returns the actual mask value to be used for masking.
The post-processing function is called after the mask value is generated. You can use it, for instance, to add commas or dollar signs to a value. For example, if a mask value is a number such as 12000, the post processing function can modify this to $12,000. Another use is for adding checksums or special encodings for the mask value that is produced.
In the following statement:
Function post_proc_udf_func (rowid varchar2, column_name varchar2, mask_value varchar2) returns varchar2;
rowid is the min (rowid) of the rows that contains the value mask_value 3rd argument.
column_name is the name of the column being masked.
mask_value is the value being masked.
Preserve Original Data
Retains the original values for rows that match the specified condition clause. This is used in cases where some rows that match a condition do not need to be masked.
Random Dates
The uniqueness of the Date column is not maintained after masking. This format is combinable.
Random Digits
This format generates unique values within the specified range. For example, for a random digit with a length of [5,5], an integer between [0, 99999] is randomly generated, left padded with '0's to satisfy the length and uniqueness requirement. This is a complementary type of random number, which will not be padded. When using random digits, the random digit pads to the appropriate length in a string. It does not pad when used for a number column. This format is combinable.
Data masking ensures that the generated values are unique, but if you do not specify enough digits, you could run out of unique values in that range.
Random Numbers
If used as part of a mixed random string, these have limited usage for generating unique values. This format generates unique values within the specified range. For example, a starting value of 100 and ending value of 200 generates an integer number ranging from 100 to 200, both inclusive. Note that Oracle Enterprise Manager release 10.2.0.4.0 does not support float numbers. This format is combinable.
Random Strings
This format generates unique values within the specified range. For example, a starting length of 2 and ending length of 6 generates a random string of 2 - 6 characters in length. This format is combinable.
Shuffle
This format randomly shuffles the original column data. It maintains data distribution except when a column is conditionally masked and its values are not unique.
For more information, see "Using the Shuffle Format".
Substitute
This format uses a hash-based substitution for the original value and always yields the same mask value for any given input value. Specify the substitution masking table and column. This format has the following properties:
The masked data is not reversible. That is, this format is not vulnerable to external security breaches because the original value is replaced, so it is not possible to retrieve the original value from the mask value.
Masking multiple times with a hash substitute across different databases yields the same mask value. This characteristic is valid across multiple databases or multiple runs assuming that the same substitution values are used in the two runs. That is, the actual rows and values in the substitution table do not change. For example, suppose the two values Joe and Tom were masked to Henry and Peter. When you repeat the same mask on another database using the same substitution table, if there were Bob and Tom, they might be replaced with Louise and Peter. Notice that even though the two runs have different data, Tom is always replaced with Peter.
This format does not generate uniqueness.
Substring
Substring is similar to the database substr function. The start position can be either a positive or a negative integer. For example, if the original string is abcd, a substring with a start position of 2 and length of 3 generates a masked string of bcd. A substring with start position of -2 and length of 3 generates a masked string of cd. This format is combinable.
Table Column
A table column enables you to select values from the chosen column as the replacement value or part thereof. The data type and uniqueness must be compatible. Otherwise, a failure occurs when the job runs. This format is combinable.
Truncate
Truncates all rows in a table. If one of the columns in a table is marked as truncated, the entire table is truncated, so no other mask formats can be specified for any of the other columns. If a table is being truncated, it cannot be referred to by a foreign key constraint or a dependent column.
User Defined Function
The data type and uniqueness of the output values must be compatible with the original output values. Otherwise, a failure occurs when the job runs.
In the following statement:
Function udf_func (rowid varchar2, column_name varchar2, original_value varchar2) returns varchar2;
rowid is the min (rowid) of the rows that contain the value original_value 3rd argument.
column_name is the name of the column being masked.
original_value is the value being masked.
You may occasionally need to consistently mask multiple, distinct databases. For instance, if you run HR, payroll, and benefits that have an employee ID concept on three separate databases, the concept may be consistent for all of these databases, in that an employee's ID can be selected to retrieve the employee's HR, payroll, or benefits information. Based on this premise, if you were to mask the employee's ID because it actually contains his/her social security number, you would have to mask this consistently across all three databases.
Deterministic masking provides a solution for this problem. You can use the Substitute format to mask employee ID column(s) in all three databases. The Substitute format uses a table of values from which to substitute the original value with a mask value. As long as this table of values does not change, the mask is deterministic or consistent across the three databases.
Before creating a masking definition, note the following advisory information:
Make sure the format you select does not violate check constraints and does not break any applications that use the data.
For triggers and PL/SQL packages, data masking recompiles the object.
Exercise caution when masking partitioned tables, especially if you are masking the partition key. In this circumstance, the row may move to another partition.
Data Masking does not support clustered tables, masking information in object tables, XML tables, and virtual columns. Relational tables are supported for masking.
If objects are layered on top of a table such as views, materialized views, and PL/SQL packages, they are recompiled to be valid.
To create a masking definition:
From the Schema menu, select Data Masking Definitions.
The Data Masking Definitions page appears, where you can create and schedule new masking definitions and manage existing masking definitions.
Click Create to go to the Create Masking Definition page.
A masking definition includes information regarding table columns and the format for each column. You can choose which columns to mask, leaving the remaining columns intact.
Specify a required database name. The Database field shows the database name of the database target.
Click Add to go to the Add Columns page, where you can add one or more columns for masking and automatically add foreign key columns. You need to add at least one column in the masking definition.
In the Search section, minimally provide a schema name and optionally provide input for the other search fields to filter the results, then click Search.
Either select one or more columns for later formatting on the Create Masking Definition page, or formatting now if the data types of the columns you have selected are identical.
Tip:
For information on data types, see "Supported Data Types".Decide if you want to mask selected columns as a group. Columns that you want to mask as a group must all be from the same table.
Select this check box if you want to mask more than one column together, rather than separately. When you select two or more columns and then later define the format on the Define Group Mask page, the columns appear together, and any choices you make for format type or masking table apply collectively to all of the columns.
After you define the group and return to this page, the Column Group column in the table shows an identical number for each entry row in the table for all members of the group. For instance, if you have defined your first group containing four columns, each of the four entries in this page will show a number 1 in the Column Group column. If you define another group, the entries in the page will show the number 2, and so forth. This helps you to distinguish which columns belong to which column groups.
Either click Add to add the column to the masking definition, return to the Create Masking Definition page and define the format of the column later, or click Define Format and Add to define the format for the column immediately.
The Define Format and Add feature can save you significant time. When you select multiple columns to add that have the same data type, you do not need to define the format for each column as you would when you click Add. For instance, if you search for Social Security numbers (SSN) and the search yields 100 SSN columns, you could select them all, then click Define Format and Add to import the SSN format for all of them.
Do one of the following:
If you clicked Add in the previous step:
You will eventually need to define the format of the column in the Create Masking Definition page before you can continue. When you are ready to do so, click the icon in the page Format column for the column you want to format. Depending on whether you decided to mask selected columns as a group on the Add Columns page, either the Define Column mask or Define Group mask appears. Read further in this step for instructions for both cases.
If you clicked Define Format and Add in the previous step and did not check Mask selected columns as a group:
The Define Column Mask page appears, where you can define the format for the column before adding the column to the Create Masking Definition page, as explained below:
Provide a format entry for the required Default condition by either selecting a format entry from the list and clicking Add, or clicking Import Format, selecting a predefined format on the Import Format page, then clicking Import.
For information about Oracle-supplied predefined masking format definitions, see "Using Oracle-supplied Predefined Masking Formats".
For descriptions of the choices available in the Format Entry list, see "Providing a Masking Format to Define a Column".
Add another condition by clicking Add Condition to add a new condition row, then provide one or more format entries as described in the previous step.
When you have finished formatting the column, click OK to return to the Create Masking Definition page.
If you clicked Define Format and Add in the previous step and checked Mask selected columns as a group:
The Define Group Mask page appears, where you can add format entries for group columns that appear in the Create Masking Definition page, as explained below:
Select one of the available format types. For complete information on the format types, see the online help.
For descriptions of the choices available in the Format Entry list, see "Providing a Masking Format to Define a Column".
Optionally add a column to the group.
When you have finished formatting the group, click OK to return to the Create Masking Definition page.
Your configuration appears in the Columns table.
Decide whether the default advanced options are applicable for your needs.
For more information, see "Selecting Data Masking Advanced Options".
Click OK to save your definition and return to the Data Masking Definitions page.
At this point, super administrators can see each other's masking definitions.
Select the definition and click Generate Script to view the script for the list of database commands used to mask the columns you selected earlier.
This process checks whether sufficient disk space is available for the operation, and also determines the impact on other destination objects, such as users, after masking. After the process completes, the Script Generation Results page appears, enabling you to do the following:
Save the entire PL/SQL script to your desktop, if desired.
Clone and mask the database using the Clone Database wizard (this requires a Provisioning pack license).
Schedule the data masking job without cloning.
View errors and warnings, if any, in the impact report.
Tip:
For information on page user controls, see the online help for the Script Generation Results page.Note:
If any tables included in the masking definition or reorganization have columns of data type
LONG, a warning message may appear. For more information, see "Using Data Masking with LONG Columns".Do one of the following:
If you are working with a production database, click Clone and Mask to clone and mask the database you are currently working with to ensure that you do not mask your production database.
The Clone and Mask feature requires a Provisioning and Patch Automation pack license.
For more information, see "Cloning the Production Database".
If you are already working with a test database and want to directly mask the data in this database, click Schedule Job.
Tip:
For information on page user controls, see the online help for Scheduling a Data Masking Job.The following options on the Masking Definitions page are all checked by default, so you need to uncheck the options that you do not want to enable.
The data masking options include:
Disable redo log generation during masking
Masking disables redo logging and flashback logging to purge any original unmasked data from logs. However, in certain circumstances when you only want to test masking, roll back changes, and retry with more mask columns, it is easier to uncheck this box and use a flashback database to retrieve the old unmasked data after it has been masked. You can use Enterprise Manager to flashback a database.
Note:
Disabling this option compromises security. You must ensure this option is enabled in the final mask performed on the copy of the production database.Refresh statistics after masking
If you have already enabled statistics collection and would like to use special options when collecting statistics, such as histograms or different sampling percentages, it is beneficial to turn off this option to disable default statistics collection and run your own statistics collection jobs.
Drop temporary tables created during masking
Masking creates temporary tables that map the original sensitive data values to mask values. In some cases, you may want to preserve this information to track how masking changed your data. Note that doing so compromises security. These tables must be dropped before the database is available for unprivileged users.
Ignore orphan foreign key rows
When masking encounters a row in a dependent column table that does not have a corresponding row in the parent table, it can either preserve the row as is or it can delete the orphan row. This option is on by default, so masking then deletes the orphan rows. If the option is turned off, the rows are populated and set to null if the column allows nulls. If the column does not allow nulls, the row is preserved with the original sensitive information.
Use parallel execution when possible
Oracle Database can make parallel various SQL operations that can significantly improve their performance. Data Masking uses this feature when you select this option. You can enable Oracle Database to automatically determine the degree of parallelism, or you can specify a value. For more information about using parallel execution and the degree of parallelism, see Oracle Database Data Warehousing Guide.
The random number generation options include:
Favor Speed
The DBMS_RANDOM package is used for random number generation.
Favor Security
The DBMS_CRYPTO package is used for random number generation. Additionally, if you use the Substitute format, a seed value is required when you schedule the masking job or database clone job.
Use the text box to specify any user-specified SQL script that must run before masking starts.
Use the text box to specify any user-specified SQL script that must run after masking completes. Since masking modifies data, you can also perform tasks, such as rebalancing books or calling roll-up or aggregation modules, to ensure that related or aggregate information is made consistent.
The following prerequisites apply for the column to be defined as dependent:
A valid dependent column should not already be included for masking.
The column should not be a foreign key column or referenced by a foreign key column.
The column data should conform to the data in the parent column.
If the column does not meet these criteria, an "Invalid Dependent Columns" message appears when you attempt to add the dependent column.
To add dependent columns:
From the Create Masking Definition page, click the Add + icon in the Dependent Columns Add column for the column you want to format.
The Add Dependent Columns page appears.
In the Search section, minimally provide a schema name or select it by clicking on the flashlight search icon, then clicking Search.
Select one or more column names from the list that appears below, then click Add.
The Create Masking Definition page reappears and displays your added dependent column(s) in the Dependent Columns table at the bottom of the page. The dependent column(s) will be masked using the same format as specified for the parent column.
When you clone and mask the database, a copy of the masking script is saved in the Enterprise Manager repository and then retrieved and executed after the clone process completes. Therefore, it is important to regenerate the script after any schema changes or modifications to the production database.
To clone and optionally mask the masking definition's target database:
Ensure that you have a Provisioning and Patch Automation pack license before proceeding. The Clone Database feature requires this license.
From the Data Masking Definitions page, select the masking definition you want to clone, select Clone Database from the Actions list, then click Go.
The Clone Database wizard appears, where you can create a test system to run the mask. You can also access this wizard by clicking the Clone and Mask button from the Script Generation Results page.
Proceed through the wizard steps as you ordinarily would to clone a database. For assistance, refer to the online help for each step.
In the Database Configuration step of the wizard, add a masking definition.
Schedule and then run the clone job.
You can import and re-use a previously exported data masking definition saved as an XML file to the current Enterprise Manager repository.
Click the Import button on the Data Masking Definition page to import the XML file. After the import finishes, the Data Masking Definitions Page reappears and displays the imported definition in the table list for subsequent viewing and masking.
Note the following advisory information:
The XML file format must be compliant with the masking definition XML format.
Verify that the name of the masking definition to be imported does not already exist in the repository.
Verify that the target name identifies a valid Enterprise Manager target.
A shuffle format is available that does not preserve data distribution integrity. This format masks a column by shuffling the original column values among its rows. It replaces the original values with one of the values picked up randomly from a set of distinct original values.
For example, consider the Original Table (Table 13-1) that shows two columns: EmpName and Salary. The Salary column has three distinct values: 10, 90, and 20.
If you mask the Salary column with this format, each of the original values is replaced with one of the values from this set. Assume that the shuffle format replaces 10 with 20, 90 with 10, and 20 with 90 (Table 13-2).
The result is a shuffled Salary column as shown in the Masked Table (Table 13-3), but the data distribution is changed. While the value 10 occurs three times in the Salary column of the Original Table, it occurs only twice in the Masked Table.
When Reorganize Objects script generation completes, an impact report appears. If any tables included in the reorganization have columns of data type LONG, the following warning message may be displayed in the impact report:
Reorganization includes a table with a LONG column. To support reorganization of tables with LONG columns that are greater than 32KB, the external procedure MGMT$REORG_MOVELONGCOMMAND must be configured properly. It has been determined this external procedure is not currently configured as expected.
If this message is displayed in the impact report, examine the data in the LONG columns. If the data is less than 32KB, you can ignore this message. If the data is greater than 32KB, return from the Reorganize Objects wizard and use the following procedure:
To configure the database for external procedure connections:
Shut down the target database and its listener.
Edit $ORACLE_HOME/network/admin/tnsnames.ora and add the following entry:
EXTPROC_CONNECTION_DATA =
(DESCRIPTION =
(ADDRESS_LIST =
(PROTOCOL=IPC)(KEY=EXTPROC))
(CONNECT_DATA =
(SID=PLSExtProc)(PRESENTATION=RO)))
Save the changes to tnsnames.ora and exit the editor.
Edit $ORACLE_HOME/network/admin/listener.ora and make the following changes:
An entry in listener.ora looks similar to the following example:
LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS =
(PROTOCOL = tcp)(HOST = host1.us.oracle.com)(PORT = 1521)))))
Add a new ADDRESS_LIST parameter to this entry:
LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS =
(PROTOCOL = tcp)(HOST = host1.us.oracle.com)
(PORT = 1521)))
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC)))))
A second entry in listener.ora looks similar to the following example:
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC = (SID_NAME = db1)(ORACLE_HOME = /scratch/oracle/db1)))
Add a new SID_DESC parameter to this entry:
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC = (SID_NAME = db1)(ORACLE_HOME = /scratch/oracle/db1))
(SID_DESC =
(SID_NAME = PLSExtProc)
(ORACLE_HOME = /scratch/oracle/db1)
(PROGRAM = extproc)
(ENVS =
"EXTPROC_DLLS=ANY,
LD_LIBRARY_PATH=/usr/lib:/scratch/oracle/db1/lib")))
Save the changes to listener.ora and exit the editor.
Ensure that the following file exists in your database installation:
$ORACLE_HOME/lib/libnmuc.so
Restart the listener and the database.
Launch Reorganize Objects and generate the script.
The warning message should now not appear in the impact report.
Schedule and submit the job.
The following message will appear in the job output log:
Copy with PLSQL block failed due to size of long. Using gmt$Reorg_MoveLongCommand to perform the reorganization.
This message is expected. Any tables with LONG columns are masked or reorganized successfully.
|
 Copyright © 2008, 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|