RE: Suggestions for controlling SYSDBA / DBA privileges ?
- From: "Powell, Mark D" <mark.powell@xxxxxxx>
- To: "Oracle-L" <oracle-l@xxxxxxxxxxxxx>
- Date: Wed, 3 Aug 2005 12:22:57 -0400
It is the purpose of the DBA to have access to the database so that the
DBA can manage and protect the database data. With any advanced IT
system such as the operating system, a database manager, and many
advanced complex applications that require an application administrator
there is always a person entrusted with near blanket access. There is
virtually no practical way to design workable systems where this is not
true. Therefore it is the responsibility of management to hire
competent, trustable people to hold System Administrator and DBA's
positions and to monitor their work activities after they are hired.
If you do not trust the people in System Administrator or DBA positions
they should be immediately replaced.
HTH -- Mark D Powell --
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] 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
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
