Bus-Stop File Locations

Bus-stop files for Java components are located in the following directory:

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

Bus-stop files for system components are located in the following directory:

$ORACLE_INSTANCE/auditlogs/Component_Type/Component_Name

Bus-Stop File Size

In Java components, the maximum size of a bus-stop file is set with the audit.maxFileSize property.

In system components, the maximum size of a bus-stop file is set in the auditconfig.xml file:

<serviceInstance name="audit" provider="audit.provider">
  <property name="audit.maxFileSize" value="10240" />      
  <property name=" audit.loader.repositoryType " value="Db" />      
</serviceInstance>

When you switch from a file to a database store for audit data, all the events collected in the files are moved to the database tables and the audit files are deleted.

You must perform the following tasks to manage audit policies for Java and system components with Fusion Middleware Control.

• Task 1, Opening the Audit Page

• Task 2, Choosing Events to Audit for a Java Component

• Task 3, Customizing Audit Policies for a Java Component

• Task 4, Creating Audit Filters for a Java Component

• Task 5, Importing and Exporting Audit Policies for a Java Component

• Task 6, Choosing Events to Audit for a System Component

• Task 7, Customizing Audit Policies for a System Component

• Task 8, Creating Audit Filters for a System Component

• Task 9, Importing and Exporting Audit Policies for a System Component

Task 1, Opening the Audit Page

Log in to Fusion Middleware Control and go to Domain, then to Security, and then to Audit Policy. The Audit Policy page is displayed.

Task 2, Choosing Events to Audit for a Java Component

1. In the Audit Component Name drop-down, choose a Java component. The table of audit categories relevant to the component is displayed in the Audit Policy Settings area.

   Note:

   The values you enter in the Audit Policy Settings area do not apply to Oracle Access Manager audit.

2. In the Audit Level drop-down, choose the audit level according to your needs:

   • None - Selects no event categor.ies

   • Low, Medium, High - Selects subsets of event categories representing predefined audit levels.

   • Custom - Selects custom filters.

   Check flags are displayed in the Select for Audit column, and events in the chosen categories will be audited. View the events within a flagged category by clicking on that row in the categories table. The table of events can be edited in a custom level only.

Task 3, Customizing Audit Policies for a Java Component

1. In the Audit Component Name drop-down, choose a Java component. The table of audit categories relevant to the component is displayed in the Audit Policy Settings area.

2. In the Audit Level drop-down, choose Custom. All categories become available.

3. Choose categories and events to customize the audit policy by checking the box in the Select For Audit column.

4. Click Apply to save the changes.

Task 4, Creating Audit Filters for a Java Component

1. In the Audit Component Name drop-down, choose a Java component. The table of audit categories relevant to the component is displayed in the Audit Policy Settings area.

2. A pencil icon in the Edit Filter column denotes that a filter is available for the event. Click on a pencil icon for an event. The Edit Filter dialog is displayed.

   Each filter attribute has a formal name and a display name. Either name is displayed in the Edit Filter edit dialog.

3. Create a filter condition by choosing an item from the Condition drop-down, an operator, and a value. Then click the add button. When you are finished adding conditions, click OK.

4. Optionally, under Users to Always Audit, specify a comma-separated list of users to audit events initiated by these users. Audit occurs regardless of the audit level or filters that have been specified. User names you enter in this field are not validated

5. Restart Oracle WebLogic Server on which the Java component is running for the changes to take place.

Task 5, Importing and Exporting Audit Policies for a Java Component

1. In the Audit Component Name drop-down, choose a Java component. The table of audit categories relevant to the component is displayed in the Audit Policy Settings area.

2. At any time while editing a policy, do one of the following:

   • Click Export to save the current settings to a file

   • Click Import to load settings from a file

Task 6, Choosing Events to Audit for a System Component

1. Go to a system component home page. The table of audit categories relevant to the component is displayed in the Audit Policy Settings area.

2. In the Audit Level drop-down, choose the audit level.

   • None, selects no event categor.ies

   • Low, Medium, High - Selects subsets of event categories representing predefined audit levels.

   • Custom - Selects custom filters.

   Check flags are displayed in the Select for Audit column, and events in the chosen categories will be audited. View the events within a flagged category by clicking on that row in the categories table. The table of events can be edited in a custom level only.

Task 7, Customizing Audit Policies for a System Component

1. go to a system component home page. The table of audit categories relevant to the component is displayed in the Audit Policy Settings area.

2. In the Audit Level drop-down, choose Custom. All categories become available.

3. Choose categories and events to customize the audit policy by checking the box in the Select For Audit column.

4. Click Apply to save the changes.

Task 8, Creating Audit Filters for a System Component

1. Go to a system component home page. The table of audit categories relevant to the component is displayed in the Audit Policy Settings area.

2. A pencil icon in the Edit Filter column denotes that a filter is available for the event. Click on a pencil icon for an event. The Edit Filter dialog is displayed. A filter attribute has a formal name and a display name. Either name is displayed in the Edit Filter edit dialog

3. Create a filter condition by choosing an item from the Condition drop-down, an operator, and a value. Then click the add button. When you are finished adding conditions, click OK.

4. Optionally, under Users to Always Audit, specify a comma-separated list of users to audit events initiated by these users. Audit occurs regardless of the audit level or filters that have been specified. User names you enter in this field are not validated. Particular users, such as a system administrator, will generate audit traffic anytime that user executes any auditable events for any component.

5. Restart WebLogic Server on which the system component is running.

Task 9, Importing and Exporting Audit Policies for a System Component

Use this section manage audit policies with WLST.

The audit loader stores two kinds of data records in tables:

• General information (such as time, event type, and event status), stored in one row of the common table (dynamic model) or the base table.

• Component-specific information, stored in one row of the custom table (dynamic model) or the component table.

The average audit record size is approximately 0.3 KB. Use this average when you plan to resize database tables, and in addition, monitor how your audit database size grows according to policies and level of activity.

The attributes of the base table are derived from the following file:

$ORACLE_HOME/modules/oracle.iau_12.2.1/components/generic/generic_events.xml

The attributes of the component table are derived from the following file:

$ORACLE_HOME/modules/oracle.iau_12.2.1/components/componentName/component_events.xml

Table C-6 lists the attributes defined in the IAU_BASE base table. Table C-7 lists the attributes defined in the IAU_COMMON common table.

To get a list of attribute names for individual component tables, use the listAuditEvents WLST command.

For efficient queries, an index is created by default for the IAU_TSTZORIGINATING column in the base table and for each of the component-specific tables.

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

Additional columns and indexes in the common table are:

• IAU_TSTZORIGINATING, indexed by DYN_EVENT_TIME_INDEX

• IAU_AuditUser, indexed by DYN_USER_INDEX

• IAU_ComponentType, indexed by DYN_COMPONENT_TYPE_INDEX

• IAU_EventCategory, indexed by DYN_EVENT_CATEGORY_INDEX

• IAU_EventType, indexed by DYN_EVENT_TYPE_INDEX

Import and export the audit schema to migrate data, for example, if you wish to combine several audit repositories into a single audit store, or if you wish to scale up the database. Use Oracle Data Pump to import and export data from an Oracle Database.

The framework provides the following SQL scripts to purge records from the audit store, in the directory $MW_HOME/oracle_common/common/sql/iau/scripts:

• auditDataPurge.sql

• auditDeleteData.sql

• auditReclaimSpace.sql

To delete records without taking any other action, use auditDeleteData.sql. This script has the following syntax:

auditDeleteData.sql audit_schema_user number_of_days_to_keep

For example, to delete records older that 100 days:

sqlplus> @auditDeleteData.sql DEV_IAU 100

To reclaim space, use auditReclaimSpace.sql. This script has the following syntax:

auditReclaimSpace.sql audit_schema_user

To delete audit records and reclaim space, use auditDataPurge.sql. This script has the following syntax:

auditDataPurge.sql audit_schema_user number_of_days_to_keep

For example, to delete all records older than 100 days and enable row movements to shrink space:

sqlplus> @auditDataPurge.sql DEV_IAU 100

Partitioning tables allows you to store individual partitions on different storage tiers. Typically, you create tablespaces in high-performance or low-cost disks, and create partitions in different tablespaces based on the value of the data or other criteria.

Oracle Information Lifecycle Management (ILM) features streamlined data management with partitioning and compression.

Database views enable you to run queries against audit records. Furthermore, you can create indexes on custom tables for their attributes with indexable views. We recommend that applications create a simple view first and switch to an indexable view later on when needed.

To create an indexable view:

If you change event definitions, then drop the associated materialized view before redeployment.

Ensure that all audit names conform to the following naming conventions:

• Do not use any of the following characters in component Type, Category, Event, or Attribute names: !, @, “, #, $, %, ‘, (, ), *, +, comma, period, -, _, /, space, :, ;, <, =, >, ?, {, }, ~, ^.

• The space character is allowed in display names only.

When you name audit events:

• Do not prefix the event name with the component name.

• Try to make names as specific as possible. For example, use HTTPResponse instead of Response when defining an HTTP response code.

• Do not append the suffix Event to all event names. For example, instead of AuthenticationEvent, use Authentication.

To optimize the use of events:

• Define separate events for each operation. For example, instead of defining the event Policy with attributes Delete and Create, define the separate events PolicyCreate and PolicyDelete.

• Do not define separate events for the events success and failure. For example, do not define the separate events PolicyCreateSuccess and PolicyCreateFailure. Instead use the EventStatus attribute to record them.

To categorize events:

• Refer system categories when applicable. For example, UserSession and Authorization.

• For configuration operations, make a category around a group of operations. For example, put PolicyCreate, PolicyDelete in a component specific category called Policy.

When you define generic attributes:

• Include the following event attributes:

  • Initiator - the user who performed the event action

  • MessageText - a short description of what happened.

  • EventStatus - the event outcome

  • FailureCode - the error code applicable to the failure.

• Use the attribute Resource - the object that was affected, such as the accessed URI or the granted permission.

The Audit Framework considers the union of all common attributes in each event and defines a database column for each of them. So try to define as many common attributes as possible.

Define enough information so that events generated by your component can be cross linked to other events.

The component_events.xml file provides version support. If you decide to change the event definitions, make sure to delete any associated materialized view.