Chapter 10. Developing an Audit Plan Database auditing is the monitoring and recording of activities occurring within a database. You typically audit to ensure that no unauthorized users are removing data from the data dictionary or accessing tables they should not have the privileges to see. You might also want to audit specific tables that help you determine the volume of accesses occurring at peak times. This type of auditing is helpful in analyzing trends and evaluating system performance. The Oracle RDBMS provides functions that let you audit most actions that can be taken within and against the database. These actions can include (but are not limited to) the following: -
Viewing, modifying, or removing information from tables -
Creating or removing objects like tables, indexes, views, procedures, triggers, etc. -
Executing programs This standard Oracle functionality does not support auditing at the row level. In other words, through standard auditing, you can audit actions that have been performed against a table, but not what has changed in a specific row of that table. To gain the ability to monitor who has changed a specific row of a table or exactly what action was taken against a row of a table, custom code is required; we'll show you an example of such code in Chapter 11.  | This chapter mainly discusses the standard auditing functionality of Oracle. Where appropriate, we'll mention custom approaches that you might want to take to extend this capability. | | There are many schools of thought about enabling auditing on a database. If your company has implemented firewalls or other isolating security measures, you might believe that your system is secure. You might feel there is no need to enable auditing. Often, the issue of whether to perform any kind of auditing is overlooked when a security plan is being written. If auditing has not been discussed by the people creating the security policy and plan, an auditing policy and auditing plan may not be created. There are some companies that have never seen a need to implement auditing within their database and have never had a problem that they are aware of. Many sites don't initially activate the auditing of a database. In fact, auditing might not be activated unless or until there has been a security breach either by an outside intruder or by an employee who has overstepped his or her bounds. Either you observe some suspicious activity, or you spot resource usage that seems inconsistent with the normal pattern of operation. You might then enable auditing to confirm that something is wrong. We don't recommend this after-the-fact approach. It's like closing the barn door after the horse has escaped. You stand the chance of a hacker breaking in and either damaging the data in your database or obtaining information that might compromise your company's competitive edge. Other sites choose to audit and audit heavily. But this approach isn't always the right one either. Since each object you audit carries with it a potential cost in performance and resource use, you need to carefully evaluate and choose the forms of auditing that make the most sense for your own company's environment.  |
