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
-- //www.freelists.org/webpage/oracle-l
