FINE GRAINED AUDITING

Shahul Ismail

FGA
Auditing is a mechanism for logging the activitiy of database users. The limitations on traditional auditing is extended in Fine grained auditing introduced in 9i, extends to capture both changing and querying data(by auditing what the user selected) Audit info is stored in FGA_LOG$(traditional method stores in AUD$) of Sys and the data dictionary view is DBA_FGA_AUDIT_TRAIL User does not require the Audit System or Audit Any system privileges. To use FGA, needs only the Execute privilege on DBMS_FGA privilege FGA can be temporarily disabled and enabled at will, but regular auditing cant be. To pause the regular auditing , we have to use NOAUDIT on the object. Regular auditing does not have a way to discriminate between granular actions, such as whether a particular column was accessed. With FGA, you can audit only particular, relevant columns. FGA can record Select accesses to a table or all types of DML access

Privileges Needed Execute on DBMS_FGA Select on dba_fga_audit_trail Why FGA Enhance Security

FGA

Is the primary purpose of FGA. The ability to record the users against the database is an important security characteristic. For example it stores the exact query used by the user which is not possible in traditional method

Analyze Sql execution

Seeing the actual statements issued by the users provides a great tool for DBAs to see different types of statements issued from the applications from specific users at certain times, which is useful for tuning

Emulate SELECT triggers

FGA can mimic a Select trigger, by executing a procedure when a user issues Select. You can further control execution by placing conditions(eg.,columns selected, value of columns referenced) upon its execution

FGA
A Simple example Begin DBMS_FGA.add_policy(object_schema=>DSSOTADM,object_name => emp_fgatest,policy_name=EMPFGA_SEL); End; If user dssotadm issues the below statement Select sal from emp_fgatest; It will be recorded in Sys.FGA_LOG$ Select db_user,sql_Text from dba_fga_audit_trail Where object_schema=DSSOTADM and object_name=EMP_FGATEST; DB_USER -------------DSSOTADM SQL_TEXT ---------------Select sal from emp_fgatest;

FGA
Specifying Audit columns Audit will be done only when the user selects specific columns Begin DBMS_FGA.add_policy(object_schema=DSSOTADM,object_name=>EMP_FGATEST, policy_name =>EMPFGA_SEL,audit_column =>SAL); END; We can further narrow down to audit only when the salary selected is more than 150000 Begin DBMS_FGA.add_policy(object_schema=DSSOTADM,object_name=>EMP_FGATEST, policy_name =>EMPFGA_SEL,audit_column =>SAL,audit_condition=>SAL >=150000); END; Auditing can be done for specific users like Begin DBMS_FGA.add_policy(object_schema=DSSOTADM,object_name=>EMP_FGATEST, policy_name =>EMPFGA_SEC,audit_column=>SAL,audit_condition =>USER=DMADM); END;

FGA
Specifying a proc to get executed We can also mention a stored procedure to be executed when the audit trail conditions met Begin DBMS_FGA.add_policy(object_schema=DSSOTADM,object_name=>EMP_FGATEST, policy_name =>EMPFGA_SEL,audit_column=>SAL,audit_condition =>SAL >=5000),handler_schema=DSSOTADM,handler_module=INSERT_EMPFGA); END; From this point on, everytime the audit conditions are met , the insert_empfga proc is executed along with a record to FGA_LOG$ table.The presence of a user defined handler does not stop the audit records from being written to the normal log We can query dba_audit_policies to see the FGA policies

FGA
FGA in 10g In Oracle9i FGA supports the auditing of Select stements only, the DML statements cant be audited.IN 10g DML can also be audited Begin DBMS_FGA.add_policy(object_schema=DSSOTADM,object_name=>EMP_FGATE ST,policy_name =>EMPFGA_DML,audit_column=>SAL,audit_condition =>SAL >=150000),statement_types =>SELECT,INSERT,UPDATE,DELETE); End; If statement_types is omitted while creating policy then Select only audited. The records are available in the same view DBA_FGA_AUDIT_TRAIL When we create the policy for DML, then the audit condition should be simple predicate(i.e with just one condition) In 9i, there was no way to specify a combination of columns as an audit condition. In Oracle10g this can be done through the audit_colum_opts parameter in Add_policy procedure

FGA
Begin DBMS_FGA.add_policy(object_schema=DSSOTADM,object_name=>EMP_FGATE ST, policy_name =>EMP_DML,audit_column=>SAL,DNAME,audit_condition =>SAL >=150000),statement_types =>SELECT,INSERT,UPDATE,DELETE, Audit_column_opts =>DBMS_FGA.all_columns); End; This policy will force to records the audit only when both Sal and Comm columns are referenced in the statements Important columns in DBMS_FGA_AUDIT_TRAIL view Sql_text Sql_bind - bind variable value Statement_type (Select , Insert, Update or Delete) Extended_Timestamp Instance_number Os_process Operating system process id Transactionid Client_id

FGA
One more important usage of audit trail, is the ability to track the client name/id of the statement .For example, upon login to the application, the CECID of the user can be set as below Begin DBMS_SESSION.set_identifier(cecid); End; Select db_user,sql_Text ,client_id from dba_fga_audit_trail Will return the cecid of the user who executed a particular report on a table .This is very useful to track the sensitive reports as all applications use the connection pool and just tracking the sessionid wont help to find out who executed a particular sql statement