15 Managing the Audit Vault Server and Database Firewalls

Learn how to manage day-to-day Audit Vault Server and Database Firewall operations after the initial configuration is completed.

15.1 Managing Audit Vault Server Settings, Status, and Maintenance Operations

Learn how to manage the Audit Vault Server settings, status, and maintenance operations.

15.1.1 Checking Server Status and System Operation

This procedure enables you to check the server status and system operation.

  1. Log in to the Audit Vault Server as an administrator.
  2. Use one of the following methods to find the system status:
    • Select the Home tab. The page displays overall system status information (some of which you can drill down into) for Agents, Audit Trails, Targets, Disk Space, Database Firewalls, and CPU Usage.
    • Select the Settings tab, and then in the left navigational menu, select System. The status page displays detailed information for areas such as the overall server status, configuration status, and monitoring status.

15.1.2 Managing Diagnostics

You can generate diagnostic reports to find the source of errors, warnings, and other issues in Audit Vault and Database Firewall.

15.1.2.1 About Managing Diagnostics

You can run diagnostic tools to help you debug problems that may arise.

You can adjust the amount of diagnostics information gathered by setting the LOGLEVEL for different server components using the AVCLI ALTER SYSTEM SET command. When you perform the download operation, the process captures the log and trace file information, along with configuration information that is available at that time. Be aware that a change in the log level only affects those trace or log files that are generated after the change is made. For example, if you encounter a problem after you set the log level to DEBUG, then you must reproduce the issue before you run the procedure in this section to download the diagnostic report. Otherwise, the debug or trace is not captured in the report.

Be aware, however, that the DEBUG setting will generate many files, which can affect the performance of your system. Therefore, only use this setting on a temporary basis, when you are trying to diagnose problems. After you find and correct the problem, then set DEBUG to the original setting, such as ERROR.

Logging Levels

The logging levels determine the amount of information to record in the log files. The following logging levels are listed in the order of amount of information written to log files, with Debug providing the most information:

  • Error: Reports only critical information. This generates the least amount of log messages.

  • Warning: (Default) Reports warning and error messages (not supported for Web Console UI).

  • Info: Writes informational, warning, and error messages. This level is appropriate for testing environments but not for production.

  • Debug: Writes detailed messages for debugging purposes. This generates the most amount of log messages. Debug logs may contain sensitive information about the state of your system. Add the debug log level only when necessary, and remove it once debugging is complete.

System Components

You can set different logging levels for these system components:

Table 15-1 Components with Variable Logging Levels

Agent Alert

Archive and Retrieve

Background Server Process

Data Repository

Database Firewall

Notification

Plug-in Management

Policy Management

Report Generation

SAN Storage

Transaction Log Trail

Web Console UI (has three logging levels only)

N/A

15.1.2.2 Running Diagnostics Checks for the Audit Vault Server

Follow this procedure to run diagnostics checks for Oracle Audit Vault Server.

You can run a diagnostics check for the Audit Vault Server that tracks activities such as whether necessary files exist, whether the HTTP server is running, whether the Oracle listener and other processes are running.
  1. Log in to the Audit Vault Server console as a super administrator.
  2. Click the Settings tab.
  3. In the left navigation menu, click the System tab.
  4. Under Monitoring section, click the Diagnostics link. The Diagnostics dialog is displayed as follows:
  5. In the Diagnostics dialog, do one of the following:
    • Set the diagnostic category that you want to use for diagnostic (for example, for Agent, selecting Warning), and then click Save.
    • Set the diagnostic categories that you want, and then click Run Diagnostics. A second window Test Diagnostics appears listing the diagnostics as they are being captured.
    • To download the diagnostics report, click Download Diagnostics. A diagnostics log file (.zip) is downloaded to the location that you select. Be aware that the diagnostics zip file may contain sensitive data from your appliance. Take appropriate precautions when you transfer and store this file.
    • Click Clear Diagnostic Logs to clear the current set of diagnostic logs on the Audit Vault Server.
15.1.2.3 Downloading Detailed Diagnostics Reports for Oracle Audit Vault Server

You can download diagnostics reports for Oracle Audit Vault Server to review activity and to assess other operations.

To download zip file for Audit Vault Server diagnostics:

  1. Log in to the Audit Vault Server console as a super Administrator.
  2. Click the Settings tab, and in the System menu, click Diagnostics.
  3. Click the Download Diagnostics button.

    A download window appears for the diagnostics zip file.

  4. Select a file location and then click Save.

    See Also:

15.1.2.4 Clearing Diagnostic Logs

Follow this process to empty your Oracle Audit Vault and Database Firewall diagnostic logs.

  1. Log in to the Audit Vault Server console as a super administrator.

  2. Click the Settings tab.

  3. In the left navigation menu, select System.
  4. Under Monitoring, click Diagnostics.
  5. In the Diagnostics window, click Clear Diagnostic Logs, then in the confirmation window, click OK.

15.1.3 Accessing the Audit Vault Server Certificate and Public Key

You can use the Audit Vault Server console to access the Audit Vault server certificate and public key.

15.1.3.1 Accessing the Server Certificate

If you have deployed Database Firewalls, you must provide the Audit Vault Server certificate and IP address to each Database Firewall.

  1. Log in to the Audit Vault Server console as an administrator.
  2. Click the Settings tab.
  3. In the left navigation menu, select Security.
  4. In the status page, click Certificate.
    The server's certificate is displayed. You can copy the certificate and provide it to each Database Firewall.
  5. In the Security menu, click Certificate.
15.1.3.2 Accessing the Server Public Key

You can access the Audit Vault Server public key from the Manage Archive Locations area.

You must provide the server's public key to another system in order to upload archive files from the Audit Vault Server to that system. This public key must be added to the authorized_keys file for that system. For a typical Linux installation, this file is in the user's home directory under .ssh, and its permissions must be set to 0600, or even 0400.
  1. Log in to the Audit Vault Server console as an administrator.
  2. Click the Settings tab.
  3. In the left navigation menu, select Archiving.
  4. In the page that appears, click Manage Archive Locations, and then click Create.
  5. In the Create Archive Location window, in the Public Key field, copy this key and past it into the appropriate file on another system.

15.1.4 Changing the Keyboard Layout

You can change the keyboard layout for Audit Vault and Database Firewall depending your geographic location.

  1. Log in to the Audit Vault Server console as a super administrator.
  2. Click the Settings tab.
  3. In the left navigation menu, select System.
  4. In the page that appears, under Configuration, select Manage.
  5. In the Manage window, select the keyboard you want from the Keyboard menu.
  6. Click Save.
  7. In the confirmation dialog box, select OK.
    You may be logged out if your selection affects the server's time changes significantly.

15.1.5 Restarting or Powering Off the Audit Vault Server

You must be a super administrator to restart or power off the Audit Vault Server.

  1. Log in to the Audit Vault Server as super administrator.
  2. Click the Settings tab.
  3. In the left navigation menu, select System.
  4. Under Configuration, select Manage.
  5. In the Manage window, click Reboot or Power Off.

15.2 Changing Oracle Audit Vault Server Network and Services Configurations

Use this procedure to change Oracle Audit Vault Server network and services configurations.

To set or change the network or services configuration, follow the relevant procedure below:

15.3 Managing Server Connectors for Email and Syslog

Follow this procedure to manage server connectors for email and syslog.

To set or change connector information, follow the relevant procedure below:

15.4 Configuring Remote Syslog Over TLS

Use this procedure to configure remote syslog over TLS.

Syslog provides a convenient mechanism to transfer logs from one device to another. The logs contain sensitive information. Therefore, it is important that you secure the logs during transfers. Do this by authenticating and encrypting the connection beween the client and the server. The remote feature in the syslog supports this functionality. Use this procedure to establish secure communications between the syslog clients and servers.

Prerequisites

  • Ensure that the normal or unencrypted remote syslog functionality works using TCP.
  • Complete the server side configuration. Load the imtcp module and specify the listener port.
  • Complete the client side configuration. Specify the remote machine to which the logs are sent.
  • Upon completion of the server side and client side configuration. Restart the syslog service.
  • Restart the syslog service in case any of the devices were added, modified, or activated.
  • Ensure the logs from the client are listed in the log file of the server. This is a confirmation and you can proceed to securing the communication channel.

To load the imtcp module and to specify the listener port, modify the /etc/rsyslog.conf file as follows:


# listen for tcp input
$ModLoad imtcp
# listening on port <port number>
$InputTCPServerRun <port number>
# Remote logs written to /var/log/messages.
*.* /var/log/messages

To specify the destination remote machine to which the logs will be sent, modify the /etc/rsyslog.conf file as follows:


# Forward messages to remotehost:port
*.* @@<Ip address of the remote host>:<port number>

Syslog contains modules, protective transport layer, and digital certificates to ensure mutual authentication. It covers many aspects. The syslog messages are encrypted in transit. The syslog sender authenticates to the syslog receiver. The receiver is able to identify and in return authenticates to the syslog sender. The receiver performs few checks to validate if it is the valid recipient of the messages. This kind of mutual authentication and hand shake prevents any kind of attacks.

The syslog mutual authentication system makes use of CA certificate and peer certificates. In case there is no signed certificate available, the user can create a self signed certificate using OpenSSL. The server must have the CA (certificate authority) certificate and it’s own digital certificate. These certificates enable SSL operation that provides the necessary crypto keys used to secure the connection.

Syslog makes use of GTLS module as the network stream driver. Syslog has TLS protected transport security feature and ensures messages are encrypted. It makes use of digital certificates to ensure mutual authentication.

Configuring the server

The server configuration involves specifying the location of the certificates, the GTLS driver to be used, and starting of the listener. The following example is applicable to Linux based remote server only. It is different for other platforms. To make any changes to the server's syslog configuration, refer to the documentation of the specific syslog server. Modify the /etc/rsyslog.conf file as follows:


# listen for tcp input
$ModLoad imtcp
# make gtls driver the default
$DefaultNetstreamDriver gtls
# certificate files
$DefaultNetstreamDriverCAFile /path/to/cacert.pem
$DefaultNetstreamDriverCertFile /path/to/servercert.pem
$DefaultNetstreamDriverKeyFile /path/to/serverkey.pem
# Auth mode and permitted peers
$InputTCPServerStreamDriverAuthMode x509/name
$InputTCPServerStreamDriverPermittedPeer <permittedHost>
$InputTCPServerStreamDriverMode 1 # run driver in TLS-only mode
# Listening on port <port number>
$InputTCPServerRun <port number>
# Generic log file watching
$WorkDirectory /var/cache/rsyslog
# Remote logs
*.* /var/log/messages

Configuring the client

Syslog sends messages to a remote system from the client (Audit Vault Server or the Database Firewall). The client configuration involves specifying the location of the certificates, the GTLS driver to be used, and specifying the destination of the messages. Modify the /etc/rsyslog.conf as follows:


# make gtls driver the default
$DefaultNetstreamDriver gtls
# certificate files
$DefaultNetstreamDriverCAFile /usr/local/dbfw/syslog/certs/cacert.pem
$DefaultNetstreamDriverCertFile /usr/local/dbfw/syslog/certs/clientcert.pem
$DefaultNetstreamDriverKeyFile /usr/local/dbfw/syslog/certs/clientkey.pem
# Auth modes and permitted peers
$ActionSendStreamDriverAuthMode x509/name
$ActionSendStreamDriverPermittedPeer avs08002719479d
$ActionSendStreamDriverMode 1 # run driver in TLS-only mode
# Send to remote system
*.* @@<Ip address>:<port number>

Note:

The rsylog.conf is generated from the template file:

/usr/local/dbfw/templates/template-rsyslog-conf

The client settings must also be made to the template file. Any changes made to this template is persistent and preserved even after the reboot of the appliance.

Creating and Using SSL Certificates

  1. Execute the following command to create CA certificates:

    openssl req -new -x509 -keyout private/cakey.pem -out cacert.pem -days 365 -config openssl.cnf

  2. Execute the following commands to create server certificates using the CA certificate:

    openssl req -nodes -new -x509 -keyout serverkey.pem -out serverreq.pem -days 365 -config openssl.cnf

    openssl x509 -x509toreq -in serverreq.pem -signkey serverkey.pem -out tmp.pem

    openssl ca -config openssl.cnf -policy policy_anything -out servercert.pem -infiles tmp.pem

  3. Execute the following commands to create client certificates using CA certificate:

    openssl req -nodes -new -x509 -keyout clientkey.pem -out clientreq.pem -days 365 -config openssl.cnf

    openssl x509 -x509toreq -in clientreq.pem -signkey clientkey.pem -out tmp.pem

    openssl ca -config openssl.cnf -policy policy_anything -out clientcert.pem -infiles tmp.pem

  4. Transfer the following certificates to the specific location on the log server.

    cacerts.pem,servercert.pem,serverkey.pem

  5. Transfer the following certificates to the specific location on the client.

    cacerts.pem,clientcert.pem,clientkey.pem

15.5 Archiving and Retrieving Audit Data

Learn how to archive and retrieve audit data.

15.5.1 Enabling Automatic Archival

Oracle Audit Vault and Database Firewall 20.1 supports automatic archival to an NFS configured location.

When the online period of the data on the tablespace expires, it is automatically archived without user's intervention.
  1. Configure a list of NFS archive locations. Ensure that NFS is configured on the Audit Vault Server as the archive location.
  2. Log in to the Audit Vault Server console as an administrator.
  3. Click Settings tab.
  4. In the left navigation menu, select Archiving.
  5. On the main page, click Data Retention.
  6. Click Enable button, against Auto Archive Status.

15.5.2 Starting an Archive Job Manually

To start an archive job, you must have configured at least one archive location.

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. Else copying the data file may fail. Transferring large files using SCP or SMB may take long.
You can register a remove file system by using the AVCLI command REGISTER_REMOTE_FILESYSTEM.
  1. Log in to the Audit Vault Server as an administrator.
  2. Click Settings tab.
  3. In the left navigation menu, select Archiving.
  4. In the page that appears, click Data Retention.
  5. Under Job Name, enter a name for the archive job.
  6. Under Archive Location, select the archive location from the list.
  7. From the list, select the files you want to archive.

    The files listed are those for which the Months Online period has expired according to the target's retention policy.

  8. Click Archive.

15.5.3 Retrieving Oracle Audit Vault and Database Firewall Audit Data

You can retrieve data files for a specific target and time range.

The Months Archived value in a targets retention (archiving) policy determines how long the target's data is available to retrieve to the Audit Vault Server. When the Months Archived period expires, the data is no longer available to retrieve, however, it continues to reside in the archive location.
  1. Log in to the Audit Vault Server as an administrator.
  2. Click the Settings tab, and from the left navigation menu, click Archiving.
  3. Select Retrieve sub tab on the main page.
  4. Under Retrieve Request, enter the following:
    • Target menu: Select the target.
    • Start Date field: Enter the start date, optionally using the date icon to select from a calendar. The start and end dates are associated with the event time (the time the event occurred).
    • End Date field: Enter the end date, optionally using the date icon to select from a calendar.
  5. Click the Retrieve button.

    Note:

    • You can check the status of the retrieve job in the Jobs dialog that can be accessed from the System tab in the left navigation menu.
    • When the retrieved data files are available, they are listed in the Retrieved Datafiles section of the Retrieve tab, and the data will be visible in reports.
    • Starting Oracle AVDF 20.4, the datafiles archived in NFS locations are deleted from the location after the retrieve job completes.
  6. To purge retrieved files when no longer needed, from the Retrieved Datafiles section. Select the files you want to unload from the system, and then click the Release button. Once the release is successful, the data is not visible in reports.
  7. After the retrieved data files are released, they are now eligible to be archived again. If they are not needed anytime soon, then they should be archived to release disk space to the system.

    Note:

    Alternately, you can view or get the tablespaces archived by following these steps:

    1. Connect to the primary Audit Vault Server using SSH.

    2. Connect to SQL*Plus as administrator.

    3. Run the following commands:

      set linesize 100
      column TABLESPACE_NAME format a30
      column EVENT_MONTH a15
      SELECT * FROM TABLE(avsys.ilm.get_target_eventmonth_for_tablespaces);
    4. The above query displays the results with TABLESPACE_NAME, SECURED_TARGET_ID and EVENT_MONTH indicating the month for which the data is stored for the respective target ID for each tablespace. This information can be used to retrieve data.

15.6 Managing Repository Encryption

Managing the repository encryption key includes tasks such as rotating the master encryption key or changing the keystore password.

15.6.1 About Oracle Audit Vault Server Repository Encryption

Learn about repository encryption.

Encryption of the Oracle Audit Vault Server's event repository is enabled on new installations of Oracle Audit Vault and Database Firewall 12.2. This feature uses Oracle Database's Transparent Data Encryption (TDE) to encrypt all audit event data stored in the Audit Vault Server, data stored in external SAN storage, and data stored in archive locations.

15.6.2 Rotating the Master Key for Repository Encryption

Rotating encryption keys adds a layer of security to your encrypted data.

You should rotate the master encryption key for the Audit Vault Server's event repository on a regular basis, according to your organization's guidelines. It is also a good practice to rotate the encryption key as needed. For example, when a person who had access to your master key leaves your organization.

Note:

If you restore the Audit Vault Server from a backup, the restore operation restores the system to a point in time. Therefore, restoring the system may reinstate an older encryption key.

  1. Log in to the Audit Vault Server console as a super administrator.
  2. Click the Settings tab.
  3. In the left navigation menu, select Storage tab.
  4. In the page that appears, click Repository Encryption tab.
  5. In the Rotate Master Key section, in the Keystore Password field, enter the keystore password.

    This password is originally set as a required post-installation step.

  6. Click the Re-key button.

15.6.3 Changing the Keystore Password

For better security, periodically change the keystore password.

The keystore password for repository encryption is originally set as a required post-installation step. It is the same as the Event Repository Encryption password. You only need this password for restore operations, not backup operations. Thereafter, you can change this password in the Audit Vault Server console.
  1. Log in to the Audit Vault Server console as a super administrator.
  2. Select the Settings tab.
  3. In the left navigation menu, select Storage.
  4. In the page that appears, click Repository Encryption tab.
  5. Under Change Keystore Password section, enter the following:
    • Old password
    • New password
    • Re-enter new password
  6. Click Change Password button.

    See Also:

    Backing Up and Restoring the Audit Vault Server for more information on using the keystore password to restore the Audit Vault Server from backup files.

15.6.4 Backing Up TDE Wallets

You can back up TDE wallets to preserve information.

It is important to perform regular backups of Oracle Audit Vault Server, which include the TDE wallet. However, if you cannot back up Oracle Audit Vault Server, then you should, at a minimum, do regular backups of the TDE wallet at this location:

/usr/local/dbfw/etc/wallets/dbfwdb_wallet

Oracle Audit Vault and Database Firewall does not provide the ability to back up wallets. You should securely back the wallet up in a remote location.

15.6.5 Data Encryption on Upgraded Instances

Learn about data encryption on upgraded instances in Oracle Audit Vault Server.

Phases of Data Encryption

This topic contains a detailed procedure that can be used to start data encryption process.

WARNING:

Do not run data encryption processes on a newly installed Oracle Audit Vault Server or on a system that has been upgraded from fresh install of release Oracle Database 12.2.x. With versions of Oracle Database 12.2.0 and above, all of the new installations have encryption enabled automatically. Thus, all of the table spaces are encrypted by default.

The data encryption process happens in two phases:

  1. Enabling Data Encryption:

    This phase is automatic and data encryption is enabled while performing an Audit Vault Server upgrade. The upgrade process prompts for a keystore password on standalone and primary systems. Upon successful upgrade, data encryption is automatically enabled. The newly created table spaces thereafter are automatically encrypted. However, table spaces created before upgrade continue to be in clear text.

  2. Encrypting existing clear text table spaces:

    This phase is triggered by the user. To encrypt the existing clear text table spaces, the user must initiate the data encryption process. This process is triggered by running the /usr/local/dbfw/bin/avdf_data_encryption.sh script. The detailed steps for encrypting existing clear text table spaces triggered by the user are available in this topic.

Before you begin

  • The rate of encryption is approximately 20 to 50 seconds to encrypt 1 GiB of data, depending on the hardware profile of the system.

  • To begin the process of encrypting the table spaces, the user must execute the /usr/local/dbfw/bin/avdf_data_encryption.sh script as root.

  • Ensure to take AVDF backup prior to the encryption process.

  • The user must have root operating system user privileges to execute this procedure. Ensure the proper privileges are obtained.

  • The encryption process script must be executed on standalone system or on the primary in a HA set up. Ensure that the standby system is also up and running before running the encryption script. The script may result in an error if the standby system is down. The script encrypts table spaces on both the primary and standby system.

  • Ensure that the database is up and running prior to executing the encryption process. To verify the status of the database, log in as root user and execute the command /etc/init.d/dbfwdb status

  • The encryption process script stops all the jobs running in the background. Ensure there is no critical process running that may be impacted.

Note:

Data encryption is not completely enabled on HA system, until the primary is successfully upgraded. After a successful upgrade, all clear text table spaces are in one of the following states:

  • online

  • offline local (offline but the data file resides on the AVS)

  • offline remote (offline but the data files reside on the remote archive location)

  • online retrieved by user

  • online retrieved by a trail

To start Data Encryption process:

  1. Log in to the system as root user.
  2. Execute the following command to start encryption:
    /usr/local/dbfw/bin/avdf_data_encryption.sh start
  3. The following message is displayed on the screen:
    **************************************************************
    * This script will encrypt all online tablespaces and create *
    * a background job to encrypt offline tablespaces.           *
    * Encrypting online tablespaces could potentially take long  *
    * time depending on the size of the online data collected.   *
    * Note that during this time                                 *
    *   - There will be no access to Web UI console.             *
    *   - Event collection will be shutdown.                     *
    *   - AV agents will not be able to connect.                 *
    *   - AVCLI will not be able to connect.                     *
    *                                                            *
    *  NOTE: It is recommended to take backup before continuing. *
    **************************************************************
    Do you want to continue (Y/N):
    
  4. Type Y to continue with encryption.
  5. The following message is displayed:
    ************************************************************
    * Do not interrupt this script execution or reboot.        *
    * To stop the script execution use                         *
    * 'avdf_data_encryption stop' command.                     *
    * Check /root/avdf_data_encryption.log to track progress   *
    ************************************************************
    

    Note:

    At this point, it is recommended to move the process to background by executing Ctrl+z followed by bg. Alternately to keep the session alive, the user can execute the command ssh -o ServerAliveInterval 20

    The following messages are displayed on the screen:

    Successfully encrypted online table spaces. 
    System is ready for use.
    Offline table space encryption can be managed on the AVS GUI.

    Note:

    Contact My Oracle Support with the printed output in the event of a failure.

  6. The following message is displayed in the /var/log/avdf_data_encryption.log file:
    Encrypting <tbsp name> Tablespace : % done
  7. Once the encryption process is successfully completed, another job to encrypt offline table spaces is created and enabled in the background. All the services appear online and the following message is displayed:
    System is ready for use
  8. In case the encryption process fails, the /var/log/avdf_data_encryption.log file displays the following error message.
    Failed to encrypt table spaces: Please contact Oracle Support
  9. Execute the following command to stop encryption:
    /usr/local/dbfw/bin/avdf_data_encryption.sh stop

    Note:

    Ensure to execute the stop command only after you see the following message in the /var/log/avdf_data_encryption.log:

    You may issue stop command to gracefully stop the encrypting process

    Note:

    Once the stop encryption command is executed, the encryption process exits only after encrypting the current table space that is being encrypted. It is always recommended to run the script again to complete the encryption process.

  10. In case the user decides to perform a reboot of the system during the encryption process, it stops at the current table space that encryption last accessed. The user can decide to run the script again to complete the encryption process.
  11. In case the dbfwdb service terminates unexpectedly, contact Oracle Support. The encryption script will not run if this service is down.
  12. The encryption process collects all the logs to /var/log/avdf_data_encryption.log file securely.
  13. After all online table spaces are encrypted, a background job ENCRYPT_OFFLINE_TBSP is enabled to perform encryption of offline table spaces. This job encrypts all table spaces for those data files that reside locally on the system. In case the data file is located on the remote location nfs/scp/smb, the data file is copied to the local system, encrypted, and setup for re archival. The user must manually perform the re archival process to ensure that the data file in the remote location scp/smb is encrypted. The user can navigate to Settings and Repository Encryption page to view a list of offline table spaces that are not encrypted. If the data file is not available, the message displayed indicates the same.
  14. The process of encrypting offline table spaces can be in one of the following states.
    Message Description

    NOT YET STARTED

    The user has not executed the script to encrypt table spaces.

    COMPLETED

    All online and offline table spaces are encrypted. Any new table spaces created will also be encrypted. This is the final state.

    IN PROGRESS

    The background job is currently encrypting offline table spaces.

    USER

    The background job is waiting for user input. User must visit the Repository Encryption page and take appropriate action.

    ERROR

    There was an error in encrypting one or more table spaces. The user must download the diagnostics and provide that to Oracle Support.

    TRAIL

    The table space has been retrieved by a trail as it is collecting old data. Wait for the trail to release the table space.

  15. In the ERROR state the background job is disabled and hence the user, after fixing the cause of the error must re-enable the job from the Repository Encryption page.
  16. In the event of system reboot, power failure, switch over, or fail over the user can execute the encryption process again.

15.7 Backing Up and Restoring the Audit Vault Server

You can back up and restore the Audit Vault Server from the Audit Vault Server console.

15.7.1 About the Backup and Restore Utility

The Oracle Audit Vault Server backup utility backs up all Oracle Audit Vault Server data as well as configuration settings.

You can perform full backups as well as incremental backups, which contain only new data and configuration changes since the previous hot backup. For example, you might do full backups on Sundays, then do incremental backups on Mondays, Wednesdays, and Fridays.

The backup utility can perform hot or cold backups. A hot backup runs while Oracle Audit Vault Server is up and running. A cold backup shuts down Oracle Audit Vault Server before running.

You can store the backup files on the Audit Vault Server, but it is better to store them in a remote location, such as an NFS file system, in case the Audit Vault Server computer fails. The location of the backup files should be accessible by the Audit Vault Server.

The restore utility lets you restore the data and configuration to a new Audit Vault Server from backup files. The computer on which you do a restore must have the same version of Oracle Audit Vault and Database Firewall as the computer from which you took the backups.

Note:

  • The user must note to have the same path of the backup while performing restore operation. For example, if the backup directory is /usr/local/backup, then while performing restore operation specify /usr/local/backup, as the backup directory.

  • The Database Firewall does not need to be backed up. The Audit Vault Server can reapply all existing configuration of the monitoring point to the Database Firewall. See Restoring Database Firewall Monitoring Points for more information.

  • The backup functionality does not backup archived files. The data files in the archive location are not backed up by avbackup as 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 setup as before.

  • 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.

  • The restore operation takes time to complete. It depends on the amount of data being restored. In case the restore operation is being performed using SSH or Terminus, the connection may drop if there is no user interaction. Ensure to keep the SSH or Terminus alive.

How Backup and Restore Operations Work in a High Availability Configuration

If you are using a high availability configuration, then be aware that Oracle Audit Vault and Database Firewall performs the backup only on the primary server, not the secondary server. When you perform a restore operation from the high availability primary backup, then the final restored system becomes a standalone server, which is not in high availability configuration.

Repository Encryption and Backup Encryption

If you did a full install of Oracle Audit Vault and Database Firewall (as opposed to an upgrade), the stored data in the Audit Vault Server is automatically encrypted using Oracle Database Transparent Data Encryption (TDE). This feature is not available on upgraded systems.

If you are restoring from backup files where the system backed up had TDE enabled, you will be prompted for the TDE keystore password during the restore. You must use the TDE keystore password that was in place when the backup was taken. Since the TDE keystore password may change after a backup, it is important that you keep track of the keystore password in place at the time you do each backup.

In addition, you can set encryption on backup files regardless of whether you have the TDE feature available. In this case, you will need a backup encryption password, which will be required if you do a restore.

Therefore, you may need to provide up to two passwords when doing a restore.

See Also:

15.7.2 How Much Space Do I Need for Backup Files?

Determine the amount of space you need for backup files.

The amount of space needed for backup files is determined by the size of your Oracle Audit Vault Server database. You can obtain an upper estimate of the backup file size for the database by running the following SQL query on the Audit Vault Server:

sqlplus system
Enter password: password
SELECT SUM (BYTES)/1024/1024/1024||' GB' FROM DBA_DATA_FILESFoot 1

Note:

  • Ensure that the RAM size and Disk size in the new system is equal or greater than the original system. This ensures that out of memory error is not encountered while performing the backup and restore task.

  • The backup process does not include the SAN configuration. Ensure the new system has sufficient disk space before performing restore. For more information on the disk space needed, refer to the info.txt file available in the backup directory.

  • The restore system requires at least the same amount of memory and disk space as the backup system. Otherwise, the restore operation fails.

15.7.3 Backing Up the Audit Vault Server

After you back up the Audit Vault Server, you can validate the backup that you created.

15.7.3.1 Step 1: Configure the Backup Utility

You can perform a cold backup in a high availability environment.

  1. If you are using a high availability configuration and want to perform a cold backup, then do the following:

    1. Log in to the Audit Vault Server console as administrator.

    2. Select Settings.

    3. In the left navigation menu, select System.

    4. In the page that appears, under the Configuration section, select High Availability.
    5. Select the Disable Failover button.

    6. In the Confirmation dialog, click OK.

  2. Log in to the Audit Vault Server as root.

  3. Run the command below and input information when prompted:

    /var/lib/oracle/dbfw/bin/avbackup config
    

    The system prompts you for the following:

    BACKUP_DIR

    This prompt specifies the directory where the backup files are stored. The directory name is limited to 200 character. After you specify this directory, do not change this directory path, because Oracle Recovery Manager (RMAN) tracks the backup files in this directory. Files are written to this directory by the Oracle user . All access to this directory is handled by the user oracle. (The user oracle is in the oinstall group.) Oracle automatically uses this directory path during the restore operation.

    This directory should be accessible by the Audit Vault Server, and owned by oracle:oinstall. This value should never change once set, and must be the same whether you are doing a full or an incremental backup.

    Do not put closed backups and online backups in the same BACKUP_DIR location. Follow these guidelines:

    • Place the online incremental 1 backup on top of the online full (incremental 0) backup in the same BACKUP_DIR directory. Alternatively, you can place a closed incremental 1 backup on top of a closed incremental 0 backup in the same BACKUP_DIR directory.

    • Do not place a closed incremental 1 backup on top of an online incremental 0 backup in the same BACKUP_DIR directory, nor an online incremental 1 backup on top of a closed incremental 0 backup in the same BACKUP_DIR directory. Doing so cause the restore operation of these backup files to fail.

    The same directory path will be used automatically during the restore operation. This backup destination must be a mounted file system with enough free space to hold the backup files. This may be an NFS file system (to mount this, see "Remote File System AVCLI Commands"), but not a SAN storage location.

    For example:

    BACKUP_DIR[/backup]:/AVBACKUP 
    

    TMP_DIR

    This directory is a temporary working parent directory where the work directory is created. This directory must have at least 100 MB of free space. The oracle user must have read-write access to TMP_DIR.

    For example:

    TMP_DIR[/tmp]:/usr/local/dbfw/tmp/BCKTMP
    

    KEEP_LOGS

    This setting determines where the log files are kept after a successful backup operation. Log files are always kept after a failure. Enter YES to retain logs upon successful backup or restore. Enter NO to automatically delete logs after successful backup or restore.

    For example:

    KEEP_LOGS[NO]:yes
    

    INCREMENTAL_STRATEGY

    This setting selects the RMAN incremental backup level. Enter 0 to do a full backup. Enter 1 to do an incremental backup. An incremental backup backs up the changes since the previous backup.

    For example:

    INCREMENTAL[0]:0
    

    BACKUP_TYPE

    This setting specifies the type of backup to perform. Enter HOT or COLD. A hot backup runs while the Audit Vault Server database is running. However, archive log mode must be enabled during the hot backup process. If archive log mode is not enabled, then you must shut down the database to turn on archive log mode, and then restart the database. The operation to turn on archive log mode is quick, but a shutdown and restart must be performed. For a cold backup, the Audit Vault server database is shut down during the backup process. You should schedule a maintenance shutdown before you perform a cold backup.

    For example:

    BACKUP_TYPE[HOT]:COLD
    

    PASSWD

    (Optional) This setting sets an encryption password for the backup files. You will need this password when you restore from backup files. Unlike other parameters, the password parameter cannot be automatically retrieved from the backup. If you omit this setting, then the backup files are not encrypted.

    For example:

    PASSWD[-- not set --]: password
    Confirm password: password
    

    MAXPIECESIZE

    This setting specifies the maximum backup file size. The valid maximum file size depends on the actual file system. This is set only if CHANNEL_PARALLELISM is set to 1.

    For example:

    MAXPIECESIZE[2G]:

    CHANNEL_PARALLELISM

    This setting specifies the number of channels (processes) used in executing commands. It should match the number of devices accessed.

    If parallelism is more than 1, then the user is prompted for location and section size. If parallelism is equal to 1, then the user is prompted for MAXPIECESIZE.

    For example: One for each physical disk.

    If the number of channels is larger than 1, then specify the location for each channel and section size next.

    CHANNEL_PARALLELISM[1]:4

    Best Practice:

    In case there are multiple physical disks, then it is advised to set CHANNEL_PARALLELISM to an appropriate value according to the number of physical disks. To backup large databases, set CHANNEL_PARALLELISM and SECTION_SIZE according to the actual physical disks configured to improve the time needed to backup the system.

    CHANNEL_LOCATION

    Specifies the location for channel. The user can set multiple locations for each channel. All locations can be the same for all channels. The location is the full path for backup files. To improve performance, the user must specify different locations on a different physical hard disk. The user may specify all locations to the same path.

    For example:

    CHANNEL_LOCATION_1[]:/disk_1
    CHANNEL_LOCATION_2[]:/disk_2
    CHANNEL_LOCATION_3[]:/disk_3
    CHANNEL_LOCATION_4[]:/disk_4

    SECTION_SIZE

    The section size is smaller than the largest data file or parallelism and smaller than the size the physical disk can handle.

    For example:

    SECTION_SIZE[]:32G

    USE_NEW_IP

    For restore operation it specifies the new (current) IP address of the restore system, instead of the old IP address from the backup system. The allowed values are Y or N.

    USE_NEW_IP[N]:Y

    REDUNDANCY

    This setting specifies a number that sets how many full backups to keep. When you run the backup command, backups that are older than this number of backups (as well as their related incremental backups) are deleted. More redundancy requires more disk space for the backup, specified in the BACKUP_DIR parameter.

    For example:

    REDUNDANCY[1]: 
    

    After you complete these settings, a summary of your selection is displayed similar to the following:

    BACKUP_DIR=/long_backup_directory_name_so_three_times_is_more_than_two_hundred_chars
    TMP_DIR=/tmp
    KEEP_LOGS=NO
    INCREMENTAL=0
    BACKUP_TYPE=HOT
    PASSWD=-- not set --
    CHANNEL_PARALLELISM=3
    CHANNEL_LOCATION=/long_backup_directory_name_so_three_times_is_more_than_two_hundred_chars /long_backup_directory_name_so_three_times_is_more_than_two_hundred_chars /long_backup_directory_name_so_three_times_is_more_than_two_hundred_chars
    SECTION_SIZE=500M
    REDUNDANCY=1
    USE_NEW_IP=Y

    If you changed the archivelog mode during the backup configuration process, after the database restarts, then ensure that the Java Framework internal tool is running on the Audit Vault Server.

    For example:

    /usr/local/dbfw/bin/javafwk status 
    

    If the output is Java framework process is stopped, then restart it as follows:

    /usr/local/dbfw/bin/javafwk start 
15.7.3.2 Step 2: Back Up Oracle Audit Vault Server

Use this procedure to back up Oracle Audit Vault Server.

This step backs up Oracle Audit Vault Server databases and configurations.

  1. If applicable, ensure that you have the backup file encryption password and/or event repository encryption keystore password.
  2. Log in to the Audit Vault Server as root.
  3. Run the following command and input information at the prompts:
    /var/lib/oracle/dbfw/bin/avbackup backup
    

    When the backup is complete, you should see a number of files in your backup directory, similar to the following:

    DBID_1440353975_09Q7EF7L_1_1
    DBID_1440353975_C-1440353975-20150520-00

    Note:

    Oracle recommends that you reboot your system in case there is a failure while performing a cold backup operation.

15.7.3.3 Step 3: Validate the Backup

This step validates the backup. It performs the validate operation on the last backup that you created, regardless the settings of the avbackup config file.

The backup configuration file is release specific. It works only for the same release. It is advisable to execute the avbackup config command and create a new configuration file before performing the backup operation after every upgrade.
  1. Log in to the Audit Vault Server as root.
  2. Run the following command:
    /var/lib/oracle/dbfw/bin/avbackup validate
    

    The backup status is displayed, similar to the following:

    Backup Restore exit status: 0
    

    Status 0 = Success. Status 1 = Failure.

  3. Check these log files for errors:
    /TMP_DIR/av_backup_timestamp
    /var/lib/oracle/dbfw/av/log/av.backup_restore-pid-0.log
    /var/lib/oracle/dbfw/av/log/av.backup_restore_error-pid-0.log
    

    If you need help diagnosing errors, contact Oracle Support.

The location of closed backup and online backup must be different. Do not use the same BACKUP_DIR location. Once you specify this location, it is advisable not to change the directory path as Oracle Recovery Manager (RMAN) tracks the backup files in this directory.

Note:

If you use avbackup to do regular backup, or setup cron job for full and incremental backup, or using your own script to perform a backup operation, then:

  • The avbackup tool performs a back up of the database and the configuration of Oracle Audit Vault and Database Firewall.

  • RMAN backup is only backing up the Oracle Audit Vault and Database Firewall database. RMAN plays a crucial role in the archive, backup, and upgrade processes. The default RMAN settings of the Audit Vault Server must not be altered.

  • For RMAN only backup, in the event of a system crash, you cannot restore on a new system. The backup does not work as the original configuration is missing.

  • The backup strategy with RMAN works only in the event of the database crash and the system is still running.

To resolve this issue of avbackup configuration execute the following commands. These commands are example only and work for the cron job setup. However, any issues resulting out of this is not supported by Oracle.

Task Procedure

To run the avbackup configuration once for the full backup.

Move /var/lib/oracle/dbfw/av/backup/.backup_restore_config to /var/lib/oracle/dbfw/av/backup/.full_backup_restore_config

To run the avbackup configuration once for the full incremental backup.

Move /var/lib/oracle/dbfw/av/backup/.backup_restore_config to /var/lib/oracle/dbfw/av/backup/.incr_backup_restore_config

To setup one cron job for full backup.

Copy full_backup_restore_config to backup_restore_config. Run the command avbackup backup.

To setup one cron job for incremental backup.

Copy incr_backup_restore_config to backup_restore_config. Run the command avbackup backup.

15.7.4 Restoring the Audit Vault Server

Learn how to restore the Audit Vault Server from a backup.

15.7.4.1 About Restoring Audit Vault Server

Learn about restoring Audit Vault Server.

The following actions occur after you restore Audit Vault Server:

  • All database accounts are replaced by the accounts from the earlier system. After the restore process completes, you can modify these accounts as needed.

  • The keystore password is replaced by the keystore password that was used in the earlier system. After the restore process is complete, you can modify the keystore password as needed.

  • Operating system accounts are not affected by the restore process. Therefore, the passwords that you set for the root and support accounts remain the same as before the restore.

15.7.4.2 Prerequisites for Restoring Audit Vault Server

Examine the prerequisites for restoring Audit Vault Server.

Before restoring backup files to a new Audit Vault Server:

  • Shut down and remove the earlier Audit Vault Server from the subnet on which it resides. This task enables the new Audit Vault Server to be restored on the same subnet as the previous server.
  • Check the FIPS 140-2 status of the Audit Vault Server which was backed up. In case the FIPS 140-2 status was enabled, ensure to enable the same on the system on which you are restoring. The status must be the same.
  • Perform full installation of the same release version of Oracle AVDF, including the post-installation tasks, on the system to which you are restoring. See Oracle Audit Vault and Database Firewall Installation Guide for instructions.
  • Ensure that the new Audit Vault Server is on the same subnet as the Audit Vault Server from which you took the backups.
  • Ensure that the new Audit Vault Server has a different IP address than the Audit Vault Server from which you took the backups.

Note:

  • After you complete the restore process, the IP address of the new Audit Vault Server is automatically changed to the IP address of the old system. If you want to restore the system with the IP address of the old system (prior to backup), ensure the new Audit Vault Server is on the same subnet as the Audit Vault Server from which you took the backup. Set the USE_NEW_IP parameter to N while executing the avbackup config command on the restore system. For this case, if the original system is still up and running, the restore fails because it cannot switch the IP address which is in use.
  • If you plan to restore the system to a new IP, not to the original backed up system IP, make sure you set USE_NEW_IP parameter to Y while executing the avbackup config command on the restore system. In this case, you do not need to restore on the same subnet as the backup system. You may use this configuration when you are restoring on a different data center, which is on a different subnet, or restore the backup on a new IP while the backup system is up and running.
15.7.4.3 Step 1: Configure the Backup Utility on a New Audit Vault Server

Learn how to configure the backup utility on a new Audit Vault Server.

To restore the new Audit Vault Server from backup files, configure the backup utility on the new Audit Vault Server.

Follow the procedure as in "Step 1: Configure the Backup Utility", providing the same values for BACKUP_DIR and PASSWD as you did on the backed up system.

15.7.4.4 Step 2: Restore Audit Vault Server

Learn how to restore Audit Vault Server.

To restore the Audit Vault Server:

  1. Copy the backup files to your new Audit Vault Server, placing the files in the BACKUP_DIR directory that you specified in "Step 1: Configure the Backup Utility on a New Audit Vault Server".

    Make sure the backup files are owned by oracle:oinstall.

  2. Log in to Audit Vault Server as root.
  3. In case the backup files are in NFS, then ensure the NFS location is mounted on the system used for restore. The backup directory must be accessible through the mount point. Run the following command to manually mount the NFS location prior to performing the restore operation:
    /bin/mount -t nfs <NFS server IP>:<NFS export> <mount point of Audit Vault Server>
  4. Run the following command:
    /var/lib/oracle/dbfw/bin/avbackup restore
    
  5. If you have TDE enabled, then when prompted, then enter the keystore password, using the same value for the keystore password for the original system.

    For example:

    Enter keystore password:
    

    If TDE is not enabled, then this step is bypassed.

  6. When restore is complete, check the following log files for errors:
    /TMP_DIR/av_backup_timestamp
    /var/lib/oracle/dbfw/av/log/av.backup_restore-pid-0.log
    /var/lib/oracle/dbfw/av/log/av.backup_restore_error-pid-0.log
    

    Common errors and their solutions are as follows:

    • No access to BACKUP_DIR: Ensure that the BACKUP_DIR directory is owned by oracle:oinstall.

    • Disk full: Ensure that the BACKUP_DIR disk has enough room for the backup files.

    • Incorrect password: Re-run the avbackup config command to set the password correctly.

    • In addition, a common error is not running the script as root.

    • The restore operation takes time to complete. It depends on the amount of data being restored. In case the restore operation is being performed using SSH or Terminus, the connection may drop if there is no user interaction. Ensure to keep the SSH or Terminus alive.

15.7.5 Restoring a Backup to a New System with a New or Different IP Address

Learn how to restore a backup to a new system with a new or different IP address.

After performing the restore operation, the system has the same IP address. The user has an option to keep the new IP address without disrupting the service and functionality of the system. If the new IP address is used, the system restores the database and keeps the new IP address. This section contains the necessary steps to be performed after the restore operation so that the system or Audit Vault Server does not retain the original IP address by default.

Follow these steps after the restore operation when the system has a new IP address:

  1. Log in to the Audit Vault Server as root user.
  2. Restore the backup on a new Audit Vault Server with a new IP address.
  3. Log in to the Agent machine:
    1. Update the IP addresses in Agent_Home/av/conf/bootstrap.prop file for Audit Vault Agent deployment and in Agent_Home/hm/bootstrap.prop file (for Host Monitor Agent deployment). Replace the old IP addresses with the new IP addresses in bootstrap.prop file.
    2. Restart the Agent. It downloads the new agent.jar file from the Audit Vault Server with the new IP address.

    Note:

    Execute this operation on all Audit Vault Agents and restart them.

  4. Log in to the Audit Vault Server console as admin user.
  5. Click Database Firewall tab.
  6. In the System menu, click Audit Vault Server.
  7. In the Audit Vault Server 1 IP Address field, enter the new IP address of the Audit Vault Server.

    Result:

    This ensures that new communication between Audit Vault Server and Database Firewall is established.

    Note:

    If this communication is not established, then Oracle Audit Vault Server cannot access Oracle Database Firewall. It may result in a common access issue error or an incomplete restore operation.

  8. Update the IP address on all instances of Database Firewall.

Note:

  • Upon completion of restore process on a new IP, the console certificate in the backup system is no longer valid or in use. You must generate a new certificate and upload it.

  • The restore operation takes time to complete. It depends on the amount of data being restored. In case the restore operation is being performed using SSH or Terminus, the connection may drop if there is no user interaction. Ensure to keep the SSH or Terminus alive.

15.8 Backing Up and Restoring the Database Firewall

You can back up and restore the Database Firewall instance.

The Database Firewall configuration is backed up automatically when the Audit Vault Server backup is taken. This does not require any additional action.

Restoring the Database Firewall Configuration on an Existing Database Firewall Instance

A copy of the Database Firewall configuration is stored on the Audit Vault Server. If required, it can overwrite the existing settings of the Database Firewall and maintain a copy of the same on the Audit Vault Server.

To restore the Database Firewall configuration from the Audit Vault Server, follow these steps:

  1. Ensure the Audit Vault Server's certificate is installed on the Database Firewall. See Specifying the Audit Vault Server Certificate and IP Address for more information.
  2. Ensure the IP address of the Database Firewall remains the same.
  3. Follow the steps mentioned in section Resetting Database Firewall.

Restoring the Database Firewall Configuration on a New Database Firewall Instance

In case the Database Firewall instance has failed, it is possible to restore the Database Firewall settings on a newly installed system.

To restore the Database Firewall configuration on a new system, follow these steps:

  1. Install the Database Firewall. See Configuring Database Firewall for complete information.
  2. Configure the same IP address which was used during the previous configuration.
  3. Install the Audit Vault Server's certificate on the Database Firewall. See Specifying the Audit Vault Server Certificate and IP Address for more information.
  4. Update the Audit Vault Server with the new Database Firewall's certificate by following the instructions mentioned in section Fetching an Updated Certificate from Database Firewall.
  5. To restore the Database Firewall configuration, follow the steps mentioned in section Resetting Database Firewall.

15.9 Enabling Oracle Database In-Memory for the Audit Vault Server

After you enable Oracle Database In-Memory, you can monitor it.

15.9.1 About Enabling Oracle Database In-Memory for Oracle Audit Vault Server

You can enable Oracle Database In-Memory for Oracle Audit Vault Server.

You can improve the performance of Oracle Audit Vault and Database Firewall reports and dashboards by enabling Oracle Database In-Memory in Oracle Audit Vault Server. This feature lets you allocate a certain amount of system memory for audit data for a specified period of time. The audit data residing in-memory then becomes available more quickly for use in dashboards and reports.

Based on the amount of system memory you allocate for Oracle Database In-Memory, and the average amount of data collected per day in your environment, Oracle Audit Vault and Database Firewall calculates the number of days of audit data that will fit into that allocated memory. From this calculation, the system displays the in-memory date range to Oracle Audit Vault and Database Firewall auditors, letting them know the time ranges for which they can obtain faster reports. For example, if 1 gigabyte can accommodate 2 days of data, and you have provided 1 gigabyte of memory for Oracle Database In-Memory, then 2 days of the latest data will be put in Oracle Database In-Memory. If you provide 2 gigabytes of memory to Oracle Database In-Memory, then 4 days of data will go to Oracle Database In-Memory.

Before enabling Oracle Database In-Memory, be sure to estimate the amount of memory needed for your current and future targets and Database Firewall monitoring points. You can find some guidelines for calculating RAM requirements in the Oracle Audit Vault and Database Firewall Sizing Advice (MOS Doc ID 2223771.1). This document can be obtained from Oracle Support. After estimating your normal RAM requirements, if you want to use the Oracle Database In-Memory feature, estimate how much RAM you want to use for in-memory database and add that to your RAM requirement. If you enable this feature, you must allocate at least 1 GB for Oracle Database In-Memory.

15.9.2 Enabling and Allocating Memory for Oracle Database In-Memory

You can enable and allocate memory for Oracle Database In-Memory from the Audit Vault Server console.

  1. Log in to the Audit Vault Server console as a super administrator.
  2. Click the Settings tab.
  3. In the left navigation menu, select select System.
  4. Under Configuration, select Oracle Database In-Memory.
  5. In the Oracle Database In-Memory dialog, select the Enable Oracle Database In-Memory check box.
    The Oracle Database In-Memory window expands to show the total system RAM.
  6. If you have sufficient memory on your system, configure the following settings:
    • Allocated In-Memory field: Enter (or change) the amount of RAM to allocate in Gigabytes. You must enter a minimum of 1 (default), and up to Maximum available for Database In-Memory indicated on this dialog.
    • Keep latest data option: Select this option to retain the data that has just been collected. This setting enables the system to automatically select the most recent dates, based on the in-memory size that was configured.
    • Select a date range option: Select this option if you want the memory to be available for a specific period of time.
  7. Click Save.

    After you enable or disable Oracle Database In-Memory, the Audit Vault Server database, Audit Vault Agents, and audit trails shut down for a few minutes, and then restart automatically.

15.9.3 Disabling Oracle Database In-Memory

You can disable Oracle Database In-Memory from the Audit Vault Server console.

  1. Log in to the Audit Vault Server console as a super administrator.
  2. Click the Settings tab.
  3. In the left navigation menu, select System.
  4. Under Configuration section, select Oracle Database In-Memory.
  5. In the Oracle Database In-Memory window, select the Enable Oracle Database In-Memory check box to clear it. If enabled, the disable option is available in the dialog.
  6. Click Save.

    After you enable or disable Oracle Database In-Memory, the Audit Vault Server database, Audit Vault Agents, and audit trails go down for a few minutes, and then restart automatically.

15.9.4 Monitoring Oracle Database In-Memory Usage

You can monitor the Oracle Database In-Memory usage from the Audit Vault Server console.

To see in-memory usage in the Audit Vault Server dashboard:

  1. Click the Settings tab.
  2. In the left navigation menu, select select System.
  3. Under Configuration, select Oracle Database In-Memory.
  4. The Oracle Database In-Memory dialog contains all the details.

15.10 Managing Plug-ins

You can use plug-ins to deploy additional target types in Oracle Audit Vault and Database Firewall environments.

You can deploy additional plug-ins to support more types of targets, or un-deploy plug-ins that are no longer needed.

15.11 Monitoring Server Tablespace Space Usage

You can monitor server table space usage in Oracle Audit Vault Server.

Oracle Audit Vault Server contains the SYSAUX tablespace, which by default has one data file. The SYSAUX tablespace is a locally managed tablespace with automatic segment space management.

You should monitor the space usage for the SYSAUX tablespace and create additional data files for storage as needed.

See Also:

15.12 Monitoring Server Archive Log Disk Space Use

You can monitor archive log disk space use to manage your system.

By default, ARCHIVELOG mode is disabled in Oracle Audit Vault Server. The ARCHIVELOG mode once enabled, copies the filled online redo logs to disk. This enables you to back up the database while it is open and being accessed by users, and to recover the database to any desired point in time. You should monitor the disk space usage for the redo logs.

To change from No Archive Mode to Archive Mode, follow these steps:

  1. Log in as oracle user.
  2. Connect to SQL*Plus as sysdba user.
  3. Run the command:

    SQL> archive log list;

    Observe the following output:

    Database log mode No Archive Mode

    Automatic archival Disabled

    Archive destination USE_DB_RECOVERY_FILE_DEST

  4. In case the Database log mode is No Archive Mode, then run the following commands:

    SQL> shutdown immediate;
    SQL> startup mount;
    SQL> alter database archivelog;
    SQL> archive log list;
  5. Observe the following output:

    Database log mode Archive Mode

    Automatic archival Enabled

    Archive destination USE_DB_RECOVERY_FILE_DEST

  6. Run the command:

    SQL> alter database open;

Note:

  • If you change the ARCHIVELOG mode during the backup configuration process, after the database restarts, then ensure the Java Framework internal tool is running on the Audit Vault Server.
  • Archivelog mode is required for hot backup.

See Also:

15.13 Monitoring Server Flash Recovery Area

Monitoring server flash recovery area is advisable to ensure you have enough space for backups.

By default, Oracle Audit Vault Server has the following initialization parameter settings:

  • The DB_RECOVERY_FILE_DEST_SIZE initialization parameter is set to 2 GB.

  • The DB_RECOVERY_FILE_DEST initialization parameter is set to the default flash recovery area, typically the ORACLE_HOME/flash_recovery_area directory.

Ensure that the size of your flash recovery area is large enough to hold a copy of all data files, all incremental backups, online redo logs, archived redo logs not yet backed up on tape, control files, and control file auto backups. This space can fill quickly, depending on the number of audit trails configured, the scope of the audit record collection being administered, and the backup and archive plans that you have in place.

You can use Oracle Enterprise Manager Database Control to monitor the available space in the flash recovery area. Monitor the percent space that is usable in the Usable Flash Recovery Area field under the High Availability section on the Home page. Check the alert log in the Database Console for messages. When the used space in the flash recovery area reaches 85 percent, a warning message is sent to the alert log. When the used space in the flash recovery area reaches 97 percent, a critical warning message is sent to the alert log.

You can manage space in the flash recovery area by increasing the value of the DB_RECOVERY_FILE_DEST_SIZE initialization parameter to accommodate these files and to set the DB_RECOVERY_FILE_DEST initialization parameter to a value where more disk space is available.

15.14 Monitoring Jobs

You can see the status of various jobs that run on the Audit Vault Server, such as report generation, and user entitlement or audit policy retrieval from targets.

  1. Log in to the Audit Vault Server as an administrator.
  2. Click the Settings tab.
  3. In the left navigation menu, select System.
  4. In the Status page, under Monitoring section, click Jobs.

    The Jobs window appears, listing all the jobs that have been configured. It shows the job type, current status (such as Starting), when last updated, when started, who created the job, and any messages that may result from the job.

  5. To see details for an individual job, click the Job Details icon to the extreme left of a specific job.

15.15 Scheduling Maintenance Jobs

Oracle AVDF runs some jobs on the Audit Vault Server for proper and effective functioning of the system.

Oracle recommends that you run these jobs during a period when the Audit Vault server usage is low, such as night. You can schedule these jobs as per your time zone.
  1. Log in to the Audit Vault Server as an administrator.
  2. Click Settings tab.
  3. Click System tab in the left navigation menu.
  4. In the Configuration section:
  5. To schedule a new maintenance job, select Start Time. Enter the time in hours and minutes for the maintenance job to start at a specific time. The time specified here is the time on the browser.
  6. In the Time Out (In hours) field, enter the duration of the maintenance job in hours.

    Note:

    In case the job does not complete within the duration specified, it is timed out.
  7. In the Repeat Frequency field, select the frequency of the maintenance job to be repeated.

    Note:

    This field cannot be edited, and by default the value remains Daily. The job runs at the specified start time daily.
  8. Click Save.

15.16 Downloading and Using the AVCLI Command Line Interface

You can download the AVCLI command line interface from the Audit Vault Server console.

15.16.1 About the AVCLI Command-Line Interface

Learn about the AVCLI command-line interface.

As an alternative to using the Oracle Audit Vault Server console (Web) UI, you can use the AVCLI command line interface to manage Oracle Audit Vault and Database Firewall, including registering and configuring targets and their connections to the Audit Vault Server.

You can run AVCLI from the Audit Vault Server, or download the AVCLI utility from the Audit Vault Server and install and run the utility on another computer.

The syntax used for AVCLI is similar to SQL*Plus. For example, from within AVCLI, you can use the CONNECT command to log in as another user. In addition, the AVCLI commands are not case sensitive. In this manual, the commands are entered in upper case.

Note:

Set the JAVA_HOME environment variable to point to JDK installation directory. On Windows, add %JAVA_HOME%\bin to the PATH environment variable.

See Also:

AVCLI Commands Reference for details of the available AVCLI commands.

15.16.2 Downloading the AVCLI Command Line Utility and Setting JAVA_HOME

The AVCLI utility is already installed on the Audit Vault Server. If you want to run AVCLI on a different computer, then you must download it from the Audit Vault Server console and install it on the other computer.

  1. Log in to the Audit Vault Server console as an administrator.
  2. Click the Settings tab.
  3. In the left navigation menu, select Audit Vault CLI.
  4. Click the Download AVCLI button. Save the avcli.jar file.
  5. Copy the avcli.jar file to the computer from which you want to run AVCLI. Run the command:

    java -jar avcli.jar

    The AVCLI utility is installed in the current directory with the necessary permissions. To install in a different directory, use the command:

    java -jar avcli.jar -d directory_name

  6. Set the JAVA_HOME environment variable to point to the JDK installation directory. On Windows, add %JAVA_HOME%\bin to the PATH environment variable.

15.16.3 Logging in to AVCLI

You can log in to the Audit Vault command line interface by using different methods.

15.16.3.1 About Logging in to AVCLI

You can log in to AVCLI interactively with or without a user name, and with stored credentials.

Before users log in, ensure that the JAVA_HOME environment variable in the server points to JDK installation directory. The user who logs in to AVCLI must be granted the granted the AV_ADMIN role, which you can grant by using the Audit Vault Server console.

The ways to log in are as follows:

  • By supplying a user name and password by executing the avcli command
  • Without supplying a user name and password, but you will be prompted for these credentials after you execute avcli
  • By using a stored credential, which is useful for situations in which you must run scripts.
15.16.3.2 Logging in to AVCLI Interactively

You can start AVCLI interactively at the command line with or without a user name.

Except for a few commands where it is optional, all AVCLI commands must end in a semi-colon (;). For simplicity, in this guide we use a semi-colon for all AVCLI commands.
  1. Log in to the server where AVCLI is installed as a user who has been granted the AV_ADMIN role.
  2. At the command line, use one of the following methods to log in to AVCLI:
    • Logging in with a user name: Use the following syntax:
      avcli -u username
      Enter password: password
      

      For example:

      avcli -u psmith
      AVCLI : Release 20.1.0.0.0 - Production on timestamp
      Copyright (c) 1996, 2020 Oracle.  All Rights Reserved.
      Enter password for 'psmith': password
      
      Connected to:
      Oracle Audit Vault Server 20.1.0.0.0
      
      AVCLI> 
    • Logging in without a user name: Use the following syntax:
      avcli
      AVCLI> CONNECT [username];
      

      For example:

      avcli
      
      AVCLI : Release 20.1.0.0.0 - Production on timestamp
      Copyright (c) 1996, 2020 Oracle.  All Rights Reserved.
      
      AVCLI> CONNECT psmith
      Enter password: password;
      Connected.
      

      If you do not enter a user name, then you will be prompted for one.

15.16.3.3 Storing or Overwriting Administrative Credentials

If you are the AVCLI owner (that is, you installed the AVCLI utility) you can store the credentials of one Oracle AVDF administrator in the AVCLI wallet.

Thereafter, that administrator can invoke AVCLI without providing credentials, and can also run scripts without intervention.
As a prerequisite for an administrator to be able to invoke AVCLI without credentials (non-interactively), the AVCLI owner must store that administrator's credentials. As the AVCLI owner, you can store credentials for only one administrator.
  1. As the AVCLI owner, run avcli without connecting to the Audit Vault Server.
    For example:
    avcli
    
    AVCLI : Release Release 20.1.0.0.0 - Production on timestamp
    Copyright (c) 1996, 2020 Oracle.  All Rights Reserved.
    
    AVCLI>
    
  2. Run the command STORE CREDENTIALS and provide the administrator's credentials when prompted.
    For example:
    AVCLI> STORE CREDENTIALS;
    Enter user name: username
    Enter password:password
    Re-enter password:password
    

    Any previously stored credentials will be overwritten. If this administrator's password changes, follow this procedure again to store the new credentials.

15.16.3.4 Logging in to AVCLI Using Stored Credentials

To start AVCLI without having to enter credentials, your credentials must be stored in the Audit Vault Server.

  1. Log in to the server where AVCLI is installed as a user who has been granted the AV_ADMIN role.
  2. Use one of the following methods to log in to AVCLI using stored credentials:
    • From the shell: In the Audit Vault Server console, enter the following command, which logs you in to AVCLI and connects to the Audit Vault Server:
      avcli /@
      
    • From within AVCLI: If you have invoked AVCLI from the shell without credentials (by typing avcli), connect to the Audit Vault Server by entering:
      AVCLI> CONNECT /@;
      

      For example:

      avcli
      
      AVCLI : Release 20.1.0.0.0 - Production on timestamp
      Copyright (c) 1996, 2020 Oracle.  All Rights Reserved.
      
      AVCLI> CONNECT /@;
      Connected.
      

Related Topics

15.16.4 Running AVCLI Scripts

You can run AVCLI scripts without user intervention or putting credentials inside the script.

An AVCLI script contains a series of AVCLI commands. You can run an AVCLI script from the shell. Valid AVCLI script names have a .av extension.

Here is an example AVCLI script:

#Here is an AVCLI command
start collection for secured target sample_target1 using host sample_host1 from        table SYS.AUD$;
#More AVCLI commands
#Quit command
quit;
  1. Log in to the server where AVCLI is installed as a user who has been granted the AV_ADMIN role.
  2. Use the following syntax to run the script:
    avcli -u username -f scriptname.av

    For example:

    avcli -u psmith -f myscript.av
    AVCLI : Release 20.1.0.0.0 - Production on timestamp
    Copyright (c) 1996, 2020 Oracle.  All Rights Reserved.
    Enter password for 'psmith': password
    
    Connected to:
    Oracle Audit Vault Server 20.1.0.0.0
    
    AVCLI> the script myscript.av executes

    If you have stored administrator credentials, to run an AVCLI script, use the appropriate command below:

    • avcli /@ -f sample_script1.av

      This command uses the stored credentials, connects to the Audit Vault Server, and runs the script.

    • avcli -f sample_script2.av

      You can use the above command if you include the following command at the beginning of your script:

      connect /@

      Then the script runs using the stored credentials, and connecting to the Audit Vault Server.

15.16.5 Specifying Log Levels for AVCLI

When you run AVCLI, you can specify log levels to capture different categories of information or errors.

Oracle Audit Vault and Database Firewall writes the logs to the Audit Vault Server $ORACLE_HOME/av/log directory.
  • info: Logs informational and error messages

  • warning: Logs both warning and error messages

  • error: Logs only error messages (default)

  • debug: Logs debug, error, warning, and informational messages

To specify a log level, enter the L option. For example, to invoke AVCLI as user psmith with the log level set to warning:

avcli -l warning -u psmith
AVCLI : Release 20.1.0.0.0 - Production on timestamp
Copyright (c) 1996, 2020 Oracle.  All Rights Reserved.
Enter password for 'psmith': password

Connected to:
Oracle Audit Vault Server 20.1.0.0.0

AVCLI> 

To invoke AVCLI using a script and with the debug warning level:

avcli -l debug -f myscript.av

AVCLI : Release 20.1.0.0.0 - Production on timestamp
Copyright (c) 1996, 2020 Oracle.  All Rights Reserved.

AVCLI> Connected.

AVCLI> the script myscript.av executes

Note: You must be connected as a valid user who has been granted the AV_ADMIN role. You can do so using the CONNECT username/password directive.

15.16.6 Displaying Help and the Version Number of AVCLI

You can display help information for various AVCLI commands and find the AVCLI version number from the command line.

To display the AVCLI help information and version number:

avcli -h

If you only want to find the version number, then use the V argument:

avcli -v

15.17 Downloading the Oracle Audit Vault and Database Firewall SDK

An SDK is available for developing custom Oracle Audit Vault and Database Firewall plug-ins.

  1. Log in to the Audit Vault Server console as an administrator.
  2. Click the Settings tab.
  3. In the left navigation menu, click System.
  4. In the Status page that appears, under Monitoring, click Plug-ins.
  5. In the Plug-ins window, do not select any of the plug-ins.
  6. Click Download SDK.
  7. Select Save File and then specify a location.

15.18 Managing Database Firewalls

Management tasks for Database Firewalls include tasks such as changing the network or services configuration.

15.18.1 Changing the Database Firewall Network or Services Configuration

Learn how to change the Database Firewall network or services configuration.

See one of the topics below if you need to change a Database Firewall's network, traffic sources, or services configuration:

15.18.2 Viewing Network Traffic in a Database Firewall

You can view network traffic for debugging purposes.

  1. Log in to the Audit Vault Server console.
  2. Select the Database Firewalls tab.
  3. In the left navigation menu, select Database Firewalls.
  4. Select the specific Database Firewall instance for which the network traffic needs a check.
  5. The details of the Database Firewall instance are displayed on the page. Under Diagnostics, select Network Traffic Capture.
  6. In the Network Traffic Capture dialog, from the Duration (min) menu, set the number of minutes you want to capture. Then click the Capture button.
    In a moment, a message appears telling you that the network files were successfully captured. The capture appears in the table on this window.
  7. Select the check box for the network files that you captured, and then click the Download button. Then select a location to download the file.

15.18.3 Capturing Network Traffic in Database Firewall

Learn how to capture network traffic in Database Firewall.

You can capture traffic to a file (.pcap file type) that you can download and analyze.

To capture network traffic to a file:

  1. Log in to the Audit Vault Server console.
  2. Select the Database Firewalls tab.
  3. In the left navigation menu, select Database Firewalls.
  4. Select the specific Database Firewall instance for which the network traffic needs to be captured.
  5. The details of the Database Firewall instance are displayed on the page. Under Diagnostics, select Network Traffic Capture.
  6. In the Network Traffic Capture dialog, select the network traffic source in the field Network Interface.
  7. In the Duration (min) menu, set the number of minutes you want to capture. Then click the Capture button.
    In a moment, a message appears telling you that the network files were successfully captured. The capture appears in the table on this window.
  8. Select the specific file, and click Download for the network traffic file you want to download. Specify the location and download the traffic file in .pcap format.

15.18.4 Restarting or Powering Off Database Firewall

Use this procedure to restart or power off Database Firewall.

To restart or power off a Database Firewall:

  1. Log in to the Audit Vault Server as an administrator.
  2. Click the Database Firewalls tab.
  3. Select the specific Database Firewall you want to reboot or power off.
  4. Click the Reboot or Power Off button.

15.18.5 Removing Database Firewall from Audit Vault Server

You can remove Database Firewall from Audit Vault Server.

To remove Database Firewall from Audit Vault Server:

  1. Log in to the Audit Vault Server as an administrator.
  2. Click the Database Firewalls tab.
  3. Select the specific Database Firewall you want to remove.
  4. Click the Delete button.

15.18.6 Fetching an Updated Certificate from Database Firewall

Learn how to obtain updated certificates from Database Firewall.

You can update the Database Firewall certificate stored in the Audit Vault Server using the Audit Vault Server console. You must update this certificate when you upgrade the Database Firewall to maintain communication between the Database Firewall and the Audit Vault Server.

To update the Database Firewall certificate stored in the Audit Vault Server:

  1. After upgrading the Database Firewall, log in to the Audit Vault Server console as an administrator.
  2. Select the Database Firewalls tab.
  3. In the left navigation menu, select Database Firewalls tab.
  4. Select the specific Database Firewall instance from the list.
  5. If the Database Firewall instance is down due to certificate validation error, then the Update Certificate button appears on the page. Click this button to update the certificate.

15.18.7 Viewing Diagnostics for Database Firewall

See Also:

Viewing the Status and Diagnostics Report for Database Firewall for viewing Database Firewall diagnostics.

15.18.8 Resetting Database Firewall

Learn how to reset the Database Firewall instance.

This block contains information about the Database Firewall settings and the details of resetting a Database Firewall instance. The Reset Firewall button is available in the page that contains details of the specific Database Firewall instance. It performs a reset of the Firewall ID. The Firewall ID is a unique identification number of the Database Firewall. It is derived from the Management Interface card.

Once the reset is performed, it removes the existing monitoring point instances and creates new ones using the configuration information stored in Audit Vault Server. The monitoring point instances not listed on the Audit Vault Server are removed once the reset is performed. The captured data which is not processed is also deleted. The network setting (Management Interface) of the Database Firewall is not altered. This operation restores the network interface card settings other than the Management Interface. It also restores the proxy ports information that was stored in the Audit Vault Server.

Note:

  • Whenever the Network Interface Card is replaced, the Database Firewall ID must be reset.
  • The network setting (Management Interface) of the Database Firewall is not altered. Ensure the Database Firewall network is configured appropriately before attempting to reset Firewall ID.

The user must reset the Firewall ID in the following scenarios:

  1. After replacing the Management Interface card on the Database Firewall.
  2. After replacing an existing and configured Database Firewall instance with a newly installed Database Firewall instance.

15.18.9 Restoring Database Firewall Monitoring Points

Learn how to restore Database Firewall monitoring points.

When you restore the Audit Vault Server from a backup, you must restore the status of the Database Firewall monitoring points that are registered with the Database Firewall.

See Also:

Resetting Database Firewall for more information.



Footnote Legend

Footnote 1:

In this guide, 1 GB represents 2 to the 30th power bytes or in decimal notation 1,073,741,824 bytes.