The Audit Vault Server installs in a secure state by default. Therefore, it is important to be careful if changing default settings, as this may result in a less secure state. For details of the installation, see the Oracle Audit Vault and Database Firewall Installation Guide.
Consider the following guidelines to protect your data:
Account Names and Passwords: Use secure passwords for the Audit Vault Server console UI, root, support, and sys accounts and keep these passwords safe.
Administrator Accounts: Oracle AVDF Administrator accounts should never be shared. This allows better auditing of administrator activity.
Strong Password Policies: Create password policies to force users to use strong passwords.
Installed Accounts: Oracle AVDF is installed with terminal (shell) access and embedded database accounts. You should avoid adding new accounts of this type or unlocking the existing ones, since these accounts can be used to tamper with the data or operation of the Oracle AVDF system.
Secure Archiving: Since archive data is transferred over the network, ensure that the archive destination and network infrastructure are secure.
Remote Access: Oracle AVDF allows you to set remote access permissions in the Services page of the Audit Vault Server console (Settings tab). Remote access can be granted for Web access to the console, shell (ssh), and SNMP. Follow these guidelines when granting remote access:
Grant access only if you need it for a specific task, and then revoke access when that task is completed.
Restrict access by IP address. Do this immediately after installing the system.
Grant terminal (shell) access only when doing a patch update, or when requested to do so in documentation or by Oracle support.
Oracle recommends that you follow these security recommendations:
If you are using the Database Firewall to block unwanted traffic, ensure that all data flowing from the database clients to the database and back, passes through the Database Firewall. This includes both requests and responses.
Use the appropriate security measures for your site to control access to the computer that contains the Audit Vault Server and the Database Firewall appliances. Give access only to specific users.
Ensure that passwords conform to best practice.
Separate the duties of administrators and auditors by assigning these roles to different people.
Assign users of the Audit Vault Server the appropriate administrator, super administrator, auditor, and super auditor roles.
This section is relevant to the Database Firewall.
You deploy Database Firewall between the database tier and application tier. The Database Firewall can decrypt traffic to and from an Oracle database. For non-Oracle databases, if SQL traffic between the database tier and application tier is encrypted, then the Database Firewall cannot understand or enforce protection policies on this SQL traffic.
You can use SSL termination solutions to terminate the SQL traffic just before it reaches the Database Firewall.
This section is relevant to the Database Firewall.
The Database Firewall policy enforcement relies on capturing and understanding SQL traffic between the database client and server. Because the Database Firewall only analyzes network traffic between the application tier and the database server, be aware that it cannot see SQL that is directly invoked from the database server itself. Some of the common types of SQL statements that the Database Firewall cannot see are system-provided and user-defined SQL executed from stored procedures and callouts, SQL executed from background jobs such as those that were created by the DBMS_JOB or DBMS_SCHEDULER PL/SQL packages in Oracle databases, or SQL that is indirectly executed from DDLs or other SQL statements. You can use the auditing features in Oracle AVDF to capture these types of SQL statements.
The Database Firewall builds its execution context entirely from the information that it captures from the network traffic. However, enforcement may depend on context information on the server. The lack of this context affects how an identifier used in novelty policies is resolved.
Be aware of how Oracle AVDF works with the following types of database access paths:
Non-SQL protocol access. Database platforms support different network protocols beyond the database SQL-based protocols. For example, Oracle Database supports HTTP, FTP, Advanced Queuing, Direct Path, and NFS access to the data stored in the database. The Database Firewall provides policy enforcement only for SQL-based access to the database. The protocols that the Database Firewall understands are Oracle TTC/Net and Tabular Data Stream (TDS) for Microsoft SQL Server, Sybase ASE, and IBM Distributed Relational Database Architecture (DRDA)
IPv6 Connections. Oracle AVDF does not support IPv6 deployments. The Database Firewall automatically blocks all traffic coming from an IPv6 connection.
Non-TCP-based Connections. The Database Firewall only supports TCP-based network connections to database servers. It cannot monitor connections made to database servers using non-TCP protocols such as Systems Network Architecture (SNA), Internetwork Packet Exchange/Sequenced Packet Exchange (IPX/SPX).
This section is relevant to the Database Firewall.
A shared server architecture enables a database server to permit many user processes to share few server processes. The dispatcher process directs multiple incoming network session requests to a common queue, and then redirects these session requests to the next available process of the shared server. By default, Oracle Database creates one dispatcher service for the TCP protocol. In the init.ora file, this setting is controlled by the DISPATCHERS parameter, as follows:
dispatchers="(PROTOCOL=tcp)"
In the default configuration, a dynamic port listens to the incoming connection using the TCP protocol. With a shared server configuration, many user processes connect to a dispatcher on this dynamic port. If the Database Firewall is not configured to monitor the connections on this port, then the policy cannot be enforced on these connections. To facilitate the Database Firewall connection configuration, you should explicitly include the port number in the DISPATCHERS parameter. For example:
dispatchers="(PROTOCOL=tcp)(PORT=nnnn)"
Choose a value for nnnn, and configure the Database Firewall to protect that address, alongside the usual listener address.
See also Oracle Database Administrator's Guide for more information about managing shared servers. For more information about the DISPATCHERS parameter, see Oracle Database Reference.
When the Database Firewall is in Database Policy Enforcement (DPE) mode, the secured target database only recognizes the Database Firewall's IP address, which is the IP address assigned to the Database Firewall bridge (as described in "Configuring a Bridge in the Database Firewall"). It will no longer recognize the IP addresses of the protected database's clients, and as a result, users will be unable to connect to this database.
You can remedy this problem by including the Database Firewall Bridge IP address in the TTC/Net parameter TCP.INVITED_NODES setting in the sqlnet.ora file. The TCP.INVITED_NODES parameter specifies the nodes from which clients are allowed access to the database. When you deploy the Database Firewall, you should use the policy profiles feature to implement network access restrictions similar to those provided by TCP.INVITED_NODES. The policy profiles feature in the Database Firewall supports additional factors such as IP address sets, time of day, users, and so on. See Oracle Audit Vault and Database Firewall Auditor's Guide for more information about profiles.
As described in this section, the client IP address seen by the database server is the address assigned to the bridge in the Database Firewall. This feature can affect functionality on the database server that depends on the original client IP address. Some of this functionality that can depend on the client IP address includes logon triggers, analysis of audit data, and Oracle Database Vault factors.
Client-side context. Database Firewall policies can be configured to use client-side context information such as client program name, client OS username, etc. After the client transmits this information to the database server, the Database Firewall captures it from the network. The Database Firewall does not control or enforce the integrity of the client side or network; the integrity of this information must be considered before using it to define a security policy.
Multiple databases and services on a shared listener. The Database Firewall supports policies based on Oracle Database service names. For non-Oracle databases, the Database Firewall enforces policies that are based on the IP address and port number. In a configuration where a single listener endpoint (IP_address:port) is shared among multiple databases, the Database Firewall cannot differentiate traffic directed to each individual database.