Page 1 of 1

Select Privileges & Sox compliance

Posted: Thu Mar 08, 2007 6:50 am
by zzgani
Hi,

I guess a lot might have been discuss about the need for select privileges on certain sys table for Oracle Enterprise stage to work.

But my client is adament on not to give these select privileges on dba tables to ETL user account as they are against the Sox compliance :roll: .

Is there any work around in this case ?

Thanks
zzgani

Posted: Thu Mar 08, 2007 6:58 am
by kumar_s
You will be ended up in not using Oracle stages, as simple as that. You would still able to acheive all the functionality through stored procedures are script and it been called via Datastage, but by this you ultimately loose the efficiency of High speed capacity of Datastage.

Re: Select Privileges & Sox compliance

Posted: Thu Mar 08, 2007 8:29 am
by chulett
zzgani wrote:But my client is adament on not to give these select privileges on dba tables to ETL user account as they are against the Sox compliance :roll: .

I'm sorry, but that is just so wrong and shows a poor understanding of what 'Sox compliance' means. Without those privs you are SOL. So, it's ok for the ETL user to delete production data but not to select from dba views? :roll:

The work around is to talk to the DBAs behind the client's back. :wink:

Posted: Thu Mar 08, 2007 8:37 am
by ray.wurlod
Where, in the SOX legislation, does it say that you can't have SELECT privilege to SYS tables?!!

It is IMPOSSIBLE to do damage with only SELECT privilege.

It is also impossible to use the Oracle Enterprise stage without SELECT privilege to these tables, because it (the stage) needs to check the metadata at runtime, so that the design is "idiot-proofed" - a laudable aim, surely?

Re: Select Privileges & Sox compliance

Posted: Thu Mar 08, 2007 8:56 am
by zzgani
chulett wrote:
zzgani wrote:But my client is adament on not to give these select privileges on dba tables to ETL user account as they are against the Sox compliance :roll: .

I'm sorry, but that is just so wrong and shows a poor understanding of what 'Sox compliance' means. Without those privs you are SOL. So, it's ok for the ETL user to delete production data but not to select from dba views? :roll:

The work around is to talk to the DBAs behind the client's back. :wink:


Hi chulett,

Just to give you some background on this ,we are dealing with Oracle ERP and Siebel as our source systems. I'm not an expert on Sarbanes-Oxley,but the Sarbanes-Oxley act requires that companies monitor and secure financial and other systems, such as ERP, CRM, and SCM, which monitor corporate data.
Currently we require the select privileges on these Oracle ERP and Siebel databases as they are our sources. Since these databases are constantly audited for any unwarrented /undue privileges, the DBA has raised his concern.

So I think it is not completely out of context to mention about Sox compliance here.But the pertinent question is giving select privileges on certain set of sys tables is really a matter of concern.

Probably with Ray's words I can go back and try to convince the DBA that SELECT privileges would not do any damage :idea: .

Thanks
zzgani

Posted: Thu Mar 08, 2007 10:26 am
by ray.wurlod
Taking that argument to its logical conclusion, the system tables should be barred from everyone, including the DBA.

How about that for some words?!!

The DBAs can't do their job without access, neither can the Oracle Enterprise stage.

Re: Select Privileges & Sox compliance

Posted: Thu Mar 08, 2007 10:33 am
by DSguru2B
zzgani wrote:Since these databases are constantly audited for any unwarrented /undue privileges, the DBA has raised his concern.

I have been there. I was questioned DataStage's privilige to go directly to my source systems. Just a select to the tables that were to be transformed. They wanted DataStage to call a stored proc., get the data, transform it and call a stored proc. to load. Wierd huh !!!
Sometimes DBA's can be that pushy. But as you mentioned 'undue privilege' is concerning the DBA. Well this is not undue privilige. The stage needs access to these tables to function.

Posted: Thu Mar 08, 2007 5:31 pm
by kumar_s
Infact its responsible for the DBA to maintain all the previlages in an ERP system. Its obvious that ERP will be used my many other system than its own. And those system which deals with DML operation in the system will certainly require permission to certain level. Its impossible to get details of a partition table with out getting access to DBA_TAB_PARTITIONS or USER_TAB_PARTITIONS.

Posted: Thu Mar 08, 2007 6:31 pm
by ray.wurlod
Not when using the system tables is "hard-wired" into the stage! Presumably because this is the most reliable way.
In any case, it's documented as being required.

Posted: Thu Mar 08, 2007 7:48 pm
by vmcburney
It's odd because they are giving you access to the most sensitive tables - the customer and financial data tables - and are kicking up a stink about irrelevant system tables that have no private information in them. I think you could publish most system tables to the entire world without breaking SOX compliance.

Posted: Thu Mar 08, 2007 8:09 pm
by kumar_s
Its a valid point given by Vincent, with which you can speak to DBA. If access is given to core functional tables, there is no point in restricting the system tables. After all, those are for supporting the business.

Posted: Thu Mar 08, 2007 11:50 pm
by ray.wurlod
Do let us know how you get on.

And also, if they continue to refuse, how they suggest you work around the fact that the Oracle Enterprise stage can not be used.

Posted: Fri Mar 09, 2007 12:30 am
by zzgani
ray.wurlod wrote:Do let us know how you get on.

And also, if they continue to refuse, how they suggest you work around the fact that the Oracle Enterprise stage can not be used.



Hey, Thanks all for your feedback :D . I will keep you updated on this.

Thanks
zzgani