Re: Hiding sensitive EBS column data from certain users
From: Mark Burgess <mark_at_burgess-consulting.com.au>
Date: Fri, 5 Oct 2018 09:06:02 +1300
Message-Id: <C1219A1B-9754-4ACC-A13E-D3B9C5EE9201_at_burgess-consulting.com.au>
>> Thank you all for fhe swift response.
>>
>> Its a production EBS 12.2.6 environment. The requirement is to hide certain columns data in HR and Finance modules to specific users through forms.
>> If we apply VPD it will break forms functionality. Also APPS. These are application defined users. In EBS its not simple VpD. So, any body with EBS functional and development knowledge can respond this.
>>
>> Regards
>>
>> On Thu, 4 Oct 2018 at 8:56 PM Matthew Parker <dimensional.dba_at_comcast.net <mailto:dimensional.dba_at_comcast.net>> wrote:
>> 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
>>
>> Dimensional.dba_at_comcast.net <mailto:Dimensional.dba_at_comcast.net>
>> View Matthew Parker's profile on LinkedIn <http://www.linkedin.com/pub/matthew-parker/6/51b/944/>
>> www.dimensionaldba.com <http://www.dimensionaldba.com/>
>>
>>
>> From: oracle-l-bounce_at_freelists.org <mailto:oracle-l-bounce_at_freelists.org> <oracle-l-bounce_at_freelists.org <mailto:oracle-l-bounce_at_freelists.org>> On Behalf Of Tim Gorman
>> Sent: Thursday, October 4, 2018 10:52 AM
>> To: dimensional.dba_at_comcast.net <mailto:dimensional.dba_at_comcast.net>; sjaffarhussain_at_gmail.com <mailto:sjaffarhussain_at_gmail.com>; 'Oracle-L Freelists' <oracle-l_at_freelists.org <mailto:oracle-l_at_freelists.org>>
>> 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
>>
>> Dimensional.dba_at_comcast.net <mailto:Dimensional.dba_at_comcast.net>
>> View Matthew Parker's profile on LinkedIn <http://www.linkedin.com/pub/matthew-parker/6/51b/944/>
>> www.dimensionaldba.com <http://www.dimensionaldba.com/>
>>
>>
>> From: oracle-l-bounce_at_freelists.org <mailto:oracle-l-bounce_at_freelists.org> <oracle-l-bounce_at_freelists.org> <mailto:oracle-l-bounce_at_freelists.org> On Behalf Of Syed Jaffar Hussain
>> Sent: Thursday, October 4, 2018 9:51 AM
>> To: Oracle-L Freelists <oracle-l_at_freelists.org> <mailto:oracle-l_at_freelists.org>
>> 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
>>
>>
>> --
>> Best Regards,
>>
>> Syed Jaffar Hussain
>> Oracle ACE Director <http://apex.oracle.com/pls/otn/f?p=19297:4:4640302666204919::NO:4:P4_ID:186>
>> Oracle Certified Master (10g) <http://education.oracle.com/education/otn/shussain.html>
>> Authored Expert Oracle RAC 12c <http://www.apress.com/9781430250449>
>> Oracle 11gR1/R2 RAC Essentials <http://link.packtpub.com/yNZicz>,
>> Oracle Exadata Expert's Handbook <http://www.pearsonhighered.com/educator/product/Oracle-Exadata-Experts-Handbook/9780321992604.page>
>> Oracle Problem Solving and Troubleshooting Handbook <http://www.pearson.com.au/products/A-C-Ault-Czuprynski/Oracle-Problem-Solving-and-Troubleshooting-Handbook/9780134429205?R=9780134429205>
>> Oracle Magazine DBA of year (2011)
>> OCP 8i/9i/10g/11g DBA, RAC Certified Expert, ITIL V3 foundation certified
>> Mini MBA
>> Certified Oracle Exadata Database Machine Implementation Essentials
>> Oracle Certified Expert, Oracle Exadata X3 and X4 Administrator
>> Charity : www.sajcharity.org <http://www.sajcharity.org/>
>> I blog at : http://jaffardba.blogspot.com/ <http://jaffardba.blogspot.com/>
>> LinkedIn : http://www.linkedin.com/in/sjaffarhussain <http://www.linkedin.com/in/sjaffarhussain>
>> Follow me on twitter : http://twitter.com/#!/sjaffarhussain <http://twitter.com/#%21/sjaffarhussain>
>> --------------------
>> "Winners don't do different things. They do things differently."
>
Date: Fri, 5 Oct 2018 09:06:02 +1300
Message-Id: <C1219A1B-9754-4ACC-A13E-D3B9C5EE9201_at_burgess-consulting.com.au>
Syed,
just to add to the excellent comments already made. You must work within the EBS application security model to limit user access to data - this is inclusive of user eBS application access through forms or custom application access. Locking down your user access will require correct role/responsibility assignment to the relevant users which is typically a functional/sysadmin setup task as there are significant dependencies in how the system operates based on how user roles and responsibilities are defined.
Form Folders are one option to control what data is presented from the forms UI - this is a functional/developer setup type of activity as well.
Assuming here that the restriction is required for the Oracle eBS forms and not a custom app that is accessing the eBS database. Custom apps have their own special requirements in order to work within the eBS security model.
Regards,
Mark
> On 5 Oct 2018, at 7:20 am, Tim Gorman <tim.evdbt_at_gmail.com> wrote: > > Syed, > > Your best bet is to use the security functionality of EBS to differentiate between groups of users, either by setting up custom responsibilities or even multi-org functionality. EBS is extremely integrated with Oracle database, and as you know many features within Oracle database were instigated by EBS (i.e. VPD, editions, etc) over the years. > > I'm sure something clever might be devised that might work in R12.2.6, but you'd have to add retesting of such functionality to already enormous project of patching and upgrading, forever. And if any future patch or upgrade did break what was concocted, then it would be a lengthy task for future folks to determine if it can be fixed or to start from square one again. > > In summary, this is actually a functional problem, not a technical problem. > > Hope this helps... > > -Tim > > > > On 10/4/18 12:10, Syed Jaffar Hussain wrote:
>> Thank you all for fhe swift response.
>>
>> Its a production EBS 12.2.6 environment. The requirement is to hide certain columns data in HR and Finance modules to specific users through forms.
>> If we apply VPD it will break forms functionality. Also APPS. These are application defined users. In EBS its not simple VpD. So, any body with EBS functional and development knowledge can respond this.
>>
>> Regards
>>
>> On Thu, 4 Oct 2018 at 8:56 PM Matthew Parker <dimensional.dba_at_comcast.net <mailto:dimensional.dba_at_comcast.net>> wrote:
>> 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
>>
>> Dimensional.dba_at_comcast.net <mailto:Dimensional.dba_at_comcast.net>
>> View Matthew Parker's profile on LinkedIn <http://www.linkedin.com/pub/matthew-parker/6/51b/944/>
>> www.dimensionaldba.com <http://www.dimensionaldba.com/>
>>
>>
>> From: oracle-l-bounce_at_freelists.org <mailto:oracle-l-bounce_at_freelists.org> <oracle-l-bounce_at_freelists.org <mailto:oracle-l-bounce_at_freelists.org>> On Behalf Of Tim Gorman
>> Sent: Thursday, October 4, 2018 10:52 AM
>> To: dimensional.dba_at_comcast.net <mailto:dimensional.dba_at_comcast.net>; sjaffarhussain_at_gmail.com <mailto:sjaffarhussain_at_gmail.com>; 'Oracle-L Freelists' <oracle-l_at_freelists.org <mailto:oracle-l_at_freelists.org>>
>> 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
>>
>> Dimensional.dba_at_comcast.net <mailto:Dimensional.dba_at_comcast.net>
>> View Matthew Parker's profile on LinkedIn <http://www.linkedin.com/pub/matthew-parker/6/51b/944/>
>> www.dimensionaldba.com <http://www.dimensionaldba.com/>
>>
>>
>> From: oracle-l-bounce_at_freelists.org <mailto:oracle-l-bounce_at_freelists.org> <oracle-l-bounce_at_freelists.org> <mailto:oracle-l-bounce_at_freelists.org> On Behalf Of Syed Jaffar Hussain
>> Sent: Thursday, October 4, 2018 9:51 AM
>> To: Oracle-L Freelists <oracle-l_at_freelists.org> <mailto:oracle-l_at_freelists.org>
>> 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
>>
>>
>> --
>> Best Regards,
>>
>> Syed Jaffar Hussain
>> Oracle ACE Director <http://apex.oracle.com/pls/otn/f?p=19297:4:4640302666204919::NO:4:P4_ID:186>
>> Oracle Certified Master (10g) <http://education.oracle.com/education/otn/shussain.html>
>> Authored Expert Oracle RAC 12c <http://www.apress.com/9781430250449>
>> Oracle 11gR1/R2 RAC Essentials <http://link.packtpub.com/yNZicz>,
>> Oracle Exadata Expert's Handbook <http://www.pearsonhighered.com/educator/product/Oracle-Exadata-Experts-Handbook/9780321992604.page>
>> Oracle Problem Solving and Troubleshooting Handbook <http://www.pearson.com.au/products/A-C-Ault-Czuprynski/Oracle-Problem-Solving-and-Troubleshooting-Handbook/9780134429205?R=9780134429205>
>> Oracle Magazine DBA of year (2011)
>> OCP 8i/9i/10g/11g DBA, RAC Certified Expert, ITIL V3 foundation certified
>> Mini MBA
>> Certified Oracle Exadata Database Machine Implementation Essentials
>> Oracle Certified Expert, Oracle Exadata X3 and X4 Administrator
>> Charity : www.sajcharity.org <http://www.sajcharity.org/>
>> I blog at : http://jaffardba.blogspot.com/ <http://jaffardba.blogspot.com/>
>> LinkedIn : http://www.linkedin.com/in/sjaffarhussain <http://www.linkedin.com/in/sjaffarhussain>
>> Follow me on twitter : http://twitter.com/#!/sjaffarhussain <http://twitter.com/#%21/sjaffarhussain>
>> --------------------
>> "Winners don't do different things. They do things differently."
>
-- http://www.freelists.org/webpage/oracle-lReceived on Thu Oct 04 2018 - 22:06:02 CEST