Oracle Data Masking with Oracle Enterprise Manager

Commonly companies who are serious about IT and their IT infrastructure and their IT landscape do tend to a DTAP strategy. DTAP stands for Development, Test, Acceptance and Production environments. Commonly DTAP landscapes are used in environments where companies do create their own software or customizations on standard software. This means that for every production system you will have 3 separate environments to be used by developers, testers and the business to approve the changes before they will be deployed in your production environment.

In situations where multiple projects for the same production environments are done simultaneously it is not uncommon to have multiple DTA environments while having a single production environment. When you are working with multiple development projects at once it is of vital importance to have a correct version and configuration management in place to ensure that when the projects are combined in the single production instance it is able to work integrated and is not undoing some of the work done in the other project.

Almost as important as a good configuration and version management is the management of your none-production environments. This is not only the case when working with multiple projects and changes at the same time. This is evenly important when developing in a single DTA(P) setup.  Your developers and testers are in need of environments that are as close to the production situation as possible. Commonly production systems are cloned to Development, test and Acceptance environments to enable your developers and testers to do their job.

Technically it is a simple exercise to clone a production environment to a none-production environment. At least, this is the case for most Oracle products. Even though it is technically it is a simple exercise it can be a complicated exercise from a legal, risk and security perspective. Companies who do not pay attention to this process in their company can end up in the situation that confidential production data becomes available to developers. A developer for example working on customizations in the Oracle E-Business suite payroll modules can get access to the entire payroll information of your corporation. Secondly, when not paying attention your developers can gain access to production passwords as most developers have unlimited access to the application and database. An example of such an exploit on Oracle E-Business suite passwords can be found in my blogpost from December 2006. Currently most companies do understand that they have to reset production passwords during a clone before releasing it to developers and testers. The understanding of masking and/or sub-setting your production data before releasing it to none-production systems is however not that common. 

Next to changing passwords when you move your data from production to none-production systems you will have to consider the strategy on which data can be accessed by your developers which is not critical or confidential data. Oracle is providing a solution for this in the form of Oracle Data Masking solutions which are an integrated part of Oracle Enterprise Manager. By using Oracle data masking you can create profiles of your data and make sure confidential data is masked (changed to none confidential data) and you can do sub-setting.

As you can see in the above diagram you can create an Application Data Model in which you  can define which data has to be extracted from your production system. The extracted data will be pumped to the datamasking and/or subsetting 

Subsetting:
The intention of subsetting is to decrease the amount of data that is transported to your none-development environments. For example, in your Application Data Model you stated you want to extract all the information from your Order Management module. This will ensure that you get ALL the data from your Order Management module you have indicated that needs to be extracted. In subsetting you can define you would like to have for example only the orders from the past 2 months. In most cases your developers and testers do not need the full set of data to perform their job. This is not only resulting in shorter times to move the data it will also reduce the amount of storage needed in your none-production environments.

Datamasking:
The intention of datamasking is to ensure no confidential data is moved out of your production database to your none-production database. This is done while keeping the integrity of your data. For example, you might have customer creditcard numbers in your Order Management module data. You do not want this data to be moved and to be accessed by your developers and testers however you do want to have creditcard numbers with the same logic in it. You could for example have some logic in your application to check if the creditcard number is a valid number. Due to this reason you cannot simply substitute the original creditcard number with a random number, you want it to have the same structure as a official creditcard number. The same applies for example for social security numbers, zip-code information, etc etc.

In the above screenshot you can see the format library, here you can define the format of a to-be substituted value. You can define how a creditcard number should be formed. By using this you can substitute values by “random” values while keeping the integrity. This enables your developers and testers to work on production data which is made anonymous and where the confidential data is substituted by none-confidential data.

For some Oracle products there are standard libraries available, if you have a custom build application you will have to create your own strategy. Even though it takes some knowledge and effort to initially create this you will benefit from it and the security of your confidential data is not compromised.

The below video shows you an example of Oracle Data Masking while using Oracle Enterprise Manager 11G. Do keep in mind that a newer version of Oracle Enterprise Manager is currently available.