Registering or Removing Targets in Audit Vault Server

Learn about registering and removing targets in Audit Vault Server.

About Targets in the Audit Vault Server

Oracle Database Security Central (Oracle DBSecCentral) super administrators can create targets and grant other administrators access on those targets.

Administrators can also create targets, but the targets that they create are accessible only to the creator and to the super administrator who created the administrator.

The following guidelines apply when creating and accessing targets:

• Both super administrators and administrators can create targets.

• Super administrators can grant access on targets or target groups to specific administrators.

• Super administrators have access to all targets, and administrators have access only to those targets on which they have been granted access.

In Oracle Database 12c, if you are not using a multitenant container database (CDB), then register a target for your database as you would for previous versions of Oracle Database. If you use a CDB, then you must register a target for the CDB, as well as for each pluggable database (PDB).

Registering Targets

Before you can begin audit collection and Database Firewall monitoring, you need to register the targets that you want to audit or monitor.

Target Information

1. Log in to the Oracle Database Security Central console as an administrator.

2. Select Targets.

   Targets is selected in the left navigation menu by default. This page contains a list of configured targets. You can sort or filter the list of targets.

3. Select Register.

4. Enter the name and optionally the description for the new target.

5. Select the target type from the Type drop-down list. For example, Oracle Database.

6. Select a policy from the Retention Policy drop-down list.

   This list displays all the pre-configured policies and user-defined policies from the Archiving. If the super administrator has set a user-defined policy as the default, then that policy is selected by default. Otherwise the default value is 3 month(s) online, 6 month(s) in archive.

Audit Connection Details Tab

Enter the details to connect to the target.

The fields in this section change, depending on the target type. The following list describes all the possible fields and options that may appear.

1. Active Data Guard: For Oracle Database targets, select this checkbox if the target is an Active Data Guard database. For details, see Additional Information for Audit Collection from Oracle Active Data Guard.

2. Core (previously Basic) or Advanced: For database targets, select Advanced if you know the connection string. Otherwise, select Core.

3. Host Name / IP Address: You can use a virtual IP address.

   Tip: To improve the accuracy of using Database Discovery to discover unregistered databases, host name/IP address should be provided. This will prevent a database from being falsely labeled as unregistered.

4. Port

   Tip: To improve the accuracy of using Database Discovery to discover unregistered databases, port information should be provided. This will prevent a database from being falsely labeled as unregistered.

5. Service Name: If the target is an Oracle Database, enter the Oracle Database service name or SID.

6. Protocol: Select TCP or TCPS.

7. Connection String (previously Target Location): If you selected the Advanced option for a database target, enter the connection string or connection URL for the database. This connection string is required for the Audit Vault Agent to collect audit data, but it’s not required to deploy the Database Firewall only.

   Note:

   • For Oracle Database, the string may look like the following: jdbc:oracle:thin:@//:/hrdb

   • When you configure Oracle Real Application Clusters (Oracle RAC) as a target for Audit Vault Agent data collection, enter the SCAN listener host name.

   • If the target is a Microsoft SQL Server Cluster, you need to set a mandatory collection attribute.

8. Database User Name (previously User Name): Enter the name of an existing database user that has access to the audit data that’s generated on the target.

   Note: Only case insensitive database user names are supported for Oracle Database.

9. Password: Enter the password for the database user.

10. Test Connection: For Oracle Database and Microsoft SQL Server targets, select this to test the connection details that you just entered.

    If Oracle Oracle Database Security Central is unable to connect to the host or database, or if there are other issues, an error message displays more details so you can resolve the issue before continuing.

Audit Collection Attributes Tab

Enter audit collection attributes for the target.

1. Select Add to enter the attribute details in the Name and Value columns.

   The Audit Vault Agent may require collection attributes for some target types. The following table lists the mandatory collection attributes to enter for different target types.

   Target Type	Mandatory Collection Attributes
   Microsoft SQL Server Cluster	av.collector.clusterEnabled
   PostgreSQL	av.collector.securedTargetVersion
   Oracle Database for Transaction Log Audit Collection	AV.COLLECTOR.TIMEZONEOFFSET Note: This is the timezone offset of the Oracle Database.
   Microsoft SQL Server for Transaction Log Audit Collection	AV.COLLECTOR.TIMEZONEOFFSET Note: This is the timezone offset of the SQL Server database.
   MySQL for Transaction Log Audit Collection	AV.COLLECTOR.TIMEZONEOFFSET Note: This is the timezone offset of the MySQL database.

   Note: For PostgreSQL, enable the pgaudit extension. If this extension is disabled, the audit collection is incomplete and reports will be missing operational details.

2. Optionally use the following information to improve the audit collection rate or effectively utilize the resources of the Audit Vault Agent and Audit Vault Server.

   Note: This functionality is not applicable to the Host Monitor Agent or network trails.

   • You can improve audit collection performance and increase the audit collection rate by setting the av.collfwk.MULTI_THREADED attribute to true.

     This applies to all audit trails belonging to the target. While this configuration improves the audit collection rate, the resource (CPU and memory) requirements on the Audit Vault Agent machine also increase. There may also be an increase in resource utilization on the Audit Vault Server. Oracle recommends that you use this configuration if the target audit record generation rate is between 86 and 172 million records per day (or between 1000 to 2000 records per second).

   • The Audit Vault Agents automatically choose the best possible configuration for improving audit collection rate. This dynamic multithreaded collector functionality effectively utilizes the resources of the Audit Vault Server and Audit Vault Agent.

     This functionality is the default behavior and increases the throughput of the audit trail by increasing the number of threads when the target audit generation rate is high. It also reduces the number of threads when the target audit generation rate is low. This functionality improves the audit collection rate and can support targets generating records up to 2000 per second or 172 million per day. When the target audit generation rate is very high, the resource (CPU and memory) requirements on the Audit Vault Agent machine also increase. There may also be an increase in resource utilization on the Audit Vault Server.

     Oracle recommends that you avoid setting the av.collfwk.MULTI_THREADED attribute and rely on the dynamic multithreaded collector functionality.

     If high throughput is not required due to Audit Vault Agent machine resource constraints, then use the single-threaded collector by setting the av.collfwk.MULTI_THREADED attribute to false. This is the default behavior in Oracle Oracle Database Security Central 20.5 and earlier.

     If high throughput is always required due to an audit data generation rate of 86 to 172 million records per day, then use the static multithreaded collector (always uses maximum threads) by setting the av.collfwk.MULTI_THREADED attribute to true.

3. If you’re configuring audit collection, select Save to complete the target registration.

   To configure Database Firewall monitoring, continue with the remaining steps.

Database Firewall Monitoring Tab

Enter Database Firewall monitoring details.

1. Select Add.

2. In the Database Firewall Monitor dialog box, enter the following information on the Core (previously Basic):

   1. Database Firewall: Select a value from the list.

   2. Mode: Select one of the following deployment modes:

      • Monitoring (Out-of-Band): The Database Firewall can monitor and alert on SQL traffic, but it can’t block or substitute SQL statements.

      • Monitoring (Host Monitor): The Database Firewall can monitor and alert on SQL traffic, but it can’t block or substitute SQL statements.

      • Monitoring / Blocking (Proxy): The Database Firewall can block or substitute SQL statements.

      Note: Ensure that you select the right mode in accordance with the Database Firewall policy defined for the target. If the Database Firewall policy contains SQL blocking rules, but you select a mode for monitoring only, SQL statements are not blocked. Therefore, if you want to block SQL statements according to policy rules, use Monitoring / Blocking (Proxy) mode.

      For more information about deployment modes, see Introduction to Database Firewall Deployment.

   3. Network Interface Card: Select a value from the list.

   4. Proxy Ports: Select a value from the list.

   Note: For an Oracle RAC instance, select the network interface card (NIC) and proxy ports if you selected Monitoring / Blocking (Proxy) mode. The proxy port is not mandatory for monitoring-only modes.

3. If the target is Oracle Real Application Clusters (Oracle RAC), select the RAC Instance/Autonomous DB checkbox.

   Caution: If you set up an Oracle RAC protected database to be a scan listener, you also need to select the RAC Instance/Autonomous DB checkbox when registering the database as a target. If you don’t identify the target as a RAC database, the scan listener could redirect the client to a different IP address, bypassing the Database Firewall entirely.

4. In the Connection Details section, select Add to add a target.

   Enter the following information for each available connection to the database:

   • Host Name / IP Address

   • Port

   • Service Name (Optional, for Oracle Database only)

     For Monitoring Only (Host-Monitor) and Monitoring Only (Out-Of-Band) mode, you can enter multiple SIDs or service names, each on a separate line. For Monitoring/Blocking (proxy-mode) mode,

     • You can use one proxy port and specify multiple OSNs on the target database that are going to be processed. Specify the OSNs in a list delimited by the “" character. For example, target1\target2\target 3.

     If you provide a service name or SID, Database Firewall applies policies only to the sessions that match that service name or SID. All other traffic is ignored by default. In Monitoring/Blocking (proxy-mode) mode, that traffic is passed to the target database. You can block those sessions by selecting the Block Traffic for Unregistered Service Names checkbox on the Advanced tab.

5. Select Advanced.

6. Enter a number for Database Firewall Monitor Threads.

   The minimum and default value is 1. This controls the number of traffic handling threads in the Database Firewall monitoring point. Use due caution before modifying this value.

7. If the target database is an Oracle Database and Mode is set to Monitoring / Blocking (proxy), optionally select the Block Traffic for Unregistered Service Names checkbox to have the Database Firewall block sessions that use service names other than the one that is configured in the target Connection Details section.

8. If the database client and server are communicating over the TLS protocol, enable TLS.

   With this option, the Database Firewall acts as a TLS proxy. It serves as a TLS server for the database client and acts as a TLS client to the database server. The Database Firewall and the Audit Vault Server have access to the decrypted SQL traffic for further analysis. This feature applies only for Database Firewalls that are deployed in Monitoring / Blocking (Proxy) mode.

   1. Select Enable TLS support.

      Note: If you select this option, the Decrypt With Native Network Encryption Key checkbox is hidden.

   2. Select the certificate type under Inbound TLS (From client to DBFW).

      The TLS protocol uses the certificate to authenticate the communication participant. You can use the default certificate that is signed by the Database Firewall or a certificate that is signed by an external Certificate Authority (CA).

   3. If you use the default self-signed certificate, then select Download DBFW Certificate.

      You need to install this certificate on the database client to enable Database Firewall authentication.

   4. If you use the external CA signed certificate, then select the certificate from the drop-down list.

   5. Select the cipher suite level.

      Level 4 - strongest, is the default.

   6. If you don’t need database client authentication, then deselect Client Authentication.

      This option is available only for the inbound connection. The outbound connection is always authenticated. If you deselect this option, the Client Trusted Certificates button is disabled.

   7. To manage certificates for client authentication, select Client Trusted Certificates.

   8. Select Choose File and select the certificate on the local machine.

   9. Select Open to load the certificate and add it to the Database Firewall.

      The details of the uploaded certificate appear in the dialog box.

   10. Select Cancel to exit the dialog box.

   11. Follow a similar process to select and manage certificates and the cipher suite level under Outbound TLS (From DBFW to Database).

       To manage the certificates for server authentication, select Database Trusted Certificates.

9. If Oracle Database uses native network encryption, select Decrypt With Native Network Encryption Key to enable the decryption of traffic.

   Note: If the Enable TLS support checkbox is selected, the Decrypt With Native Network Encryption Key checkbox is hidden.

   This option also supports the retrieval of session information for Oracle Database. Complete the remaining fields as applicable.

   For Oracle Real Application Clusters (Oracle RAC) targets (if the RAC Instance/Autonomous DB checkbox is selected on the Core), enter the SCAN Listener IP address.

   For Oracle standalone database targets, enter the IP address of the database listener.

   For Microsoft SQL databases, the field is Retrieve session information from target DB. Retrieving session information is not available for any other non-Oracle database types.

   Note: Ensure that the Database Firewall is allowed to make a network connection to the database listener.

10. Optionally select the Capture Database Response checkbox to have the Database Firewall monitor the SQL response from the database.

11. Optionally select the Full Error Message checkbox to capture the database response codes and error codes.

12. Select Save in the dialog box to save the configuration for the monitoring point.

13. Select Save on the main page to save the target.

    Note: TCPS must be configured for registering Hybrid Cloud Oracle Databases. See Securing the Agent and Oracle Database Target Connection.

Note:

After registration is complete for Oracle Database targets, the following jobs are automatically submitted. Audit policy retrieval job User entitlement retrieval job Security assessment Sensitive objects retrieval job Stored procedure auditing See Viewing and Changing Settings for a Target for more details about these jobs.

See Also:

• Plug-ins That are Shipped with Oracle Database Security Central

• Audit Collection Attributes to look up requirements for a specific target type.

• Using Oracle Database Firewall with Oracle RAC to configure Oracle Database Firewall in an Oracle RAC environment.

• Working with Lists of Objects in the Oracle Database Security Central Console to sort or filter the list of targets.

• Target Locations (Connect Strings)

• Using Oracle Database Security Central Console

• Setting User Account Privileges on Targets

• Monitoring Jobs

• Assessment Reports

Modifying Targets

You can modify a target after it’s been registered.

1. Log in to Oracle Database Security Central console as an administrator.

2. Select Targets.

   Targets is selected in the left navigation menu by default. This page contains a list of configured targets. You can sort or filter the list of targets.

3. Select name of the target that you want to modify.

4. You can update the name, description, and retention policy of the target.

5. To modify the target’s Audit Connection Details or Audit Collection Attributes, select Modify.

6. Made your changes.

   1. If you change audit connection details for an Oracle Database or Microsoft SQL Server target, select Test Connection button to test the connection details that you just entered.

      If Oracle DBSecCentral is unable to connect to the host or database, or if there are other issues, an error message displays more details so you can resolve the issue before continuing.

7. Select Save.

   Note:

   If you change the name of a target, it will have the following affects:

   • The new name won't appear in Oracle Database Security Central reports until you restart the Audit Vault Agent.

   • There will be no duplicates entries for the modified target because the secured_target_id will remain the same. Additionally, there will be no impact to the audit trails or retention policies for the target.

   • In the Event log and Alerts table, the target name will not get changed for old events, but new events will get logged with new target name. So it recommended that if you are querying the Event log or Reports for any targets, that you use secured_target_id to get all the entries for the target, instead of the target name.

Related Topics

• Registering Targets

• Working with Lists of Objects in the Oracle Database Security Central console

• Using Oracle Database Security Central console

Removing Targets

Learn about removing targets.

If you no longer need to have a target registered with Oracle Database Security Central, then you can use either the console or the command-line utility to remove the target. After you have removed the target, the audit data pertaining to the target still resides in the data warehouse within its retention period (according to the archiving policy).

After you have removed a target, its identity data remains so that there will be a record of targets that have been dropped. Remove the target only if you no longer want to collect its data or if it has moved to a new host computer.

To remove a target:

1. Log in to the Oracle Database Security Central console as an administrator.

2. Select Targets.

3. The Targets in the left navigation menu is selected by default. Select the check boxes against the targets that you want to remove.

4. Select Delete button in the top right corner of the page.

   See Also:

   • Creating and Deleting Archive and Retention Policies for information on archiving (retention) policies.