Re: VPD

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 the source-of-record

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:
> Thanks Vishnu
>
> On Friday, June 15, 2018, 5:34:38 PM EDT, Vishnu
> <vishnukumarmp_at_gmail.com> wrote:
>
>
> Sanjay - refer below link
> https://gjilevski.com/2011/02/01/example-of-vpd-implementation-in-oracle-10g11g/
>
> Thanks,
> Vishnu
>
> On Thu, Jun 14, 2018 at 4:25 PM Sanjay Mishra <smishra_97_at_yahoo.com
> <mailto:smishra_97_at_yahoo.com>> wrote:
>
> Vishnu
>
> 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
> policy part
>
> Tx
> Sanjay
>
> On Thursday, June 14, 2018, 12:47:17 PM EDT, Vishnu
> <vishnukumarmp_at_gmail.com <mailto:vishnukumarmp_at_gmail.com>> wrote:
>
>
> Hi Sanjay,
>
> 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.
>
> Thanks,
> Vishnu
>
> On Thu, Jun 14, 2018 at 11:54 AM Sanjay Mishra
> <dmarc-noreply_at_freelists.org <mailto:dmarc-noreply_at_freelists.org>>
> wrote:
>
> YEs VPD look like is the solution and so looking for some high
> level approach from the experts who has worked with VPD.
>
> Tx
> Sanjay
>
> On Thursday, June 14, 2018, 9:31:33 AM EDT, Jko
> <jacques.kostic_at_gmail.com <mailto:jacques.kostic_at_gmail.com>>
> wrote:
>
>
> Hi
>
> Vpd will solve your problem easily.
>
> Cheers
> Jki
>
> Le 14 juin 2018 15:26:26 "Sanjay Mishra"
> <dmarc-noreply_at_freelists.org
> <mailto:dmarc-noreply_at_freelists.org>> (Redacted sender
> "smishra_97" for DMARC) a écrit :
>
>> Hi Everyone
>>
>> 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
>> masked.
>>
>> 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
>>
>> TIA
>> Sanjay
>

--
http://www.freelists.org/webpage/oracle-l