13 Configuring and Managing Auditing

13.2.1 Create the Audit Schema using RCU

To switch to a database as the permanent store for your audit records, you first use the Repository Creation Utility (RCU) to create a database store for audit data.

This section explains how to create the audit schema. Once the database schema is created, you can:

• create a datasource to point to this schema

• update the domain configuration to switch the audit data store for audit records (see Section 13.2.3.2, "Configure the Audit Data Store and Bus-Stop Storage").

Before You Begin

Before you begin, make sure to collect the details on which database to use, along with the DBA credentials to use.

Configuring the Database Schema

The procedure shown here configures a schema for the audit data store.

The steps are as follows:

1. Go to $RCU_HOME/bin and execute the RCU utility.

2. Choose Create at the starting screen. Click Next.

3. The Database Connection Details page appears. Enter your database details:

   
   

   Click Next.

4. The Select Components page appears. Choose the option to create a new prefix, for example IDM. The prefix is applied to schema owner and tablespace names. Three schema users are created using this prefix; in the example, they are IDM_IAU, IDM_IAU_APPEND, and IDM_IAU_VIEWER.

   Also, select 'Audit Services' from the list of schemas.

   
   

   Click Next.

5. The Schema Passwords page appears.

   
   

   Enter the password and click Next.

6. The Map Tablespaces page appears. Click Next and accept the tablespace creation.

   
   

7. The Summary page appears.

   
   

   Check the details and click Create.

8. Check for any errors while the schemas are being created. Verify that the job is successful on the Completion Summary page:

   
   

This process will take several minutes to complete.

13.2.2 Set Up Audit Data Sources

As explained in Section 13.2.1, "Create the Audit Schema using RCU", after you create a database schema to store audit records in a database, you must set up an Oracle WebLogic Server audit data source that points to that schema.

Take these steps to set up an audit data source:

1. Connect to the Oracle WebLogic Server administration console:

   http://host:7001/console
   

2. Under JDBC, click the Data Sources link.

3. The Data Sources page appears. Click New to create a new data source.

4. Enter the following details for the new data source:

   • Name: Enter a name such as Audit_Data_Source-0.

   • JNDI Name: jdbc/AuditDB

   • Database Type: Oracle

   • Database Driver: Oracle's Driver (Thin XA) Versions: 9.0.1, 9.0.2, 10, 11

   If deploying to a managed cluster server, also check AdminServer; this ensures that the data source is listed in the audit data store when switching from file to database store.

   Click Next.

5. The Transaction Options page appears. Click Next.

6. The Connection Properties page appears. Enter the following information:

   • Database Name: Enter the name of the database to which you will connect. This usually maps to the SID.

   • Host Name: Enter the hostname of the database.

   • Port: Enter the database port.

   • Database User Name: This is the name of the audit schema that you created in RCU. The following conventions apply to this entry:

     • Use all upper-case letters.

     • Prepend the schema prefix used when creating the audit schema in the database.

     • Append the schema name. For this data source, the schema name is IAU_APPEND.

     For example, if you used "ENG" as your schema prefix, the value you enter here must be "ENG_IAU_APPEND".

   • Password: This is the password for the audit schema that you created in RCU.

   Click Next.

7. The next page lists the JDBC driver class and database details. Accept the defaults, and click Test Configuration to test the connection. If you see the message "Connection established Successfully", click Next. If it displays any error, go back and check the connection details.

8. In the Select Targets page, select the servers where this data source needs to be configured, and click Finish.

13.2.3 Configure a Database Audit Data Store for Java Components

After the schema is created, configuring a database-based audit data store involves:

• creating a data source that points to the audit schema you created, and

• configuring the audit data store to point to the data source

This section describes the following tasks related to audit data store configuration:

• View Audit Data Store Configuration

• Configure the Audit Data Store and Bus-Stop Storage

13.2.3.1 View Audit Data Store Configuration

Note:

This task is performed with Oracle Enterprise Manager Fusion Middleware Control.

To view the current audit data store configuration:

1. Navigate to Domain, then Security Provider Configuration.

2. Under the Audit Service section, click Configure.

This page shows:

• Datasource JNDI Name - If a database store is configured for audit records, this field shows the JNDI name of the datasource. The field is empty when the audit data store is not configured. By default a database is not configured, and audit records are stored in bus-stop files.

• Audit Loader Frequency - This field shows the frequency, in seconds, at which data is moved from bus-stop files to the audit data store.

See Section 13.2.2, "Set Up Audit Data Sources" for datasource examples.

13.2.4 Configure a Database Audit Data Store for System Components

Oracle Process Manager and Notification Server (OPMN) manages several system components running in Oracle WebLogic Server. For these components, the mechanism through which the audit events are pushed from local bus-stop files to the database audit data store is handled by OPMN.

You must execute the following steps in every instance of the component to configure an audit data store:

1. Open the opmn.xml file, which resides in

   (UNIX) $ORACLE_INSTANCE/config/OPMN/opmn/opmn.xml 
   (Windows) %ORACLE_INSTANCE%/config/OPMN/opmn/opmn.xml 
   

2. Locate the rmd-definitions element, which looks like this :

   (UNIX)
   <rmd-definitions>
            <rmd name="AuditLoader" interval="15">
               <conditional>
               <![CDATA[({time}>=00:00)]]>
               </conditional>
               <action value="exec $ORACLE_HOME/jdk/bin/java -classpath 
    $COMMON_COMPONENTS_HOME/modules/oracle.osdt_11.1.1/osdt_cert.jar: 
    $COMMON_COMPONENTS_HOME/modules/oracle.osdt_11.1.1/osdt_core.jar: 
    $ORACLE_HOME/jdbc/lib/ojdbc5.jar: 
    $COMMON_COMPONENTS_HOME/modules/oracle.iau_11.1.1/fmw_audit.jar: 
    $COMMON_COMPONENTS_HOME/modules/oracle.pki_11.1.1/oraclepki.jar:
    $COMMON_COMPONENTS_HOME/modules/oracle.jps_11.1.1/jps-manifest.jar:
                    -Doracle.home=$ORACLE_HOME 
                    -Doracle.instance=$ORACLE_INSTANCE           
                    -Dauditloader.jdbcString=jdbc:oracle:thin:@host:port:sid           
                    -Dauditloader.username=username 
                    oracle.security.audit.ajl.loader.StandaloneAuditLoader"/>
               <exception value="exec /bin/echo 
                   PERIODICAL CALL For Audit Loader FAILED"/>
            </rmd>
   </rmd-definitions>
   
   (Windows)
   <rmd-definitions>
            <rmd name="AuditLoader" interval="15">
               <conditional>
               <![CDATA[({time}>=00:00)]]>
               </conditional>
               <action value="exec %ORACLE_HOME%\jdk\bin\java -classpath 
    %COMMON_COMPONENTS_HOME%\modules\oracle.osdt_11.1.1\osdt_cert.jar; 
    %COMMON_COMPONENTS_HOME%\modules\oracle.osdt_11.1.1\osdt_core.jar; 
    %ORACLE_HOME\jdbc\lib\ojdbc5.jar; 
    %COMMON_COMPONENTS_HOME%\modules\oracle.iau_11.1.1\fmw_audit.jar; 
    %COMMON_COMPONENTS_HOME%\modules\oracle.pki_11.1.1\oraclepki.jar;
    %COMMON_COMPONENTS_HOME%\modules\oracle.jps_11.1.1\jps-manifest.jar 
                    -Doracle.home=%ORACLE_HOME% 
                    -Doracle.instance=%ORACLE_INSTANCE%           
                    -Dauditloader.jdbcString=jdbc:oracle:thin:@host:port:sid           
                    -Dauditloader.username=username 
                    oracle.security.audit.ajl.loader.StandaloneAuditLoader"/>
               <exception value="exec \bin\echo 
                   PERIODICAL CALL For Audit Loader FAILED"/>
            </rmd>
   </rmd-definitions>
   

3. Replace the existing RMD definition for audit loader; you need to modify only these values:

   • jdbcString - this is the database JDBC connection string; change this from the default string to a valid connection string.

   • username

   • interval - this is the interval in seconds at which audit records are pushed from the component's bus-stop file to the audit data store.

     By default the interval value is set very high (31536000 seconds) so that the audit loader is effectively disabled. Change this to a reasonable interval such as 15 seconds.

     Note:

     Insert these lines after the <ias-instance> tag is closed.

4. Ensure that ORACLE_HOME, ORACLE_INSTANCE , and COMMON_COMPONENTS_HOME are defined. For example:

   (UNIX) ORACLE_HOME = /u01/oracle/as11_oh
   ORACLE_INSTANCE = /u01/oracle/instances/instance 
   COMMON_COMPONENTS_HOME = $MW_HOME/oracle_common
    
   (Windows) ORACLE_HOME = \u01\oracle\as11_oh
   ORACLE_INSTANCE = \u01\oracle\instances\instance 
   COMMON_COMPONENTS_HOME = %MW_HOME%\oracle_common
   

5. Populate the audit data store password in the secret store (the password that you have specified when creating the audit schema in RCU):

   (UNIX) ORACLE_HOME/jdk/bin/java -classpath 
            $COMMON_COMPONENTS_HOME/modules/oracle.osdt_11.1.1/osdt_cert.jar:
            $COMMON_COMPONENTS_HOME/modules/oracle.osdt_11.1.1/osdt_core.jar:
            $ORACLE_HOME/jdbc/lib/ojdbc5.jar:
            $COMMON_COMPONENTS_HOME/modules/oracle.iau_11.1.1/fmw_audit.jar:
            $COMMON_COMPONENTS_HOME/modules/oracle.pki_11.1.1/oraclepki.jar:
            $COMMON_COMPONENTS_HOME/modules/oracle.jps_11.1.1/jps-manifest.jar 
            -Doracle.home=$ORACLE_HOME -Doracle.instance=$ORACLE_INSTANCE 
            -Dauditloader.jdbcString=jdbc:oracle:thin:@host:port:sid 
            -Dauditloader.username=username 
            -Dstore.password=true 
            -Dauditloader.password=password 
            oracle.security.audit.ajl.loader.StandaloneAuditLoader
   
   (Windows) ORACLE_HOME\jdk\bin\java -classpath 
               %COMMON_COMPONENTS_HOME%\modules\oracle.osdt_11.1.1\osdt_cert.jar;
               %COMMON_COMPONENTS_HOME%\modules\oracle.osdt_11.1.1\osdt_core.jar;
               %ORACLE_HOME%\jdbc\lib\ojdbc5.jar;
               %COMMON_COMPONENTS_HOME%\modules\oracle.iau_11.1.1\fmw_audit.jar;
               %COMMON_COMPONENTS_HOME%\modules\oracle.pki_11.1.1\oraclepki.jar;
               %COMMON_COMPONENTS_HOME%\modules\oracle.jps_11.1.1\jps-manifest.jar
               -Doracle.home=%ORACLE_HOME% -Doracle.instance=%ORACLE_INSTANCE% 
               -Dauditloader.jdbcString=jdbc:oracle:thin:@host:port:sid 
               -Dauditloader.username=username 
               -Dstore.password=true 
               -Dauditloader.password=password 
               oracle.security.audit.ajl.loader.StandaloneAuditLoader
   

   Enter the appropriate values for jdbcString, username, and password.

6. Save and exit the file.

7. Reload OPMN:

    $ORACLE_INSTANCE/bin/opmnctl validate (Validation step to verify edits)
         $ORACLE_INSTANCE/bin/opmnctl reload
   

8. Execute a scenario in an audited component to generate an audit event. For example, log in to an Oracle HTTP Server instance; assuming that Oracle HTTP Server is configured to audit "User Logins" under the User Sessions category, then logging in will generate an audit event.

9. Check for errors/events uploaded at $ORACLE_INSTANCE/diagnostics/logs/OPMN/opmn/rmd.out. The output will look like this

   8/08/26 10:54:24 global:AuditLoader
   

13.2.5 Tuning the Bus-stop Files

This section contains topics related to maintaining file-based storage of audit records, including:

• bus-stop file locations

• file size

• directory size

Location of Bus-stop Files

Bus-stop files for Java components are located in:

$DOMAIN_HOME/servers/$SERVER_NAME/logs/auditlogs/Component_Type 

Bus-stop files for system components are located in:

$ORACLE_INSTANCE/auditlogs/Component_Type/Component_Name

File Size

Java Components

The size of a file for the file storage mode can be managed using the max.fileSize property described in the configuration file jps-config.xml. This property controls the maximum size of a bus-stop file for Java components.

Specify the sizes in bytes as described in Section 13.3.4, "Manage Audit Policies Manually".

System Components

The size of a file for the file storage mode can be set in the auditconfig.xml file. SeeSection 13.3.4.4, "Manually Configuring Audit for System Components".

Directory Size

Java Components

The size of a directory for the file can be managed using the max.DirSize property described in the configuration file jps-config.xml. This property controls the maximum size of a bus-stop directory.

Specify the sizes in bytes as described in Section 13.3.4, "Manage Audit Policies Manually".

System Components

The size of a directory for the file storage mode can be set in the auditconfig.xml file. See Section 13.3.4.4, "Manually Configuring Audit for System Components".

13.2.6 Configuring the Stand-alone Audit Loader

As shown in Figure 12-1, Common Audit Framework's audit loader moves records from bus-stop files to the audit data store. The mechanism driving the audit loader depends on the application environment:

• Java EE components and applications deployed on Oracle WebLogic Server use the audit loader functionality provided through the application server.

• System components and non-Java applications use the audit loader functionality provided through Oracle Process Manager and Notification Server (OPMN).

• Java SE applications, which run outside an application server container, use a stand-alone audit loader.

This section explains how to set up and execute the stand-alone audit loader:

• Configuring the Environment

• Running the Stand-Alone Audit Loader

$COMMON_COMPONENTS_HOME/jdk/jre/bin/java 
-classpath $COMMON_COMPONENTS_HOME/modules/oracle.osdt_11.1.1/osdt_cert.jar:
$COMMON_COMPONENTS_HOME/modules/oracle.osdt_11.1.1/osdt_core.jar:
$COMMON_COMPONENTS_HOME/modules/oracle.iau_11.1.1/fmw_audit.jar:
$COMMON_COMPONENTS_HOME/modules/oracle.pki_11.1.1/oraclepki.jar:
$COMMON_COMPONENTS_HOME/modules/oracle.jdbc_11.1.1/ojdbc6dms.jar:
$COMMON_COMPONENTS_HOME/modules/oracle.dms_11.1.1/dms.jar 
-Doracle.home=$ORACLE_HOME 
-Doracle.instance=$ORACLE_INSTANCE 
-Dauditloader.jdbcString=jdbc:oracle:thin:@host:port:sid 
-Dauditloader.username=db-user-name 
-Dstore.password=true  
oracle.security.audit.ajl.loader.StandaloneAuditLoader 

$COMMON_COMPONENTS_HOME/jdk/jre/bin/java 
-classpath $COMMON_COMPONENTS_HOME/modules/oracle.osdt_11.1.1/osdt_cert.jar:
$COMMON_COMPONENTS_HOME/modules/oracle.osdt_11.1.1/osdt_core.jar:
$COMMON_COMPONENTS_HOME/modules/oracle.iau_11.1.1/fmw_audit.jar:
$COMMON_COMPONENTS_HOME/modules/oracle.pki_11.1.1/oraclepki.jar:
$COMMON_COMPONENTS_HOME/modules/oracle.jdbc_11.1.1/ojdbc6dms.jar:
$COMMON_COMPONENTS_HOME/modules/oracle.dms_11.1.1/dms.jar:
$COMMON_COMPONENTS_HOME/modules/oracle.jps_11.1.1/jps-manifest.jar -Doracle.home=$ORACLE_HOME 
-Doracle.instance=$ORACLE_INSTANCE -Dauditloader.jdbcString=jdbc:oracle:thin:@host:port:sid -Dauditloader.username=db-user-name oracle.security.audit.ajl.loader.StandaloneAuditLoader 

13.3.1 Manage Audit Policies for Java Components with Fusion Middleware Control

The domain Audit Policy Settings page manages audit events for all Java components such as Oracle Access Manager, and system libraries like Oracle Platform Security Services.

Use these steps to view and update the currently configured audit policies:

1. Log in to Fusion Middleware Control.

2. Using the topology panel to the left, navigate to the domain of interest under "WebLogic Domain".

3. From the domain menu, navigate to Domain, then Security, then Audit Policy. The Audit Policy page appears.

4. Use the Audit Component Name drop-down to select the Java component whose audit policy you wish to configure.

   
   

   When you select a component, a table of audit categories relevant to the component appears in the area of the page titled Audit Policy Settings. The following example is for Oracle Access Manager:

   
   

5. Use the Audit Level drop-down to select a subset of the audit events for the component. The choices are:

   
   

   • None - No event categories selected.

   • Low, Medium, High - Subsets of event categories representing pre-defined levels of auditing.

   • Custom - Enables you to create or modify a custom filter definition.

   Depending on the level you select, check flags appear in the column Select for Audit. Events in the checked categories will be audited. For example, at the Medium level for Oracle Access Manager:

   
   

   The flagged categories are selected for audit. You can view the events within a flagged category by clicking on that row in the categories table. For example, clicking on the Server category produces the following event table below it:

   
   

   Note:

   The table of events can only be edited in custom level. It cannot be edited at the pre-defined levels.

6. While the pre-defined levels are sufficient in many cases, you may wish to fine-tune the audit policy for the component.

   To customize the audit policy, use the "Custom" option from the drop-down. This preserves the pre-defined categories but the green check-marks now appear as check-boxes, and all categories are available for selection:

   
   

   You can select desired categories and events to fine-tune the audit policy. For example, you might wish to audit only failed authentication attempts in the Server category:

   
   

7. Filters are rule-based expressions that you can define to qualify or filter events for audit. The expressions are based on attributes of the event. For example, you may wish to further fine-tune the policy to narrow down the types of failed authentication attempts to audit.

   A pencil icon in the Edit Filter column denotes that a filter is available for the event. Click on the icon to bring up the Edit Filter dialog:

   
   

   Specify the filter using the condition boxes, which consist of the filter condition, an operator, and a value. After specifying each condition, click the add button. When finished adding conditions, click OK to save the changes.

   In this example, a failed authentication attempt triggers an audit event only if the server hosting the protected application is named myhost1:

   
   

   Note:

   Each filter attribute has a formal name and a display name. You may see either name in the filter edit dialog. Display names are shown in the drop-down, while names are shown in the edit dialog. For example, if you select 'Client Address IP' in the drop-down box, it is renamed to 'RemoteIP' after you add it to the filter expression.

8. Import/Export - These buttons enable you to save and re-use a policy configuration. At any time while editing the policy, click Export to save the current settings to a file, and Import to load the settings from a saved file.

9. Optionally, under “Users to Always Audit”, you can specify a comma-separated list of users to force the audit framework to audit events initiated by these users; auditing occurs regardless of the audit level or filters that have been specified.

   
   

   Notes:

   • Be aware that if you use this feature to audit key users such as system administrators, this will generate audit traffic anytime that user touches any of the auditable events for any component. For example, a component's audit policy may be set to None, but if these users perform some activity in the component instance, it is still audited.

   • No validation is performed for user names you enter in this field.

10. If you made any policy changes, click Apply to save the changes. For Java components, you must restart the managed Oracle WebLogic Server (on which the affected Java component is running) for the changes to be effective; changes are effective after a pre-defined refresh interval, which is 10 minutes by default..

    Click Revert to discard any policy changes and revert to the existing policy.

About Component Events

Each component and application in the domain defines its own set of auditable events. Thus, when you expand the Names column of the table, each component displays a list of events that applies to instances of that component.

13.3.2 Manage Audit Policies for System Components with Fusion Middleware Control

This section describes how to view and update audit policies for system components that are managed through OPMN.

Audit policy for system components is managed in their home pages. The domain Audit Policy Settings page manages audit events for Java components running in the domain.

The events are organized in a tree structure under the Name column. The tree can be expanded to reveal the details of the events available.

Use these steps to view and update audit policies for OPMN-managed components:

1. Log in to Fusion Middleware Control.

2. Using the topology panel to the left, navigate to the system component of interest such as Oracle HTTP Server.

3. From the component menu, navigate to Security, then Audit Policy. The Audit Policy Settings page appears

4. You can select from a drop-down list of pre-configured audit levels. Three pre-defined levels (Low, Medium, High) will automatically pick up a subset of the audit events for the component.

   
   

   Note:

   The selection of events under the drop-down box cannot be edited for the pre-defined levels. It can only be edited in custom level.

   • None - No events are selected for audit.

   • Low - A small set of events is selected, typically those having the smallest impact on component performance.

   • Medium, High- This is a larger set of events. These events may have a higher impact on component performance.

   • Custom - This level enables you to fine-tune the policy, and is described in Step 5 below.

   The table shows the events you can audit for the component instance. This example is for Oracle HTTP Server:

   
   

   The table consists of these columns:

   • Name - shows the component events grouped by type, such as Authorization events.

   • Enable Audit - shows whether the corresponding event type is being audited. This column is greyed out unless the Custom audit policy is in force.

   • Filter - shows any filters in effect for the event type.

5. To customize the audit policy, use the "Custom" option from the drop-down. This allows you to select event categories by checking the relevant boxes under the "Select For Audit" column.

   A second table lists the events in each category, enabling you to additionally filter for success and failure outcomes of each individual event to further control how they are audited, as explained in Step 6.

6. Filters are rule-based expressions that you can define to qualify or filter events for audit. The expressions are based on attributes of the event. For example, a Login type event could specify an initiator as a user filter in which case the event would generate an audit record whenever the specified user logged in.

   A pencil icon indicates that a filter is available for the corresponding event.

   
   

   Click on a pencil icon to bring up the Edit Filter dialog.

   
   

   Note:

   Each filter attribute has a formal name and a display name. You may see either name in the filter edit dialog. Display names are shown in the drop-down, while names are shown in the edit dialog. For example, if you select 'Client Address IP' in the drop-down box, it is renamed to 'RemoteIP' after you add it to the filter expression.

7. Click "Select Failures Only" to select only failed events in the policy - for example, a failed authentication. The Enable Audit box is now checked for failed events.

8. Import/Export - These buttons enable you to save and re-use a policy configuration. At any time while editing the policy, click Export to save the current settings to a file, and Import to load the settings from a saved file.

9. Optionally, under “Users to Always Audit”, a comma-separated list of users can be specified to force the audit framework to audit events initiated by these users; auditing occurs regardless of the audit level or filters that have been specified.

   
   

   Notes:

   • Be aware that if you use this feature to audit key users such as system administrators, this will generate audit traffic anytime that user touches any of the auditable events for any component. For example, a component's audit policy may be set to None, but if these users perform some activity in the component instance, it is still audited.

   • No validation is performed for user names you enter in this field.

10. If you made any policy changes, click Apply to save the changes.

    Click Revert to discard any policy changes and revert to the existing policy.

13.3.3 Manage Audit Policies with WLST

This section explains how to view and update audit policies using the Oracle WebLogic Scripting Tool (WLST) command-line tool:

• View Audit Policies with WLST

• Update Audit Policies with WLST

• Example 1: Configuring an Audit Policy for Users with WLST

• Example 2: Configuring an Audit Policy for Events with WLST

• Custom Configuration is Retained when the Audit Level Changes

setAuditPolicy
   (filterPreset="None",addSpecialUsers="user2,user3",removeSpecialUsers="user1")

setAuditPolicy
(filterPreset="Custom",addCustomEvents="OHS:UserLogin",
removeCustomEvents="OHS:UserLogout")

13.3.4 Manage Audit Policies Manually

This section explains how to configure auditing policies and other features by manually updating:

• the platform configuration file jps-config.xml for Java components

• component-specific files for system components

This section contains these topics:

• Location of Configuration Files for Java Components

• Audit Service Configuration Properties in jps-config.xml for Java Components

• Switching from Database to File for Java Components

• Manually Configuring Audit for System Components

$DOMAIN_HOME/config/fmwconfig/jps-config.xml

<?xml version="1.0" encoding="UTF-8" standalone='yes'?>
<jpsConfig xmlns="http://xmlns.oracle.com/oracleas/schema/11/jps-config-11_1.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.oracle.com/oracleas/schema/11/jps-config-11_1.xsd" schema-major-version="11" schema-minor-version="1">
 
    <serviceProviders>
     <serviceProvider name="audit.provider" type="AUDIT" class="oracle.security.jps.internal.audit.AuditProvider">
     </serviceProvider>
    </serviceProviders>
 
  <serviceInstances>
   <serviceInstance name="audit" provider="audit.provider">
      <property name="audit.filterPreset" value="Low"/>
      <property name="audit.specialUsers" value ="admin, fmwadmin" />
      <property name="audit.customEvents" value ="JPS:CheckAuthorization,          CreateCredential; OIF:UserLogin"/>
      <property name="audit.loader.jndi" value="jdbc/AuditDB"/>
      <property name="audit.loader.interval" value="15" />
      <property name="audit.maxDirSize" value="102400" />
      <property name="audit.maxFileSize" value="10240" />      
      <property name=" audit.loader.repositoryType " value="Db" />      
   </serviceInstance>
  </serviceInstances>
    <jpsContexts default="default">
        <jpsContext name="default">
            <serviceInstanceRef ref="audit"/>
        </jpsContext>
    </jpsContexts>
</jpsConfig>

<AuditConfig xmlns="http://xmlns.oracle.com/ias/audit/audit.xsd">
  <Filters>
    <!-- FilterPreset can be None,Low,Medium,or Custom.  Default value: None -->
    <FilterPreset>Low</FilterPreset>
 
    <!-- Comma separated list of special users for whom auditing is always turned on. Default value: no users -->
    <SpecialUsers>u1,u2</SpecialUsers>
 
    <!-- In case of custom, a comma separate list of events that are to be enabled for auditing. Default value: no events -->
    <CustomEvents>e1,e1</CustomEvents>
 
  </Filters>
  <LogsDir>
 
    <!-- Maximum dir size of the log directory (busstop). 0 implies unlimited size. Default value: 0 -->
    <MaxDirSize>0</MaxDirSize>
 
    <!-- Maximum file size of each audit.log file. Default value: 100MB -->
   <MaxFileSize>104857600</MaxFileSize>
 
 </LogsDir>
<AuditConfig>

13.5.1 Location of Audit Logs

Fusion Middleware Audit Framework provides a set of log files to help with audit administration. You can use these logs to trace errors and for diagnostic purposes when the audit framework is not functioning properly.

For a listing of all audit log locations, how to configure the loggers, and how to use the logs to diagnose issues, see Section L.1.1.7, "Audit Loggers".

13.5.2 Audit Timestamps in Bus-stop Files

Time stamps in the audit bus-stop files are recorded in Coordinated Universal Time. This may differ from the machine time depending on the machine's time zone setting.

13.6.1 Schema Overview

The common tables in the Oracle Fusion Middleware Audit Framework schema consist of the following:

• common attributes in the IAU_COMMON table

• generic attributes in dedicated tables

• custom attribute tables in the IAU_CUSTOM_nnn tables.

For details about these tables, see Section 12.4.

The audit schema also contains the following:

• A base table

• A translation table

• A set of component-specific tables of audit data

For details about these tables, see Section 13.6.2.

About the Bus-stop File

By default, the bus-stop file is maintained in the directory

WebLogic Domain Home/servers/server_name/diagnostics/auditlogs/JPS/audit.log

Here is a sample bus-stop file for Oracle Platform Security Services.

#Fields:Date Time Initiator EventType EventStatus MessageText HomeInstance ECID RID ContextFields SessionId TargetComponentType ApplicationName EventCategory ThreadId InitiatorDN TargetDN FailureCode RemoteIP Target Resource Roles CodeSource InitiatorGUID Principals PermissionAction PermissionClass mapName key
#Remark Values:ComponentType="JPS"
2008-12-08 10:46:05.492  - "CheckAuthorization" true "Oracle Platform Security Authorization Check Permission SUCCEEDED." - - - - - - - "Authorization" "48" - - "true" - - "(oracle.security.jps.service.policystore.PolicyStoreAccessPermission context=APPLICATION,name=SimpleServlet getApplicationPolicy)" - "file:/oracle/work/middleware/oracle_common/modules/oracle.jps_11.1.1/jps-internal.jar" - "[]" - - - -

Common Table and Custom Tables

Figure 13-1 shows the data in the common table and how it relates to the custom tables.

Figure 13-1 Common and Custom Audit Tables

Base Table and Component Tables

Figure 13-2 shows the data in the base table and how it relates to the component-specific tables.

Figure 13-2 Audit Base and Component Tables

13.6.2 Base and Component Table Attributes

When generated, audit records are stored in a file; if an audit database store is configured, the audit loader stores each audit record in one row of the base table and one row of a component table:

• General information (such as Time, EventType, and EventStatus) is written into the base table

• component-specific information (such as CodeSource) is written into the component table

The average record size in the base table IAU_BASE is approximately 0.3 KB. When you plan for tablespace sizing:

• use this number as a guideline for the average record size

• monitor how audit database size is growing based on the audit policy selected and the level of activity

• take into account the period of time for which the audit data is being stored.

The attributes of the base table and the component-specific tables respectively are derived from these files:

• $ORACLE_HOME/modules/oracle.iau_11.1.1/components/generic/generic_events.xml
  

  for the base table, and

• $ORACLE_HOME/modules/oracle.iau_11.1.1/components/componentName/component_events.xml
  

  for each component table.

Table 13-1 lists a few important attributes defined in the base table IAU_BASE. The first four attributes are common in that table and all component tables. The primary key is defined as IAU_ID + IAU_TSTZORIGINATING.

You can use the listAuditEvents OPSS script to get a list of all attribute names for individual component tables.

13.6.3 Indexing Scheme

For efficient queries, an index is created by default on the Timestamp (IAU_TSTZORIGINATING) in the base table and on each of the component-specific tables.

The default index in IAU_BASE is named EVENT_TIME_INDEX, and in the component tables it is named tableName_INDEX (such as OVDCOMPONENT_INDEX, OIDCOMPONENT_INDEX, JPS_INDEX and so on).

13.6.4 Backup and Recovery

Compliance regulations require that audit data be stored for long periods. A backup and recovery plan is needed to protect the data.

A good backup plan takes account of these basic guidelines:

• Growth rate of Audit Events

  The number of audit events generated depends on your audit policy. The number of audit events generated daily determines, in turn, how often you want to perform backups to minimize the loss of your audit data.

• Compliance regulations

  Consult you organization's compliance regulations to determine the frequency of backups and number of years for which audit data storage is mandatory.

• Online or Offline Data Management

  Consult you organization's compliance regulations to determine the frequency of backups and the portion of audit data that needs to be easily accessible.

Oracle Database uses Oracle Recovery Manager (RMAN) for backup and recovery. For details, see:

http://www.oracle.com/technology/deploy/availability/htdocs/BR_Overview.htm

http://www.oracle.com/technology/deploy/availability/htdocs/rman_overview.htm

13.6.5 Importing and Exporting Data

You can import and export the audit schema to migrate data if you started with multiple audit databases and wish to combine them into a single audit data store, or if you wish to change the database to scale up.

Oracle Database sites can utilize the utilities of Oracle Data Pump to import and export data. For details, refer to:

http://www.oracle.com/technology/products/database/utilities/htdocs/data_pump_overview.html

13.6.6 Partitioning

Not all database systems support partitioning, all the tables in the audit schema are unpartitioned by default.

Since audit data is cumulative and older data is never removed, if you store a high volume of audit data you should consider partitioning the audit schema, as it will allow for easier archiving.

Benefits of partitioning include:

• Improved Performance: If a table is range-partitioned by Timestamps, for example, queries by Timestamps can be processed on the partitions within that time-frame only.

• Better Manageability: Partitions can be created on separate tablespaces (thus different disks). This enables you to move older data to slower and larger disks, while keeping newer data in faster and smaller disks.

  In addition, partitioning makes archival much easier. For example, you can compress a singlve partition rather than having to partition the entire table.

• Increased Availability: If a single partition is unavailable, for example, and you know that your query can eliminate this partition from consideration, the query can be successfully processed without needing to wait for the unavailable partition.

ALTER TABLE IAU_BASE DROP PARTITION IAU_BASE_Q4_2008;

ALTER TABLE IAU_BASE ADD PARTITION IAU_BASE_Q4_2008 VALUES LESS THAN ('01-JAN-2009');

[Unix]
RCU_HOME/rcu/integration/iau/scripts

[Windows]
RCU_HOME\rcu\integration\iau\scripts

auditDeleteData.sql audit_schema_user number_of_days_to_keep

sqlplus> @auditDeleteData.sql DEV_IAU 100

@auditReclaimSpace.sql audit_schema_user

sqlplus> @auditDataPurge.sql DEV_IAU

@auditDataPurge.sql audit_schema_user number_of_days_to_keep

sqlplus> @auditDataPurge.sql DEV_IAU 100

ALTER TABLE IAU_BASE MOVE PARTITION IAU_BASE_Q1_2008
TABLESPACE AUDITARCHIVE UPDATE INDEXES;