|
||
Title: Performance Impact of Auditing Post by Pete Finnigan on Mar 8th, 2006, 9:11pm Background: Due to SOX and regulatory compliance, the database operations group will be asked to enable auditing of certain events. Here are the things that the auditor will be recommending: Authentication Success/Failure Authorization Failure (object access) Grant/Revoke roles, privileges Grant/Revoke object access Use of admin privileges (start/stop database, changing global params, etc.) The db ops group has been asked to implement a subset of these auditing items before, but have claimed that there is too much of an impact on performance. My experience has shown me differently, but I would like an objective 3rd party to point at. Can anyone point me in the direction of articles that discuss the performance impact of enabling auditing features in Oracle 8/9/10, SQL Server 7/2k/2k5 and Sybase 12.x? Please remember that this will not involve auditing DML. Thanks. |
||
Title: Re: Performance Impact of Auditing Post by Pete Finnigan on Mar 9th, 2006, 1:56pm Hi, I don't know of any documents that discuss the performance impact of enabling audit on Oracle, SQL and Sybase. I have seen discussions about performance of enabling audit before but cannot immediately find any links. I know from personal experience that as long as you dont audit actions that occur frequently the performance impact is negligable. For instance auditing connections should occur once per session and the additional time is not noticable. For the use of system privileges, applications should not be using system privileges at any rate that should cause a performance issue. The same should be true for failure to access an object - i.e. the user does not have permissions. This should not happen often if the application is configured correctly. The same is true of granting, revoking and use of admin privileges. The audit you mention, i always advocate and from experience auditing these things does not incur performance penalities. If you audit DML then there can be issues but this depends on what you are auditing and is very specific to each site/application hth cheers Pete |
||
Title: Re: Performance Impact of Auditing Post by Pete Finnigan on Mar 13th, 2006, 3:05pm Hi My experience matches yours and Pete's. If you are auditing functions that by definition do not occur often then the performance hit is low. Given the range of database's you are talking about I should point out that there is a different issue with each of them. With Oracle, you need to be sure you are writting the audit trail to a secure location. SOX requires an audit trail that DBA's can not modify. Oracle can either audit to a DB table, not recommended for performance, or to an external file, you need to be sure of access controls to the OS based file. On SQL, there is more of a performance degredation than on any of the others for these functions, and you need to be sure where the authentication is happening for the auditors to believe the audit trail, i.e. is it Windows/SQL or mixed mode authentication. On Sybase, auditing is done to a seperate db, but make sure you know who the owner is, otherwise DBA's can turn it off very easily. Hope this helps. Kevin NoFools |
||
Title: Re: Performance Impact of Auditing Post by Pete Finnigan on Mar 15th, 2006, 12:34am "or to an external file, you need to be sure of access controls to the OS based file. " Presumably if the oracle process is writing the audit records, the file must be enabled for read/write for that oracle process. In that case, doesn't it follow that, using CREATE DIRECTORY and UTL_FILE, the audit file is accessible and amendable through the database ? I guess you can set up an OS process that copies the audit file such that the copy is not writable by oracle. |
||
Title: Re: Performance Impact of Auditing Post by Pete Finnigan on Mar 17th, 2006, 11:09am This is the age old problem of how do you protect an audit trail to prevent the people you are trying to audit from modifying it....... It's why I am now tending to use network appliance based tools on the solutions I am designing. These have two advantages. 1/ No performance hit on the DB. 2/ Easy segregation of duties, allowing audit to get to the trail, while still protecting it from modification. The problem is that there are not many auditors that understand SQL yet, and the in built knowledge on these appliances varies greatly. Regards Kevin. |
||
Powered by YaBB 1 Gold - SP 1.4! Forum software copyright © 2000-2004 Yet another Bulletin Board |