Configuring and Managing Audit Trail Collection

Learn about configuring and managing audit trail collection.

Prerequisites for Adding Audit Trails in Oracle Audit Vault Server

Complete these prerequisites before adding audit trails in Oracle Audit Vault Server.

• To configure transaction log audit trails for Oracle Database, Microsoft SQL Server, or MySQL install Oracle GoldenGate. See the Transaction Log Audit Data Collection for Oracle Database, Microsoft SQL Server, and MySQL for more information.

• Add the target in the Audit Vault Server. See Registering or Removing Targets in Audit Vault Server.

• Register the host machine. This machine is where the Audit Vault Agent is deployed and the target resides for directory trails. See Registering Hosts and Deploying the Agent.

• If you’re deploying the Audit Vault Agent, deploy and start the Audit Vault Agent on the host machine. See Deploying the Audit Vault Agent on Host Computers.

You can use agentless collection instead of the Audit Vault Agent for Oracle Database table audit trails and Microsoft SQL Server directory audit trails for .sqlaudit and .xel (Extended Events) files. The total number of audit trails configured for agentless collection must not exceed 20. See Adding Audit Trails with Agentless Collection.

• For IBM DB2 targets, ensure that the binary audit file has been converted to ASCII format before starting an audit trail.

• For MySQL targets, run the XML transformation utility. See Running the XML Transformation Utility for MySQL Audit Formats.

Adding Audit Trails with Agentless Collection

You can use agentless collection instead of the Audit Vault Agent for Oracle Database table audit trails and Microsoft SQL Server directory audit trails for .sqlaudit and .xel (Extended Events) files. The total number of audit trails configured for agentless collection must not exceed 20. See Adding Audit Trails with Agentless Collection.

With agentless collection, you use the agentless collection service that comes with the Audit Vault Server instead of deploying the Audit Vault Agent on the target host machines. The agentless collection service is automatically installed when you install the Audit Vault Server.

Note: Agentless collection is supported on both standalone and high availability AVS

Prerequisites

1. Ensure you have the latest available version installed.

2. Ensure that the Audit Vault Server is not paired for high availability. To unpair the Audit Vault server, see Unpair Primary and Standby Audit Vault Servers.

3. Register the Oracle Database or Microsoft SQL Server target. See Registering Targets.

4. Prepare the target. See Preparing Targets for Audit Data Collection.

Agentless Collection Support for Microsoft SQL Server

Ensure that Microsoft SQL Server targets meet the following conditions for agentless collection support:

• Agentless and remote collection are supported for the following versions of Microsoft SQL Server:

  • .sqlaudit audit events: All supported versions of Microsoft SQL Server.

  • .xel audit events: Microsoft SQL Server 2017 and later.

• Agentless and remote collection are not supported in Microsoft SQL Server clustered environments.

• Agentless and remote collection may be slow when there’s a large number of files. In this case, Oracle recommends that you use local, agent-based collection.

• Audit trail cleanup (ATC) is not supported for agentless and remote collection.

  You need to set up the file rollover count properly so that the audit file is purged automatically and doesn’t lose audit data. See the Microsoft SQL Server documentation for more information about the file rollover count.

Procedure

1. Select Targets.

2. Select link for the Oracle Database or Microsoft SQL Server target for which you want to add the audit trail.

3. Under Audit Data Collection, select Add.

4. For Audit Trail Type, select one of the following values:

   • For Oracle Database, select TABLE.

   • For Microsoft SQL Server, select DIRECTORY.

   For details on these audit trail types, see the plug-in reference, see Oracle Database Plug-in for Oracle Database Security Central

5. In the Trail Location field, enter or select the location of the audit trail on the target computer.

   For example:

   • Oracle Database example: UNIFIED_AUDIT_TRAIL

   • Microsoft SQL Server examples: <directory_path>\*.sqlaudit or <directory_path>\*.xel

6. Select Agentless Collection. This option is only visible for Oracle Database TABLE trails and Microsoft SQL Server DIRECTORY trails.

7. Select Save.

   The agent name for the audit trail appears as Agentless Collection on the Audit Trails and Targets pages.

Adding Audit Trails with Agent-Based Collection

To begin collecting audit data with the Audit Vault Agent, configure an audit trail for each target that’s registered on the Audit Vault Server and then start the audit trail collection.

Note: When using the Audit Vault Agent to collect directory trails, the agent must be installed on the same host that contains the directory.

1. Create a new target.

2. Select Targets.

3. Select link for the target for which you want to add the audit trail.

4. Under Audit Data Collection, select Add.

5. For Audit Trail Type, select one of the following trail types:.

   • CUSTOM

   • DIRECTORY

   • EVENT LOG

   • NETWORK

     For monitoring multiple nodes of an Exadata or RAC database using network trail, create a separate target for each node.

   • SYSLOG

     This trail type can collect from syslog or rsyslog files. If both are present, you must provide the exact trail location in the next step if you want to collect audit data from rsyslog files.

     Note: Ensure that records generated by rsyslog have the same time zone information as the Audit Vault Agent that’s running on the collection host.

   • TABLE

   • TRANSACTION LOG

     Note:

     For details on which types of audit trails can be collected for each target type, see Table C-19.

     For complete details on all audit trail types, see Plug-ins That are Shipped with Oracle Database Security Central.

6. In Trail Location, enter the location of the audit trail on the target computer. The trail location depends on the type of target.

   For example, for Oracle Database, the trail location might be unified_audit_trail.

   For supported trail locations, see Audit Trail Locations.

   Note: If you select DIRECTORY or TRANSACTION LOG for Audit Trail Type, then the trail location must be a directory mask.

7. Select Agent-based Collection if it’s visible. If it’s not visible, then agent-based collection is used by default for the audit trail.

8. For Agent Host, select the host computer where the Audit Vault Agent is deployed.

9. Select Save.

   The audit trail should now appear on the Audit Trails. The collection status is stopped (a red circle) initially. The audit trail starts automatically shortly after you add it.

   See Also: About Plug-ins

Stopping, Starting, and Autostart of Audit Trails in Oracle Audit Vault Server

Lean about stopping, starting, and setting up autostart of audit trails in Oracle Audit Vault Server.

An audit trail starts automatically shortly after you add it. To start an audit trail, the Audit Vault Agent must be running on a host computer.

Audit trails that are started will automatically restart if the Audit Vault Agent is restarted, or updated due to an Audit Vault Server update.

An audit trail can go down at times such as when the target goes down temporarily. With Autostart, the system automatically attempts to restart an audit trail if it goes down. Autostart is normally enabled unless you have manually stopped the trail. You can set parameters on when and how many times the system attempts Autostart using the AVCLI utility.

Audit trails are monitored daily. Alerts are generated and email notifications are sent if audit trail is in STOPPED_ERROR state even after 20 retries.

Network trails are monitored hourly. Alerts are generated and email notifications are sent out if network trail is in STOPPED_ERROR state.

To start or stop audit trail collection for a target:

1. Log in to the Oracle Database Security Central console as an administrator.

2. Select Targets. The Targets in the left navigation menu is selected by default.

3. Select the specific target by clicking on the name.

4. Under the Audit Data Collection section, select the targets that have the audit trails that you want to start or stop.

5. Select Stop or Start accordingly.

   Note:

   • You cannot start an audit trail while the Audit Vault Agent is updating.

   • If your environment has a large number of audit files to collect, for example one million or more, then the audit trail may take a few minutes to start.

See Also:

• ALTER SYSTEM SET to set parameters on when and how many times the system attempts Autostart using the AVCLI utility.

• Deploying the Audit Vault Agent on Host Computers

• Updating Audit Vault Agent

• Using Oracle Database Security Central Console

Checking the Status of Trail Collection on the Audit Vault Server

Learn about checking the status trail collection in Audit Vault Server.

1. Log in to the Oracle Database Security Central console as an administrator.

2. Select Targets. The Targets in the left navigation menu is selected by default.

3. Select Audit Trails in the left navigation menu.

   It lists targets that have audit trails configured. Check the Collection Status column. The status can be one of the following:

   • Idle - Trail is up and running, no new audit data to collect. In this state, the trail is waiting for the target to generate new audit data.

   • Starting - Collection process is starting.

   • Collecting - Trail is currently actively collecting audit data.

   • Stopping - Collection process is stopping.

   • Stopped - Trail is currently stopped.

   • Recovering - Trail is recovering after it has been stopped previously. The trail was stopped before updating the checkpoint for the records collected. In the recovery state, the trail reads records starting from the current checkpoint and filter out the duplicate records which were already read. The recovery state can take a while depending on the server load.

   • Unreachable - A heartbeat timeout has occurred, indicating that a heartbeat message has not been received from the trail in the last 30 minutes. This status is temporary unless the trail has crashed. The Audit Vault Server checks the status of the audit trail. It attempts to check the status 20 times (by default) to reach the audit trail before concluding it is Unreachable.

   • Archive data files are required (link) - If you see this link, it means a new audit trail contains expired audit records that must be archived, and that the required archive data files are not available.

   The Trail Autostart Details column indicates whether autostart is enabled for a trail, and whether there have been attempts to restart a failed audit trail (for example, if a target goes down temporarily).

Tip: You can sort and filter the audit trail list.

Note:

• To view audit trails status for a specific agent host, select name of the trail.

• If an audit trail fails to start, then you can get more information by looking at the Error Message column.

See Also: Handling New Audit Trails with Expired Audit Records

Check the Audit Trail Status with SQL*Plus

To check the audit trail status with SQL*Plus, query avsys.audit_trail_view.

For example:

SELECT location, host_name, status FROM audit_trail_view

Returns:

    LOCATION                                                        HOST_NAME            STATUS
--------------------------------------------------------------- -------------------- -----------
unified_audit_trail                                             xxxxxxxx             IDLE
sys.unified_audit_trail_DELETED_2016-06-28 11:56:25.203 +00:00  xxxx                 STOPPED
/var/log/audit/audit.log_DELETED_2016-06-29 08:49:04.446 +00:00 xxxx                 STOPPED
/var/log/audit_DELETED_2016-06-29 08:53:00.906 +00:00           xxxx                 STOPPED
dvsys.audit_trail$                                              xxxx                 IDLE

Note: If the AVSYS account is locked or the password is unknown, see Unlocking and Locking the AVSYS User.

Check the Audit Trail Status with AVCLI

To check the audit trail status with AVCLI, use the LIST TRAIL FOR SECURED TARGET command.

For example:

LIST TRAIL FOR SECURED TARGET <TARGET_NAME>;

Returns:

-----------------------------------------------------------------------------------------------------------------------------------------|
AUDIT_TRAIL_TYPE | HOST | LOCATION | STATUS | REQUEST_STATUS |  AUTO_START_STATUS | AUTOSTART_ATTEMPTS | LAST_START_TIME | ERROR_MESSAGE |
=========================================================================================================================================|
TABLE | xxx.xxx.com | UNIFIED_AUDIT_TRAIL | STARTING | | ENABLED | 3 | 2016-07-28 | 20:06:42.802312 GMT ||
------------------------------------------------------------------------------------------------------------------------------------------

Checking Downtime History of the Trail

Oracle Database Security Central console displays the current status of the trail. The Oracle Database Security Central console maintains record of the trail downtime. It also displays the reason for the downtime. This information is available in the Downtime Report. This report contains downtime information of every trail and a cumulative downtime report of all the trails in the Audit Vault Server. It captures the intervals during which the specific trail may have gone down either due to an error, or if it was manually stopped through the Oracle Database Security Central console, or it had changed status to one of the following:

Status	Description
STOPPED_ERROR	If this status is seen, then the trail has gone down due to an error. In this case there is an additional column Error Message that specifies the reason the trail was stopped.
UNREACHABLE	This status is dynamically calculated and is seen when the trail is unable to connect to the Audit Vault Server for more than 30 minutes.
STOPPED_UNKNOWN	If this status is seen, then the trail downtime data has been purged as the trail is down for more than the specified retention period.
STOPPED	The trail has stopped and is not collecting data.
STARTING	The trail is about to start with collection.
STOPPING	The trail is about to stop collecting data.
COLLECTING	The trail is active and collecting data.
IDLE	The trail is idle and not collecting data.
RECOVERING	The trail is in recovering mode.

Note: Not all the status information is available in the reports.

To capture downtime report for the trail and to view the history of the trail, follow these steps:

1. Log in to the Oracle Database Security Central console as an administrator.

2. Select Targets.

3. Select Audit Trails in the left navigation menu.

4. Select the trails for which the downtime report needs to be generated.

5. Select Downtime . The downtime report for the selected trails is displayed. Use the filter option, download the report, or select back to navigate to the Audit Trails.

The downtime of the Audit Vault Agent, the specific time as to when the Agent went down, the duration for which the data has not been captured, and the reason for the Agent going down is also made available in the reports.

Note:

• This downtime data is available, archived, and purged like any other data managed by Oracle DBSecCentral. By default, the downtime data is available for a period of one month and is purged after that.

• The history of trails configured is not captured or available.

• The report for new trails configured after is available.

• Data for the trails configured is available from the time the trail was started.

Audit Collection Best Practices

Follow these best practices for audit collection.

• Periodically purge the records that have already been read by the audit trail.

  For some targets, the Audit Vault Agent contains scripts for cleanup. See Audit Trail Cleanup for more information. If there are remaining targets where the records have already been read by the audit trail, you can manually clean up the audit trail.

  If you don’t purge the records, the following issues might occur:

  • There may be too many records (more than a million) in a table audit trail. This can slow down audit data collection and reduce the throughput of the table audit trail.

  • For directory trails, there may be too many files (more than a thousand) with a size of more than 1 GB. This can slow down audit data collection and reduce throughput of the directory trail.

• Ensure that the directories of transaction log audit trails, directory audit trails, and Oracle GoldenGate are access controlled.

• For directory and transaction log audit trails, if the agent user does not have read permission on audit files, then provide the agent user with read permission on the audit files by running the following commands.

  Operating System	Command
  Linux	setfacl -Rm u::r-x setfacl -Rdm u::r--
  Solaris	chmod A+user::rx:fd:allow chmod A+user::r:allow /*
  AIX/HP-UX	Add the agent user to the group that has read permission on the audit data.

Handling New Audit Trails with Expired Audit Records

Learn about handling new audit trails with expired audit records.

With established audit trail collection, audit data is retained in Oracle Audit Vault Server for the Months Online period of a retention (or archiving) policy. After this period, the data files are made available for archiving. The data is then kept in archives for the Months Archived period of the retention policy, and is available to retrieve to the Audit Vault Server during that period.

However, when you add a new audit trail to an existing target, the audit data collected may contain records that fall into the Months Archived period in the retention policy assigned to this target. That is, the online period for these audit records has expired and they should be archived according to the retention policy.

In this case, Oracle Database Security Central attempts to automatically archive these expired records during the new audit trail collection. In some cases, you may need to make the archive data files available in order for the audit trail to complete collection.

When collecting a new audit trail for an existing target, follow these instruction if you see an Archive data files are required link in the Collection Status of the audit trail.

To make archive data files accessible:

1. Log in to the Oracle Database Security Central console as an administrator.

2. Select Targets, and then select Audit Trails.

3. In the Collection Status column, if applicable, select Archive data files are required link.

   The required archive data files are listed.

4. Check that required data files are available in the archive location, and that the connection to the location is set up correctly.

5. After you make the required data files available, restart this audit trail.

   See Also:

   • Defining Archive Locations to check the required data files are available in the archive location and the connection to the location is established.

   • About Archiving and Retrieving Data in Oracle Database Security Central

   • Using Oracle Database Security Central Console

Deleting an Audit Trail

Learn how to delete an audit trail.

1. Log in to the Oracle Database Security Central console as an administrator.

2. Select Targets.

3. In the left navigational menu, select Audit Trails.

4. Select the audit trails that you want to delete and then, if necessary, select Stop to stop the audit trail.

5. Select the audit trails that you want to delete, and then select Delete.

Converting Audit Record Formats for Collection

You can use special tools to convert audit record formats so that Database Security Central can collect these records.

Prerequisites for Converting Oracle Audit Vault Record MySQL Formats

Learn about the prerequisites for converting Oracle Audit Vault record MySQL formats.

Before you begin the format conversion process, ensure that you have completed the following tasks.

• Register the MySQL target in the Audit Vault Server. See Registering or Removing Targets in Audit Vault Server.

• Deploy the Audit Vault Agent on the MySQL host machine. See Deploying the Audit Vault Agent.

Running the XML Transformation Utility for MySQL Audit Formats

Learn how to run the XML transformation utility for MySQL audit formats.

Audit records of some databases are in the format that cannot be read directly by Oracle Database Security Central collectors. Such audit records are first converted to a readable format and then collected.

For MySQL targets, Oracle Database Security Central provides a utility to transform the MySQL XML audit format log file into a required format for audit data collection. You must run this utility on the MySQL host machine before adding an audit trail.

Note: This procedure is only applicable for the old audit format. The default audit format of MySQL 5.5 and 5.6 is old. The default audit format of MySQL 5.7 is new. The audit format can be changed by modifying the configuration on MySQL Server.

To run the XML Transformation Utility:

1. On the MySQL host computer, go to the directory AGENT_HOME/av/plugins/ com.oracle.av.plugin.mysql/bin/

2. Run the following command:

   MySQLTransformationUtility.bat inputPath=<path_to_log_folder>
   outputPath=<path_to_converted_xml> agentHome=<path_to_AGENT_HOME>
   interval=<interval_in_minutes> xslPath=<XSL_file_path> securedTargetName=<registered_secured_target_name>

   This command contains the following variables:

   • <path_to_log_folder>:

     • For MySQL version prior to 5.7.21: The path to the MySQL log folder listed in my.ini

     • For MySQL version 5.7.21 and later: The path to the MySQL log folder listed in my.ini\<audit file name>.*.log

   • <path_to_converted_xml> - The path to the folder where the converted XML files will reside. You will use this path as the Trail Location when creating the audit trail for this MySQL target in the Audit Vault Server, or when starting audit trail collection using the AVCLI command line.

   • <path_to_AGENT_HOME> - The path to the installation directory of the Audit Vault Agent

   • <interval_in_minutes> - (Optional) The waiting time, in minutes, between two transformation operations. If not specified, the default it is 60 minutes. To run the transformation utility once, specify -ve for this argument.

   • <XSL_file_path> - (Optional) The path to the XSL file to use for the transformation.

   • <registered_secured_target_name> - The name of the MySQL target registered in the Audit Vault Server.

   Example:

   For MySQL version prior to 5.7.21: MySQLTransformationUtility.bat inputPath=D:\MySQLLog outputPath=D:\ConvertedXML agentHome=E:\MySQLCollector interval=1 securedTargetName=MYSQL_DEV

   For MySQL version 5.7.21 and later: MySQLTransformationUtility.bat inputPath=D:\MySQLLog\audit.*.log outputPath=D:\ConvertedXML agentHome=E:\MySQLCollector interval=1 securedTargetName=MYSQL_DEV

Converting Binary Audit Files to ASCII Format for IBM DB2

Learn about converting binary audit files to ASCII format for IBM DB2.

IBM DB2 creates its audit log files in a binary file format that is separate from the DB2 database. For IBM DB2 targets, you must convert the binary file to an ASCII file before each time you collect audit data (start an audit trail) for a DB2 database, using the script instructions in this section.

Ideally, schedule the script to run periodically. If the script finds older text files that have already been collected by the DB2 audit trail, then the script deletes them. It creates a new, timestamped ASCII text file each time you run it. Optionally, you can set the script to purge the output audit files.

Note: It is recommended that you extract audit log files for each database and each instance in a separate directory. You must configure separate audit trails for each database and each instance in Oracle Oracle Database Security Central.

In case of multiple instances, if the instances are not owned by the same user, it is recommended to extract audit data corresponding to each instance in a separate location. To collect the audit data, use one agent per instance. Ensure that the agent user is same as the instance user.

1. Identify a user who has privileges to run the db2audit command.

   This user will extract the binary files to the text files.

2. This user must have execute privileges to run the conversion script from the Oracle DBSecCentral directory. The script name is DB295ExtractionUtil (for Microsoft Windows, this file is called DB295ExtractionUtil.bat.)

3. This user identified in the initial step, must have read permission for the $AGENT_HOME/av/atc directory and its contents.

4. In the server where you installed the IBM DB2 database, open a shell as the SYSADM DB2 user.

5. Set the following variables:

   • AGENT_HOME (this is the Audit Vault Agent installation directory)

   • DB2AUDIT_HOME (this directory points to the main directory that contains the db2audit command)

6. Ensure that the Oracle DBSecCentral owner of the agent process has read permissions for the audit text files that will be generated by the extraction utility.

7. Log in as the DB2 user that you identified in IBM DB2 for LUW Setup Scripts.

8. Run one of the following scripts, depending on the version of DB2 that you have installed:

   • For supported DB2 databases:

     DB295ExtractionUtil -archivepath <archive_path> -extractionpath <extraction_path> -audittrailcleanup <yes/no> -databasename <database_name>

     In this specification:

     • <archive_path>: This is DB2 archive path configured using the db2audit utility.

     • <extraction_path>: This is the directory where the DB2 extraction utility places the converted ASCII text file. This file is created in either the db2audit.instance.log.0.YYYYDDMMHHMMSS.out or db2audit.db.database_name.log.0.20111104015353.out format.

     • audittrailcleanup <yes/no>: Enter yes or no, to enable or disable the audit trail cleanup. Entering yes deletes the archived IBM DB2 audit files that were collected by the Oracle DBSecCentral DB2 audit trail. If you omit this value, then the default is no.

     • <database_name>: (Optional) This is the name, or names separated by spaces, of the database(s) that contain the audit records.

       The utility creates a separate ASCII file for each database named in the command. If this parameter is omitted, then the utility converts the instance binary to an ASCII file. This parameter enables you to collect categories of audit records such as object maintenance (objmaint) records, which capture the creation and dropping of tables.

       Important: If you enter more than one database name in this command, be sure to put the ASCII file for each database in a separate directory after you run the command.

   • Support for IBM DB2 Database Partition Feature

     IBM DB2 Database Partition Feature is supported on Linux and AIX platforms. This functionality is supported for DB2 version 10.5 and later. The Database Partition functionality is not supported on Windows platform.

     Specify the following parameters in the DB295ExtractionUtil script:

     • databasepartition <yes/no>: (Optional) Enter yes if current DB2 setup has Database Partition Feature setup, else enter no. If you omit this value, then the default is no.

     • <nodes>: (Optional) This is the name of the node (or multiple nodes) separated by spaces, of the DB2 Database Partition Feature setup.

     Note:

     • If the archive path and extraction path are on the shared location, that is accessible by all the nodes in the Database Partition Feature (DPF) setup, then you can exclude the nodes input parameter. The script generates the archive data and audit data for all the nodes in the Database Partition Feature setup, in the shared location.

     • If the archive path and extraction path are host machine specific locations, that are accessible only by the nodes on that machine, then it is recommended to run the script on every machine of the Database Partition Feature setup. Include the nodes input parameter with only the nodes present on the specific machine.

     For example: Machine 1 has Node 0 and Node 1. Machine 2 has Node 2 and Node 3. The script must be run on Machine 1 with parameters -databasepartition yes -nodes 0 1. The script must be run on Machine 2 with parameters -databasepartition yes -nodes 2 3.

   Example 1: The following command creates an ASCII file for the TOOLSDB database, places the file in the /home/extract_dir directory, and deletes the archive files after audit data is collected:

   DB295ExtractionUtil -archivepath /home/archive_dir -extractionpath /home/extract_dir -audittrailcleanup yes -databasename TOOLSDB

   Example 2: The following command creates an ASCII file for the database instance, places the file in the /home/extract_dir directory, and deletes the archive files after audit data is collected:

   DB295ExtractionUtil -archivepath /home/archive_dir -extractionpath /home/extract_dir -audittrailcleanup yes

   Example 3: The following command creates an ASCII file for all the nodes of the database instance with Database Partition Feature setup, places the file in the /home/extract_dir directory, and deletes the archive files after audit data is collected:

   DB295ExtractionUtil -archivepath /home/archive_dir -extractionpath /home/extract_dir -audittrailcleanup yes -databasepartition yes

   Example 4: The following command creates an ASCII file for the specified nodes (0, 1, and 2) of the database instance with Database Partition Feature setup, places the file in the /home/extract_dir directory, and deletes the archive files after audit data is collected:

   DB295ExtractionUtil -archivepath /home/archive_dir -extractionpath /home/extract_dir -audittrailcleanup yes -databasepartition yes -nodes 0 1 2

   Example 5: The following command creates an ASCII file for all the nodes of the TOOLSDB database with Database Partition Feature setup, places the file in the /home/extract_dir directory, and deletes the archive files after audit data is collected:

   DB295ExtractionUtil -archivepath /home/archive_dir -extractionpath /home/extract_dir -audittrailcleanup yes -databasename TOOLSDB -databasepartition yes

   Example 6: The following command creates an ASCII file for the specified nodes (0, 1, and 2) of the TOOLSDB database with Database Partition Feature setup, places the file in the /home/extract_dir directory, and deletes the archive files after audit data is collected:

   DB295ExtractionUtil -archivepath /home/archive_dir -extractionpath /home/extract_dir -audittrailcleanup yes -databasename TOOLSDB -databasepartition yes -nodes 0 1 2

To schedule the script to run automatically, follow these guidelines:

• UNIX: Use the crontab UNIX utility. Provide the same information that you would provide using the parameters described previously when you normally run the script.

• Microsoft Windows: Use the Windows Scheduler. Provide the archive directory path (for release 9.5 databases only), extraction path, and target database name in the scheduled task.

Configuring Audit Trail Collection for Oracle Real Application Clusters

You can configure audit trail collection for Oracle Real Application Clusters (Oracle RAC).

Configure a SCAN listener for the RAC and use the SCAN listener IP as the single IP during target registration.

To configure Audit Trail collection for Oracle Real Application Clusters (RAC), follow these guidelines.

Audit Trail Type	Number of Audit Trails
TABLE	To configure table trail audit data collection from Oracle RAC environment, 1 audit trail is sufficient.
DIRECTORY	To configure directory audit data collection from Oracle RAC environment, separate audit trails are required. The trail location must be different directories in the shared storage of the Oracle RAC environment.
TRANSACTION LOG	To configure Transaction Log audit data collection from Oracle RAC environment, 1 audit trail is sufficient.

See Also: Adding Audit Trails with Agent-Based Collection to configure an audit trail.

Configuring Audit Trail Collection for CDBs and PDBs

Learn about configuring audit trail collection for CDBs and PDBs.

Oracle Database can work as Container Database (CDB) or Pluggable Databases (PDB). A PDB is a portable collection of schemas, schema objects, and nonschema objects that appears to an Oracle Net client as a non-CDB. All Oracle databases before Oracle Database 12c are non-CDB.

The PDB and CDB can be registered as targets. Oracle Database Security Central supports CDB and PDB level audit collection. To collect audit data from multiple PDB instances within a CDB, adopt either one of the following approaches:

Approach 1: Create a separate target for each PDB instance and create audit trail for each PDB target, which collects data from UNIFIED_AUDIT_TRAIL table.

Approach 2: Create one target for the CDB and create audit trail which collects data from CDB_UNIFIED_AUDIT_TRAIL table.

Note:

• Oracle Oracle Database Security Central collects from CDB_UNIFIED_AUDIT_TRAIL, only if all the PDBs are up and running.

• CDB_UNIFIED_AUDIT_TRAIL provides audit records from all PDB instances in a multitenant environment. The performance of audit collection from CDB_UNIFIED_AUDIT_TRAIL is lower than audit collection from UNIFIED_AUDIT_TRAIL of every PDB instance. If the number of audit records generated per day in CDB_UNIFIED_AUDIT_TRAIL is higher than 8 million, then configure audit collection from UNIFIED_AUDIT_TRAIL of every PDB instance.

To configure Audit Trail collection for CDB or PDB, follow these guidelines:

Audit Trail Type	Guidelines
TABLE	Audit records specific to CDB activities can be collected from UNIFIED_AUDIT_TRAIL table of the CDB target. Audit records corresponding to CDB activities and all PDB activities can be collected from CDB_UNIFIED_AUDIT_TRAIL. Every PDB stores it's own audit data in it's own UNIFIED_AUDIT_TRAIL table which does not contain audit data of other PDBs. Separate audit trails can be configured for the PDB target to collect data corresponding to that specific PDB only. For PDB target, collection from CDB_UNIFIED_AUDIT_TRAIL is not supported. Note:
DIRECTORY	Audit from directory trail can be collected for CDB, by providing directory trail location as <value of AUDIT_FILE_DEST> (database parameter). Audit from directory trail can be collected for each PDB, by providing directory trail location as <value of AUDIT_FILE_DEST>/<GUID of the PDB>. Note: If you are using a multitenant container database (CDB) in Oracle Database 12c, then for a CDB you must register a target for the CDB as well as for every PDB.

Audit data is collected from CDB_UNIFIED_AUDIT_TRAIL for PDBs that are up and running, even if some of the PDBs are down. When a PDB is down, the data corresponding to the PDB with status down is not visible in CDB_UNIFIED_AUDIT_TRAIL. When the PDB which was earlier down comes up, then the data corresponding to the specific PDB is collected from CDB_UNIFIED_AUDIT_TRAIL.

If any PDB is down, then the last archive timestamp is not set on the CDB_UNIFIED_AUDIT_TRAIL, even if other PDBs are up and running. Hence those records that have already been read by the audit trail are not purged from the CDB_UNIFIED_AUDIT_TRAIL and this can lead to severe performance degradation of the audit trail.

If there are any PDBs that are permanently taken down or taken down for few days, then they must be specified in the AV.COLLECTOR.IGNORE_PDB_IF_DOWN_LIST target attribute. The value of the AV.COLLECTOR.IGNORE_PDB_IF_DOWN_LIST target attribute is a list of PDBs separated by a colon. For example, PDB1:PDB2:PDB5.

If a PDB is down, but is present in the AV.COLLECTOR.IGNORE_PDB_IF_DOWN_LIST, then the audit trail ignores the specific PDB if it is down and sets the last archive timestamp on the CDB_UNIFIED_AUDIT_TRAIL if all the other PDBs are up and running.

Audit data collection from PDBs which are mentioned in the AV.COLLECTOR.IGNORE_PDB_IF_DOWN_LIST is not completely accurate. Some of the audit records for these PDBs may be missed. It is also possible that the data is purged from these PDBs, depending on when the last archive timestamp was set.

If there is a PDB with status down, that was present in the AV.COLLECTOR.IGNORE_PDB_IF_DOWN_LIST, and has to brought up, then first remove it from AV.COLLECTOR.IGNORE_PDB_IF_DOWN_LIST. Wait for 10 minutes so that the audit trail reads and processes the updated AV.COLLECTOR.IGNORE_PDB_IF_DOWN_LIST attribute. After approximately 10 minutes, bring up the PDB. This ensures that all future records are successfully collected from this PDB without any data loss.

See Also: Adding Audit Trails with Agent-Based Collection to configure an audit trail.

Migrating Audit Trails from Agentless Collection to Agent-Based Collection

1. Log in to the Audit Vault Console as an administrator.

2. Stop the audit trail that you need to migrate.

   See Stopping, Starting, and Autostart of Audit Trails in Oracle Audit Vault Server.

3. On the Audit Trails page, record the time in the Data Collected Until column for the audit trail.

   This indicates the time and date until which audit records have been collected.

4. On the target database or machine, purge the audit records that have already been collected.

   See Audit Trail Cleanup.

5. Delete the audit trail that you need to migrate.

   See Deleting an Audit Trail.

6. Create a new audit trail for the target and select Agent-based Collection when adding the audit trail.

   See Adding Audit Trails with Agent-Based Collection.

   Note:

   If records that have already been collected by the agentless collection service are not deleted from the target, then the newly created agent-based audit trail will collect duplicate records.

   Even after following the preceding steps, there’s a possibility that a small set of duplicate data will be collected.

Migrating Audit Trails to Another Audit Vault Agent

You can use the UI console or AVCLI commands to migrate an audit trail from one Audit Vault Agent to another. The same process can also be used to migrate trails from agent-based collection to agentless collection and vice versa. This can be beneficial if an Audit Vault Agent is facing CPU or memory shortages due to a large number of audit trails.

Use the UI Console Use AVCLI Commands

1. Log in to Oracle Database Security Central Console as an administrator.

2. Select Targets.

3. Select Audit Trails in the left navigation menu.

4. Select which audit trail(s) you’d like to move.

5. Select Move.

6. Select Agent-based Collection to move the audit trails to another Audit Vault Agent or select Agentless Collection.

7. If you selected to move the audit trails to another Audit Vault Agent in the previous step, select the Audit Vault Agent.

8. Select Move.

1. Login to AVCLI with administrator privileges.

   Logging in to AVCLI

2. Use the LIST COLLECTION command to see a list of available Audit Vault Agents.

   List Collection for Agent

3. Use the MOVE COLLECTION FOR SECURED TARGETS command to move the audit trails.

   Move Collection for Secured Targets

Related Topics

• Adding Audit Trails with Agentless Collection

Audit Collection Downtime Alerts

Audit and network trails are monitored frequently and a system alert is generated if the trails are in the STOPPED_ERROR state.

Audit trails are monitored daily. Alerts are generated and email notifications are sent if audit trail is in STOPPED_ERROR state even after 20 retries.

Network trails are monitored hourly. Alerts are generated and email notifications are sent out if network trail is in STOPPED_ERROR state.

Related Topics

• Stopping, Starting, and Autostart of Audit Trails in Oracle Audit Vault Server

• Creating a Network Audit Trail

• System Alerts