By Muthuvel Arumugam-Oracle on Jul 10, 2015
In Release 10 of Fusion Applications, Oracle Data Masking for Fusion HCM Security Cloud Service is offered as an optional subscription service for Fusion HCM Cloud customers. Release 11 extends this to include ERP and Sales Cloud products, masking PII attributes in tables owned by these products.
Data masking, also known as data scrambling or data anonymization, is the process of obscuring sensitive information copied from a production database with realistic, scrubbed data based on masking rules, to a test or non-production database. Data masking is ideal for any situation where confidential or regulated data needs to be shared with non-production users who need access to the original data, but not necessarily to every column of every table. Examples of non-production users include internal application developers or external business partners, such as offshore testing companies, suppliers or customers.
Customers can submit a data masking service request as part of an environment refresh request. Personally Identifiable Information (PII) data are removed or masked in the Applications schema, and removed from temporary tables, interface tables and audit shadow tables including workflow notifications. In addition, links to attachments are removed, thus removing access to these attachments from the user interfaces. Data masking is run after the environment refresh and released to customers after the masking process is complete.
Data Masking in Release 10 of Fusion Applications is designed to mask specific sensitive personal data or PII attributes. Different masking rules are applied for these attributes to ensure the masked data does not fail validation when the same is queried in Fusion Applications user interfaces. PII attributes covered by data masking are:
- Person Name
- Person Telephone Number
- Date of Birth
- Date of Death
- Country / Town / Region of Birth
- Bank Account Number
- Credit Card Number
- Instant Messaging / Email Address
- Passport Number, Visa or Work Permit details
- Tax Registration Number or National Taxpayer Identifier
Customers are strongly encouraged to use the principle of least privilege when granting users access to a masked database by restricting the access privileges. Users should be granted only those privileges that are necessary to complete their work.
There are some scenarios that are not addressed by the Oracle Data Masking for Fusion Applications.
- Underlying identities are not masked in the Fusion schema; therefore, it is possible to associate internal database IDs with identities and infer those identities in the masked database.
- User login accounts are not masked; therefore, certain formats such as firstname.lastname may reveal identities in the masked database.
- Other sensitive information, such as compensation, performance and benefits are not masked.
- Running Payroll on a masked database may not fetch valid results as any PII attributes related to payroll calculation are scrambled.
Ensure you understand the limitations with using masked data before requesting data masking service. Masking data may not be helpful in certain scenarios which include:
- Testing payroll calculation or other processes that uses data masked by data masking service
- Verifying interfaces to downstream systems that require real or original (unmasked) data