RE: Pre-Approved database changes
- From: jo_holvoet@xxxxxxxx
- To: oracle-l@xxxxxxxxxxxxx
- Date: Fri, 18 Jun 2004 09:22:42 +0200
Been following this thread with interest (we are also dealing with
Sarbanes-Oxley) and Fuad raises an interesting point. My first thought
upon reading Jared's email was that surely user administration tasks
should be pre-approved changes. However, what if you create a login for a
developer on a production machine with fairly extensive privileges ? This
then goes against S.A. 's "segregation of duties" principles. So there are
usually arguments possible both ways.
What we usually end up doing when drawing up such lists is to get them
approved by our external S.A. auditors (assuming they have a clue about
what a DBA does all day and that they are willing to use some common
sense).
mvg/regards
Jo
Fuad Arshad <fuadar@xxxxxxxxx>
Sent by: oracle-l-bounce@xxxxxxxxxxxxx
06/18/2004 04:00
Please respond to oracle-l
To: oracle-l@xxxxxxxxxxxxx
cc:
Subject: RE: Pre-Approved database changes
Sarbaines-oxley is a law which pretty much every unit in an organization
has to deal with .
This includes dba's as this law makes it tough for every company without
a proper change control can be audited and fined. Most of US companies are
dealing with this.
Jared my addition would be
Jared My Addition would b
Database Upgeades/Critical Patch fixes
Development and qa data migrations
Creation of extra/new indexes.
And the biggest of all
Developer access to production Servers.
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Michael Thomas
Sent: Thursday, June 17, 2004 8:33 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: Re: Pre-Approved database changes
Hi,
I'm confused (..as usual..I heard that..) because I have a basic problem
with the subject. How does Sarbanes-Oakly (SO) define database changes
that
a DBA needs to document (general rule is sufficent)?
Why would many of the tasks of a DBA administrator, w.r.t. CCG (change
control group), be restricted to 'pre-approved database changes'?
The business owns the data, the users change the data, and the DBA
administers the data repository. Does the CCG pre-approve every user
change
to data through an application? Depends on the data, and there may be
strange examples where the answer is yes. An DBA administrator is
similarly
operating an Oracle database application.
Two exceptions, however.
1) Developers. If the application developers, or database developers wish
to
change/convert/transform/ translate data (application development changes
involving data content type changes) then those tasks might require
'pre-approved database changes'. Depends on the data, really, just like
data
changes by the application users.
Keep in mind its worthless to have a data controlled by a certified
application with ID 10 T users (that's an acronym for idiot users). Every
user of such application requires a system specific training or
proof-of-competence certificate. This is the process to avoid pre-approval
of every user data change via the application.
2) *Code* and *Data* changes. Tuning SQL that changes application *code*
might or might not require CCG controls. If required, these could be
pre-approved on a per-project basis with a pre-defined, pre-documented
process, testing of results with data, and might include a document
describing the implemented *code* changes (user *data* may not change).
The
'might not'
test for documenting a *code* change can apply if the original application
code is not similarly documented, given valid reasons the original code is
not documented.
There should be little need to pre-approve any DBA 'discretion' for
administration, unless you have ID 10 T DBAs. The same system specific
training or proof-of-competence certificate applies to DBAs that applies
to
other application users.
If the 'pre-approved' CCG process fails, no problem.
Simply repeat if the the process fails. I say give'em pagers, too. ;-)
This
helps explain why 'database administration' is not in the 'task specific'
CCG scope while some *data* and *code* changes would be.
As an aside, just for fun:
Say vendor XXXXXX's off-the-shelf Sarbanes-Oakly certfied product fails
because of a RI constraint or uniqueness. Why would the DBA be required to
fix the data? Doesn't vendor XXXXXX guarantee RI and uniqeness with SO
certification? The rebellious DBA in me would not worry about documenting
these type changes, either.
Sorry if I'm Sarbanes-Oakly ignorant and I've just made it apparent. HTH.
Regards,
Mike Thomas
--- Jared.Still@xxxxxxxxxxx wrote:
> oracle-l-bounce@xxxxxxxxxxxxx wrote on 06/17/2004
> 04:05:18 PM:
>
> >
....
>
> True, but I have no desire to try and document when it should and
> shouldn't be done. This is one if the areas that will still require
> some DBA discretion.
>
> I don't want to go to CC to get approval to generate stats for a
> single table that has had a lot of DML activity and now gets a useless
> plan. Not too often but it does happen occasionally.
>
> Thanks,
>
> Jared
>
__________________________________
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.
http://promotions.yahoo.com/new_mail
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put
'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
