Skip Headers
Oracle® Fusion Middleware Application Security Guide
11g Release 1 (11.1.1)

Part Number E10043-12
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

12 Introduction to Oracle Fusion Middleware Audit Framework

In Oracle Fusion Middleware 11g Release 1 (11.1.1), auditing provides a measure of accountability and answers the "who has done what and when" types of questions. This chapter introduces auditing in Oracle Fusion Middleware. It contains the following topics:

12.1 Benefits and Features of the Oracle Fusion Middleware Audit Framework

This section contains these topics:

12.1.1 Objectives of Auditing

With compliance becoming an integral part of any business requirement, audit support is also becoming a focus in enterprise deployments. Customers are looking for application vendors to provide out-of-the-box audit support. In addition, middleware customers who are deploying custom applications would like to centralize the auditing of their deployed applications wherever audit is appropriate.

IT organizations are looking for several key audit features driven by compliance, monitoring, and analytics requirements.

Compliance

Compliance is obviously a major requirement in the enterprise. With regulations such as Sarbanes-Oxley (financial) and Health Insurance Portability and Accountability Act (healthcare), many customers must now be able to audit on identity information and user access on applications and devices. These include events like:

  • User profile change

  • Access rights changes

  • User access activity

  • Operational activities like starting and stopping applications, upgrades, and backups

This allows compliance officers to perform periodic reviews of compliance policies.

Monitoring

The audit data naturally provides a rich set of data for monitoring purpose. In addition to any log data and component metrics that are exposed, audit data can be used to create dashboards and to build Key Performance Indicators (KPIs) for alerts to monitor the health of the various systems on an ongoing basis.

Analytics

Audit data can also be used in assessing the efficacy of controls through analysis on the audit data. The data can also be used for risk analysis. Based on historical data, a risk score can be calculated and assigned to any user. Any runtime evaluation of user access can include the various risk scores as additional criteria to protect access to the systems.

12.1.2 Today's Audit Challenges

To satisfy the audit requirements, IT organizations often battle with the deficiencies in audit support for their deployed applications. There is no reliable standard for:

  • Audit Record Generation

  • Audit Record Format and Storage

  • Audit Policy Definition

As a result, today's audit solutions suffer from a number of key drawbacks:

  • There is no centralized audit framework.

  • The quality of audit support is inconsistent from application to application.

  • Audit data is scattered across the enterprise.

  • Complex data correlation is required before any meaningful cross-component analysis can be conducted.

  • Audit policies and their configurations are also scattered.

These factors are costing IT organization considerable amount of time and resources to build and maintain any reasonable audit solutions. With the data scattered among individual silos, and the lack of consistency and centralization, the audit solutions also tend to be fragile with idiosyncrasies among applications from different vendors with their current audit capabilities.

12.1.3 Oracle Fusion Middleware Audit Framework in 11g

Oracle Fusion Middleware Audit Framework, introduced in11g Release 1 (11.1.1), is designed to provide a centralized audit framework for the middleware family of products. The framework provides audit service for the following:

  • Middleware Platform - This includes Java components such as Oracle Platform Security Services (OPSS) and Oracle Web Services. These are components that are leveraged by applications deployed in the middleware. Indirectly, all the deployed applications leveraging these Java components will benefit from the audit framework auditing events that are happening at the platform level.

  • Java EE applications - The objective is to provide a framework for Java EE applications, including Oracle's own Java EE-based components. Java EE applications are able to create application-specific audit events.

  • System Components - For system components in the middleware that are managed by Oracle Process Manager and Notification Server, the audit framework also provides an end-to-end structure similar to that for Java components.

See Also:

Understanding Key Oracle Fusion Middleware Concepts in the Oracle Fusion Middleware Administrator's Guide.

12.2 Overview of Audit Features

Key features of the Oracle Fusion Middleware Audit Framework include:

12.3 Oracle Fusion Middleware Audit Framework Concepts

This section introduces basic concepts of the Oracle Fusion Middleware Audit Framework:

12.3.1 Audit Architecture

The Oracle Fusion Middleware Audit Framework consists of the following key components:

  • Audit APIs

    These are APIs provided by the audit framework for any audit-aware components integrating with the Oracle Fusion Middleware Audit Framework. During runtime, applications may call these APIs where appropriate to audit the necessary information about a particular event happening in the application code. The interface allows applications to specify event details such as username and other attributes needed to provide the context of the event being audited.

  • The audit framework provides these APIs:

    • audit service API

    • audit client API

  • Audit Events and Configuration

    The Oracle Fusion Middleware Audit Framework provides a set of generic events for convenient mapping to application audit events. Some of these include common events such as authentication. The framework also allows applications to define application-specific events.

    These event definitions and configurations are implemented as part of the audit service in Oracle Platform Security Services. Configurations can be updated through Enterprise Manager (UI) and WLST (command-line tool)

  • The Audit Bus-stop

    Bus-stops are local files containing audit data records before they are pushed to the audit data store. In the event that no audit data store is configured, audit data remains in these bus-stop files. The bus-stop files are simple text files that can be queried easily to look up specific audit events. When an audit data store is in place, the bus-stop acts as an intermediary between the component and the audit data store. The local files are periodically uploaded to the audit data store based on a configurable time interval.

    A key advantage of the audit data store is that audit data from multiple components can be correlated and combined in reports, for example, authentication failures in all middleware components, instances and so on.

  • Audit Loader

    As its name implies, the audit loader loads audit data from the audit bus-stop into the audit data store, if one is configured. For Java component auditing, the audit loader is is a startup class that is started as part of the container start-up. For system components, the audit loader is a periodically spawned process that is invoked by OPMN.

  • Audit Data Store

    The audit data store is a database that contains a pre-defined Oracle Fusion Middleware Audit Framework schema, created by Repository Creation Utility (RCU). Once configured, all the audit loaders are aware of the audit data store and upload data to it periodically. The audit data in the store is expected to be cumulative and will grow overtime. Ideally, this should not be an operational database used by any other applications - rather, it should be a standalone RDBMS used for audit purposes only.

    The audit database can store audit events generated by Oracle components as well as user applications integrated with the audit framework.

  • Audit Metadata Store

    The audit metadata store contains audit event definitions for components and applications.

  • Audit Configuration Mbeans

    All audit configuration is managed through audit configuration MBeans. For Java components and applications, these MBeans are present in the domain administration server and the audit configuration is centrally managed. For system components, separate MBean instances are present for every component instance. Enterprise Manager UI and command-line tools manage Audit configuration using these MBeans.

  • Oracle Business Intelligence Publisher

    The data in the audit data store is exposed through pre-defined reports in Oracle Business Intelligence Publisher. The reports allow users to drill down the audit data based on various criteria. For example:

    • Username

    • Time Range

    • Application Type

    • Execution Context Identifier (ECID)

    You can also use Oracle Business Intelligence Publisher to create your own audit reports.

Figure 12-1 Audit Event Flow

Surrounding text describes Figure 12-1 .

Audit Flow

The process can be illustrated by looking at the actions taken in the framework when an auditable event (say, login) occurs within an application server instance:

Note:

The architecture shown in Figure 12-1 contains an audit data store; if your site did not configure an audit data store, the audit records reside in the bus-stop files.

  1. During application deployment or audit service start-up, a client such as a Java EE application or Oracle component registers with the audit service.

  2. The service reads the application's pre-configured audit definition file and updates the metadata store with the audit definitions.

  3. When a user accesses the component or application, an audit API function is called to audit the event.

  4. The audit framework checks if events of this type, status, and with certain attributes need to be audited.

  5. If so, the audit function is invoked to create the audit event structure and collect event information like the status, initiator, resource, ECID, and so on.

  6. The event is stored on a local file in an intermediate location known as the bus-stop; each component has its own bus-stop.

  7. If a database is configured for an audit store, the audit loader pulls the events from the bus-stops, uses the application's metadata to format the data, and moves the data to the audit store.

  8. Reports can also be generated from the audit data using Oracle BI Publisher. A set of pre-defined reports are available. (See Chapter 14, "Using Audit Analysis and Reporting".)

Application Behavior in Case of Audit Failure

It is important to note that an application does not stop execution if it is unable to record an audit event for any reason.

12.3.2 Key Technical Concepts

This section introduces key concepts in the Oracle Fusion Middleware Audit Framework.

Audit-Aware Components

The term "audit-aware" refers to components that are integrated with the Oracle Fusion Middleware Audit Framework so that audit policies can be configured and events can be audited for those components. Oracle Internet Directory is an example of an audit-aware component.

Stand-alone applications can integrate with the Oracle Fusion Middleware Audit Framework through configuration with the jps-config.xml file. For details, see see Chapter 28.

Audit Metadata Store

The audit metadata store contains audit event definitions for components as well as applications integrated with the audit framework.

Audit Data Store

The audit data store is the repository for audit event data.

Note:

The metadata store is separate from the audit data store.

Audit Loader

The Audit Loader is a module of the Oracle WebLogic Server instance and provides process control for that instance. The audit loader is responsible for collecting the audit records for all components running in that instance and loading them to the audit data store.

Audit Policy

An audit policy is a declaration of the type of events to be captured by the audit framework for a particular component. For Java components, the audit policy is defined at the domain level. For system components, the audit policy is managed at the component instance level.

Oracle Fusion Middleware Audit Framework provides several pre-defined policy types:

  • None

  • Low (audits fewer events, definition is component-dependent)

  • Medium (audits many events, definition is component-dependent)

  • Custom (implements filters to narrow the scope of audited events)

Audit Policy Component Type

This refers to the component type to be audited; for example, Oracle Internet Directory is a source of auditable events during authentication.

For lists of the events that can be audited for each component, see Section C.1, "Audit Events".

Event Filters

Certain audit events implement filters to control when the event is logged. For example, a successful login event for the Oracle Internet Directory component may be filtered for specific users.

For details, see Section 13.3, "Managing Audit Policies".

Oracle Platform Security Services

Oracle Platform Security Services, a key component of the Oracle Fusion Middleware 11g, is the Oracle Fusion Middleware security implementation for Java features such as Java Authentication and Authorization Service (JAAS) and Java EE security.

For more information about OPSS, see Section 1.1, "What is Oracle Platform Security Services?".

12.3.3 Audit Metadata Storage

Audit metadata refers to information about audit events, their attributes and categories.

For details, see Chapter 28.

12.3.4 Audit Data Storage

As shown in Figure 12-1, audit data can reside in two types of storage:

  • bus-stop files for intermediate storage of audit data. Each component instance writes to its own bus-stop.

    Bus-stop files are the default out-of-the-box storage mechanism for audit records:

    • For Java components, there is one bus-stop for each Oracle WebLogic Server instance. Audit records generated for all Java EE components running in a given Oracle WebLogic Server instance are stored in the same bus-stop.

    • For system components, there is a separate bus-stop for each component; thus, for example, each instance of Oracle Internet Directory has its own bus-stop.

    Bus-stop files are text-based and easy to query. For further details, see Section 12.3.1, "Audit Architecture"

  • permanent storage in a database; this is known as the audit data store.

    If using a database, audit records generated by all components in all Oracle Fusion Middleware 11g instances in the domain are stored in the same store. You must use an audit data store to utilize Oracle Business Intelligence Publisher reports.

You can move from file-based storage to an audit data store. This requires a specific configuration procedure. See Section 13.2.3, "Configure a Database Audit Data Store for Java Components" for details.

Advantages of Using a Database Store

Having the audit records in the bus-stop files has some practical limitations:

  • you cannot view domain-level audit data

  • reports cannot be run on Oracle BI Publisher

Thus, there are certain advantages to using a database audit data store:

  • You can use Oracle Business Intelligence Publisher for reporting.

  • The database store centralizes records from all components in the domain, whereas the bus-stop stores audit records on a per-instance basis.

  • performance may be improved compared to file-based storage

For these reasons, Oracle recommends that customers switch to a database store for enhanced auditing capabilities.

12.3.5 Analytics

With Oracle Fusion Middleware 11g, you can utilize Oracle Business Intelligence as a full-featured tool for structured reporting.

A large number of pre-defined reports are available, such as:

  • Users created/deleted

  • User transactions

  • Authentication and authorization failures

  • Policy violations

With Oracle Business Intelligence:

  • You can select records based on criteria like username, date-time range, and so on.

    Note that Oracle Business Intelligence works with the database audit store only, and is not usable with bus-stop files.

BI Publisher page
Description of the illustration cafintro1.gif

The pre-defined audit report types available with Oracle Business Intelligence include:

  • errors and exceptions

  • operational

  • user activity

  • authentication and authorization history

  • transaction history

For further details, see Section C.2, "Pre-built Audit Reports." You can also use the audit schema details to create custom audit reports as needed.