This content has been marked as final. Show 8 replies
Check the Oracle docs at http://tahiti.oracle.com and you will find many other statements that may, or may not, meet your criteria. These three are just the first three I wrote down.
SQL> audit grant any object privilege by access; SQL> audit grant any privilege by access; SQL> audit grant any role by access;
The following documents by Cameron Larner, may just be what you're looking for:
Auditing the DBA: What non-technical managers and auditors should know
http://www.absolute-tech.com/download/Auditing%20the%20DBA%20-%20Whitepaper.pdf and http://www.absolute-tech.com/download/Auditing%20the%20DBA%2015-JAN-07.pps
If this helps in any way, mark the thread as answered and closed.
But it not getting tracked,when DBA account grants DML privs to other account.
'grant insert,update on xxxxx to yyyyy'.
How to tracke these type of statements?
Just to add to the other replies ..
When you set audit_sys_operations = TRUE, anytime anyone logs into the database as SYSDBA/SYSOPER, all of the operations are audited by writing the SQL TEXT to the OS audit files.
In addition to the other audit commands, I may suggest the following:
audit system grant;
Thanks for your response.
Where these commands not tracking below statemands.
grant select on emp to james;
Can you give audit statements to tracke these type of statements.
as tbednar wrote 'audit system grant' will audit grant/revoke statement. Did you set AUDIT_TRAIL or AUDIT_SYS_OPERATIONS parameters in your database? Did you restart your database after setting them? (these parameters are static so you have to restart your database after setting them)
As a side note, if you did execute a statement by SYSDBA/SYSOPER and you have audit_sys_operations = true, you will need to look at the sql_text column to see exactly what the SYSDBA/SYSOPER did. In Oracle auditing, sysdba/sysoper connections are audited differently by always logging the sql text that was executed and the audit records are written into an OS text file that can be defined by the audit_file_dest parameter or usually it is in $OH/admin/sid/adump.
Can we restrict the audit to certain schemas rather than the entire database? We are in a shared data warehouse database with many other app schemas that we don't want to audit.