The following actions are part of the data masking process:
a. Re-create masked table copy & populate using renamed original table and mapping table.
b. Disable constraints on table & rename table.
c. Build mapping table containing original sensitive and masked values using masking routines.
d. Drop renamed table and mapping table.
e. Restore constraints based on original table & collect statistics.
In which order are these actions performed?
A.
A-B-C-D-E
B.
E-D-C-B-A
C.
A-C-E-B-D
D.
C-B-A-D-E
E.
C-A-B-E-D
Explanation:
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 “Masking with an Application Data Model and Workloads”.
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.