Just need to highlight the problem in prod.
The rules applied can actually cause problems with the COTS applications like
EBS that has their own internal security architecture.
Just need to do lots of testing.
Matthew Parker
Chief Technologist
Dimensional DBA
Oracle Gold Partner
425-891-7934 (cell)
D&B 047931344
CAGE 7J5S7
<mailto:Dimensional.dba@xxxxxxxxxxx> Dimensional.dba@xxxxxxxxxxx
<http://www.linkedin.com/pub/matthew-parker/6/51b/944/> View Matthew Parker's
profile on LinkedIn
<http://www.dimensionaldba.com/> www.dimensionaldba.com
From: oracle-l-bounce@xxxxxxxxxxxxx <oracle-l-bounce@xxxxxxxxxxxxx> On Behalf
Of Tim Gorman
Sent: Thursday, October 4, 2018 10:52 AM
To: dimensional.dba@xxxxxxxxxxx; sjaffarhussain@xxxxxxxxx; 'Oracle-L Freelists'
<oracle-l@xxxxxxxxxxxxx>
Subject: Re: Hiding sensitive EBS column data from certain users
For production environments, technologies which mask data in-flight, including
Oracle's data redaction and SQL Server's dynamic data masking are appropriate
solutions when a portion of the user community should not have access to
certain data.
In development or testing (a.k.a. non-production) environments, there is no
reason for anyone to have access to confidential data, including database
administrators and systems administrators, partially because of the movement of
development and testing environments to out-sourced, off-shore, or cloud
environments. Masking data at-rest is the appropriate solution for
non-production environments by permanently and irreversibly obfuscating data in
datafiles, thus removing any value to intruders.
Following the implementation of GDPR
<https://en.wikipedia.org/wiki/General_Data_Protection_Regulation> in Europe
this past May, CCPA <https://www.caprivacy.org/> in California has already
been signed into law, with more countries and states to follow. The
professional honor code to which all of IT has adhered for the past 40-50 years
is no longer sufficient to protect confidential data. Essentially, unmasked
data in non-production is becoming a liability to the DBAs, developers, and
testers who work with it, because at some point, all these laws may hold
individuals (as well as organizations) liable for the damages from data
breaches. I expect that, like SOX, individual liability will begin at the top
of the organization (i.e. CEO, CFO, etc) but with examples like Snowden there
is no reason why those lower in the hierarchy cannot be targeted.
On 10/4/18 11:04, Matthew Parker wrote:
In Production or in Development? Different ways to do things based on the
environment.
What version of the database are you running?
In 12.1 there is RAS Security (VPD 2.0) that also does column level data
masking at no extra cost, but you have to create/implement the rules yourself.
Normally you control PROD by standard security controls, but you can implement
RAS against report users if they are landing on your primary database. Just
need to make sure anything you implement it doesn’t affect base EBS apps.
Matthew Parker
Chief Technologist
Dimensional DBA
Oracle Gold Partner
425-891-7934 (cell)
D&B 047931344
CAGE 7J5S7
<mailto:Dimensional.dba@xxxxxxxxxxx> Dimensional.dba@xxxxxxxxxxx
<http://www.linkedin.com/pub/matthew-parker/6/51b/944/> View Matthew Parker's
profile on LinkedIn
<http://www.dimensionaldba.com/> www.dimensionaldba.com
From: oracle-l-bounce@xxxxxxxxxxxxx <mailto:oracle-l-bounce@xxxxxxxxxxxxx>
<mailto:oracle-l-bounce@xxxxxxxxxxxxx> <oracle-l-bounce@xxxxxxxxxxxxx> On
Behalf Of Syed Jaffar Hussain
Sent: Thursday, October 4, 2018 9:51 AM
To: Oracle-L Freelists <mailto:oracle-l@xxxxxxxxxxxxx> <oracle-l@xxxxxxxxxxxxx>
Subject: Hiding sensitive EBS column data from certain users
Hello List,
Is there anyway to hide data of sensitive columns in Oracle EBS (v12.2) to
certain users? I thought of VPD, but, it seems, it has different approaches in
EBS. Something like, personalizing the form to hide the values of the columns,
though not sure.
Appreciate if any EBS expert can shed some light on this.
Thanks in advance,
--
Best Regards,
Syed Jaffar Hussain
