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 .EVENT_LOG table is not supported in Oracle Database Security Central (Oracle DBSecCentral) 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 DBSecCentral server. The EVENT_LOG data is encrypted, unmodifiable, and managed internally by retention policies.

About Archiving and Retrieving Data in Oracle Database Security Central

Learn about archiving and retrieving data in Oracle Database Security Central.

Data files are archived as part of an information lifecycle strategy. Oracle Database Security Central 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 Database Security Central Or, you can manually archive jobs with the desired settings.

When you upgrade to Oracle Database Security Central, 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, 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 Database Security Central 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 Database Security Central does one of the following:

If this is an audit trail for a newly configured target, then Oracle Database Security Central automatically archives that data as the audit trail is collected.
If this is a new audit trail for an existing target, then Oracle Database Security Central 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 Oracle Database Security Central 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

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 by avbackup because they may be located on a remote file system. In case those files are on NFS mount point, then they are accessible after restoring on a new system with the same mount points that were previously configured.

Log in to the Audit Vault Server as an administrator.

See Using Oracle Database Security Central Console for more information.
Select Data Retention.
Select Remote Archiving in the left navigation.
Select Create , and complete the fields. See the following field descriptions for more information.
Select Save.

Field	Value
Transfer Method	Select the method to transfer data from Oracle Audit Vault Server to the machine that archives the data: Secure Copy (SCP): Select if the data is archived by a Linux machine. For Secure Copy (SCP) archive locations, archive jobs fail if the remote archive server’s SSH host key changes. If an SCP archive job reports that the remote archive server’s host key has changed, then edit and save the archive location details again. If the SCP archive location existed before the upgrade and has already been used to store archived data, it cannot be revalidated through the UI. Run the following command instead: `/usr/local/dbfw/bin/os_manager avs-scp-bootstrap-hostkey <scp_address> <scp_port> <scp_host_id>` Windows File Sharing (SMB): Select if the data is archived by a Windows machine. Network File System (NFS): Select if you're using a network file share or NAS. 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 `AVCLI` utility to register a remote file system. Then you can select this file system in the Oracle Database Security Central console. This is not possible in a high availability environment. In a high availability environment, you create the archive locations through the Oracle Database Security Central console by selecting the Create New Filesystem option. See Downloading and Using the AVCLI Command Line Interface for details about using the `AVCLI` utility.
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 `/etc/exports` file of the NFS server. Ensure that the oracle user (User ID: 503) has appropriate `read` and `write` permissions to this directory. 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: Secure Copy (scp): If there is no leading slash character, the path is relative to the user's home directory. If there is a leading slash, the path is relative to the `root` directory. Windows File Sharing (SMB): Enter the share name, followed by a forward slash and the name of the folder. For example: `/sharename/myfolder`. Network File System (NFS): Enter the path relative to the export directory. For example, if the export directory is `/export_dir` and the full path to the directory that you want to designate as an archive location is `/export_dir/dir1/dir2`, then enter `/dir1/dir2` in the Path field. To put archives directly in the NFS server's export directory, enter `/` (forward slash) for the path. Select Test to validate the NFS location.
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 (`~/.ssh/authorized_keys`) has permissions set to `664`.
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`.

Related Topics

Creating and Deleting Archive and Retention Policies

Learn about creating and deleting policies.

Creating Archive and Retention Policies

You can create retention policies (also called archive policies) that an Oracle Database Security Central (Oracle DBSecCentral) auditor can apply to targets.

Log in to the Oracle Database Security Central console as an administrator.
Select Data Retention.
Select Retention Policies in the left navigation menu.
Select 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.
Select 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.

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 Database Security Central console as an administrator.
Select Data Retention.
Select Retention Policies in the left navigation menu.
Select a minimum of one user-defined retention policies from the list.
Select Delete.
Select Ok in the dialog box to confirm deletion of the selected policies.

Viewing Archived Datafiles

Learn how to view archived datafiles.

Log in to the Oracle Database Security Central console as administrator.
Select Settings.

Select Archiving in the left navigation menu.

This page lists the archived datafiles with the following details:


Table Field	Description
Target	Name of the target.
Event Month	The specific month in which the events occurred.
Datafiles	Name of the datafile.
Online data expiration date	Data is online until the specified month. Later it is offline.
Offline data expiration date	Data is offline until the specified month. Later it is purged.
Retention Policy	Specifies the online and offline duration of the data.
Archived	Specifies if data is archived externally on SCP, SMB, or NFS locations.
Archive Location	If the data is archived externally, then this field is enabled. It contains the name of the archive location. If you hover the mouse on this field, it displays the type of archive location (SCP, SMB, or NFS), IP address of the archive location, and the path to the archive directory.

Note:

A super administrator can view datafiles pertaining to all targets. An administrator can view datafiles only for the targets they have access to.

Running Archive and Retrieval Jobs

Learn how to run archive and retrieval jobs.

See “Archiving and Retrieving Audit Data”.