4 Configuring Audit Vault Server
Learn about configuring Audit Vault Server.
4.1 About Configuring Audit Vault Server
Learn about configuring Audit Vault Server.
This chapter explains how to perform the initial Audit Vault Server configuration.
Note:
Audit Vault Server and Database Firewall 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:
-
Perform the initial configuration tasks at the Audit Vault Server. For example, confirm system services and network settings, and set the date and time.
-
(Optional) Configure the Audit Vault Agents.
-
(Optional) Define resilient pairs of servers for high availability.
-
(Optional) Add each Database Firewall at Audit Vault Server.
-
(Optional) Configure Oracle Audit Vault and Database Firewall to work with third party Security Information Event Management (SIEM) products that can read from Syslog.
-
(Optional) Configure Microsoft Active Directory or Open LDAP.
-
Check that the system is functioning correctly.
See Also:
-
Configuring High Availability for Audit Vault Servers for more information about configuring a resilient pair of Audit Vault Servers for high availability. Perform the initial configuration that is described in this chapter for both Audit Vault Servers.
-
Summary of Configuration Steps to understand the high level workflow for configuring Oracle Audit Vault and Database Firewall.
4.2 Changing the UI (Console) Certificate for Audit Vault Server
Learn how to change the UI certificate for Audit Vault Server.
When you first access the 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 Audit Vault Server console as a super administrator. See Using Audit Vault Server Console for more information
To change the UI certificate for the Audit Vault Server:
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.
The certificate is valid for a specific duration as listed in the table below:
Oracle AVDF Release | Validity Duration |
20.1 to 20.3 | 10 years |
20.4 | 27 months |
4.3 Specifying Initial System Settings and Options on Audit Vault Server (Required)
Learn how to specify initial system settings and options on Audit Vault Server.
4.3.1 Specifying the Server Date, Time, and Keyboard Settings
Learn how to specify the Audit Vault Server date, time, and keyboard settings.
Super administrators can change the Audit Vault Server date, time, and keyboard settings. It is important to ensure that the date and time that you set for Audit Vault Server are correct. This is because events that the server generates 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 Timestamps
Audit Vault Server stores all data in UTC. Timestamps are displayed as follows:
-
If you are accessing data interactively, for example using the Audit Vault Server console or AVCLI command line, then all timestamps 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 Audit Vault Server as
root
orsupport
, then timestamps are displayed in UTC, unless you change theTZ
environment variable for that session. -
If you are looking at a PDF or XLS report that is generated by the system, then the timestamps displayed reflect the Time Zone Offset setting in the Audit Vault Server Manage link (see procedure below).
WARNING:
Do not change the Audit Vault Server database time zone through any configuration files. Doing so causes serious problems in Audit Vault Server.
Prerequisite
Log in to Audit Vault Server console as super administrator. See Using Audit Vault Server Console for more information.
Set the Server Date, Time, and Keyboard Settings
-
Click Settings tab.
-
Click on the System tab in the left navigation menu.
-
In the Configuration tab on the main page:
Click For Oracle AVDF Release Manage 20.1 and 20.2 System Settings 20.3 and later - For Oracle AVDF 20.3 and later, click the Time & Keyboard tab in the System Settings dialog box.
-
From the Timezone Offset drop down list, select your local time in relation to Coordinated Universal Time (UTC). Timezone Offset is used in non-interactive scheduled PDF or XLS reports. The time set here is converted to local time and is displayed in Event Time field of the report.
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.
Note:
To change the time only for the console and to the specific user session, follow the steps in Changing the Time Zone. This functionality is available starting with Oracle AVDF release 20.6. -
From the Keyboard drop down list, select the keyboard setting.
-
In the System Time field, select Set Manually or Use NTP.
Selecting NTP synchronizes time with the average of the time recovered from the time servers specified in the NTP Server 1/2/3 fields.
-
Select Use NTP, and then select Synchronize Periodically 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.
-
Optionally select Synchronize Once After Save, to synchronize the time once when you click Save.
-
In the NTP Server 1, NTP Server 2, and NTP Server 3 sections 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 Services dialog under System tab is used for name resolution.
-
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.
-
Click Save.
Note:
- In case of high availability environment the steps above change the time only on the primary Audit Vault Server.
- In case of NTP, specify the IP address of the default gateway and a DNS server to enable time synchronization.
Set the Time on Secondary Audit Vault Server
In case of high availability environment it is important that the primary and secondary Audit Vault Servers must have same time. Follow the steps below to manually set the time on the secondary Audit Vault Server.
For Oracle AVDF 20, follow these steps:
-
Log in to the secondary Audit Vault Server as root user.
-
Run the following commands:
systemctl stop monitor
systemctl stop controller
systemctl stop dbfwdb
systemctl stop asmdb
-
Set the date and time by running the following command:
date -s "Day Month DD HH:MM:SS UTC YYYY"
For example:
date -s "Fri Jun 02 07:51:17 UTC 2021"
-
Run the following commands:
systemctl start asmdb
systemctl start dbfwdb
systemctl start controller
systemctl start monitor
- Verify the high availability status. It should be
High Availability mode is enabled
.
For Oracle AVDF 12.2, follow these steps:
-
Log in to the secondary Audit Vault Server as root user.
-
Run the following commands:
/etc/init.d/monitor stop
/etc/init.d/controller stop
/etc/init.d/dbfwdb stop
/etc/init.d/asmdb stop
-
Set the date and time by running the following command:
date -s "Day Month DD HH:MM:SS UTC YYYY"
For example:
date -s "Fri Jun 02 07:51:17 UTC 2021"
-
Run the following commands:
/etc/init.d/asmdb start
/etc/init.d/dbfwdb start
/etc/init.d/controller start
/etc/init.d/monitor start
- Verify the high availability status. It should be
High Availability mode is enabled
.
4.3.2 Changing the Time Zone
Learn how to change the time zone in the Audit Vault Server console only for the active session.
The time can be changed in the Audit Vault Server console only for the active session. This is limited only for the console (User Interface). This functionality is available starting with Oracle AVDF release 20.6. Follow these steps:
4.3.3 Specifying Audit Vault Server System Settings
Learn about configuring Audit Vault Server system settings.
4.3.3.1 Changing the Primary Audit Vault Server Network Configuration
The Oracle Audit Vault and Database Firewall (Oracle AVDF) installer configures the initial network settings for Audit Vault Server during installation. You can change the network settings after installation.
Related Topics
4.3.3.2 Changing the Standby Audit Vault Server Network Configuration
Learn how to change the standby Audit Vault Server network configuration.
Starting with Oracle AVDF release 20.7, the network settings of the standby Audit Vault Server can be configured using the primary Audit Vault Server console.
To configure the standby Audit Vault Server network settings:
4.3.3.3 Configuring or Changing the Audit Vault Server Services
Learn how to configure and change the Audit Vault Server sevices.
To configure the Audit Vault Server services:
4.3.3.4 Changing the Standby Audit Vault Server System Settings
Learn how to change the system settings for the standby Audit Vault Server.
Starting with Oracle AVDF release 20.7, the system settings of the standby Audit Vault Server can be changed using the primary Audit Vault Server console.
To configure the standby Audit Vault Server system settings:
4.3.3.5 Changing IP Addresses of Active and Registered Agents
Learn about changing the IP addresses of active and registered Agents.
Use this procedure to change the IP address of a live registered Agents without affecting the functionality of the Audit Vault Agent.
Prerequisites
-
Stop all audit trails managed by the specific Audit Vault Agent. See section Stopping, Starting, and Autostart of Audit Trails in Oracle Audit Vault Server for more information.
-
Stop Audit Vault Agent before changing the IP address of the 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 Agent
4.3.3.6 Updating the Audit Vault Server IP Address in the NTP Configuration File
After updating the Audit Vault Server IP address, if you're using
Network Time Protocol (NTP), you need to update the
/etc/ntp.conf
file.
Prerequisite
Update the Audit Vault Server IP address. See Changing the Primary Audit Vault Server Network Configuration.
Procedure
- Log into the Audit Vault Server console as an administrator.
- Click the Settings tab.
- Click the System in the left navigation menu.
- Under Configuration, click System Settings (Manage in Oracle AVDF 20.2 and earlier).
- For Oracle AVDF 20.3 and later, click the Time & Keyboard tab in the System Settings dialog box.
-
Select Set Manually.
This updates
/etc/ntp.conf
. - Check the
/etc/ntp.conf
file to verify that the IP address has changed. -
In the System Settings dialog box, select Use NTP and enter the NTP server IP addresses or names.
For details on the field values, see Specifying the Server Date, Time, and Keyboard Settings.
- Click Save.
4.3.4 Configuring Audit Vault Server Syslog Destinations
Learn how to configure Audit Vault Server syslog destinations.
Use the following procedure to configure the types of syslog messages to send from 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.
Note:
Syslog message is sent to the destination machine. The message is not written to the Audit Vault Server /var/log/message file.Prerequisites
-
Log in to the Audit Vault Server console as a super administrator. See Using Audit Vault Server Console for more information.
-
Ensure that the IP addresses provided for syslog destinations are on a different host than the Audit Vault Server.
4.3.5 Configuring Custom Ports on Network Interfaces
Learn how to configure custom ports on network interfaces in standalone and high availability environment.
Oracle Audit Vault and Database Firewall requires TCP and
TCPS based external SQL access. By default, the TCP and TCPS ports
are 1521 and 1522 respectively.
Oracle
Audit Vault and Database Firewall supports the configuration of
more
than one set of custom ports.
User-defined
ports are also used for SQL connections. As a
super administrator
user you can specify a
custom TCP and TCPS port for SQL communication on Oracle Audit Vault
Server. Custom ports can be configured for network interfaces in
standalone and high availability environment. Upon configuring a
custom port, SQL communication is enabled and added to the network
configuration.
Follow these instructions while performing backup and restore operations. If you configured a custom port before performing the backup operation, then the port should remain as you configured it during the restore operation.
To configure custom ports on a primary network interface:
Note:
The commands in the procedure below must be executed only on the primary Audit Vault Server in a high availability environment.4.4 Configuring the Email Notification Service
Learn about configuring the email notification service.
4.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.
4.5 Configuring Archive Locations and Retention Policies
Learn about configuring archive locations and retention policies.
Note:
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.
- Deleting or truncating records in the
<AVSYS>.EVENT_LOG
table is not supported in Oracle Audit Vault and Database Firewall (AVDF) 12.2. This table is automatically managed and partitioned by the appliance. To remove all test data, the only option is to rebuild the Oracle AVDF server. TheEVENT_LOG
data is encrypted, unmodifiable, and managed internally by retention policies.
4.5.1 About Archiving and Retrieving Data in Oracle Audit Vault and Database Firewall
Learn about archiving and retrieving data in Oracle Audit Vault and Database Firewall.
Data files are archived as part of an information lifecycle strategy. Oracle Audit Vault and Database Firewall release 20.1.0.0.0 supports automatic archival of a job only for NFS configured locations. When the online period of the data on the tablespace expires, it is automatically archived without your intervention. You have a choice to enable automatic archival during a fresh installation of Oracle Audit Vault and Database Firewall in release 20.1.0.0.0. Or, you can manually archive jobs with the desired settings.
When you upgrade to Oracle Audit Vault and Database Firewall release 20.1.0.0.0 from an older release, the system continues to use manual archiving. You have to enable automatic archiving of jobs post upgrade.
You can switch between automatic and manual job archiving. If there is a job in progress during the switch over, then the change occurs after the active job is completed. A suitable message is displayed to the user. After you switch to automatic archiving, all of the existing NFS locations are configured into an automatic archiving list. They are listed under Manage Archive Locations. If the space in archive location is full or inaccessible, then automatic archiving chooses the next archive location from the list. The automatic archival functionality runs on a daily basis and archives the data that is available for archiving.
Note:
After you enable automatic archiving, manual archiving is disabled. When upgrading to a newer version in release 20.1.0.0.0, the system continues to use either the automatic or the manual archiving that you configured prior to the upgrade.You create retention policies and archive locations so that the archived data is transferred in accordance with your policies. Oracle recommends that you archive regularly in accordance with your company's policy.
Automatic archival is supported only on Network File Systems (NFS). 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 your file system. Otherwise, the data file copying may fail. Transferring large files using SCP or SMB may take a long time.
What Is a Retention Policy?
Retention policies (also called archive policies) determine how long data is retained in Oracle Audit Vault Server, when data is available for archiving, and for how long archived data can be retrieved to Oracle Audit Vault Server. An administrator creates these policies and an auditor assigns a specific policy to each target as well as to scheduled reports. The settings that you can specify in a policy are as follows:
-
Months Online: The audit data is available in Oracle Audit Vault Server for the number of months online that you specify. During this period, data is available for viewing in reports. When this period elapses, 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 Oracle Audit Vault Server.
-
Months Archived: The archived audit data can be retrieved to Oracle Audit Vault Server for the number of months specified in
Months Archived
. If you retrieve the data during this period, then it will be available again in reports. When the months archived period expires, the data can no longer be retrieved to Oracle Audit Vault Server.
Note:
Retention times are based on the event time (time it is generated). If the auditor does not select a retention policy for a target or scheduled report, Audit Vault Server uses the default retention policy (12 months for online retention, and 12 months in archives).Example
Suppose your retention policy is:
-
Months Online: 2
-
Months Archived: 4
With this retention policy, audit data that is generated during the last two months is available in Audit Vault Server. Data that is older than two months 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 but newer than six months, and can be retrieved from the archives to Oracle Audit Vault Server. Data that is older than six months is no longer available.
Updating Retention Policies Assigned to Targets
Changing the retention policy will not apply to already collected data. It will be applied to new data and in some cases can take a month for it to be applied. The cases where it takes a month is because of the optimization we have to pre-create underlying data partitions.
For example, if it is currently April and the current policy is six months online and six months in archive and then the policy is modified to be 12 months online and 12 months in archive on April 28th, the data collected in May will use the original six months online and six months in archive policy. However, starting in June the data collected will have the new 12 months online and 12 months in archive retention policy.
When new Data Collected is Older than Retention Policy Limits
When you collect audit data for a newly configured target, or from a new audit trail on an existing target, the data collected from that target may be older than the Months Online period. In fact, the data may be even be older than the Months Archived period.
For instance, suppose your retention policy is the same as the above Example. Now suppose you begin collecting audit data from a newly configured 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, then Oracle Audit Vault and Database Firewall does one of the following:
-
If this is an audit trail for a newly configured target, then 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 target, then 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
4.5.2 Defining Archive Locations
You need to 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 the 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 back up archived files. The data files in the archive location are not backed up byavbackup
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.
- Log in to the Audit Vault Server as an administrator.
See Using Audit Vault Server Console for more information.
- Click the Settings tab.
- Click Archiving in the left navigation menu.
- Click Manage Archive Locations.
- Click the Create button, and complete the fields. See the following field descriptions for more information.
- Click Save.
- Log in to the Audit Vault Server as an administrator.
See Using Audit Vault Server Console for more information.
- Click the Data Retention tab.
- Click the Remote Archiving tab in the left navigation.
- Click the Create button, and complete the fields. See the following field descriptions for more information.
- Click Save.
Field | Value |
---|---|
Transfer Method |
Select the method to transfer data from Oracle Audit Vault Server to the machine that archives the data:
If you do not select a transfer method, then the archive files will be retained in Event Data in the Audit Vault Server. |
Location Name | Enter the name of the archiving destination. This name appears as the archiving destination when you start an archive. |
Remote Filesystem |
If you use the NFS transfer method, then you can select an existing file system, or one will be created automatically based on the details of this archive location. Note: In a standalone system, you can use the
See Downloading and Using the AVCLI Command Line Interface for details about using the
|
Address | Enter the host name or IP address of the NFS server that the Audit Vault Server uses for archiving. If you use the Windows File Sharing transfer method, then specify the IP address. |
Export Directory |
If you use the NFS transfer method, then enter the
export directory of the NFS server. For example, you can create
this directory in the Note: Special characters (such as $, #, and !) are not allowed in export directory names. |
Path | Enter the path to the archive storage location.
Enter a path to a directory (not a file) and follow these
requirements for each transfer method:
|
Port |
This is the port number that secure copy (scp) uses or the Windows file share service on the machine that archives the data. You can normally use the default port number. If you selected Windows file sharing (SMB) as the transfer method, then use port 445. |
Username | Enter the account name on the machine to which the archive data will be transferred. |
Authentication Method |
If you use secure copy (scp) as the transfer method, then you can select Password Authentication and enter the login password. If you use a Linux machine, then you can select
Key-based Authentication. If you use
key-based authentication, then the administrator of the remote
machine must ensure that the file that contains the RSA key
( |
Password and Confirm Password | If you use Windows file sharing (SMB), or if you selected the password authentication method, then enter the login password for the machine that archives the data. |
Public Key | This field appears if you selected key-based
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 .
|
4.5.3 Creating and Deleting Archive and Retention Policies
Learn about creating and deleting policies.
4.5.3.1 Creating Archive and Retention Policies
You can create retention policies (also called archive policies) that an Oracle Audit Vault and Database Firewall (Oracle AVDF) auditor can apply to targets.
- Log in to the Audit Vault Server console as an administrator.
- Click the Settings tab.
- Click Archiving in the left navigation menu.
- Click Manage Policies.
- Click Create.
- Enter a name for the policy.
- In the Months Online field, enter the number of months to retain audit data on the Oracle Audit Vault Server before the data is marked for archiving.
- In the Months Archived field, enter the number of months to retain audit data in the archive location. After this time the data will be purged.
- Optional - Starting with Oracle AVDF Release 20.7, if you're signed in as a super administrator you can set the policy as the default by selecting Set as default.
- Log in to the Audit Vault Server console as an administrator.
- Click the Data Retention tab.
- Click Retention Policies in the left navigation menu.
- Click Create.
- Enter a name for the policy.
- In the Months Online field, enter the number of months to retain audit data on the Oracle Audit Vault Server before the data is marked for archiving.
- In the Months Archived field, enter the number of months to retain audit data in the archive location. After this time the data will be purged. The default value is 6.
- Optional - If you're signed in as a super administrator you can set the policy as the default by selecting Set as default.
- Click Save.
Months Online
When a target uses an assigned retention policy, the audit data will be available online in the Audit Vault Server for the specified amount of months before moving to the archive location.
Note:
After the months online period expires, the data is no longer visible in reports. Data is removed from the online view and is available in the archive location. You can't delete the online data manually.Months Archived
When a target uses an assigned retention policy, the audit data will be available in the archive location for the specified amount of months before being purged. While it is in the archive location it is available to be retrieved back online to the Audit Vault Server.
Note:
See Setting a Data Retention (Archiving) Policy for instructions on assigning retention policies.
4.5.3.2 Deleting Archive and Retention Policies
You can delete user-defined retention policies (also called archive policies) that are not assigned to any target databases.
- Log in to the Oracle Audit Vault Server console as an administrator.
- Click the Settings tab.
- Click Archiving in the left navigation menu.
- Click Manage Policies.
- Under User-defined Policy, select the policy to delete.
- Click Delete.
- Log in to the Audit Vault Server console as an administrator.
- Click the Data Retention tab.
- Click Retention Policies in the left navigation menu.
- Select a minimum of one user-defined retention policies from the list.
- Click Delete.
- Click Ok in the dialog box to confirm deletion of the selected policies.
4.6 Managing Archival and Retrieval in High Availability Environments
Learn how to manage 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 Audit Vault Servers have the same number of NFS archive locations. This is crucial for archiving and file management functionality to work effectively in a high availability environment.
Note:
- Any user with admin privileges can perform archival and retrieval tasks.
- It is recommended that NFS archive locations for primary and secondary Audit Vault Servers are on separate NFS servers.
- It is recommended to have these NFS servers within the same Data Center as the Audit Vault Server. As in the NFS server for primary Audit Vault Server should be in the same data center and NFS server for secondary Audit Vault Server should be in the same data center.
- 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 Prerequisites for Configuring High Availability for Audit Vault Servers are satisfied before configuring high availability.
After you complete the high availability pairing, the NFS locations pertaining to both the primary and secondary Audit Vault Servers are displayed under Manage Archive Locations of the primary Audit Vault Server console. These NFS locations include those created on both the primary and secondary Audit Vault Servers before and after configuring high availability. The names of these NFS locations have the primary location name or the name defined while creating the location once high availability is configured. The Audit Vault Server console provides details of the host, export directory, and destination path for both the primary and secondary Audit Vault Servers.
Note:
Oracle Audit Vault and Database Firewall release 20.1.0.0.0 supports automatic archival on both primary and secondary Audit Vault Servers. If automatic archival is enabled on the primary Audit Vault Server, it is enabled on the corresponding secondary Audit Vault Server as well. The Audit Vault Server console displays the archive locations of the primary host with their mapped corresponding secondary locations.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 to start archiving.
Updating or Deleting NFS locations
The super admin can update or delete the NFS locations after high availability pairing of primary and secondary Audit Vault Servers. The NFS locations on both the primary and secondary Audit Vault Servers can be updated or deleted. In case the datafiles are archived, the location cannot be updated or deleted. The Location Name and the Primary Server Path or the Secondary Server Path can be updated in case high availability is enabled. However, the NFS mount point is internal and cannot be changed.
See Also:
4.7 Defining Resilient Pairs for High Availability
Learn how to define resilient pairs for high availability.
You can define resilient pairs of Oracle Audit Vault Servers, Oracle Database Firewalls, or both.
When you define a resilient pair of Oracle Audit Vault Servers, you must perform all of the configuration tasks. These tasks include adding database firewalls to the server and registering the targets on the primary Oracle Audit Vault Server.
See Also:
4.8 Registering Database Firewall in Audit Vault Server
Use this procedure to register an Database Firewall with the Audit Vault Server.
Prerequisites
-
If you are deploying more than one Database Firewall, then you must register each firewall in Audit Vault Server to enable communication among the servers. We suggest that you first configure Database Firewall using the instructions in Configuring Database Firewall.
-
You must register Database Firewalls in Audit Vault Server before you can pair them for high availability. See Configuring High Availability for Database Firewalls for more information.
-
Provide the Audit Vault Server certificate and IP address to the Database Firewall that you are registering. See Specifying the Audit Vault Server Certificate and IP Address.
-
Log in to Audit Vault Server as an administrator. See Using Audit Vault Server Console for more information.
To register Database Firewall in Audit Vault Server:
4.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 Using Audit Vault Server Console for more information.
To test your system's operation:
4.10 Configuring Fiber Channel-Based Storage for Audit Vault Server
Learn about configuring fiber channel-based storage for Audit Vault Server.
Audit Vault Server supports fiber channel-based storage. You can configure this storage during installation by performing this procedure.
To configure fiber channel-based storage for Audit Vault Server:
4.11 Fiber Channel Based Multipath in Oracle AVDF
Learn about support for multipath in Oracle AVDF.
Oracle Audit Vault and Database Firewall 20.1 and later supports fiber channel based storage with multipath. The redundant paths in multipath can enhance performance and utilize features like dynamic load balancing, traffic shaping, automatic path management, and dynamic reconfiguration. The connection to the disk can be made through two fiber channel ports.
Here are some important aspects of multipath in Oracle AVDF:
- It is not supported with ISCSI storage.
- It does not support the device xvd*.
- Multipath is supported only for Audit Vault Server installation.
- Multipath is not supported for Database Firewall installation.
- It does not support removable block devices. Check for removable block devices in the system as they can lead to installation failure.
Note:
In case there are removable block devices in the system, the following error may be encountered during Audit Vault Server installation:
ERROR: Failed to check if the disk is in multipath Traceback (most recent call last): File "/run/install/repo/partitions.py", line 386, in <module> main() File "/run/install/repo/partitions.py", line 372, in main write_partition_table( None ) File "/run/install/repo/partitions.py", line 322, in write_partition_table part_table = generate_partition_table_data(dev_list) File "/run/install/repo/partitions.py", line 243, in generate_partition_table_data raise RuntimeError("No disks detected") RuntimeError: No disks detected
4.12 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. |
|
Case 2 |
Audit Vault Server configuration with high availability. |
|
Case 3 |
Primary and secondary Audit Vault Servers with different NAT IP addresses. |
|
To add the NAT IP address of Audit Vault Server into Audit Vault Agent, follow these steps:
4.13 Monitoring Audit Vault Server
Learn how to monitor Audit Vault Server.
Monitoring enables investigation of suspicious activity, accountability for actions, and address auditing requirements for compliance.
Starting in Oracle AVDF 20.13 application auditing is enabled by default on the Audit Vault Server. Additionally, along with application audit reports, the OS audit and embedded repository audit reports are available out of the box. Application Auditing and OS and Repository Auditing in AVDF 20.13 and later
In Oracle AVDF 20.7 - 20.12, monitoring involves configuring auditing (in both embedded repository and operating system) and collecting the generated records into a shadow Audit Vault Server for analysis and reporting. The Audit Vault Server automatically configures auditing for both the operating system and the embedded repository: OS and Repository Auditing in AVDF 20.7-20.12.
4.13.1 Application Auditing
Learn how to monitor the AVDF application in Oracle AVDF 20.13 and later.
- Administrator operations
- User management and activities
- Target management
- Audit trail management
- Audit Vault Agent management
- Database Firewall management
- Auditor operations
- User management
- Global Sets management
- Audit, Database Firewall, and Alert policy activities
- Alert status changes
- Assessment report
- Target - Schedule Retrieval Jobs
Application audit records are automatically collected and available as reports for analysis. These reports are purged after six months from the date of the event.
By default, the application audit trail is purged every seven days by
the AVS_MAINTENANCE_JOB
.
Oracle recommends a minimum of 12 GB and a maximum of 30 GB of free
space on the EVENTDATA
disk for application auditing.
4.13.1.1 Viewing AVDF Application Auditing Reports
The application audit reports can be viewed by a super
auditor
on the AVDF System Report page.
-
Log in to the Audit Vault Server Console as a
super auditor
. - Click on the Reports tab.
- Click on AVDF System Reports.
- Select either the All Activity or
Application Auditing report.
The All Activity report includes all the audited activities of the AVDF appliance's application, embedded repository, and operating system.
The Application Auditing report includes all the audited activities of the AVDF appliance's application.
Records in the AVDF System Reports will be purged after six months.
You can schedule and generate these reports, Scheduling and Generating PDF or XLS Reports.
Related Topics
4.13.1.2 Disable AVDF Application Auditing
Perform the following steps to disable AVDF application auditing which is enabled by default in AVDF 20.13 and later.
Note:
Disabling application auditing is not recommended, but if application auditing is causing operational issues then it may be necessary to temporarily disable it.-
Log in to the Audit Vault Server through SSH and switch to the
root
user. -
Unlock the
avsys
account.-
Switch to the
dvaccountmgr
user.su - dvaccountmgr
-
Start SQL*Plus without the user name and password.
sqlplus /
-
Run the following command to unlock
avsys
:alter user avsys identified by <password> account unlock;
-
Exit SQL*Plus.
exit
Note:
Remember to relock theavsys
account when you've completed this task. -
-
Log in to the Audit Vault Server through SSH and switch to the
root
user. -
Switch to the
oracle
user.su - oracle
-
Start SQL*Plus as the
avsys
user.sqlplus avsys
- Execute the following to stop the AVDF application audit
trail:
avsys.app_audit.disable;
If this trail is stopped, the
AVS_MAINTENANCE_JOB
will purge the records after 28 days. - (Optional) Execute the following to stop the collection of the audit
trail:
avsys.avdf_system_audit.stop_app_audit_trail
If the application audit trail is stopped then it is redundant to stop the collection of the audit trail as the trail will be empty.
-
Lock the
avsys
account.-
Switch to the
dvaccountmgr
user.su - dvaccountmgr
-
Start SQL*Plus without the user name and password.
sqlplus /
-
Run the following command to lock
avsys
:alter user avsys account lock;
-
Exit SQL*Plus.
exit
-
4.13.1.3 Enable AVDF Application Auditing
Perform the following steps to re-enable AVDF application auditing which is enabled by default in AVDF 20.13 and later.
-
Log in to the Audit Vault Server through SSH and switch to the
root
user. -
Unlock the
avsys
account.-
Switch to the
dvaccountmgr
user.su - dvaccountmgr
-
Start SQL*Plus without the user name and password.
sqlplus /
-
Run the following command to unlock
avsys
:alter user avsys identified by <password> account unlock;
-
Exit SQL*Plus.
exit
Note:
Remember to relock theavsys
account when you've completed this task. -
-
Log in to the Audit Vault Server through SSH and switch to the
root
user. -
Switch to the
oracle
user.su - oracle
-
Start SQL*Plus as the
avsys
user.sqlplus avsys
- Execute the following to start the AVDF application audit
trail:
avsys.app_audit.enable;
- If you previously stopped the collection of the application audit
trail, execute the following to re-start the
collection:
avsys.avdf_system_audit.start_app_audit_trail
-
Lock the
avsys
account.-
Switch to the
dvaccountmgr
user.su - dvaccountmgr
-
Start SQL*Plus without the user name and password.
sqlplus /
-
Run the following command to lock
avsys
:alter user avsys account lock;
-
Exit SQL*Plus.
exit
-
4.13.2 Operating System and Repository Auditing
Learn how to audit AVDF's operating system (OS) and embedded repository.
4.13.2.1 OS and Repository Auditing in AVDF 20.13 and later
Learn how to audit the AVDF OS and repository in Oracle AVDF 20.13 and later.
4.13.2.1.1 About Auditing Operating System
Learn all about auditing of the operating system.
Audit Vault Sever enables default Oracle Linux audit configuration. The
configuration settings are available in /etc/audit/auditd.conf
file and the audit logs are recorded in /var/log/audit
directory
.
4.13.2.1.2 Audit Policies Used in Application Auditing
Learn what audit policies are used to configure application auditing in Oracle AVDF 20.13 and later.
Table 4-1 Oracle Predefined Policies Configured for Audit Vault Server
Policy Name | Description |
---|---|
|
Any failed log in events. |
|
This policy is the same as
|
|
Database Vault protected |
|
Database Vault protected |
|
Database management operations. |
|
Select any dictionary privilege except for
|
AVDF_ORA_SECURECONFIG
The AVDF_ORA_SECURECONFIG
policy audits the following except for
AVSYS
and MANAGEMENT
users.
CREATE AUDIT POLICY AVDF_ORA_SECURECONFIG
PRIVILEGES ALTER ANY TABLE, CREATE ANY TABLE, DROP ANY TABLE,
CREATE ANY PROCEDURE, DROP ANY PROCEDURE, ALTER ANY PROCEDURE,
GRANT ANY PRIVILEGE, GRANT ANY OBJECT PRIVILEGE, GRANT ANY ROLE,
AUDIT SYSTEM, CREATE EXTERNAL JOB, CREATE ANY JOB,
CREATE ANY LIBRARY,
EXEMPT ACCESS POLICY,
CREATE USER, DROP USER,
ALTER DATABASE, ALTER SYSTEM,
CREATE PUBLIC SYNONYM, DROP PUBLIC SYNONYM,
CREATE SQL TRANSLATION PROFILE, CREATE ANY SQL TRANSLATION PROFILE,
DROP ANY SQL TRANSLATION PROFILE, ALTER ANY SQL TRANSLATION PROFILE,
TRANSLATE ANY SQL,
EXEMPT REDACTION POLICY,
PURGE DBA_RECYCLEBIN, LOGMINING,
ADMINISTER KEY MANAGEMENT, BECOME USER
ACTIONS ALTER USER, CREATE ROLE, ALTER ROLE, DROP ROLE,
SET ROLE, CREATE PROFILE, ALTER PROFILE,
DROP PROFILE, CREATE DATABASE LINK,
ALTER DATABASE LINK, DROP DATABASE LINK,
CREATE DIRECTORY, DROP DIRECTORY,
CREATE PLUGGABLE DATABASE,
DROP PLUGGABLE DATABASE,
ALTER PLUGGABLE DATABASE,
EXECUTE ON DBMS_RLS,
ALTER DATABASE DICTIONARY
WHEN
'sys_context(''''USERENV'''',''''CURRENT_USER'''')
NOT IN (''''AVSYS'''', ''''MANAGEMENT'''')'
EVALUATE PER STATEMENT;
AVSYS_DV_UA_POLICY
CREATE AUDIT POLICY
statement shows the
AVSYS_DV_UA_POLICY
unified audit policy definition as
follows:
create audit policy AVSYS_DV_UA_POLICY actions component=dv
realm violation on "Audit Vault Realm",
realm success on "Audit Vault Realm",
realm access on "Audit Vault Realm",
rule set failure on "AVSYS audit command",
rule set success on "AVSYS audit command",
rule set eval on "AVSYS audit command"
Unified Audit Policy for Database Vault AVSYS Realm
AVSYS
Database Vault realm protects all AVSYS
objects including AVSYS
tables, packages, and others.
AVSYS_DV_UA_POLICY
audits all activities on the Database Vault
AVSYS
realm.
The following commands are audited by Database Vault AVSYS realm:
drop database link
drop index
drop package
drop package body
drop procedure
drop sequence
drop synonym
drop table
drop type
drop type body
drop view
delete
revoke
truncate table
MANAGEMENT_DV_UA_POLICY
CREATE AUDIT POLICY
statement shows the
MANAGEMENT_DV_UA_POLICY
unified audit policy definition as
follows:
create audit policy MANAGEMENT_DV_UA_POLICY actions component=dv
realm violation on "Audit Vault Account Manager Realm",
realm success on "Audit Vault Account Manager Realm",
realm access on "Audit Vault Account Manager Realm",
rule set failure on "MANAGEMENT audit command",
rule set success on "MANAGEMENT audit command",
rule set eval on "MANAGEMENT audit command"
Unified Audit Policy for Database Vault MANAGEMENT Realm
Management Database Vault realm protects all the MANAGEMENT
object,
includes MANAGEMENT
tables, packages, etc.
MANAGEMENT_DV_UA_POLICY
audits all activities on the Database
Vault MANAGEMENT
realm.
The following commands are audited by Database Vault MANAGEMENT
realm:
drop database link
drop index
drop package
drop package body
drop procedure
drop sequence
drop synonym
drop table
drop type
drop type body
drop view
delete
revoke
truncate table
AUDIT_DB_MGMT_POLICY
CREATE AUDIT POLICY
statement shows the
AUDIT_DB_MGMT_POLICY
unified audit policy definition and audits
all users:
create audit policy audit_db_mgmt_policy
privileges
ALTER PUBLIC DATABASE LINK,
AUDIT ANY, AUDIT SYSTEM,
CREATE ANY TRIGGER, CREATE PUBLIC DATABASE LINK,
DROP ANY DIRECTORY, DROP PUBLIC DATABASE LINK
actions
ALTER FUNCTION, ALTER PACKAGE, ALTER PROCEDURE,
ALTER TRIGGER,
CREATE PACKAGE, CREATE PACKAGE BODY, CREATE PROCEDURE,
CREATE SPFILE, CREATE TRIGGER,
DROP FUNCTION, DROP PACKAGE, DROP PROCEDURE,
DROP TRIGGER;
AUDIT_SELECT_DICTIONARY_POLICY
CREATE AUDIT POLICY
statement shows the
AUDIT_SELECT_DICTIONARY_POLICY
unified audit policy definition
and audits all users except AVSYS
and
MANAGEMENT
:
CREATE AUDIT POLICY AUDIT_SELECT_DICTIONARY_POLICY
PRIVILEGES
SELECT ANY DICTIONARY
WHEN 'sys_context(''''USERENV'''',''''CURRENT_USER'''')
NOT IN (''''AVSYS'''', ''''MANAGEMENT'''')'
EVALUATE PER STATEMENT;
4.13.2.1.3 Viewing AVDF OS and Repository Audit Report
The OS and repository audit reports can be viewed by a super
auditor
on the AVDF System Report page.
-
Log in to the Audit Vault Server Console as a
super auditor
. - Click on the Reports tab.
- Click on AVDF System Reports.
- Select one of the following reports:
- All Activity - The All Activity report includes all the audited activities of the AVDF appliance's application, embedded repository, and operating system.
- Database Auditing - The Database Auditing report includes all the audited activities of the AVDF appliance's embedded repository.
- OS Auditing - The OS Auditing report includes all the audited activities of the AVDF appliance's embedded operating system.
Records in the AVDF System Reports will be purged after six months.
You can schedule and generate these reports, Scheduling and Generating PDF or XLS Reports.
Related Topics
4.13.2.1.4 Stop AVDF Operating System and Repository Auditing
Perform the following steps to stop auditing of the AVDF operating system and embedded repository in AVDF 20.13 and later.
-
Log in to the Audit Vault Server through SSH and switch to the
root
user. -
Unlock the
avsys
account.-
Switch to the
dvaccountmgr
user.su - dvaccountmgr
-
Start SQL*Plus without the user name and password.
sqlplus /
-
Run the following command to unlock
avsys
:alter user avsys identified by <password> account unlock;
-
Exit SQL*Plus.
exit
Note:
Remember to relock theavsys
account when you've completed this task. -
-
Log in to the Audit Vault Server through SSH and switch to the
root
user. -
Switch to the
oracle
user.su - oracle
-
Start SQL*Plus as the
avsys
user.sqlplus avsys
- Execute one the following to stop the collection of the listed audit
trail:
avsys.avdf_system_audit.stop_database_trail
to stop the collection of the embedded repository's unified audit trailavsys.avdf_system_audit.stop_os_trail
to stop the collection of the OS trailavsys.avdf_system_audit.stop_avdf_trails
to stop the collection of the above trails in addition to the application audit trail - Application Auditing
It is not possible to disable the audit trail for the AVDF OS or embedded repository, however stopping the collection will prevent additional records from being stored in the AVDF System Reports.
-
Lock the
avsys
account.-
Switch to the
dvaccountmgr
user.su - dvaccountmgr
-
Start SQL*Plus without the user name and password.
sqlplus /
-
Run the following command to lock
avsys
:alter user avsys account lock;
-
Exit SQL*Plus.
exit
-
4.13.2.1.5 Start AVDF Operating System and Repository Auditing
Perform the following steps to start auditing of the AVDF operating system and embedded repository in AVDF 20.13 and later.
-
Log in to the Audit Vault Server through SSH and switch to the
root
user. -
Unlock the
avsys
account.-
Switch to the
dvaccountmgr
user.su - dvaccountmgr
-
Start SQL*Plus without the user name and password.
sqlplus /
-
Run the following command to unlock
avsys
:alter user avsys identified by <password> account unlock;
-
Exit SQL*Plus.
exit
Note:
Remember to relock theavsys
account when you've completed this task. -
-
Log in to the Audit Vault Server through SSH and switch to the
root
user. -
Switch to the
oracle
user.su - oracle
-
Start SQL*Plus as the
avsys
user.sqlplus avsys
- Execute one the following to start the collection of the listed audit
trail:
avsys.avdf_system_audit.start_database_trail
to start the collection of the embedded repository's unified audit trailavsys.avdf_system_audit.start_os_trail
to start the collection of the OS trailavsys.avdf_system_audit.start_avdf_trails
to start the collection of the above trails in addition to the application audit trail - Application Auditing
-
Lock the
avsys
account.-
Switch to the
dvaccountmgr
user.su - dvaccountmgr
-
Start SQL*Plus without the user name and password.
sqlplus /
-
Run the following command to lock
avsys
:alter user avsys account lock;
-
Exit SQL*Plus.
exit
-
4.13.2.1.6 About Purging Unified Audit Trail on the Main Audit Vault Server
Learn how to configure a purge job for unified audit data pertaining to the Audit Vault Server.
Unified audit trail data that is older than 7 days is
purged by default. This is done as part of the AVS_MAINTENANCE_JOB
that is scheduled to run daily by default. The schedule can be changed using the
Audit Vault Server console.
See Also:
Schedule Maintenance JobsFollow these steps to configure unified audit trail purge job:
4.13.2.2 OS and Repository Auditing in AVDF 20.7-20.12
Learn how to audit the AVDF OS and repository in Oracle AVDF versions 20.7 to 20.12.
4.13.2.2.1 About Auditing Operating System
Learn all about auditing of the operating system.
Audit Vault Sever enables default Oracle Linux audit configuration. The
configuration settings are available in /etc/audit/auditd.conf
file and the audit logs are recorded in /var/log/audit
directory
.
4.13.2.2.2 About Auditing Audit Vault Server Repository
Learn all about auditing of Audit Vault Server repository.
Prior to Oracle AVDF release 20.7, Audit Vault Server enables the default mixed mode auditing with the following settings:
audit_file_dest = /var/lib/oracle/admin/dbfwdb/adump
audit_sys_operations = TRUE
audit_trail = DB
Note:
The above default configuration prior to release 20.7 auditsSYS
operations and does not audit
application level schemas AVSYS
and
MANAGEMENT
.
Starting with Oracle AVDF release 20.7, pure unified auditing is
automatically enabled with additional policies to audit application schemas
AVSYS
and MANAGEMENT
.
With pure unified auditing enabled, the Audit Vault Server centralizes all auditing to a unified audit trail. For example, Database Vault audit records go to the unified audit trail. The Unifed Audit Policies are configured by default. This includes fresh installations and upgrades of Audit Vault Server to release 20.7.
With traditional auditing, operations by all administrative users (such as SYS and SYSDBA) are audited by default.
With unified auditing, if the database is not open, the top-level operations by all administrative users (such as SYS and SYSDBA) are audited. If the database is open, all secure configurations are audited (in new databases). To audit administrative users, create a unified audit policy, and then apply this policy to the users.
Note:
Your Oracle Database installation configuration might affect the auditing behavior. See the Oracle Database Security Guide for more details.Table 4-2 Oracle Predefined Policies Configured for Audit Vault Server
Policy Name | Description |
---|---|
|
Any failed log in events. |
|
Secure configuration defined by Oracle Database. |
|
Database Vault protected |
|
Database Vault protected |
|
Database management operations. |
|
Select any dictionary privilege. |
AVSYS_DV_UA_POLICY
CREATE AUDIT POLICY
statement shows the
AVSYS_DV_UA_POLICY
unified audit policy definition as
follows:
create audit policy AVSYS_DV_UA_POLICY actions component=dv
realm violation on "Audit Vault Realm",
realm success on "Audit Vault Realm",
realm access on "Audit Vault Realm",
rule set failure on "AVSYS audit command",
rule set success on "AVSYS audit command",
rule set eval on "AVSYS audit command"
Unified Audit Policy for Database Vault AVSYS Realm
AVSYS
Database Vault realm protects all AVSYS
objects including AVSYS
tables, packages, and others.
AVSYS_DV_UA_POLICY
audits all activities on the Database Vault
AVSYS
realm.
The following commands are audited by Database Vault AVSYS realm:
drop database link
drop index
drop package
drop package body
drop procedure
drop sequence
drop synonym
drop table
drop type
drop type body
drop view
delete
revoke
truncate table
MANAGEMENT_DV_UA_POLICY
CREATE AUDIT POLICY
statement shows the
MANAGEMENT_DV_UA_POLICY
unified audit policy definition as
follows:
create audit policy MANAGEMENT_DV_UA_POLICY actions component=dv
realm violation on "Audit Vault Account Manager Realm",
realm success on "Audit Vault Account Manager Realm",
realm access on "Audit Vault Account Manager Realm",
rule set failure on "MANAGEMENT audit command",
rule set success on "MANAGEMENT audit command",
rule set eval on "MANAGEMENT audit command"
Unified Audit Policy for Database Vault MANAGEMENT Realm
Management Database Vault realm protects all the MANAGEMENT
object,
includes MANAGEMENT
tables, packages, etc.
MANAGEMENT_DV_UA_POLICY
audits all activities on the Database
Vault MANAGEMENT
realm.
The following commands are audited by Database Vault MANAGEMENT
realm:
drop database link
drop index
drop package
drop package body
drop procedure
drop sequence
drop synonym
drop table
drop type
drop type body
drop view
delete
revoke
truncate table
AUDIT_DB_MGMT_POLICY
CREATE AUDIT POLICY
statement shows the
AUDIT_DB_MGMT_POLICY
unified audit policy definition and audits
all users:
create audit policy audit_db_mgmt_policy
privileges
ALTER PUBLIC DATABASE LINK,
AUDIT ANY, AUDIT SYSTEM,
CREATE ANY TRIGGER, CREATE PUBLIC DATABASE LINK,
DROP ANY DIRECTORY, DROP PUBLIC DATABASE LINK
actions
ALTER FUNCTION, ALTER PACKAGE, ALTER PROCEDURE,
ALTER TRIGGER,
CREATE PACKAGE, CREATE PACKAGE BODY, CREATE PROCEDURE,
CREATE SPFILE, CREATE TRIGGER,
DROP FUNCTION, DROP PACKAGE, DROP PROCEDURE,
DROP TRIGGER;
AUDIT_SELECT_DICTIONARY_POLICY
CREATE AUDIT POLICY
statement shows the
AUDIT_SELECT_DICTIONARY_POLICY
unified audit policy definition
and audits all users except AVSYS
and
MANAGEMENT
:
create audit policy audit_select_dictionary_policy
privileges
SELECT ANY DICTIONARY;
4.13.2.2.3 About Purging Unified Audit Trail on the Main Audit Vault Server
Learn how to configure a purge job for unified audit data pertaining to the main Audit Vault Server.
Unified audit trail data that is older than 7 days is purged by default.
This is done as part of the AVS_MAINTENANCE_JOB
that is scheduled
to run daily by default. The schedule can be changed using the Audit Vault Server
console.
See Also:
Schedule Maintenance JobsAfter configuring the unified audit trail collection in the shadow Audit Vault Server, it is recommended to configure a unified audit trail purge job in the main Audit Vault Server.
Follow these steps to configure unified audit trail purge job:
4.13.2.2.4 Storage Requirement for Main Audit Vault Server
Learn about the storage requirement for the main Audit Vault Server when auditing is enabled.
For every 1 million audit records and network events collected, the Audit Vault Server generates 3 GB of audit records as part of self auditing. The administrator must complete the sizing exercise to account for this space usage as per the deployment.
For a fresh installation of Audit Vault Server, refer to Audit Vault Sizing Guide. For an upgrade of Audit Vault Server from an older version, follow these guidelines:
-
Collect the data on the number of records (in million) generated by the Audit Vault Server for a duration of 8 days. Take this as
X
. For example, if 2 million records are generated per day, thenX is 2 * 8 = 16
. -
Now calculate the space required (
Y
) for Audit Vault Server self auditing. This includesSYSTEMDATA
andEVENTDATA
. For every million records the space required is 3 GB.Y = X multiplied by 3 GB
The administrator needs to allocate Y
GB of space in
SYSTEMDATA
and EVENTDATA
disk groups. For example,
if the system is processing 2 million audit records per day, then it requires 48 GB
storage space in both SYSTEMDATA
and EVENTDATA
for
auditing Audit Vault Server. (2 million records * 8 days * 3 GB = 48
GB
).
X = 2 * 8 = 16
Y = 16 * 3 GB = 48 GB
For auditing of Audit Vault Server to process about 2 million audit records
per day, the administrator must allocate 48 GB space in
SYSTEMDATA
and EVENTDATA
.
4.13.2.2.5 Collecting Audit Records to Shadow Audit Vault Server
Learn how to collect audit records to the shadow Audit Vault Server.
You can configure a shadow Audit Vault Server to monitor the audit trails
of the main Audit Vault Server. For example, if someone logs in to the main Audit
Vault Server and drops an AVSYS
package, the activity is audited,
and the trail is collected in the shadow Audit Vault Server for reporting and
analysis. The audit records are found in the activity reports that an auditor can access in the Audit Vault Server console. For
example, All Activity report.
When you configure a shadow Audit Vault Server, you should configure collection from both unified and OS audit trails.
Configuring these trails involves the following steps:
- Deploying Audit Vault Agent on the main Audit Vault Server
- Adding a trail on the shadow Audit Vault Server to collect data from unified audit trail in the main Audit Vault Server
- Adding a trail on the shadow Audit Vault Server to collect data from operating system audit trail in the main Audit Vault Server
4.13.2.2.6 Deploying the Audit Vault Agent on the Main Audit Vault Server
Learn how to deploy Audit Vault Agent on the main Audit Vault Server.
A shadow Audit Vault Server can be configured to monitor the audit trail of the main Audit Vault Server. To accomplish this an Audit Vault Agent must be deployed on the main Audit Vault Server.
Follow these steps:
4.13.2.2.7 Adding a Trail to Collect Data From Unified Audit Trail on the Main Audit Vault Server
Learn how to add a trail to collect data from unified audit trail on the main Audit Vault Server as an Oracle Database target.
This involves two steps on a high level:
- Registering the main Audit Vault Server as an Oracle Database target.
- Configuring the trail to collect data from the unified audit trail on the main Audit Vault Server.
4.13.2.2.7.1 Registering the Main Audit Vault Server as an Oracle Database Target
Learn how to register the main Audit Vault Server as an Oracle Database target.
4.13.2.2.7.2 Configuring Trail to Collect Data from Unified Audit Trail on the Main Audit Vault Server
Learn how to add an audit trail to collect data from the unified audit trail on the main Audit Vault Server as an Oracle Database target.
- Log in to the shadow Audit Vault Server as administrator.
- Add an audit trail for the main Audit Vault Server Oracle Database target.
- Click Targets tab.
- Identify and click the main Audit Vault Server Oracle Database target.
- In the Audit Data Collection section, click Add.
- Select the table for Audit Trail Type field.
- Select
UNIFIED_AUDIT_TRAIL
in the Trail Location field. - Select the Audit Vault Agent deployed in the Agent Host field.
- In the Agent Plugin field, select
com.oracle.av.plugin.oracle
. - Click Save.
- The audit trail is started automatically.
4.13.2.2.8 Adding a Trail to Collect Data from OS Audit Trail on the Main Audit Vault Server
Learn how to add a trail to collect data from OS audit trail on the main Audit Vault Server as a Linux target.
This involves two steps on a high level:
- Registering the main Audit Vault Server as a Linux target.
- Configuring trail to collect data from OS audit trail on the main Audit Vault Server.
4.13.2.2.8.1 Registering the Main Audit Vault Server as a Linux Target
Learn how to register the main Audit Vault Server as a Linux target.
- Log in to the shadow Audit Vault Server as an administrator.
- Click Targets tab, and then click Register.
- Select
Linux
in the Type field. - Select
6 months online and 0 months
as the Retention Policy. - Enter the Host Name of the main Audit Vault Server if DNS is configured.
- Enter the IP address of the main Audit Vault Server.
- Click Save.
4.13.2.2.9 Creating an Alert Policy to Monitor
AVREPORTUSER
, AVSAUDIT
, and
ORDS_PUBLIC_USER
Users
Oracle recommends creating an alert policy with
email notifications to monitor the AVREPORTUSER
,
AVSAUDIT
, and ORDS_PUBLIC_USER
users.
upper(:EVENT_STATUS)='FAILURE' and upper(:EVENT)='LOGON' and (upper(:USER)='AVREPORTUSER' or upper(:USER)='AVSAUDIT' or upper(:USER)='ORDS_PUBLIC_USER')
For more information see, Creating Alerts and Writing Alert Conditions in the Oracle Audit Vault and Database Firewall Auditor's Guide.
If you receive an alert you should check the event
details and take action to prevent further login attempts for the
AVREPORTUSER
, AVSAUDIT
, and
ORDS_PUBLIC_USER
users.