Welcome Justin ( Account | Manage Subscriptions | Sign Out)

secure search

Technology Network FORUMS ARTICLES SAMPLE CODE

E-mail this page

PRODUCTS
Database Middleware Developer Tools Enterprise Management Applications Technology Products A-Z

GETTING STARTED

DOWNLOADS

DOCUMENTATION

TUTORIALS
Bookmark

Printer View

Security and Identity Management

Fine-Grained Auditing for Real-World Problems

By Arup Nanda Learn how to use the Oracle Database's fine-grained auditing feature to track read-only accesses to specific rows of tablesand much more Traditional Oracle Database auditing options let you track the actions users perform on objects at the macro levelfor example, if you audit for SELECT statements on a table, you can track who selected data from the table. However, you don't know what they selected. With data-manipulating statements such as INSERT, UPDATE, or DELETEyou can capture any changes by using triggers or by using the Oracle LogMiner utility to analyze the archived logs. Because simple SELECT statements are non-data-manipulating, they neither fire a trigger nor go into archived logs that you can mine later, so these two techniques fall short where SELECT statements are concerned. Oracle9i Database introduced a new feature called fine-grained auditing (FGA), which changed all that. This feature lets you audit individual SELECT statements along with exact statements issued by users. In addition to simply tracking statements, FGA provides a way to simulate a trigger for SELECT statements by executing a code whenever a user selects a particular set of data. In this three-part series of articles, I'll explain how you can use FGA for solving real-life problems. This first installment focuses on building a basic FGA system.

TECHNOLOGIES
BI & Data Warehousing Embedded Java Linux .NET PHP Security Technologies A-Z

ARCHITECTURE
Enterprise 2.0 Grid Service-Oriented Architecture Virtualization

COMMUNITY
Join OTN Oracle ACEs Oracle Mix Oracle Wiki Blogs Podcasts Events Newsletters Oracle Magazine Oracle Books Certification User Groups Partner White Papers

Example Setup
Our example is based on a banking system, where the audit trails of user accesses to specific data has been traditionally provided through application level auditing. However, the system falls short whenever the users access the data outside the application using tools such as SQL*Plus. In this article, I'll explain how you, the DBA, can accomplish the task of capturing users' SELECT access to specific rows using FGA regardless of the access tool or mechanism. In our example, the database has a table called ACCOUNTS, owned by the schema BANK, which has the following structure:

Name Null? Type ACCT_NO NOT NULL NUMBER CUST_ID NOT NULL NUMBER BALANCE NUMBER(15,2)
To construct a system that can audit anyone selecting from this table, you need to define an FGA policy on the table, as follows:

SELECT COUNTRY

begin dbms_fga.add_policy ( object_schema=>'BANK', object_name=>'ACCOUNTS', policy_name=>'ACCOUNTS_ACCESS' ); end;

This code has to be executed by a user who has execute privilege for the package dbms_fga. . However, for added security, it's advisable not to grant execute privilege to the user BANK, the owner of the table to be audited; rather, you should grant it to a secured user named, say, SECMAN, who should execute the procedure to add the policy. After you have defined the policy, when a user queries the table in the usual way, as follows:

select * from bank.accounts;

the audit trail records this action. You can see the trail by issuing:

select timestamp, db_user, os_user, object_schema, object_name, sql_text from dba_fga_audit_trail; TIMESTAMP DB_USER OS_USER OBJECT_ OBJECT_N SQL_TEXT - - - - 22-SEP-03 BANK ananda BANK ACCOUNTS select * from accounts
Note the new view named DBA_FGA_AUDIT_TRAIL, which records the fine-grained access information. Among other things, it shows the time stamp of the audited event, the database user ID of the person who made the query; the OS user ID; the name and owner of the table used in the query; and, finally, the exact query. This kind of information was impossible to get prior to Oracle9i

Database, but with the introduction of FGA, it became trivial. As of Oracle9i Database, FGA could capture only SELECT statements. With Oracle Database 10g, FGA can also handle DML statementsINSERT, UPDATEand DELETEmaking it a complete auditing feature. In Part 3 of this series, I'll explain these new functions in detail.

Audit Columns and Audit Conditions

Let's examine the previous example in more detail. We asked that any SELECT statement used on the table be audited. In real life, however, this is probably not necessary, and it may overwhelm the audit table that stores the trail. The bank may need to audit when a user selects a balance column, which contains sensitive information, but may not need to audit when a user selects the account number for a particular customer. The column BALANCE, whose selection triggers an audit, is known as the audit column, and in this case, the parameter to the dbms_fga.add_policy procedure specifies it as follows:

audit_column => 'BALANCE'

If audit trails are recorded each time a user selects from a table, the trails will grow in size, causing space and administration problems, so you may want to conduct an audit only if certain conditions are met, not every time. Perhaps the bank needs an audit only if users access the accounts of extremely wealthy account holdersfor instance, only if a user selects an account with a balance of $11,000 or more. This type of condition is known as an audit condition and is passed as a parameter to the dbms_fga.add_policy procedure as follows:

audit_condition => 'BALANCE >= 11000'

Let's see how these two parameters work. The policy definition now looks like this:

begin dbms_fga.add_policy ( object_schema=>'BANK', object_name=>'ACCOUNTS', policy_name=>'ACCOUNTS_ACCESS', audit_column => 'BALANCE', audit_condition => 'BALANCE >= 11000' ); end;
In this case, only if the user selects the column BALANCE and if the rows retrieved contain a balance more than or equal to $11,000 is the action audited. If either of these conditions is not true, the action is not written to the audit trail. The examples in Table 1 illustrate various scenarios for when an action will be audited and when not.

Optimizer Mode
FGA requires cost-based optimization (CBO) in order to work correctly. Under rule-based optimization, audit trails are always generated whenever a user selects from a table, regardless of whether the relevant columns are selected or not, increasing the chance of false-positive entries. For FGA to work properly, in addition to CBO being enabled at the instance level, there should be no RULE hint in the SQL statements and all the tables in the query must be analyzed at least with the estimate option.

Managing FGA Policies

Earlier you saw how to add an FGA policy. To drop a policy, you can use the following:

begin dbms_fga.drop_policy ( object_schema => 'BANK', object_name => 'ACCOUNTS', policy_name => 'ACCOUNTS_ACCESS' ); end;
There is no out-of-the-box solution for changing a policy. To change any parameters of the policy, you must drop the policy and add it again with the changed parameters. Sometimes you may need to disable audit collections temporarilyfor example, if you want to move the trail table to a different tablespace or want to delete it. You can disable an FGA policy as follows:

begin dbms_fga.enable_policy ( object_schema => 'BANK', object_name => 'ACCOUNTS', policy_name => 'ACCOUNTS_ACCESS', enable => FALSE ); end;
To re-enable it, use the same function but with the parameter enable set to TRUE.

The Handler Module

The power of FGA doesn't stop at merely recording events in audit trails; FGA can also optionally execute procedures. A procedure could perform an action such as sending an e-mail alert to an auditor when a user selects a certain row from a table, or it could write to a different audit trail. This stored code segment, which could be a stand-alone procedure or a procedure within a package, is known as

the handler module for a policy. It does not have to be in the same schema as the base table itself; in fact, for security reasons, you may want to deliberately place it in a separate schema. Because the procedure executes whenever a SELECT occurs, much like a trigger firing on a DML statement, you can also think of it as a SELECT statement trigger. The following parameters specify a handler module is specified for the policy:

handler_schema The schema that owns the data procedure handler_module The procedure name
The handler module can also take a package name instead of a procedure name. In that case, the parameter handler_module is specified in package.procedure format.

FGA Data-Dictionary Views

The definition of an FGA policy resides in the data-dictionary view DBA_AUDIT_POLICIES. Table 2 includes a brief description of some of the important columns of this view. The audit trails are collected in the SYS-owned table FGA_LOG$. As with any SYS-owned raw table, some views on this table present the information in a user-friendly manner. DBA_FGA_AUDIT_TRAIL is a view on the table. Table 3 contains a brief description of the important columns of this view. One important column is SQL_BIND, which specifies the values of the bind variables used in a queryknowledge that greatly enhances the tool's power. Another important column is SCN, which records the System Change Number when a particular query occurs. This information is useful for identifying what a user saw at a specific time, not what the value is now, using Flashback Queries which can show the data at a specified SCN value. I'll explain this powerful feature in detail in Part 2 of this series.

Views and FGA

So far I've discussed applying FGA on tables; now let's see how you can use FGA on views. Assume a view VW_ACCOUNTS is defined on the ACCOUNTS table as follows:

create view vw_accounts as select * from accounts;

Now, if a user selects from the view instead of from the table:

select * from vw_accounts;

you'll see the following audit trail:

select object_name, sql_text from dba_fga_audit_trail; OBJECT_NAME SQL_TEXT - ACCOUNTS select * from vw_accounts
Note that the name of the base table, not the view, appears in the OBJECT_NAME column, because the selection from the view selects from the base table. However, the SQL_TEXT column records the actual statement the user issued, and that is exactly what you want to know. If you want to audit queries only on views, not on tables, you can set the policy up on a view itself. You do this by passing the name of the view instead of that of the table to the parameter object_name in the packaged procedure dbms_fga.add_policy. The OBJECT_NAME column in DBA_FGA_AUDIT_TRAIL will then display the name of the view, and there will be no additional record for a table access.

Next Steps
Read more about the DBMS_FGA package Visit the Oracle Database home page Visit the Oracle Platform Security home page

Other Uses
In addition to recording the select access to tables, FGA is useful for some other situations:

You can use FGA on a data warehouse to capture all the statements occurring on a particular table, view, or materialized view, which is helpful for planning indexes. You don't need to go to the V$SQL view to get this information. Even if a SQL statement has have been aged out of V$SQL, it will always be available in an FGA audit trail. Because FGA captures bind variables, it can help you understand the pattern of bind-variable values, which is helpful for designing histogram collections and so on. As mentioned earlier, the handler module can send out alerts to auditors or DBAs, which is helpful for tracking rogue applications. Because FGA can act as a trigger for SELECT statements, you can use it whenever you require such functionality.

Conclusion
FGA lets you support privacy and accountability policies in an Oracle database. Because auditing occurs inside the database, not in an application, actions are audited regardless of the access methods employed by users (through tools such as SQL*Plus or applications), allowing foolproof setup.

Part 2 of this series explains advanced FGA techniques such as application user models and the reconstruction of data viewed by the user. In Part 3, I'll cover new features in Oracle Database 10g that make FGA extremely powerful, and suitable for all types of auditing situations. Arup Nanda (arup@proligence.com) is the chief database architect at IntelliClaim, a corporation based in Norwalk, Connecticut, that provides highly secure rule-based optimization of health-care insurance claims management. He is the recipient of Oracle's DBA of the Year award for 2003 and the co-author of the forthcoming Oracle Privacy Security Auditing (Rampant TechPress, 2003). Table 1: Various scenarios that illustrate when an action is audited and when not SQL Statement Audit State Audited. The user selects the audit column BALANCE, specified when the policy was added. Audited. Even though the user does not specify the column BALANCE explicitly, the * implicitly selects it. Audited. Even though the user does not specify the column BALANCE explicitly, the where clause implicitly selects it. Not audited. The user does not select the column BALANCE. Not audited. The user does not explicitly or implicitly select column BALANCE.

select balance from accounts; select * from accounts; select cust_id from accounts where balance < 10000; select cust_id from accounts; select count(*) from accounts;

Table 2: Important columns in the data-dictionary view DBA_AUDIT_POLICIES OBJECT_SCHEMA OBJECT_NAME POLICY_NAME POLICY_TEXT POLICY_COLUMN ENABLED PF_SCHEMA PF_PACKAGE PF_FUNCTION The owner of the table or view on which the FGA policy is defined Name of the table or view Name of the policy-for example, ACCOUNTS_ACCESS The audit condition specified while adding the policy-for example, BALANCE >= 11000 The audit column-for example, BALANCE YES if enabled; NO otherwise The schema that owns the policy's handler module, if one exists The package name of the handler module, if one exists The procedure name of the handler module, if one exists

Table 3: Important columns in the DBA_FGA_AUDIT_TRAIL view SESSION_ID TIMESTAMP DB_USER OS_USER USERHOST CLIENT_ID EXT_NAME OBJECT_SCHEMA OBJECT_NAME POLICY_NAME SCN SQL_TEXT SQL_BIND The Audit Session Identifier; not the same as the Session Identifier in the V$SESSION view The time stamp for when the audit record was generated The database user who issued the query The operating system user The host name of the machine from which the user connected The client identifier, if set by a call to the packaged procedure dbms_session.set_identier The name of an externally authenticated client, such as an LDAP user The owner of the table on which access triggered the audit The name of the table on which a SELECT operation triggered the audit The name of the policy that triggered the audit (If a table has multiple policies defined on it, each one will insert a record. In that case, this column shows which rows were inserted by which policy.) The Oracle System Change Number at which the audit was recorded The SQL statement issued by the user Bind variables used by the SQL statement, if any
E-mail this page Printer View

About Oracle |

| Careers | Contact Us | Site Maps | Legal Notices | Terms of Use | Privacy