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".
- 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) ?
- 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]
- 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} ?
- 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
Received on Wed Aug 03 2005 - 10:51:31 CDT
