Considerations for Deploying Network-Based Solutions

Learn about what to consider when deploying network-based solutions.

Monitoring Encrypted Traffic with the Database Firewall

The Database Firewall supports monitoring Native Network Encrypted (NNE) traffic if it is configured between a database client and an Oracle Database.

The Database Firewall supports monitoring TLS-encrypted SQL traffic between the database client and Oracle Real Application Clusters (Oracle RAC) as well as between a database client and an Oracle Database when the Database Firewall is deployed in proxy mode. The Database Firewall acts a TLS proxy terminating the session from the database client and creating a new TLS outbound session to the database server.

To monitor TLS traffic for non-Oracle databases, you can use TLS termination solutions to terminate TLS traffic just before it reaches the Database Firewall.

Managing Database Firewall Server Side SQL and Context Configurations

Learn how to manage Database Firewall SQL and context configurations.

Database Firewall policy enforcement relies on capturing and understanding SQL traffic between the database client and server. Because Database Firewall only analyzes network traffic between the application tier and the database server, the firewall cannot examine SQL that is directly sent from the database server. Some of the types of SQL statements that Database Firewall cannot examine are system provided and user defined SQL that you run from stored procedures and callouts. The firewall also cannot examine SQL that you run from background jobs, such as those that created by the DBMS_JOB or DBMS_SCHEDULER PL/SQL packages in Oracle databases, or SQL that is indirectly run from DDLs or other SQL statements. You can use the Oracle DBSecCentral auditing features to capture these types of SQL statements.

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. Any lack of context affects the resolution of identifiers that you use in database objects.

How Oracle DBSecCentral Works with Various Database Access Paths

Learn how Oracle DBSecCentral works with database access paths.

Oracle DBSecCentral 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 in the database. The Database Firewall provides policy enforcement only for SQL based access to the database. The protocols that Database Firewall understands are Oracle TTC/Net and Tabular Data Stream (TDS) for Microsoft SQL Server, and IBM Distributed Relational Database Architecture (DRDA).

• IPv6 Connections: Oracle DBSecCentral does not support IPv6 deployments.

• Non TCP based Connections: Database Firewall only supports TCP based network connections to database servers. It cannot monitor connections that are made to database servers using non TCP protocols such as Systems Network Architecture (SNA), Internetwork Packet Exchange/Sequenced Packet Exchange (IPX/SPX).

Database Firewall Configuration for Oracle Database Target Configured in Shared Server Mode

Learn about managing Database Firewall shared server configuration.

Shared server architectures enable databases to permit user processes to share server processes. A 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=<port-number>)"

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

• Oracle Database Reference for more information about the DISPATCHERS parameter

Additional Client and Listener Behavior Considerations

Learn about additional issues to be aware of with clients and shared listeners.

• Client-side context: You can configure Oracle Database Firewall policies to use client-side context information such as client program name, client operating system username, and so on. After the client transmits this information to the database, Oracle Database Firewall captures it from the network. Oracle Database Firewall does not control or enforce the integrity of the client side or network. Consider the integrity of this information before using it to define security policies.

• Multiple databases and services on a shared listener: Oracle Database Firewall supports policies based on Oracle Database service names. For non-Oracle databases, Oracle 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, Oracle Database Firewall cannot differentiate traffic that is directed to each individual database.