Data Obfuscation in Non-Prod Environments

[Rob_Dale]

I'm trying to figure out a way to handle this in OnBase, or if it's possible at all.

We have a security goal for the year of obfuscating all data in non-prod environments for all systems.  So, in QA and Test, they want to scramble and randomize all Personal Identifiable Information, such as Name, Policy Number, SSN, etc.  I'm not aware of any way to do this in OnBase.  I know modifying the database directly is not allowed.  Has anyone else been required to do this?  What was the solution?

Thank you.

[AdamShaneHyland · Accepted solution]

Hi Rob.

Hopefully others will weigh in on this as I don't have a great answer for you.  

There are a few things which come to mind.  It is always possible to determine what Keyword Values need to be updated and then use Keyword Updater as one method to scramble the data in your DEV environment.  This would work as a Find/Replace to update the values.  Keep in mind that you would need to purge the OnBase Transaction Log as part of this process else all of the updates would still be in the hsi.transactionxlog table. 

You could also use Configuration Migration (prior to OnBase 18) or the Test System Creation Utility (post OnBase 18) to create a DEV database using the configuration of another database.  Then uses another mechanism like Workflow Item Generators and/or DIP to generate data.  The Unity API could also be used to randomly generate documents and keywords.

Note, that while it is not possible for you to update the database without Hyland's consent by signing a Database Modification Agreement, that doesn't mean it is impossible.   With this method you would have to design your own SQL to be reviewed by Hyland and sign an agreement.  You would have to work with your first line of support .  This might be another way for you to manage the data in your environment if you are performing a backup and restore of a PROD database to create your TEST/DEV environment.  Keep in mind that any SQL updates would still be in the database transaction log and would need to be accounted for else the protected data still exists somewhere where it shouldn't.

Good luck.