One last comment on this thread...
There are two types of obfuscation or masking which resolve different issues...
1. masking in-flight
* obfuscation of data performed on retrieval from the database
o unmasked original data remains unchanged within the database
* provides additional data security within the source-of-record
2. masking at-rest
* obfuscation of data performed on data within the database
o data is masked within the database so that there is no
unmasked data available
* provides complete data security for copied/cloned data outside
Masking in-flight is appropriate in production systems (a.k.a. source-of-record) as a complementary solution, augmenting systems- and application-authentication and application-authorization.
Masking at-rest is the best solution for copied or cloned data, usually to non-production or lower environments such as development, testing, training, and similar. This data might come to reside outside the organization firewall (i.e. out-sourcing, cloud, etc), so eliminating the liability of confidential data possibly being outside organizational control is the best policy. This also has the side-effect of minimizing the liability from breaches of confidential data (intentional or accidental) from inside the organization. Eliminate the confidential data, eliminate the risk and liability.
Oracle VPD is "masking in-flight", so if the use-case does not involve the source-of-record, then it is probably not the best solution.
Just my US$0.02...
On 6/15/18 21:26, Sanjay Mishra (Redacted sender smishra_97 for DMARC) wrote:
On Friday, June 15, 2018, 5:34:38 PM EDT, Vishnu <vishnukumarmp@xxxxxxxxx> wrote:
Sanjay - refer below link
On Thu, Jun 14, 2018 at 4:25 PM Sanjay Mishra <smishra_97@xxxxxxxxx <mailto:smishra_97@xxxxxxxxx>> wrote:
These restrictions are on non-prod environment where all of these
ID are either Developer/Testers/manager etc. So a lot of data are
masked but some of these are critical for testing and so the
company decided to even put an additional measure in place to
restrict the access on some rows. Got some idea from your input
but can you provide any sample or link to check for some details
on first part which is not linked to the policy as I can handle
On Thursday, June 14, 2018, 12:47:17 PM EDT, Vishnu
<vishnukumarmp@xxxxxxxxx <mailto:vishnukumarmp@xxxxxxxxx>> wrote:
In your case, your mentioned "500 users in the database" , is it
all database user/schema accounts or application users that use a
common app schema to connect to the database. You can do something
like this - use database log on trigger / set db context and use
client identifier (if its a app user) or session user (if its a db
user) to identify logged in user details and apply custom written
functions that can dynamically add where clause to the queries
based on conditions that can filter and provide appropriate
results. Finally you can add policy to the object where you want
to apply vpd. so whenever that object gets requested, policy will
be applied to restrict the results.
On Thu, Jun 14, 2018 at 11:54 AM Sanjay Mishra
YEs VPD look like is the solution and so looking for some high
level approach from the experts who has worked with VPD.
On Thursday, June 14, 2018, 9:31:33 AM EDT, Jko
Vpd will solve your problem easily.
Le 14 juin 2018 15:26:26 "Sanjay Mishra"
<mailto:dmarc-noreply@xxxxxxxxxxxxx>> (Redacted sender
"smishra_97" for DMARC) a écrit :
Need some view on best approach to do data masking. I had
around 8-10 tables with 2 columnn that has secured financial
data. Column name are same in all tables where data need to
The requirement is that there are 500 users in the database
and data need to be restricted using these 2 columns for
these 10 tables
1. One set of the user will have access to all Data
2. Another set can use column 1 value condition
3. Another set of the user who can see the data based on
Column 2 value condition
Oracle 12.1 and has Enterprise license for all Oracle
options. ANy approach that can help in creating the plan
will be helpful