This content has been marked as final. Show 4 replies
Requirement 2 doesn't make sense to me. You say that the original data should not be visible. But then you say that both the application and the database should provide decrypted data to the users. That doesn't make sense to me. Did you mean that both should provide encrypted data to the users?
Are you trying to mask the data? Or to encrypt the data?
Does the data actually need to be masked in the table? Or could you simply use a VPD policy (or some other access control mechanism) to limit which users have access to the data?
I have no idea whether Oracle supports creating a VPD policy (or otherwise manipulating) the data in a delivered Oracle eBusiness Suite database (I'm assuming that R12.1.3 is referring to some application in the eBusiness Suite). That would be a question for Oracle Support and/or one of the eBusiness Suite forums.
My bad on point#2. It refers to the encrypted data.
I am trying to mask/encrypt the data whichever is easier. But it should enable us to obfuscate the data from the users from both database queries and from applications, except for a set of users.
Suppose SSN is masked/encrypted in its underlying table per_all_people_f, I should not be able to see the decrypted data using a query on the per_all_people_f table. Nor should I be able to see the SSN while I am logged in Oracle applications front end. But let's say we have user ABC that belongs to the priveleged group, he should be able to both query the data and see the decrypted SSN and also be able to see the decrypted SSN when he is logged in through oracle applications front end.
Your best bet is to use a de-identification tool where you can keep referential integrity across different types of data bases and does not involve any SQL or other types of coding. For the third point, I would provision a separate data bases that was not de-identified and point the application to this one (providing that you have the proper security waivers signed)