3 Configuring the Audit Vault Server

Topics

3.1 About Configuring Oracle Audit Vault Server

Learn about configuring Oracle Audit Vault Server.

This chapter explains how to perform the initial Oracle Audit Vault Server configuration.

Note:

Oracle Audit Vault Server and Oracle Database Firewall server are software appliances. You must not make changes to the Linux operating system through the command line on these servers unless you are following procedures as described in the official Oracle documentation or you are working under the guidance of Oracle Support.

The main steps involved in the configuration process are as follows:

  1. Perform the initial configuration tasks at the Audit Vault Server. For example, confirm system services and network settings, and set the date and time.

  2. Configure the Audit Vault agents.

  3. (Optional) Define resilient pairs of servers for high availability.

  4. (Optional) Add each Oracle Database Firewall at Oracle Audit Vault Server.

  5. (Optional) Configure Oracle Audit Vault and Database Firewall to work with F5 BIG-IP Application Security Manager (ASM).

  6. (Optional) Configure Oracle Audit Vault and Database Firewall to work with the HP ArcSight Security Information Event Management (SIEM) system.

    Note:

    Micro Focus Security ArcSight SIEM (previously known as HP ArcSight Security Information Event Management (SIEM)) is deprecated in 12.2.0.8.0 and is desupported in 12.2.0.9.0. Use the syslog integration feature instead.

  7. Check that the system is functioning correctly.

See Also:

  • Managing A Resilient Audit Vault Server Pair for more information about configuring a resilient pair of Oracle Audit Vault Servers for high availability. Perform the initial configuration that is described in this chapter for both Oracle Audit Vault Servers

  • Summary of Configuration Steps to understand the high-level workflow for configuring Oracle Audit Vault and Database Firewall

3.2 Changing the UI (Console) Certificate for Oracle Audit Vault Server

Learn how to change the UI certificate for Oracle Audit Vault Server.

When you first access the Oracle Audit Vault Server console, you see a certificate warning or message. To avoid this type of message, you can upload a new UI certificate signed by a relevant certificate authority.

Prerequisite

Log in to Oracle Audit Vault Server console as a super administrator. See Logging in to the Audit Vault Server Console UI for more information

To change the UI certificate for the Audit Vault Server:

  1. Click the Settings tab.
  2. Under Security, click Console Certificate.
  3. Click Generate Certificate Request.

    The certificate request form is displayed with the common name for the certificate.

  4. If you want to change the common name that is displayed, then click Change.

    The certificate warnings are based on the common name used to identify Oracle Audit Vault Server. To suppress the warning when you access Oracle Audit Vault Server console using its IP address instead of the host name, also check Suppress warnings for IP based URL access.

  5. Complete the form and enter content in the mandatory fields.
  6. Click Submit and Download.
  7. Save the .csr file and then submit this file to a certificate authority. Ensure that the certificate contains the following details. The COMMON NAME field is filled by default. 
    • COMMON NAME
    • ISSUER COMMON NAME
  8. After the certificate authority issues a new certificate, upload it by returning to the Change UI Certificate page and click Upload Certificate.

Note:

You may need to install the public certificate of the Certificate Authority in your browser, particularly if you are using your own public key infrastructure.

3.3 Specifying Initial System Settings and Options (Required)

Topics

3.3.1 Specifying the Server Date, Time, and Keyboard Settings

Learn how to specify the Oracle Audit Vault server date, time, and keyboard settings.

Super administrators can change the Oracle Audit Vault Server date, time, and keyboard settings. It is important to ensure that the date and time that you set for Oracle Audit Vault Server are correct. This is because events that the server performs are logged with the date and time at which they occur according to the server's settings. In addition, archiving occurs at specified intervals based on the server's time settings.

About Time Stamps

Oracle Audit Vault Server stores all data in UTC. Time stamps are displayed as follows:

  • If you are accessing data interactively, for example using the Oracle Audit Vault Server UI or AVCLI command line, then all time stamps are in your time zone. In the UI, the time zone is derived from the browser time zone. If you are using AVCLI, then the time zone is derived from the "shell" time zone (usually set by the TZ environment variable).

  • If you log in to Oracle Audit Vault Server as root or support, then time stamps are displayed in UTC, unless you change the TZ environment variable for that session.

  • If you are looking at a PDF or XLS report or email that is generated by the system, then the time stamps displayed reflect the Time Zone Offset setting in the Audit Vault Server Manage page (see procedure below).

    WARNING:

    Do not change the Oracle Audit Vault Server database time zone or change the time zone through any configuration files. Doing so causes serious problems in Oracle Audit Vault Server.

  • If you are looking at the Oracle Database Firewall UI, then all time zones are displayed in UTC.

Prerequisite

Log in to Oracle Audit Vault Server console as super administrator. See Logging in to the Audit Vault Server Console UI for more information.

To set the server date, time, and keyboard settings

  1. Click the Settings tab.

  2. From the System menu, click Manage.

  3. From the Timezone Offset drop-down list, select your local time in relation to Coordinated Universal Time (UTC).

    For example, -5:00 is five hours behind UTC. You must select the correct setting to ensure that the time is set accurately during synchronization.

  4. From the Keyboard drop-down list, select the keyboard setting.

  5. In the System Time field, select Manually Set or NTP Synchronization.

    Selecting NTP Synchronization keeps the time synchronized with the average of the time recovered from the time servers specified in the Server 1/2/3 fields.

  6. If you selected NTP Synchronization, then select Enable NTP Time Synchronization to start using the NTP Server time.

    If you do not enable time synchronization in this step, then you can still enter NTP Server information in the steps below and enable NTP synchronization later.

  7. (Optional) Select Synchronize Time After Save if you want the time to be synchronized when you click Save.

  8. In the Server 1, Server 2, and Server 3 sections, use the default server addresses, or enter the IP addresses or names of your preferred time servers.

    If you specify a name, then the DNS server that is specified in the System Services page is used for name resolution.

  9. Click Test Server to display the time from the server.

    Click Apply Server to update the Audit Vault Server time from this NTP server. The update will not take effect until you click Save.

  10. Click Save.

To enable time synchronization, you may also need to specify the IP address of the default gateway and a DNS server.

See Also:

3.3.2 Specifying the Audit Vault Server System Settings

Topics

3.3.2.1 Setting or Changing the Audit Vault Server Network Configuration

Learn how to change the Audit Vault Server network configuration.

The Oracle Audit Vault and Database Firewall installer configures the initial network settings for Audit Vault Server during installation. You can change the network settings after installation.

Note:

If you change the Audit Vault Server network configuration, then you must also do the following:

  1. Restart all audit trails.

  2. Reconfigure the resilient pair of Database Firewalls if you previously configured them.

  3. If the IP address of Audit Vault Server was changed, then update this information in Database Firewall.

Prerequisite

Log in to the Audit Vault Server console as an administrator or super administrator. See Logging in to the Audit Vault Server Console UI for more information.

To configure the Audit Vault Server network settings:

  1. Click the Settings tab.
  2. In the System menu, click Network.
  3. Edit the following fields as necessary, then click Save.

    • Host Name: The host name must be a fully qualified domain name of the Audit Vault Server. The host name must start with a letter, can contain maximum of 24 characters, and cannot contain spaces. For Oracle AVDF release 12.2.0.14.0, the host name can contain a maximum of 64 characters.

      Note:

      • Changing the host name requires a reboot. After you click Save, the system asks you to confirm if you want to reboot or cancel. If you confirm, then the system reboots and Audit Vault Server will be unavailable for a few minutes.

      • The host name cannot be changed in a high availability environment. If the host name requires to be changed, unpair the Audit Vault Servers, change the host name, and pair them again.

    • IP Address: The IP address of Audit Vault Server. An IP address was set during the installation of Audit Vault Server. To use a different address, you can change it now. The IP address is static and must be obtained from your network administrator.

      Note:

      • Changing the IP address requires a reboot.

      • If you have a high availability configuration, then the primary and secondary Audit Vault Servers must be unpaired before changing the IP address. Once the IP address of the primary or secondary Audit Vault Server is changed, pair the two servers again. Once you complete the pairing process, redeploy the Audit Vault Agents to ensure that they are updated with the new IP addresses for both the primary and the secondary Audit Vault Servers.

      You may need to add the specified IP Address to routing tables to enable traffic to go between the Audit Vault Server and Database Firewalls.

    • Network Mask: (Super Administrator only) The subnet mask of the Audit Vault Server.

    • Gateway: (Super Administrator only) The IP address of the default gateway (for example, to access the management interface from another subnet). The default gateway must be on the same subnet as Audit Vault Server.

    • Link properties: Do not change the default setting unless your network has been configured to not use auto negotiation.

    See Also:

3.3.2.2 Configuring or Changing the Oracle Audit Vault Server Services

Learn how to configure and change Oracle Audit Vault Server sevices.

Prerequisite

Log in to the Oracle Audit Vault Server console as a super administrator. See Logging in to the Audit Vault Server Console UI for more information.

To configure the Oracle Audit Vault Server services:

  1. In the System tab, from the System menu, click Services.
  2. Complete the following fields as necessary, then click Save.

    Caution:

    When allowing access to Oracle Audit Vault and Database Firewall you must be careful to take proper precautions to maintain security.

    • DNS Servers 1, 2, 3: (Optional) Select IP Address(es) and enter the IP addresses of up to three DNS servers on the network. Oracle Audit Vault Server uses these IP addresses to resolve host names. Keep the fields disabled if you do not use DNS servers. Enabling these fields could degrade system performance if you use DNS servers.

    • Web Access: If you want to allow only selected computers to access the Audit Vault Server console, select IP Address(es) and enter specific IP addresses in the box, separated by spaces. Using the default of All allows access from any computer in your site.

    • SSH Access: You can specify a list of IP addresses that are allowed to access Audit Vault Server from a remote console by selecting IP Address(es) and entering them in this field, separated by spaces. Using a value of All allows access from any computer in your site. Using a value of Disabled prevents console access from any computer.

    • SNMP Access: You can specify a list of IP addresses that are allowed to access the network configuration of Audit Vault Server through SNMP by selecting IP Address(es) and entering them in this field, separated by spaces. Selecting All allows access from any computer. Selecting the default value of Disabled prevents SNMP access. The SNMP community string is gT8@fq+E.

    See Also:

    Protecting Your Data for a list of recommendations and precautions to maintain security

3.3.2.3 Changing IP Address Of An Active And Registered Host

Use this procedure to change the IP address of a live registered host without impacting the functionality of the Audit Vault Agent.

Prerequisites

  1. Stop Audit Trails. See section Stopping, Starting, and Autostart of Audit Trails in the Audit Vault Server for more information.

  2. Stop the Audit Vault Agent before changing the IP address of the Secured Target Server. See section Stopping, Starting, and Other Agent Operations for more information to stop the Audit Vault Agent.

To change the IP address of a live Registered Host

  1. Change the IP address of the Secured Target Server.
  2. Change the IP address of the previously registered host entity of Audit Vault and Database Firewall using the Audit Vault GUI or AVCLI.
  3. Execute the following to start the Audit Vault Agent with -k option:

    agentctl start -k

  4. Enter Activation Key.
  5. Start Audit Trails.

See Also:

Changing IP Address For A Single Instance Of Database Firewall Server

3.3.3 Configuring Oracle Audit Vault Server Syslog Destinations

Learn how to configure Oracle Audit Vault Server syslog destinations.

Use the following procedure to configure the types of syslog messages to send from Oracle Audit Vault Server. The message categories are Debug, Info, or System. You can also forward Alert messages to the syslog.

Configuring Syslog enables integration with popular SIEM vendors such as Splunk, IBM QRadar, LogRhythm, ArcSight and others.

Prerequisites

  • Log in to the Oracle Audit Vault Server console as an administrator. See Logging in to the Audit Vault Server Console UI for more information.

  • Ensure that the IP addresses provided for syslog destinations are on a different host than the Oracle Audit Vault Server.

  1. Click the Settings tab.
  2. From the System menu, click Connectors. and scroll down to the Syslog section.
  3. Complete the fields, as necessary:

    • Syslog Destinations (UDP): Use this box if you are using User Datagram Protocol (UDP) to communicate syslog messages from Oracle Audit Vault Server. Enter the IP address of each machine that is permitted to receive the syslog messages, separated by spaces.

    • Syslog Destinations (TCP): Use this box if you are using Transmission Control Protocol (TCP) to communicate syslog messages from Oracle Audit Vault Server. Enter the IP address and port combinations of each server that is permitted to receive the syslog messages, separated by spaces.

    • Syslog Categories: You can select the types of syslog messages to generate as follows:

      • Alert: Alerts based on alert conditions that an Oracle Audit Vault and Database Firewall auditor specifies.

        To forward Oracle Audit Vault and Database Firewall alerts to syslog. In addition to this setting, the Oracle Audit Vault and Database Firewall auditor must configure alert forwarding.

      • Debug: Engineering debug messages (for Oracle support use only).

      • Info: General Oracle Audit Vault and Database Firewall messages and property changes.

      • System: System messages generated by Oracle Audit Vault and Database Firewall or other software that has a syslog priority level of at least INFO.

  4. Click Save.
  5. If you are using two Oracle Audit Vault Servers as a resilient pair, then repeat specifying the initial system settings and options on the second Oracle Audit Vault Server.

    See Also:

3.4 Configuring the Email Notification Service

Topics

3.4.1 About Email Notifications in Oracle Audit Vault and Database Firewall

Learn about Oracle Audit Vault and Database Firewall email notifications.

An auditor can configure Oracle Audit Vault and Database Firewall to send users email notifications when alerts or reports are generated. To do this, you must configure an SMTP server to enable email notifications. The email notifications can be sent in text format to mobile devices or they can be routed through an SMS gateway.

Note:

  • You can configure one SMTP (or ESMTP) server for Oracle Audit Vault and Database Firewall.
  • You can configure Oracle Audit Vault and Database Firewall to work with both unsecured SMTP servers as well as with secured and authenticated SMTP servers.

See Also:

Oracle Audit Vault and Database Firewall Auditor's Guide for information about configuring alerts and generating reports.

3.4.2 Configuring Email Notification for Oracle Audit Vault and Database Firewall

Learn how to configure email notification for Oracle Audit Vault and Database Firewall.

Prerequisite

Log in to Audit Vault Server console as a super administrator. See Logging in to the Audit Vault Server Console UI for more information.

To configure the email notification service:

  1. Click the Settings tab, and in the System menu, click Connectors.
  2. In the SMTP Server Address field, enter the IP address of the SMTP server.
  3. In the SMTP Port field, enter the SMTP server port.
  4. In the From Username field, enter the user name used as the sender of the email.
  5. In the From Address field, enter the sender's address that appears in the email notifications.
  6. If this SMTP server requires it, then select Require Credentials, then supply a Username, Password, and Re-enter Password.
  7. If this SMTP server requires authentication, then select Require Secure Connection, and then select the authentication protocol (SSL or TLS).

3.5 Configuring Archive Locations and Retention Policies

Learn about configuring archive locations and retention policies.

Remember the following rules while archiving and restoring tablespaces:

  • The restore policy must follow the guidelines in this section.

  • Check the tablespace that needs to be archived and the corresponding tablespace that needs to be purged as explained in the policy.

  • Restoring data into empty tablespaces is not possible. Check accordingly.

  • In case the tablespace enters the delete period, it is deleted automatically from Oracle Audit Vault Server.

  • Every tablespace is uniquely identified using the name of the month that it moves offline and the month that it is purged. The tablespaces are created automatically based on the policies that you create.

  • When the retention policy changes, the new policy is applied to the incoming data in the following month. It does not affect the existing tablespaces which adhere to the old policy.

  • You can archive the tablespace when it enters the offline period.

  • After restoring the tablespace, it is actually online. After you release the tablespace, it goes offline. You must rearchive the tablespace after it is released.

3.5.1 About Archiving And Retrieving Data In Oracle Audit Vault And Database Firewall

You can archive data files in Oracle Audit Vault and Database Firewall as part of your information life cycle strategy. To do so, you must create archiving (or retention) policies, and configure archive locations to which data will be transferred according to the policies. We recommend that you archive regularly in accordance with your corporate policy.

Oracle recommends that you use NFS to transfer data to an archive location. If you use Secure Copy (SCP) or Windows File Sharing (SMB) to transfer data to an archive location, then your data files are first copied to a staging area in the Audit Vault Server. Therefore, you must ensure that there is additional space in the file system. Otherwise the data file copying may fail. Be aware that transferring large files using SCP or SMB may take a long time.

What is a Retention (or Archiving) Policy?

Retention policies determine how long data is retained in the Audit Vault Server, when data is available for archiving, and for how long archived data can be retrieved to the Audit Vault Server. An administrator creates retention (or archiving) policies and an auditor assigns a specific policy to each secured target, as well as to scheduled reports. The settings are specified in a retention policy are as follows:

  • Months Online: The audit data is available in the Audit Vault Server for the number of months online specified. During this period, data is available for viewing in reports. When this period expires, the audit data files are available for archiving, and are no longer visible for reports. When the administrator archives these data files, the data is physically removed from the Audit Vault Server.

  • Months Archived: The archived audit data can be retrieved to the Audit Vault Server for the number of months specified in Months Archived. If the data is retrieved during this period, it will be available again in reports. When the months archived period expires, the data can no longer be retrieved to the Audit Vault Server.

Retention times are based on the time that the audit events occurred in the secured target. If the auditor does not select a retention policy for a secured target or scheduled report, the default retention policy will be used (12 months retention online and 12 months in archives).

Example

Suppose your retention policy is:

  • Months Online: 2

  • Months Archived: 4

With this retention policy, data that is newer than two months ago is available in the Audit Vault Server. Data that becomes older than two months ago is available for archiving, and is no longer visible in reports. Archived data is available to retrieve for four months. This data is older than two months ago but newer than six months ago, and can be retrieved from the archives to the Audit Vault Server. Data that becomes older than six months ago is no longer available.

When new Data Collected is Older than Retention Policy Limits

When you collect audit data for a newly configured secured target, or from a new audit trail on an existing secured target, the data collected from that secured target may be older than the Months Online period, and may even be older than the Months Archived period.

For instance, suppose your retention policy is the same as the above Example. Now suppose you start collecting audit data from a newly configured secured target. If some of this data is over six months old, it is older than the months online period and the months archived period combined. In this case, Oracle Audit Vault and Database Firewall automatically drops any newly collected audit records that are older than six months.

However, if some of this audit data is older than two months but newer than six months (that is, it falls within the months archived period), Oracle Audit Vault and Database Firewall does one of the following:

  • If this is an audit trail for a newly configured secured target, Oracle Audit Vault and Database Firewall automatically archives that data as the audit trail is collected.

  • If this is a new audit trail for an existing secured target, Oracle Audit Vault and Database Firewall attempts to archive these records automatically as the audit trail is collected. However, you may have to make required data files available during this process.

Note:

In case the archive location is not defined, once the months online period expires and before the completion of offline period, the audit data for the specific target is moved offline. The data remains on the Audit Vault Server and can be retrieved and viewed in the Reports section of the Audit Vault Server console. This is applicable for the default and user defined archival and retention policy.

See Also:

Handling new Audit Trails with Expired Audit Records for information to make required data files available.

3.5.2 Defining Archive Locations

Learn about defining archive locations.

You must define one or more locations as destinations for archive files before you can start an archive job. An archiving destination specifies the archive storage locations and other settings.

Oracle recommends that you use NFS to transfer data to an archive location. If you use Secure Copy (SCP) or Windows File Sharing (SMB) to transfer data to an archive location, then your data files are first copied to a staging area in Oracle Audit Vault Server. Therefore, you must ensure that there is sufficient space in the file system. Otherwise the data file copying may fail. Transferring large files using SCP or SMB may take a long time.

Note:

The backup functionality does not backup archived files. The data files in the archive location are not backed up by avbackup because they may be located on a remote file system. In case those files are on NFS mount point, then they are accessible after restoring on a new system with the same mount points that were previously configured.

Prerequisite

Log in to the Audit Vault Server as an administrator. See Logging in to the Audit Vault Server Console UI for more information.

To create an archive location:

  1. Click the Settings tab, and under Archiving, click Manage Archive Locations.

    A list of existing archive locations is displayed.

  2. Click the Create button, and complete the following fields:

    • Transfer Method: The method used to transfer data from Oracle Audit Vault Server to the machine that archives the data:

      • Secure Copy (scp): Select if the data is archived by a Linux machine.

      • Windows File Sharing (SMB): Select if the data is archived by a Windows machine

      • Network File Storage (NFS): Select if using a network file share or NAS.

    • Location Name: The name of the archiving destination. This name is used to select the archiving destination when starting an archive.

    • Remote Filesystem: If you use the Network File System (NFS) transfer method, then you can select an existing filesystem, or one will be created automatically based on the details of this archive location.

      Note:

      In a standalone system, you can use the AVCLI utility to register a remote filesystem. This filesystem can be later selected in the Audit Vault Server console. This is not possible in a high availability environment.

      The archive locations must be created using the Audit Vault Server console only in a high availability environment by selecting the Create New Filesystem option.

    • Address: The host name or IP address of the NFS server used by the Audit Vault Server for archiving. If Windows File Sharing is the transfer method, then specify an IP address.

    • Export Directory: If you use the Network File System (NFS) transfer method, then enter the export directory of the NFS server. For example, this directory can be created in the /etc/exports file of the NFS server. Ensure the oracle user (User ID: 503) has appropriate read and write permissions to this directory.

    • Path: The path to the archive storage location. Enter a path to a directory (not a file), noting the following for these transfer methods:

      • Secure Copy (scp): If there is no leading slash character, the path is relative to the user's home directory. If there is a leading slash, the path is relative to the root directory.

      • Windows File Sharing (SMB): Enter the sharename, followed by a forward slash and the name of the folder (for example, /sharename/myfolder).

      • Network File System (NFS): Enter the path relative to the export directory. For example if the export directory is /export_dir, and the full path to the directory you want to designate as an archive location is /export_dir/dir1/dir2, then enter /dir1/dir2 in the Path field. To put archives directly in the NFS server's export directory, enter / (forward slash) for the Path.

        You can click the Test button to validate the NFS location when done.

    • Port: This is the port number that secure copy uses or the Windows fileshare service on the machine that archives the data. You can normally use the default port number.

      If you selected Windows File Sharing as the Transfer Method, then use port 445.

    • Username: The account name on the machine to which the archive data will be transferred.

    • Authentication Method: If Secure Copy (scp) is the transfer method, then you can select Password and enter the login password. If a Linux machine is used, then you can select Key Authentication.

      If using Key Authentication, then the administrator of the remote machine must ensure that the file that contains the RSA key (~/.ssh/authorized_keys) has permissions set to 664.

    • Password and Confirm Password: If you use Windows file sharing, or if you selected Password as the authentication method, then this is the password to log into the machine that archives the data.

    • Public Key: This field appears if you selected Key Authentication. Copy this public key and add it to the public keys file on the machine that archives the data. For example, add the key in ~/.ssh/authorized_keys.

  3. Click Save.

Managing NFS locations in high availability environment

Oracle Audit Vault and Database Firewall supports archiving. Prior to release 12.2.0.11.0, archiving was configured only on the primary Audit Vault Server and there was no ability to configure archiving on the standby server. After a failover, archive locations had to be manually set on the former standby (new primary). Starting with release 12.2.0.11.0, you can now configure NFS archive locations on both the primary and standby Audit Vault Servers, reducing the amount of manual work that needs to be performed following a failover.

Follow these steps to create a new NFS archive location:

  1. Log in to the Audit Vault Server console as admin user.
  2. Click Settings.
  3. Under ARCHIVING, click Manage Archive Locations.
  4. The list of existing archive locations is displayed. Click the name of the existing archive location to modify. Make the changes and click Save.
  5. Click Create, to create a new archive location using NFS.
  6. The Network File System (NFS) is selected by default. Enter the following details to create a new NFS archive location:

    Field

    Description

    Location Name

    The name of the archiving destination.

    Remote Filesystem

    Select an existing filesystem, or one will be created automatically based on the details of this archive location.

    Primary Server Address

    NFS Server IP address for primary Audit Vault Server.

    Secondary Server Address

    NFS Server IP address for standby Audit Vault Server.

    Primary Server Export Directory

    Export directory on the NFS server for primary Audit Vault Server.

    Secondary Server Export Directory

    Export directory on the NFS server for standby Audit Vault Server.

    Primary Server Path

    The destination path relative to the export directory on the NFS server for primary Audit Vault Server.

    Secondary Server Path

    The destination path relative to the export directory on the NFS server for standby Audit Vault Server.
  7. Click Save.

Note:

3.5.3 Creating or Deleting Archiving Policies

Topics

3.5.3.1 Creating Archiving (Retention) Policies

After you create a retention policy, an Oracle AVDF auditor can apply it to secured targets.

Prerequisite

Log in to the Audit Vault Server console as an administrator. See Logging in to the Audit Vault Server Console UI for more information.

To create an archiving (retention) policy:

  1. Click the Settings tab.
  2. Under Archiving, select Manage Policies, and then click the Create button.
  3. Enter a Name for this policy.
  4. In the Months Online field, enter the number of months to retain audit data in the Audit Vault Server before it is marked for archiving. The default value is 1.

    For example, if you enter 2, then audit data for secured targets that use this retention policy will be available for archive jobs after two months online in the Audit Vault Server. After the months online period has expired, the data is no longer visible in reports.

  5. In the Months Archived field, enter the number of months to retain audit data in the archive location. The default value is 6.

    This value determines how long data is available to retrieve to the Audit Vault Server, but does not cause the data to be purged from the archive location. For example if you enter 4, data can be retrieved from archives for a period of four months after it has been archived.

    See Also:

    Oracle Audit Vault and Database Firewall Auditor's Guide for instructions on assigning retention policies.

3.5.3.2 Deleting Archiving Policies

Learn how to delete archiving policies.

You can only delete user-defined archiving policies.

Prerequisite

Log in to Oracle Audit Vault Server console as an administrator. See Logging in to the Audit Vault Server Console UI for more information.

To delete an archiving (retention) policy:

  1. Click the Settings tab.
  2. Under Archiving, click Manage Policies.
  3. Select the user-defined policy to delete and click Delete.

3.5.4 Running Archive or Retrieve Jobs

See "Archiving and Retrieving Audit Data".

3.6 Managing Archival and Retrieval in High Availability Environments

Learn about managing Oracle Audit Vault and Database Firewall data archival and retrieval in high availability environments.

Oracle Audit Vault and Database Firewall supports archiving. Prior to release 12.2.0.11.0, archiving was configured only on the primary Audit Vault Server and there was no ability to configure archiving on the standby server. After a failover, archive locations had to be manually set on the former standby (new primary). Starting with release 12.2.0.11.0, you can now configure NFS archive locations on both the primary and standby Audit Vault Servers, reducing the amount of manual work that needs to be performed following a failover.

Oracle Audit Vault and Database Firewall release 12.2.0.11.0 and later ensures that the primary and secondary Oracle Audit Vault Servers have the same number of NFS archive locations. Having the same number of locations is crucial for the effective operation of archiving and file management in high availability environments.

Note:

  • Any user with admin privileges can perform archival and retrieval tasks.
  • It is recommended that you place the NFS archive locations for the primary and secondary Oracle Audit Vault Servers on separate NFS servers.
  • It is also recommended that the primary and secondary NFS servers reside within the same data center as the Oracle Audit Vault Server.
  • NFS is a mount point on the Audit Vault Server. If you want to replace NFS server, then make sure the Audit Vault Server does not access the mount point.

Prerequisite

Ensure that all of the requirements mentioned in Prerequisites for Configuring a Resilient Pair of Audit Vault Servers are satisfied before configuring your high availability environment.

After you successfully pair your high availability servers, the NFS locations pertaining to both the primary and secondary Oracle Audit Vault Servers are displayed under Manage Archive Locations on the primary Oracle Audit Vault Server console. These NFS locations include those that you created on both the primary and secondary Oracle Audit Vault Servers before and after configuring high availability. The names of these NFS locations have the primary location name or the name that you specified when you created the location after high availability is configured. The Oracle Audit Vault Server console provides details of the host, export directory, and destination path for both the primary and secondary Oracle Audit Vault Servers.

Upgrade and archiving functionality in high availability environment

Archiving functionality is disabled during the upgrade process only when there are datafiles archived to the NFS locations. Upon completion of the upgrade process, the admin user must enable the archive functionality.

Updating or Deleting NFS locations

The super admin can update or delete the NFS locations after high availability pairing of primary and secondary Oracle Audit Vault Servers. You can update or delete the NFS locations on both the primary and secondary Oracle Audit Vault Servers. If the datafiles are archived, then you cannot update or delete the locations. The Location Name and the Primary Server Path or the Secondary Server Path can be updated when high availability is enabled.

See Also:

3.7 Defining Resilient Pairs for High Availability

You can define resilient pairs of Audit Vault Servers, Database Firewalls, or both.

When you define a resilient pair of Audit Vault Servers, you do all configuration tasks, such as adding Database Firewalls to the server and registering secured targets, on the primary Audit Vault Server.

See Also:

Configuring High Availability

3.8 Registering Database Firewall in Audit Vault Server

Learn how to register Database Firewall in Audit Vault Server.

Use this procedure to register an Database Firewall in Audit Vault Server.

Prerequisites

To register Database Firewall in Audit Vault Server:

  1. If there is a resilient pair of Audit Vault Servers, then log in to the primary server.
  2. Click the Database Firewalls tab.

    The Firewalls page displays the currently registered firewalls and their statuses.

  3. Click Register.
  4. Enter a Name for Database Firewall and its IP Address.
  5. Click Save.

    If a message indicates that there is a problem with the certificate, then ensure that the date and time settings are identical on both Database Firewall and Audit Vault Server.

3.9 Testing Audit Vault Server System Operations

Learn about testing Audit Vault Server system operations.

Verify that your system is fully operational before beginning your normal, day-to-day operations.

Prerequisite

Log in to Audit Vault Server as an administrator. See Logging in to the Audit Vault Server Console UI for more information.

To test your system's operation:

  1. Check the date and time settings of Audit Vault Server.
  2. Click the Settings tab.
  3. In the System menu, click Diagnostics.
  4. Click the Run Diagnostics button to run a series of diagnostic tests and review the results.

    These diagnostics include testing:

    • Existence and access permissions of configuration files

    • File system sanity

    • Network configuration

    • Statuses of various process that are required to run on the system, for example, database server processes, event collection process, Java framework process, HTTP server process, and so on.

  5. Click the Home tab, and check the status of Database Firewalls and Hosts.

3.10 Configuring Fiber Channel-Based Storage for Audit Vault Server

Learn about configuring fiber channel-based storage for Audit Vault Server.

Oracle Audit Vault Server supports fiber channel-based storage. You can configure this storage during installation by performing this procedure.

Note:

  • Fiber channel-based storage is supported on Oracle Audit Vault and Database Firewall release 12.2.0.0 and later only.

To configure fiber channel-based storage for Audit Vault Server:

  1. Install Audit Vault Server on the local disk of your server. During installation, Audit Vault Server attempts to use all of the disks in your system. Use the configuration tools for the fiber channel controller such as Fast!UTIL, to ensure that other disks are not accessible.

    Note:

    • If the other disks are accessible, then they are formatted and erased during installation.

    • Oracle Audit Vault Server looks for the devices with the names of sd*, xvd*, hd*, cciss*, fio* in /sys/block. The installation succeeds if the fiber channel disks are exposed as one of these block devices.

    • The first disk must be a local disk with a minimum of 300 GB available space. If the available space is less than 300 GB, then the boot partition is allocated to a SAN fiber channel disk which is not supported. It is recommended that the sizes of the other disks be greater than that of the first disk.

  2. If you are using fiber channel-based storage, then perform the following remaining steps after your installation has successfully completed to ensure that Oracle Automatic Storage Management uses the active path. Otherwise, reboot your system to complete the configuration process.

    Note:

    Fiber channel-based storage with multipath is not supported by Oracle Audit Vault and Database Firewall.

  3. Log in to Audit Vault Server as root.
  4. Stop the Oracle databases by running the following commands: 
    /etc/init.d/dbfwdb stop
    /etc/init.d/asmdb stop
  5. Stop the ASMLib driver by running the following command: 
    oracleasm exit
  6. Modify the values in the /etc/sysconfig/oracleasm file as follows: 
    ORACLEASM_SCANORDER=“dm /mnt”
  7. Reboot your system.

3.11 Adding Network Address Translation IP Addresses to Audit Vault Agent

You can add Network Address Translation (NAT) IP addresses to Audit Vault Agent.

Network Address Translation (NAT) is a method of remapping one IP address space into another. This is done by modifying network address information in the IP header of packets when they are in transit across traffic routing devices. Use this procedure to manually add the NAT IP address of the Audit Vault Server to the Audit Vault Agent.

In some deployments, Audit Vault Servers are within NAT networks. The Agents are deployed in a network outside of the NAT configured network with actual IP addresses of Audit Vault Server. In such cases, the Agents cannot reach Audit Vault Server.

In this case, you can add the NAT IP address and port mapping information to the dbfw.conf file of Audit Vault Server. This ensures adding an extra connection string in the Agent's bootstrap.prop file so that Agents can be deployed in both NAT and non NAT networks. This functionality is available from Oracle AVDF 12.2.0.8.0 and later.

Use Cases

Case Configuration Type Description

Case 1

Audit Vault Server configuration without high availability.

  • There is only one Audit Vault Server. This server is behind NAT.

  • Agents in this set up can either connect to Audit Vault Server directly without NAT, or connect to the Audit Vault Server through NAT.

  • Agents connecting to Audit Vault Server directly, use IP address and port of Audit Vault Server.

  • Agents connecting to Audit Vault Server through NAT use the IP address and port of Audit Vault Server.

Case 2

Audit Vault Server configuration with high availability.

  • Both the primary and secondary Audit Vault Servers are behind the same NAT. The primary NAT IP address and secondary NAT IP address is the same. The primary NAT port and secondary NAT port are different.

  • Agents in this set up can either connect to Audit Vault Server directly without NAT, or through NAT.

  • Agents connecting to Audit Vault Server directly use the IP address and port of Audit Vault Server. In case of a failover of the primary Audit Vault Server, the Agents continue to connect to the secondary Audit Vault Server using the IP address and port of the secondary Audit Vault Server.

  • Agents connecting to Audit Vault Server through NAT use the IP address and port of the primary Audit Vault Server. In case of failover of the primary Audit Vault Server, the Agents continue to connect to the secondary Audit Vault Server using the IP address and port of the secondary Audit Vault Server.

Case 3

Primary and secondary Audit Vault Servers with different NAT IP addresses.

  • Both the primary and secondary Audit Vault Servers are behind two different NAT IP addresses. The primary NAT IP address and secondary NAT IP address are different. The primary NAT port and secondary NAT port can be the same or different.

  • Agents in this setup can either connect to Audit Vault Server directly without NAT or through NAT.

  • Agents connecting to Audit Vault Server directly use the IP address and port of the Audit Vault Server. In case of failover of the primary Audit Vault Server, the Agents continue to connect to the secondary Audit Vault Server using the IP address and port of the secondary Audit Vault Server.

  • Agents connecting to the Audit Vault Server through NAT use the IP address and port of the primary Audit Vault Server. In case of failover of the primary Audit Vault Server, the Agents continue to connect to the secondary Audit Vault Server using the IP address and port of the secondary Audit Vault Server.

To add the NAT IP address of Audit Vault Server into Audit Vault Agent, follow these steps:

  1. Log in to the Audit Vault Command Line Interface (AVCLI) as the admin or oracle user.
  2. Take a backup of the configuration file before proceeding: 
    cp /usr/local/dbfw/etc/dbfw.conf /usr/local/dbfw/etc/dbfw.conf.backup
  3. Edit the dbfw.conf file to include the NAT IP address in the Audit Vault Server as follows: 
    NAT_PRIMARY_IP_ADDRESS=<xx.yyy.zzz.aaa>
NAT_PRIMARY_AGENT_PORT_TLS=<12345>
NAT_PRIMARY_AGENT_PORT=<12346>
  4. Save the changes.
  5. Regenerate the agent by running the following command: 
    avca configure_bootstrap
    After this, all of the Agents downloaded contain one of the strings with the NAT IP address. To verify, check the contents of the bootstrap file at /var/lib/oracle/dbfw/av/conf/bootstrap.prop which should be as follows: 
    SYS.CONNECT_STRING999=(DESCRIPTION=(ENABLE=BROKEN)(ADDRESS=(PROTOCOL=TCP)(HOST=10.240.114.167)(PORT=13031))(CONNECT_DATA=(SERVICE_NAME=DBFWDB.DBFWDB)))
SYS.SSL_CONNECT_STRING999=(DESCRIPTION=(ADDRESS=(PROTOCOL=TCPS)(HOST=10.240.114.167)(PORT=13032))(CONNECT_DATA=(SERVICE_NAME=DBFWDB.DBFWDB)(SERVER=DEDICATED))(SECURITY= (SSL_SERVER_CERT_DN="DC=com,CN=avserver,OU=db,O=oracle")))
  6. The above case is applicable in Case 1 that is mentioned in the table above. In Case 2 and Case 3, Audit Vault Server is in high availability mode. In these cases, you need to configure the dbfw.conf file with an additional set of parameters as follows: 
    NAT_PRIMARY_IP_ADDRESS=<xx.yyy.zzz.aaa>
NAT_PRIMARY_AGENT_PORT_TLS=<12345>
NAT_PRIMARY_AGENT_PORT=<12346>
NAT_SECONDARY_IP_ADDRESS=<xx.yyy.zzz.ccc>
NAT_SECONDARY_AGENT_PORT_TLS=<56789>
NAT_SECONDARY_AGENT_PORT=<12678>
  7. Save the changes.
  8. After this, the Agent’s bootstrap.prop file is configured with a high availability connect string to include the above set of IP addresses and ports. To verify this, check the contents of the bootstrap file at /var/lib/oracle/dbfw/av/conf/bootstrap.prop which should be as follows: 
    SYS.CONNECT_STRING999=(DESCRIPTION_LIST=(LOAD_BALANCE=off)(FAILOVER=on)(DESCRIPTION=(ENABLE=BROKEN)(ADDRESS_LIST=(LOAD_BALANCE=on)(ADDRESS=(PROTOCOL=TCP)(HOST=<NAT_PRIMARY_AGENT_PORT>)(PORT=<NAT_PRIMARY_AGENT_PORT>)))

(CONNECT_DATA=(SERVICE_NAME=DBFWDB.DBFWDB)))(DESCRIPTION=(ENABLE=BROKEN)(ADDRESS_LIST=(LOAD_BALANCE=on)(ADDRESS=(PROTOCOL=TCP)(HOST=<NAT_SECONDARY_IP_ADDRESS>)(PORT=NAT_SECONDARY_AGENT_PORT>)))(CONNECT_DATA=(SERVICE_NAME=DBFWDB.DBFWDB))))

SYS.SSL_CONNECT_STRING999=(DESCRIPTION_LIST=(LOAD_BALANCE=off)(FAILOVER=on)(DESCRIPTION=(ADDRESS_LIST=(LOAD_BALANCE=on)(ADDRESS=(PROTOCOL=TCPS)(HOST=<NAT_PRIMARY_IP_ADDRESS>)(PORT=<NAT_PRIMARY_AGENT_PORT_TLS>)))(CONNECT_DATA=(SERVICE_NAME=DBFWDB.DBFWDB)(SERVER=DEDICATED))(SECURITY= (SSL_SERVER_CERT_DN="DC=com,CN=avserver,OU=db,O=oracle")))(DESCRIPTION=(ADDRESS_LIST=(LOAD_BALANCE=on)(ADDRESS=(PROTOCOL=TCPS)(HOST=<NAT_SECONDARY_IP_ADDRESS>)(PORT=<NAT_SECONDARY_AGENT_PORT_TLS>)))(CONNECT_DATA=(SERVICE_NAME=DBFWDB.DBFWDB)(SERVER=DEDICATED))(SECURITY=(SSL_SERVER_CERT_DN="DC=com,CN=avserver,OU=db,O=oracle"))))