Oracle® Audit Vault Administrator's Guide Release 10.2.3.2 Part Number E14459-11 |
|
|
PDF · Mobi · ePub |
This chapter contains:
By the time you begin to use this guide, you will have installed the Oracle Audit Vault Server and the Oracle Audit Vault collection agent, to prepare for the collection of audit data from your databases (called source databases, or audit data sources). 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 usage 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.10 describes steps to follow for archiving and purging the Oracle Database audit trail.
Oracle Database SQL Reference describes data dictionary views that you can query to ensure that your configuration settings are correct. These views are as follows:
DBA_AUDIT_MGMT_CONFIG_PARAMS
DBA_AUDIT_MGMT_LAST_ARCH_TS
DBA_AUDIT_MGMT_CLEANUP_JOBS
DBA_AUDIT_MGMT_CLEAN_EVENTS
Oracle Database PL/SQL Packages and Types Reference describes the DBMS_AUDIT_MGMT
package, which contains the procedures and functions that 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 |
For the OSAUD and DBAUD collector types: Releases 9.2.x, 10.1.x, 10.2.x, and 11.x For the REDO collector type: Enterprise Edition Releases 9.2.0.8, 10.2.0.3, 10.2.0.4 and later, 11.1.0.6 and later, and 11.2 for the REDO collector type |
Microsoft SQL Server |
SQL Server 2000 and SQL Server 2005 on Windows 2000 Server and Windows 2003 Server platforms. SQL Server 2008. Only the Event Log, C2 and server-side trace audit trails are supported. |
Sybase Adaptive Server Enterprise (ASE) |
ASE 12.5.4 through ASE 15.0 on platforms based on Linux and UNIX, and on Microsoft Windows platforms |
IBM DB2 |
IBM DB2 Version 8.2 through 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 contains an Oracle database, and makes it available to reporting tools through a data warehouse.
This section contains:
The Audit Vault Server consists of:
Audit data store (a repository containing the audit data that is collected by the Audit Vault collectors)
Oracle Audit Vault Console
The following services:
Audit data collection and storage management
Alert management
Collector management and monitoring
Report management
User entitlement management reports
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.
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 (Release 10.2.0.4) to consolidate and manage audit trail records. It has the following components:
|
Table 1-3 describes the ports that the Audit Vault Server uses. To find the port numbers that were used when you installed Oracle Audit Vault, check the portlist.ini
file, which is in the $ORACLE_HOME/install
directory. Be aware that if you change the port numbers later on, the portlist.ini
file does not reflect the changes. If you need to change the port numbers, see Section 4.9.
Table 1-3 Oracle Audit Vault Server Ports
Component | Default Port NumberFoot 1 | Required to be Open | Finding the Current Port Number |
---|---|---|---|
SQL*Net listener |
1521 |
Yes |
At a command line, enter the following command: lsnrctl status |
Enterprise Manager Database Control HTTP (OC4J) |
1158, 5500 |
Yes, if you want to use Database Control with the Audit Vault Console |
At a command line, enter the following command: emctl status dbconsole |
Oracle Audit Vault Console HTTP |
5700 |
Yes |
At a command line, enter the following command: avctl show_av_status |
OC4J RMI |
5522 |
No |
Search for
|
OC4J JMS |
5542 |
No |
Search for
|
Oracle Audit Vault Reports HTTP |
5707 |
Yes |
In SQL*Plus, run the following query: SELECT DBMS_XDB.GETHTTPPORT FROM DUAL; |
Footnote 1 The default port number can vary, depending on your installation. When you install Oracle Audit Vault, Oracle Universal Installer uses a range of port numbers. If another process is using the first default port number it finds, then it checks for the next free port number.
Oracle Database Vault is included in the Audit Vault Server. Database Vault protects the Audit Vault Server data, including restricting the audited data from administrative access. By default, Database Vault is enabled.
For more information about how Oracle Database Vault is integrated with Oracle Audit Vault, see Section 5.5.
This section contains:
General Audit Vault Collection Agent and Collector Components
Default Audit Vault Collection Agent and Collector Port Numbers
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, then Oracle Audit Vault retrieves the audit data that had been accumulating since the agent was stopped.
You configure one collection agent for each host and one or more collectors for each individual source database. For example, if a host contains four databases, then you would configure one collection agent for that host and one or more collectors for each of the four databases. The number of collectors that you configure and the collection agent that you use to manage them depends on the source database type and the audit trails that you want to collect from it.
The collector that you configure for each source database is based on the type of audit trail the source database is configured to use. For example, if an Oracle source database is configured to write the audit trail to the database audit trail, then it uses the DBAUD collector.
You can create the collection agent on one computer and manage multiple collection agents from there. For example, suppose you have 25 source databases on 25 servers. You must configure a collector for each of these source databases, but you do not need to configure a collection agent of each of the 25 servers. Instead, just create one collection agent to manage the 25 collectors. Be aware, however, that for Oracle databases, you cannot use a remote collection agent to collect audit data from users who have logged in with the SYSDBA
or SYSOPER
privilege.
Table 1-4 describes the components of the collection agent.
Table 1-4 Oracle Audit Vault Collection Agent Components
Component | Description |
---|---|
OC4J |
Oracle container for Web applications. It contains the Audit Vault Collector Manager, which receives management commands from the Audit Vault Server to start and stop collectors, collect and return metrics, and so on. |
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-5 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-5 describes the types of collectors and their corresponding audit trail types.
Table 1-5 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 |
|
Oracle Database |
REDO |
Collects audit data 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 audit data from C2 audit logs, server-side trace logs, and Windows Event Logs |
Sybase ASE |
SYBDB |
Collects audit data from system audit tables ( |
IBM DB2 |
DB2DB |
Collects audit data from ASCII text files extracted from the binary audit log ( |
Table 1-6 describes the default port numbers that the Audit Vault agent uses. To find the port numbers that were used when you installed Oracle Audit Vault, check the portlist.ini
file, which is in the $ORACLE_HOME/install
directory. Be aware that if you change the port numbers later on, the portlist.ini
file does not reflect the changes. If you need to change the port numbers, see Section 4.9.
Table 1-6 Oracle Audit Vault Agent Ports
Component | Default Port NumberFoot 1 | Required to be Open | Finding the Current Port Number |
---|---|---|---|
OC4J RMI |
3101 |
Yes |
Search for
|
OC4J JMS |
3201 |
No |
Search for
|
Agent HTTP |
7010 |
Yes |
Search for
|
Footnote 1 The default port number can vary, depending on your installation. When you install Oracle Audit Vault, Oracle Universal Installer uses a range of port numbers. If another process is using the first default port number it finds, then it checks for the next free port number.
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 for the Oracle Audit Vault components 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 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, as well as send e-mail notifications and trouble ticket alerts.
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.
The details of the process flow for the Audit Vault components 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.
Table 1-7 describes the various Oracle Audit Vault administrator roles and the tasks permitted for each role. See also Table 5-2 for a listing of the roles and privileges that are granted to these administrator roles.
Table 1-7 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 In a default Oracle Audit Vault installation, this account name is based on the default Oracle Audit Vault |
|
During Audit Vault Server installation |
Database Vault owner |
Manages Oracle Database Vault roles and configuration. In a default Oracle Audit Vault installation, this account name is based on the default Oracle Audit Vault |
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. The agent for the OSAUD collector must reside on the same server as the source database. Table 1-8 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. The agent for the DBAUD collector must reside on a computer in which SQL*Net can communicate with the source database. Table 1-9 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. The agent for the REDO collector must reside on a computer in which SQL*Net can communicate with the source database. On Oracle RAC installations, the REDO collector can reside on just one database instance, because REDO logs are usually stored in a shared location. Table 1-10 shows more information about redo logs.
To find the names and source database locations of existing agents, log in to Audit Vault Console, click the Configuration tab, and then click Agent to display the Agent page. This page lists the agent, host (source database), port, and user.
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-8 lists the Oracle Database operating system audit settings that use the OSAUD collector.
Table 1-8 Oracle Database Operating System Audit Settings for the OSAUD Collector
Audit Trail | Audit Trail Setting | Comments |
---|---|---|
Linux and UNIX-based platforms ( |
For standard audit records: The For fine-grained audit records: Not applicable. |
None |
Linux and UNIX-based platforms ( |
For standard audit records: The For fine-grained audit records: The |
|
Linux and UNIX-based platforms (syslog) |
For standard audit records: The For fine-grained audit records: Not applicable |
More secure than audit records stored in operating system audit trail. Note: You cannot collect from compressed syslog files |
Windows platform Windows Event Log |
For standard audit records: The For fine-grained audit records: Not applicable |
None |
Windows platform Operating system XML files ( |
For standard audit records: The For fine-grained audit records: The |
|
Table 1-9 lists the Oracle Database database audit trail settings, which must use the DBAUD collector.
Table 1-9 Oracle Database Audit Trail Settings for the DBAUD Collector
Audit Trail | Audit Trail Setting | Audited Operations | Comments |
---|---|---|---|
|
For standard audit records: The For fine-grained audit records: Not applicable |
|
|
|
For standard audit records: Not applicable For fine-grained audit records: The |
Very specific user-defined audited conditions, such as the time a user modified a table column |
None |
|
Not applicable. The Oracle Database Vault audit trail collects data even if Oracle Database auditing is disabled. |
Oracle Database Vault audit activity specified by audit options on realms, command rules, and so on |
None |
Table 1-10 shows the redo log audit trail setting that uses the REDO collector.
Table 1-10 Oracle Database Redo Log Setting for the REDO Collector
Audit Trail | Audit Trail Setting | Audited Operations | Comments |
---|---|---|---|
Redo logs |
Audit Vault capture rule (see Oracle Audit Vault Auditor's Guide |
DML, DDL, before and after values |
Tracks before and after changes to sensitive data columns. |
To plan the Microsoft SQL Server source database instance configuration:
Ensure that auditing has been enabled in the SQL Server source database instance.
See the Microsoft SQL Server product documentation for more information.
Ensure that the agent for the MSSQLDB collector was installed on the same computer as the Microsoft SQL Server source database. To find the names and source database locations of existing agents, log in to Audit Vault Console, click the Configuration tab, and then click Agent to display the Agent page. This page lists the agent, host (source database), port, and user.
Understand the audit trail settings used for SQL Server databases.
Table 1-11 lists the SQL Server audit trail settings.
Configure the MSSQLDB collector to collect audit data from the SQL Server database, as described in Section 2.4.
Table 1-11 describes the SQL Server audit trail.
Table 1-11 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-12 shows the Sybase ASE audit trail setting information.
Ensure that the agent for the SYBDB collector was installed on a computer in which SQL*Net can communicate with the source database. To find the names and source database locations of existing agents, log in to Audit Vault Console, click the Configuration tab, and then click Agent to display the Agent page. This page lists the agent, host (source database), port, and user.
Configure the SYBDB collector to collect audit data from the Sybase ASE database, as described in Section 2.5.
Table 1-12 describes the Sybase ASE audit trail.
Table 1-12 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-13 shows the IBM DB2 audit trail setting information.
Ensure that the agent for the DB2DB collector was installed on the same computer as the IBM DB2 source database. To find the names and source database locations of existing agents, log in to Audit Vault Console, click the Management tab, and then click Collectors to display the Collectors page.
Configure the DB2DB collector to collect audit data from the DB2 database, as described in Section 2.6.
Table 1-13 describes the DB2DB audit trail.
Table 1-13 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 times that 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 |