Re: OT - SarBox paranoia prevention ?
- From: Jared Still <jkstill@xxxxxxxxx>
- To: chip.briggs@xxxxxxxxx
- Date: Mon, 21 Feb 2005 10:07:52 -0800
Hi Chip,
Share the pain. Point out to the auditors that system administrators
can easily have the same access by including themselves in the
DBA group on the server. They can then login as SYSDBA, the mother
of all DBA accounts.
You need to educate the managers, and the managers need to 'educate'
the auditors. We've had similar issues here. The auditors are not entirely
happy with this, but we are getting signatures on our accredation letter.
There is a point at which further security measures are too costly and
time consuming and inhibit the flow of business. Managers will be more
willing to negotiate this with auditors when they fully realize the
consequences.
Jared
On Sat, 19 Feb 2005 13:21:03 -0700, Chip Briggs <chip.briggs@xxxxxxxxx> wrote:
> Earlier this week, SarBox auditors wanted proof that DBA's
> could not change database stored procedures (which would
> prevent DBA's from applying vendor patches for vendor
> supplied stored procedures). Also presents a problem since
> DBA's managed stored procedure configuration. SarBox
> auditors do not like DBA privileged access to application data.
> Looks like these auditors do not trust anyone and want duties
> segregated so no single person has the ability to cook any
> books (complete prevention for Enron repeat).
>
> Any ideas how to prevent execution of non-production code
> against production data, whether the data resides in a
> database or operating system files (unix and windows) ?
>
> Have Fun :)
> --
> //www.freelists.org/webpage/oracle-l
>
--
Jared Still
Certifiable Oracle DBA and Part Time Perl Evangelist
--
//www.freelists.org/webpage/oracle-l
Other related posts:
