You must deploy Oracle Audit Vault Server before you can deploy the other components: the Audit Vault Agent component to collect audit data, and Oracle Database Firewall to protect databases.
Oracle Audit Vault Server performs these primary functions:
Consolidating the following data:
Audit data from Oracle Database and third-party databases, operating systems, directories, and other custom sources
Event logs from Oracle Database Firewall
Managing audit policies for Oracle Database
Managing database firewall component policies for any supported database
Reporting and distribution of unplanned or scheduled reports
Managing the system configuration including settings for Oracle Audit Vault Server itself, networking, firewalls and enforcement points, agents and agent hosts, secured targets, audit trails, high availability, storage area network (SAN) storage, archiving policies, and locations
When planning the Audit Vault Server deployment, it is important to consider the questions below. Several of these questions impact the sizing of Audit Vault Server. See the Oracle Audit Vault and Database Firewall Sizing Advice (MOS Doc ID 2223771.1) for help in estimating the amount of storage required. Work with Oracle Support team to obtain the sizing guide.
How many databases do I need to protect with Database Firewall?
How many systems (for example, databases, operating systems, file systems) am I going to need to collect audit data from? How many audit events do I expect to collect each day? Typically, if you mainly audit privileged user access or direct connections to a database, then the audit data is likely minimal up to a few hundred records every day. If you want to perform a fine-grained audit, you must first look at how much data is actually created.
The amount of data you will collect, and how long you retain it, will determine whether you upgrade to a higher capacity disk, or possibly configure SAN storage for Audit Vault Server data. Work with Oracle Support for help in estimating the amount of storage required.
How long do I need to retain data in Audit Vault Server?
Audit Vault Server lets you set data retention policies, and configure archive locations. You must determine how long you want data to be available online in Audit Vault Server before it is archived, and how long you want to retain the data in the archives before it is purged.
Retaining data online in Audit Vault Server lets you view reports based on that data. Once data is moved from Audit Vault Server into archive locations, the data is no longer visible in reports, but can be retrieved to Audit Vault Server if necessary. Once its specified archive period has ended, the archived data is deleted so the data can no longer be retrieved to Audit Vault Sever.
Before you start collecting audit data, you should define your data retention policies in Audit Vault Server, and select a retention policy for each secured target as required. Once data is collected, the selected retention policy will be applied to that data and cannot change. Changing the retention policy for a secured target applies that policy to new data from that point forward.
Do I need to configure high availability, and if so, will I have paired Audit Vault Servers, paired Database Firewalls, or both?
Remember that your network must also be resilient in order to achieve high availability for the Oracle AVDF system.
How often will I back up Audit Vault Server data and configuration?
Does my hardware support hardware acceleration, such as encryption using hardware security modules for Transparent Data Encryption (TDE)?
This is important for sizing Audit Vault Server. More CPUs are required if the CPUs do not support hardware acceleration.
Planning for high availability is an important part of deployment planning.
Within the Oracle Audit Vault and Database Firewall system, the term high availability is focused on ensuring no audit data is missed or lost. This is accomplished by configuring pairs of either Oracle Audit Vault Servers, Oracle Database Firewalls, or both. It is important to note that you must also ensure that high availability is built into the network itself.
The following figure shows a simplified illustration of an Oracle Audit Vault and Database Firewall deployment, where there are both Oracle Audit Vault Servers and database firewalls configured for high availability.
Figure 2-1 Pairs of Oracle Audit Vault Servers and Database Firewalls in High Availability Mode
With Oracle Audit Vault Server in high availability mode, during normal operation the system periodically checks the availability of the primary Oracle Audit Vault Server in the resilient pair. If the primary Oracle Audit Vault Server becomes unavailable, then the system automatically fails over to the secondary Oracle Audit Vault Server. The secondary Oracle Audit Vault Server continues to collect audit data, without loss, if the primary fails. After the former primary Oracle Audit Vault Server is repaired, it can then become the new secondary server.
With Oracle Database Firewall in high availability mode, both primary and secondary database firewalls:
After the data is stored in the database, Oracle Audit Vault Server deletes all the traffic log files from both the database firewall instances.
Oracle Audit Vault Server controls the state of the resilient pair of database firewalls. There is no communication between the database firewalls in a resilient pair. If Oracle Audit Vault Server is unable to contact the primary database firewall for an extended period of time, then Oracle Audit Vault Server collects the log files from the secondary database firewall, and promotes the secondary database firewall to be the primary.
Oracle Audit Vault and Database Firewall Administrator's Guide for detailed instructions for configuring high availability.