One of the most significant controls that can be placed in an Oracle Applications environment is to not allow direct SQL*Net connections to your database.  The underlying premise of this control is about knowing and controlling ‘where’ the access to the database is coming from, as well as (implicitly) creating a mechanism for identifying ‘who’ does the access.   

Almost all database hardening and database security Best Practices in place today have a control established to identify and restrict direct database connections to the database.  In the Oracle world, this is enforced primarily through the use of the tcp.validnode_checking and tcp.invited_nodes parameters in the sqlnet.ora file.  Usage of these parameters restricts the IP addresses that can connect to the database listener. 

Here is the syntax of the lines that need to be added to sqlnet.ora:

tcp.validnode_checking = YES
tcp.invited_nodes = (list of IP addresses)
tcp.excluded_nodes = (list of IP addresses)

 For example:

tcp.validnode_checking = YES
      tcp.invited_nodes = (192.168.1.91, visionhost.solutionbeacon.com)      

Notes:

• You cannot specify a range, wildcard, partial IP or subnet mask (ouch!)
• TCP.INVITED_NODES takes precedence over the TCP.EXCLUDED_NODES if both lists are present (although if a range cannot be specified, you will likely only utilize the invited nodes option).

In a multi-node/server configuration, the E-Business Suite Web Node, Admin Node, Forms Node and Concurrent Processing Node servers would be included in the list of invited nodes, as well as any other administrative or monitoring servers (e.g. Oracle Enterprise Manager). 

In both Release 11i and Release 12, you can also enable this capability via the Oracle Applications Manager (OAM) by clicking on the Security tab from the OAM dashboard and clicking on the ‘Manage Security Options’ on the main Security screen.

                                            Release 12 Oracle Applications Manager Security Main Screen
 

                                        Release 12 Oracle Applications Manager Manage Security Options

Clicking on the ‘Enable Restricted Access’ link will launch a wizard where you can specify a list of hosts that can access the Oracle Applications Database via SQL*Net. You need to complete the following tasks.

• Run this wizard and respond to the questions
• Run AutoConfig on Database Tier
• Bounce the TNS Listener

Specific to this practice of managing the direct database access, Oracle released a formal recommendation on security for client/server tools directly accessing any E-Business Suite environment.  MetaLink Note 277535.1’s pertinent statements are:

Oracle recommends that all components requiring direct connection to the E-Business Suite database are deployed on servers rather than on end user desktop machines. The E-Business Suite architecture mostly supports this requirement natively through a three-tier deployment in which end user browser sessions connect to a middle tier of servers running Oracle 9i Application Server. For the few exception cases in which Oracle E-Business Suite components or associated development tools are not directed through Oracle Application Server, it is recommended that they are deployed in a remote server environment using either Windows Server Terminal Services, Citrix or Tarantella.

If you are asking yourself, “What does this really mean?  Does this mean that my developers and/or production support group won’t be able to use SQL tools like TOAD?  Can’t we use our PCs anymore to connect to the database?”, then you aren’t alone.  For an explanation, let’s start with a security best practice statement:

"Good security controls reduce what can be attacked (the vulnerability surface area), as well as reducing the ways an attack can take place (an attack vector)."     Randy Giefer, 2006

The main point of the Oracle recommendation is to limit the number of direct connections to the database, which in turn can reduce the number of vulnerability surfaces and attack vectors.  The basic, underlying premise of this control is “knowing and controlling” which servers can have SQL access to the database, as well as (implicitly) creating an additional mechanism for identifying who does the access.  By placing an intermediate server with software like Citrix running on it in-between the database and the end-user/developer client PC, additional authentication, authorization, and auditing can be performed.   In our TOAD example, TOAD would be installed on the intermediate server and that server IP address would be included in the invited node list.  Developers, DBAs and others would access the intermediate server from their PC devices. 

Note: Be sure to research and adhere to licensing requirements for licensed software products when installed on Terminal Server products. 

Note: Specifically related to our TOAD example, the TOAD product has additional server-side security features that can be configured to restrict TOAD user capabilities.  It requires the DBA to install the TOAD server objects in the database and perform some additional configurations.  It needs to be noted that TOAD Security by itself is not a replacement for the "direct access" control as implementing just TOAD Security would still leave the database listener port exposed to an unmanageable and uncontrollable number of connectivity points.  However a much more secure alternative is to implement ‘invited nodes’, TOAD Security, and have the TOAD client installed on a hardened server running Windows Terminal Services or Citrix.

Note also that not all security alerts or recommendations from Oracle can be dealt with by simply applying a patch – this recommendation by Oracle to restrict direct database access is a perfect example.  As always, you may have to investigate whether an Oracle recommendation fits with your company’s needs, and find your own way to do what it suggests. 

The task to protect the database and yet allow authorized individuals appropriate access will require time and research for your unique circumstances.

^ top