RE: Suggestions for controlling SYSDBA / DBA privileges ?

        First things first, Where is that darned Soapbox!?

         Now, from what your telling me you have two problems. 1) Management that doesn't understand what it's managing and being audited for and 2) Auditor's that don't know what their auditing.

        Problem 1 is local, namely management has no idea what your doing and poor if any processes/controls thereon. Here we DBA's can modify data in the Finance database, but there is a strict set of rules on when we do so and who must sign off on it. The policy is strictly followed. No paperwork, no change period. There also needs to be a gatekeeper on that process. Someone who makes sure that all interested parties have signed off before the change is made. We have one & he is the absolute keeper of the keys, so to speak. If he approves the change we make it. If he doesn't then we refer those who want it to him. Simple policy, easy to understand and enforce. It is also auditable with ease through the use of before & after reports. Also the finance department has a set of reports that highlight anything that is odd. It's funny how often they catch themselves in a fat finger error.

        Problem 2 is the auditors. Ours were in a few months ago. A pile of young people who understood finance operations but as far as computers were concerned, all they knew was where the power switch was. Yes we ended up in a few arguments till they brought in a more senior person who clarified for us all exactly what they were suppose to audit. End of that problem.

        Bottom line, SARBOX does not preclude or prevent intentional falsification of data and reports. Nothing can really do that. What SARBOX demands is that you have procedures and policies to make that falsification as hard as possible and as documented as possible. What your auditors are suppose to be auditing is how well your company, and consequently you, follow those policies and procedures. And by the way a few blank, "deer in the headlights", responses to the auditors when they ask about how the finance system works go a long way to making them feel comfortable since the less you know of the mechanics the less likely you are to falsify data that is not detected. If they believe your clueless then their absolutely sure they can catch you. Course if they catch you you'll be wearing orange coveralls for a few years which in the end is the desired result.

-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Hemant K Chitale Sent: Wednesday, August 03, 2005 11:49 AM To: Oracle-L
Subject: Suggestions for controlling SYSDBA / DBA privileges ?

How do you respond to Managements that are "very concerned" after Auditors
(the SarbOx type)

tell them "the DBA has unrestricted privilege on all data in the database".

1. Can usage of SYSDBA (ie login to the DB Server as "oracle" and "CONNECT / AS SYSDBA") be Audited such that even the SYSDBA cannot remove the audit logs ? What actions can be audited
   (not just the fact that a connection was made but every command executed
   

thereafter) ?
2. How can you create Unix Server accounts for DBAs, allow them access to
Trace Files, alert .log, etc
without granting them SYSDBA (ie the Unix "dba" group) ? [Can this achieved
by seperate "oinstall" and "dba" groups or is "oinstall" intended only for
control of the inventory,
ergo the *installation* rather than the *administration* ? -- we have generally only 1 "oracle" install
per server , but there are some servers with multiple installs, all of them
administered by the same DBA]
3. How do you audit/not-audit CRON jobs {DB monitoring queries} setup to
connect as sysdba
{so that job scripts do not need to have a hard-coded username/password} ?
4. How do you respond to the assertion that the DBA can delete records from SYS.AUD$ ?
{and/or from $ORACLE_HOME/rdbms/audit for SYSDBA connections}

Hemant K Chitale
http://web.singnet.com.sg/~hkchital

--
http://www.freelists.org/webpage/oracle-l
--
http://www.freelists.org/webpage/oracle-l