Oracle® Audit Vault Administrator's Guide Release 10.2.3.1 Part Number E13841-02 |
|
|
View PDF |
This chapter contains:
By the time you begin to use this guide, you will have installed Oracle Audit Vault, and the databases (called source databases, or audit data sources) from which you want to extract audit data are ready to audit. This guide explains how to configure the source databases so that Oracle Audit Vault can collect their audit data. After you have completed this configuration, then auditors can generate and customize reports that describe this audit data.
An Oracle Audit Vault administrator is responsible for the following tasks:
Ensuring that the source databases have auditing enabled
Understanding the type of auditing that each source database uses
Selecting the correct Oracle Audit Vault component, called a collector, to connect to the source database, based on the type of auditing that database uses
Configuring this collector to connect Oracle Audit Vault to the source database
Configuring and scheduling Audit Vault Server processes
Ensuring that the collectors are collecting audit data from the source database
Managing the day-to-day activities of Oracle Audit Vault, such as disk space and backup and recovery operations
Managing security for Oracle Audit Vault
Monitoring Oracle Audit Vault to ensure that it is consistently collecting audit data
Oracle Database administrators are responsible for running the Oracle Database audit trail cleanup procedures on the source database, which purge audit trail records from the Oracle source database after these records are archived.
To administer Oracle Audit Vault, follow these steps:
Step 2: Plan the Oracle Audit Vault Source Database and Collector Configuration
Step 4: Monitor and Maintain the Audit Record Collection Process
In this chapter, Section 1.3 describes the main components of Oracle Audit Vault, and explains how these components work together. Section 1.4 describes the various tools that you use to administer Oracle Audit Vault. Section 1.5 describes the predefined roles that are created during the Oracle Audit Vault installation process. Understanding how these pieces fit together provides the foundation you need to administer Oracle Audit Vault.
Section 1.6 provides guidelines for selecting the correct Oracle Audit Vault collector (that is, the module that collects audit data from your source databases) based on the type of database from which you are collecting audit data. You must understand the audit settings and audit trail used in your source databases before you can select the correct collector.
After you have decided which collectors to use for your source database, you are ready to configure them. Chapter 2 explains how to register (configure) collectors for the source databases.
To accomplish the configuration, you can use the command-line utilities described in Section 1.4.
After you complete this step, Oracle Audit Vault is collecting audit data, which the auditors on your site can access by using the reporting tools described in Oracle Audit Vault Auditor's Guide.
After you have completed the configuration, you should monitor the audit collection activities to ensure that they are working properly. These tasks include the following:
Perform common management tasks. For example, you may need to check whether the collectors are running, fine-tune how data is collected in the Oracle Audit Vault data warehouse, or modify the attributes of a source database. See the following chapters:
Chapter 3 describes common management tasks.
Chapter 4 provides advice on managing an Oracle Audit Vault installation on an Oracle Real Application Clusters environment, and what to do if you are concerned that your audit data will fill the default tablespace and disk space.
Chapter 5 describes common security tasks and how Oracle Advanced Security and Oracle Database Vault enhance the security of an Oracle Audit Vault system.
Chapter 12 describes optimum initialization parameter settings for the REDO collector.
For Oracle Database administrators, periodically archive and purge the Oracle Database audit trail for the Oracle source database. See the following:
Section 4.8 describes steps to follow for archiving and purging the Oracle Database audit trail.
Chapter 13 describes data dictionary views that you can query to ensure that your configuration settings are correct.
Chapter 14 describes the DBMS_AUDIT_MGMT
package, which contains the calls you use to archive and purge the Oracle Database audit trail.
Troubleshoot problems that arise. See the following:
Appendix A describes how to troubleshoot the Oracle Audit Vault system.
Appendix B explains how to resolve Oracle Audit Vault-specific error messages.
A source database is a database from which Oracle Audit Vault collects audit data. Oracle Audit Vault can collect this audit data from the internal audit trail tables and operating system audit trail files of a source database.
Table 1-1 lists the supported source database products.
Table 1-1 Supported Source Database Products
Database Product | Supported Versions |
---|---|
Oracle Database |
Releases 9.2.x, 10.1.x, 10.2.x, and 11.x for the OSAUD and DBAUD collector types Enterprise Edition Releases 9.2.0.8, 10.2.0.3, 10.2.0.4, 11.1.0.6, and 11.1.0.7 and later for the REDO collector type |
Microsoft SQL Server |
SQL Server 2000 and SQL Server 2005 on Windows 2000 Server and Windows 2003 Server (32-bit) platforms |
Sybase Adaptive Server Enterprise (ASE) |
ASE 12.5.4 and ASE 15.0.2 on platforms based on Linux and UNIX, and on Microsoft Windows platforms |
IBM DB2 |
IBM DB2 Version 8.2 and Version 9.5 on platforms based on Linux and UNIX, and on Microsoft Windows platforms. If you are using Version 8.2, ensure that you have installed Fixpack 16. |
The Oracle Audit Vault Server contains the tools necessary to configure Oracle Audit Vault to collect audit data from your source databases. The Audit Vault Server also stores in an Oracle database, and makes it available to reporting tools through a data warehouse.
The Audit Vault Server consists of:
Audit Data Store
Oracle Audit Vault Console
The following services:
Audit data collection and storage management
Alert management
Collector management and monitoring
Report management
Audit settings management to establish your policy management
Published data warehouse that can be used with reporting tools such as Oracle Business Intelligence Publisher to create customized reports
Configuration services help define information about the source databases that connect to Oracle Audit Vault. Oracle Audit Vault stores information (metadata) about the sources of audit data and policy information (database audit settings).
Table 1-2 describes the Oracle Audit Vault Server components. See also Figure 1-2 to understand how these components work together.
Table 1-2 Oracle Audit Vault Server Components
Components | Description |
---|---|
Oracle Container for Java (OC4J) |
Oracle Database container for Web applications. It hosts the following components:
|
Database Client |
Infrastructure to communicate to the audit repository, consisting of:
|
Configuration and Management Tools |
Utilities used to configure and manage Oracle Audit Vault, which are described in detail in Section 1.4. They let you define and configure information about what source databases are known to Oracle Audit Vault. |
Logs |
Informational and error messages for Oracle Audit Vault. See Section A.1 for more information. |
Audit repository |
Oracle database to consolidate and manage audit trail records, consisting of:
|
A collector retrieves the audit trail data from a source database and sends it to the Audit Vault Server. The collection agent manages the collectors. The collectors send both valid and invalid audit records, get configuration information, and send error records using Oracle Call Interface (OCI) and JDBC password-based authentication. If the collection agent is stopped, then the source database will still create an audit trail (assuming auditing is enabled). The next time you restart the collection agent, Oracle Audit Vault retrieves the audit data that had been accumulating since the agent was stopped.
Table 1-3 lists the components of the collection agent. To understand how the collection agent fits in with the Oracle Audit Vault process flow, see Figure 1-2.
Table 1-3 Oracle Audit Vault Collection Agent Components
Component | Description |
---|---|
OC4J |
Oracle container for Web applications. It hosts the following components:
|
Database Server |
Infrastructure to communicate to the audit repository, consisting of:
|
Configuration and Management Tools |
Utilities used to configure and manage Oracle Audit Vault. These are the |
Logs |
Informational and error messages for Oracle Audit Vault (see Section A.1) |
Collectors |
Table 1-4 shows the type of collectors deployed by the Oracle Audit Vault collection agents and the audit trail from which audit records are extracted and collected. |
Table 1-4 lists the types of collectors.
Table 1-4 Oracle Audit Vault Collector Types and Audit Trails
Audit Source | Collector Type | Audit Trail |
---|---|---|
Oracle Database |
DBAUD |
Collects from the following audit trails:
|
Oracle Database |
OSAUD |
Collects from the following audit trails:
|
Oracle Database |
REDO |
Collects from logical change records (LCRs) from the REDO logs. If you plan to use the REDO collector, you can define the data to audit by creating capture rules for the tables from which the REDO collector will capture audit information. See Oracle Audit Vault Auditor's Guide for more information. |
Microsoft SQL Server |
MSSQLDB |
Collects from C2 audit logs, server-side trace logs, and Windows event logs |
Sybase ASE |
SYBDB |
Collects from system audit tables ( |
IBM DB2 |
DB2DB |
Collects from ASCII text files extracted from the binary audit log ( |
Figure 1-1 provides a high-level overview of how the Oracle Audit Vault components work together.
Figure 1-1 Overview of the Oracle Audit Vault Components
The process flow works as follows:
The source databases, Oracle Database, SQL Server, Sybase ASE, and IBM DB2, have all been configured to use their respective collectors:
Oracle Database uses the REDO, DBAUD, and OSAUD collectors.
SQL Server uses the MSSQLDB collector.
Sybase ASE uses the SYBDB collector.
IBM DB2 uses the DB2DB collector.
As Figure 1-1 shows, you can configure multiple databases from different database product families using the same Audit Vault collection agent to connect to the same Audit Vault Server.
The collectors listed in Step 1 retrieve the audit data from their source databases and send this data to the Audit Vault Server.
The Audit Vault Server collects and stores this data it in the database, and then makes it available in the warehouse.
The data warehouse organizes this data into a set of internal dimension tables. The Audit Vault Server stores other information as well, for both the auditor and the administrator.
Once the audit data is in the data warehouse dimension tables, an auditor can retrieve this data to generate and customize reports. Any settings that you, the administrator, create, such as security settings, are contained in this server. The Audit Vault Server stores all the tools that you need to configure the Audit Vault components and source databases.
Figure 1-2 shows a detailed view of the Oracle Audit Vault architecture.
Figure 1-2 Detailed View of the Oracle Audit Vault Components
The process flow works as follows:
The OC4J components in the Audit Vault Server and Audit Vault collection agent connect using HTTP or HTTPS.
The OC4J is a container for Web applications that consists of the Audit Vault Console, the Oracle Enterprise Manager Database Control console, the Audit Vault internal tools (management framework), and the audit policy system used to retrieve and make available the audit settings. The HTTP (or HTTPS) connection is used for starting and stopping agents, managing metrics, and running commands related to policy retrieval.
The Audit Vault Server contains its own database server, and an Oracle wallet containing the administrator's credentials. It also stores configuration information from utility settings (such as AVCA
, AVCTL
, and the command-line utilities used for the four database products) and log files that store operational information, such as broken database connections and missing files.
In addition to its HTTP or HTTPS connection, each collector in the Oracle Audit Vault collection agent maintains an OCI and a JDBC connection to the Audit Vault Server using the credentials from the client wallet.
The collectors retrieve audit records from the source databases and send this data to the audit repository, which contains the Audit Vault data warehouse.
The data warehouse organizes this data into a set of dimension tables. Oracle Audit Vault Auditor's Guide describes the data warehouse dimension tables in detail. In addition to the data warehouse, the audit repository contains auditor-created alert information.
Oracle Audit Vault receives data from the Oracle Database redo logs using a database link. The Oracle Database redo logs bypass the collectors.
You can use the following tools to administer Oracle Audit Vault:
Audit Vault Console. This graphical user interface provides most of the functionality that you need to administer Oracle Audit Vault.
Audit Vault Configuration Assistant (AVCA) command-line utility. Use AVCA
to perform operations such as adding, deploying, and dropping agents, or managing wallets. See Chapter 6 for more information.
Audit Vault Control (AVCTL) command-line utility. Use AVCTL
to load, refresh, start, and stop Oracle Audit Vault collection agents and collectors. You also can load and purge data in the Oracle Audit Vault data warehouse with this utility. See Chapter 7 for more information.
Audit Vault Oracle Database (AVORCLDB) command-line utility. Use AVORCLDB
to configure Oracle Database source databases with Oracle Audit Vault. See Chapter 8 for more information.
Microsoft SQL Server Database (AVMSSQLDB) command-line utility. Use AVMSSQLDB
to configure SQL Server source databases with Oracle Audit Vault. See Chapter 9 for more information.
Sybase ASE Database (AVSYBDB) command-line utility. Use AVSYBDB
to configure Sybase ASE source databases with Oracle Audit Vault. See Chapter 10 for more information.
IBM DB2 Database (AVDB2DB) command-line utility. Use AVDB2DB
to configure IBM DB2 source databases with Oracle Audit Vault. See Chapter 11 for more information.
A default Oracle Audit Vault installation provides a set of administrative roles that you can use to manage Oracle Audit Vault. These roles provide separation-of-duty tasks.
Table 1-5 describes the various Oracle Audit Vault administrator roles and the tasks permitted for each role. See also Table 5-1 for a listing of the roles and privileges that are granted to these administrator roles.
Table 1-5 Oracle Audit Vault Administrator Roles and Their Assigned Tasks
Role | When Is the Role Granted? | Role Is Granted to Whom? | Description |
---|---|---|---|
|
During Server installation |
Audit Vault administrator |
Accesses Oracle Audit Vault services to administer, configure, and manage a running Oracle Audit Vault system. A user who is granted this role configures and manages metadata for audit source databases, collection agents, collectors, the configuration of the source database with the collection agent, and the data warehouse. The installation process creates and grants a user account with this role. Only the user granted the You can consider the |
|
During Server installation |
Audit Vault auditor |
Accesses Oracle Audit Vault reporting and analysis services to monitor components, detect security risks, create and evaluate alert scenarios, create detail and summary reports of events across systems, and manage the reports. A user who is granted this role manages central audit settings and alerts. This user also uses the data warehouse services to further analyze the audit data to look for trends, intrusions, anomalies, and other items of interest. The installation process creates and grants a user account with this role. However, during installation, you optionally can bypass creating this user account. In that case, the roles and privileges normally granted to |
|
During collection agent registration |
Collection agent software component |
Manages collection agents and collectors by starting and stopping them. Oracle Audit Vault creates this role for internal use only. |
|
During Audit Vault Server installation |
Database Vault account manager |
Manages database user accounts. Be aware that the inclusion of Oracle Database Vault in the Audit Vault Server prevents users |
|
During Audit Vault Server installation |
Database Vault owner |
This section contains:
About Planning the Source Database and Collector Configuration
Planning the Oracle Source Database and Collector Configuration
Planning the Microsoft SQL Server Source Database and Collector Configuration
Planning the Sybase ASE Source Database and Collector Configuration
Planning the IBM DB2 Source Database and Collector Configuration
This section provides guidelines for selecting the correct Oracle Audit Vault collector for the source databases from which you want to extract audit data. In brief, for Oracle Database, the type of collector that you select depends on the type of auditing that you have enabled in the source database. The Microsoft SQL Server, Sybase ASE, and IBM DB2 databases each use one collector specific to each of these database products.
After you understand which collector to choose, you are ready to register the source database and collector with Oracle Audit Vault.
To plan the Oracle Database source database and collector configuration:
Ensure that auditing has been enabled, and find the type of auditing that the Oracle source database uses.
See Oracle Audit Vault Auditor's Guide for more information about the Oracle Database requirements.
Based on the audit trail setting, determine which collector to use.
The type of auditing that has been enabled determines the collector you will choose. The types of collectors available are as follows:
OSAUD collector. Use this collector if the audit trail is being written to operating system files. Table 1-6 lists the operating system audit trail settings that use the OSAUD collector.
DBAUD collector. Use this collector if the audit trail is being written to the database audit trail. Table 1-7 lists of the database audit trail settings that use the DBAUD collector.
REDO collector. Use this collector if the database is collecting audit data from the redo logs. Table 1-8 shows more information about redo logs.
Register the Oracle source database and the appropriate collector with Oracle Audit Vault, as described in Section 2.3.
The OSAUD operating system audit settings capture the following activities:
SELECT
statements
Data definition language (DDL) and data manipulation language (DML) statements
Succeeded and failed actions
SYS
operations (Set the AUDIT_SYS_OPERATIONS
initialization parameter to TRUE
to perform administrator auditing. SYS auditing collects SQL text information.)
Table 1-6 lists the Oracle Database operating system audit settings that use the OSAUD collector.
Table 1-6 Oracle Database Operating System Audit Settings for the OSAUD Collector
Audit Trail | Audit Trail Settings | Comments |
---|---|---|
Linux and UNIX-based platforms ( |
|
None |
Linux and UNIX-based platforms ( |
|
|
Linux and UNIX-based platforms (syslog) |
|
More secure than audit records stored in operating system audit trail |
Windows platform Windows event log |
|
None |
Windows platform Operating system XML files ( |
|
|
Table 1-7 lists the Oracle Database database audit trail settings, which must use the DBAUD collector.
Table 1-7 Oracle Database Audit Trail Settings for the DBAUD Collector
Audit Trail | Audit Trail Setting | Audited Operations | Comments |
---|---|---|---|
|
|
|
|
|
Not applicable. To enable fine-grained auditing, use the |
Very specific user-defined audited conditions, such as the time a user modified a table column |
None |
|
Not applicable |
Oracle Database Vault audit activity specified by audit options on realms, command rules, and so on |
None |
Table 1-8 shows the redo log audit trail setting that uses the REDO collector.
To plan the Microsoft SQL Server source database configuration:
Ensure that auditing has been enabled in the SQL Server source database.
See the Microsoft SQL Server product documentation for more information.
Understand the audit trail settings used for SQL Server databases.
Table 1-9 lists the SQL Server audit trail settings.
Configure the MDDSQLDB collector to collect audit data from the SQL Server database, as described in Section 2.4.
Table 1-9 describes the SQL Server audit trail.
Table 1-9 Microsoft SQL Server Source Database Audit Settings for the MSSQLDB Collector
Audit Trail - Audit Logs | Audit Trail Settings | Audited Operations | Comments |
---|---|---|---|
C2 audit logs |
Configure SQL Server security properties through SQL Server Enterprise Manager. |
Auditing compliant with C2 certification Records both failed and successful attempts to access statements and objects Uses all or nothing approach to auditing |
Records all actions |
Server-side trace logs |
Run stored procedures to start and stop tracing, to configure and filter traces. |
Records fine-grained security-related activity Can choose exactly which events to audit and what information about each event to record Trace configuration information is not persistent. It is deleted when you restart SQL Server. |
Records specific activity Traces can be configured to record only specific activity. Results can be filtered to record only activity that matches a certain pattern, such as a SQL verb (for example, |
Windows event log |
Running by default. |
Provides a standard, centralized way for applications (and the operating system) to record important software and hardware events. |
None |
To plan the Sybase ASE source database configuration:
Ensure that auditing has been enabled in the Sybase ASE source database.
See the Sybase ASE product documentation for more information.
Understand the audit trail setting information used for Sybase ASE databases.
Table 1-10 shows the Sybase ASE audit trail setting information.
Configure the SYBDB collector to collect audit data from the SQL Server database, as described in Section 2.5.
Table 1-10 describes the Sybase ASE audit trail.
Table 1-10 Sybase ASE Database Audit Setting for the SYBDB Collector
Audit Trail - Audit Logs | Audit Trail Setting | Audited Operation | Comments |
---|---|---|---|
System audit table logs |
Run system procedures to set global audit options, and then to enable, disable, or restart auditing. |
Records standard to fine-grained audit and security-related activity Can choose exactly what to audit Can choose to audit everything or just very specific events |
Implement your best practices for Sybase ASE database auditing |
To plan the IBM DB2 source database configuration:
Ensure that auditing has been enabled in the IBM DB2 source database.
See the IBM DB2 product documentation for more information.
Understand the audit trail information used for IBM DB2 databases.
Table 1-11 shows the IBM DB2 audit trail setting information.
Configure the DB2DB collector to collect audit data from the DB2 database, as described in Section 2.6.
Table 1-11 describes the IBM DB2 audit trail.
Table 1-11 IBM DB2 Database Audit Setting for the DB2DB Collector
Audit Trail - Audit Logs | Audit Trail Setting | Audited Operation | Comments |
---|---|---|---|
ASCII text files |
Run the |
Audit (AUDIT). Changes to audit records or when the audit log is accessed Authorization Checking (CHECKING). Authorization checking during attempts to access or manipulate DB2 database objects or functions Security Maintenance (SECMAINT). Grants or revokes to object or database privileges or to the Object Maintenance (OBJMAINT). Creating and dropping data objects System Administration (SYSADMIN). Operations requiring User Validation (VALIDATE). Authentication of users or retrieval of system security information Operation Context (CONTEXT). Database operation context performed. Helps when interpreting the audit log file. See the IBM DB2 documentation for more information about how the operation context of a DB2 database is audited. In addition to these categories, you can audit successes, failures, or both. |
Implement your best practices for IBM DB2 database auditing |