Fine Grained Auditing In Oracle 10G Authored by: Meenakshi Srivastava (meenaxi.srivastava@gmail.com) 2
Abstract The purpose of this document is to develop an understanding of Fine Grained Auditing(FGA) feature of Oracle. The document mainly focuses on salient features of FGA, its application in real scenario and, merits over other auditing techniques of Oracle. 3
CONTENTS INTRODUCTION... 5 TYPES OF AUDITING... 6 FINE GRAINED AUDITING (FGA)... 7 CONCLUSION... 12 REFERENCES... 13 4
Introduction Auditing has always been the most talked about topic amongst users of Oracle database. It is a method to safeguard the database systems against fraudulent or unauthorized usage. One way is to restrict user privileges,but Auditing implements strong system security by maintaining records of system activities and holding users accountable for their action. Auditing may find its application in investigating suspicious activities or monitoring of database activities to identify peak usage, frequent database activities and unusual behavior of database objects like packages/procedures. Let s say you want to monitor users who frequently log into the database or you want to monitor and control the DML, DDL activities done on any or all schema tables, then you are actually in need of an audit trail on specific users or objects. Consider the example of an OLTP system, where few customers are getting huge invoice generated against their monthly mobile usage. And you find that someone is tampering with the values in Acc_Bill_details table that records customer billing information. In this case, audit can be placed on all the DML (Insert, Update, Delete, and Select) activities done on table Acc_Bill_details. 5
Types of Auditing The Oracle9i Database provides several configurable audit options. Administrators can configure systems to audit any object, privilege, or type of statement. Infact the database can audit individual SQL statements. Audit records show details like the username, session and terminal id, timestamp, the object accessed, and system privileges used. Oracle9i auditing is efficient because audit records are parsed once for both audit and execution, and the database engine itself does the job, not an extraneous add-on server. Auditing types can be divided into following categories: Statement Auditing: Auditing on selective SQL statements irrespective of the schema object on which it is fired is Statement auditing. For example, auditing on the DDL statement fired by a user. Privilege Auditing: Privilege auditing is nothing but the auditing on usage of selective privileges like usage of Create table privilege by a user. Privilege auditing can be done on any user or all the users. Schema Object Auditing Auditing on specific schema object is met by schema object auditing. All the DML activities, Grant and Revoke performed on a specific table or all the schema tables can be captured. Fine Grained Auditing Fine grained auditing provides auditing on data access based on content. 6
Fine Grained Auditing (FGA) FGA provides better control and is a more granular method of auditing. This method creates audit records based on the exact query, condition, and data retrieved or manipulated by the statement. It provides a facility to audit only those statements (including actual values of possible bind-variables) that reference a particular column. The FGA method was introduced in Oracle9i.But Oracle Database 10g enhances the FGA capability by extending SQL Support to support the granular auditing of queries, as well as UPDATE, INSERT, and DELETE operations. Let s say, you want to capture any select, update, delete activity performed only on column invoice_amt of table Acc_Bill_details then it is achievable only using FGA. Or you want that access to SSN number of an account holder should be restricted, then that is also doable using FGA. Introduced in Oracle 9i, fine-grained auditing (FGA) performs auditing capabilities through a new package named DBMS_FGA. This package allows implementing auditing at an extremely low level of granularity against any table in the database through a special database object called an FGA policy. There are various sub programs of DBMS_FGA package. Package DBMS_FGA let s you set audit conditions and specify the audit column to designate which column within a table or view requires monitoring. When the condition is met on the particular column, fine-grained auditing writes an audit record that shows the SQL text of the query. The subprograms are explained in table below: ADD_POLICY Procedure DISABLE_POLICY Procedure DROP_POLICY Procedure ENABLE_POLICY Procedure Creates an audit policy using the supplied predicate as the audit condition Disables an audit policy Drops an audit policy Enables an audit policy The standard auditing records details like owner, timestamp, type of statement etc., but it does not give information about the change that happened in data. This information can be very useful for the DBA or user who wants to analyze the activities happening on the table. This is the reason why developer takes help of trigger and captures the table values before and after in user-defined tables. But triggers can only be written on DML statements Insert, Update and Delete and not on Select. So if you want to capture even the Select statements fired on a table or specific columns of a table, FGA comes to your rescue. 7
Till Oracle 9i, FGA only supported Select, but in Oracle 10g FGA supports all DML statements. So, all the inserts, update, delete and select statements can be captured using only FGA and can be viewed through the data dictionary DBA_FGA_AUDIT_TRAIL. Description of DBMS_FGA.ADD_POLICY Attributes: Parameter object_schema Description The schema of the object to be audited. Default value: NULL. (If NULL, the current effective user schema is assumed.) object_name policy_name audit_condition The name of the object to be audited. The unique name of the policy. A condition in a row that indicates a monitoring condition. NULL is allowed and acts as TRUE. Default value: NULL audit_column handler_schema The columns to be checked for access. These can include hidden columns. The default, NULL, causes audit if any column is accessed or affected. Default value: NULL The schema that contains the event handler. The default, NULL, causes the current schema to be used. Default value: NULL handler_module The function name of the event handler; includes the package name if necessary. This function is invoked only after the first row that matches the audit condition is processed in the query. If the procedure fails with exception, the user SQL statement will fail as well. Default value: NULL Enable Enables the policy if TRUE, which is the default. Default value: TRUE statement_types The SQL statement types to which this policy is applicable: insert, update, delete, or select only. Default value: SELECT audit_trail Whether to populate LSQLTEXT and LSQLBIND in fga_log$. Default value: DB_EXTENDED 8
Syntax: DBMS_FGA.ADD_POLICY ( object_schema VARCHAR2, object_name VARCHAR2, policy_name VARCHAR2, audit_condition VARCHAR2, audit_column VARCHAR2, handler_schema VARCHAR2, handler_module VARCHAR2, enable BOOLEAN, statement_types VARCHAR2, audit_trail BINARY_INTEGER IN DEFAULT, audit_column_opts BINARY_INTEGER IN DEFAULT ); Usage: Let s put an audit on invoice_amt column Acc_bill_details table, such that if a user tries to query account information of a customer having invoice_amt more than 11000, user details would get captured in view DBA_FGA_AUDIT_TRAIL. begin dbms_fga.add_policy ( object_schema => 'TEST', object_name => 'ACC_BILL_DETAILS, policy_name => 'INVOICE_ACCESS', audit_column => 'INVOICE_AMT', audit_condition => 'INVOICE_AMT > 11000' ); end; Now what if the DBA wants to get notified whenever such users are logged in? Not just that, he also wants to make call to a stored procedure ACC_BILL_AUDIT, that would send email to all concerned users and perform some specific activities in database. But the limitation of FGA is that already existing policy INVOICE_ACCESS can not be modified. So, the DBA drops the policy using procedure DROP_POLICY. This is how he could do it: 9
Begin Dbms_fga.drop_policy ( object_schema => 'TEST', object_name => 'ACC_BILL_DETAILS, policy_name => 'INVOICE_ACCESS' ); END; Now the DBA created an audit table named ACC_BILL_AUDIT in Test schema. Then, created INVOICE_ACCESS policy with added functionality. This is how the policy is defined: BEGIN DBMS_FGA.add_policy ( object_schema => 'TEST', object_name => 'ACC_BILL_DETAILS', policy_name => INVOICE_ACCESS', handler_schema => 'TEST', handler_module => 'TEST.ACC_BILL_AUDIT', audit_column => 'INVOICE_AMT', audit_condition => 'INVOICE_AMT > 11000' statement_types => 'INSERT, UPDATE,DELETE, SELECT', audit_trail => DBMS_FGA.DB+DBMS_FGA.EXTENDED ); END; But after analyzing the system for a week or so, the DBA decides to disable the Invoice_access policy; Begin Dbms_fga.disable_policy ( object_schema => 'TEST', object_name => 'ACC_BILL_DETAILS, policy_name => 'INVOICE_ACCESS' ); END; Also, if the auditing is done on a large table and records are stored in a user defined audit table like ACC_BILL_AUD$, then overall performance can be hit big time as soon as the audit table size increases. Make sure you device a method to counter such situation. Probably you can implement a schedule job to purge audit records after regular interval or device conditional auditing to avoid storing each and every activity on table. 10
Salient Features: The salient features of FGA can be segregated as following: Column Referencing: We can define policy such that audit is triggered only if the specified columns are referenced in query statement. Conditional auditing: As explained in previous example also, auditing can be condition driven using FGA. For example, DBA wants to know the users who query on account holders having invoice_amt greater than 11000 against them. Combined audit trailing in DBA_Common_audit_trail for standard and FGA auditing. Event Handling can also be achieved using FGA add_policy subprogram. FGA is triggered on statement level, and not on row level unlike triggers: Let s say a user fires query; Update Acc_bill_details set invoice_amt = 5000 where invoice_amt>11000; In this case trigger would be fired for each row where invoice_amt>11000 and insert details in user-defined table. This can degrade performance and table size would also increase rapidly. But if we use FGA, only one audit statement will be stored. Possible Limitation of FGA: FGA records show both operations that were performed and attempted whether those were successful or not. This can be an overhead for the administrator. Probably your DBA does not want to audit DML (Insert, update, delete) statements that have been Rollback by user. In such scenarios, trigger can be a viable option. 11
Conclusion Fine grained auditing provides a flexible, yet controlled approach to audit the database activities. The salient features like event handling, conditional auditing, and column referencing gives the FGA an edge over other auditing techniques of Oracle. On top of all, FGA is easy to manage and does not add as an overhead to the database administrator. 12
References [1] http://www.databasejournal.com/features/oracle/ [2] http://www.oracle.com/technology/ 13