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:
This section contains these topics:
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 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.
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.
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.
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.
Oracle Fusion Middleware Audit Framework is a new service in11g Release 1 (11.1.1), 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.
JavaEE applications - The objective is to provide a framework for JavaEE applications, starting with Oracle's own components. JavaEE applications will be able to create application-specific audit events.
In 11g Release 1 (11.1.1), the audit framework is only available for Oracle's own applications.
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.
Key features of the Oracle Fusion Middleware Audit Framework include:
A uniform system for administering audits across a range of Java components, system components, and applications
support for Oracle Platform Security Services auditing for non-audit-aware applications
the ability to search for audit data at any application level
Capturing authentication history/failures, authorization history, user management, and other common transaction data
Flexible audit policies
pre-seeded audit policies, capturing customers' most common audit events, are available for ease of configuration
tree-like policy structure simplifies policy setup
Prebuilt compliance reporting features
Oracle Fusion Middleware Audit Framework provides out-of-the-box analytical reporting capabilities within Oracle BI Publisher; data can be analyzed on multiple dimensions (Execution Context ID (ECID), user ID, and so on) across multiple components. These reports can also be customized according to your preferences.
Reports are based on centralized audit data.
Customers can customize the reports or write their own based on the published audit schema.
See Chapter 13, "Using Audit Analysis and Reporting" for details.
Audit record storage
Data store (database) and files (bus-stop) are available. Maintaining a common location for all audit records simplifies maintenance.
Using a data store lets you generate reports with Oracle Business Intelligence Publisher.
Common audit record format
Highlights of the audit trail include:
baseline attributes like outcome (status), event date-time, user, and so on
event-specific attributes like authentication method, source IP address, target user, resource, and so on
contextual attributes like the execution context ID (ECID), session ID, and others
Common mechanism for audit policy configuration
Oracle Fusion Middleware Audit Framework offers a unified method for configuring audit policies in the domain.
Leverages the Oracle Fusion Middleware 11g infrastructure
is usable across Oracle Fusion Middleware 11g components and services such as Oracle Web Services Manager, Oracle Internet Directory, Oracle Virtual Directory, and Oracle Directory Integration and Provisioning
integrates with Oracle Enterprise Manager Fusion Middleware Control for UI-based configuration and management
wlst for command-line, script-based configuration
integrates with Oracle Platform Security Services to provide multiple benefits
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.
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 store. In the event that no audit 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 store is in place, the bus-stop acts as an intermediary between the component and the audit store. The local files are periodically uploaded to the data store based on a configurable time interval.
A key advantage of the audit 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.
As its name implies, the audit loader loads audit data from the audit bus-stop into the audit 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.
The audit 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 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.
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 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:
Execution Context Identifier (ECID)
You can also use Oracle Business Intelligence Publisher to create your own audit reports.
The process can be illustrated by looking at the actions taken in the framework when an event (say, login) occurs at a component like Oracle HTTP Server or Oracle Virtual Directory within an application server instance:
Note:The architecture shown in Figure 11-1 contains a data store; if your site did not configure a data store for auditing, the audit records reside in the bus-stop files.
Oracle Fusion Middleware Audit Framework is activated for a component when the component starts up.
The component calls an audit function to audit the event.
The framework checks if events of this type, status, and with certain attributes need to be audited.
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.
The event is stored on a local file in an intermediate location known as the bus-stop; each component has its own bus-stop.
The next component in the flow is the Audit Loader, a which is 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.
If a database is configured for an audit store, the audit loader pulls the events from the bus-stops and moves the data to the audit store.
Reports can also be generated from the audit data using Oracle BI Publisher. A set of pre-defined reports are available. (See Chapter 13, "Using Audit Analysis and Reporting".)
It is important to note that an application does not stop execution if it is unable to record an audit event for any reason.
See Also:Oracle Fusion Middleware Administrator's Guide for details about these concepts.
This section introduces key aspects of the Oracle Fusion Middleware Audit Framework.
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 be integrate d with the Oracle Fusion Middleware Audit Framework through configuration with the
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:
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)
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".
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 JavaEE security.
For more information about OPSS, see Section 2.1, "What is Oracle Platform Security Services?".
As shown in Figure 11-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 JavaEE 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.
See Also:"Audit Flow" in Section 11.3.1, "Audit Architecture".
permanent storage in a database; this is known as the audit 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 store to utilize Oracle Business Intelligence Publisher reports.
You can move from file-based storage to an audit store. This requires a specific configuration procedure. See Section 12.2.3, "Configure a Database Audit Store for Java Components" for details.
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 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.
With Oracle Fusion Middleware 11g, you can utilize Oracle BI Publisher as a full-featured tool for structured reporting.
A large number of pre-defined reports are available, such as:
Authentication and authorization failures
With Oracle BI Publisher
You can select records based on criteria like username, date-time range, and so on.
Note that Oracle BI Publisher works with the database audit store only, and is not usable with bus-stop files.
The pre-defined audit report types available with Oracle BI Publisher include:
errors and exceptions
authentication and authorization history
See Also:Section C.2, "Pre-built Audit Reports"
You can also use the audit schema details to create custom audit reports as needed.