OAS Security Guide - Recommended Deployment Topologies

Here are some key points from the Oracle Application Server Security Guide - 
Recommended Deployment Topologies all quoted from:

   Oracle Application Server Security Guide - Recommended Deployment Topologies

Figure 3-3 (mod_plsql Access to Business Data is required)

Figure 3-2 (NO mod_plsql Access to Business Data is required - Best Practice)

All incoming Internet HTTP traffic must be processed by HTTP servers in the DMZ 
zone connected to the Internet. Because HTTP proxies do not fully process 
messages and are not a defense against cross-site scripting, directory 
traversal, and many other attacks, this means that all HTTP servers must reside 
in this zone, which is called the Web Server Tier zone. Thus, all OracleAS Web 
Cache (which is a proxy), Oracle HTTP Server and OracleAS Single Sign-On HTTP 
servers, HTTP load balancers, and HTTPS to HTTP appliances must reside in the 
DMZ zone.

CPUs that contain HTTP servers should not have direct access to the intranet if 
possible. HTTP servers are at most risk for intrusion because of their 
complexity, because they first process incoming messages, and because hackers 
tend to focus efforts on these servers. As a result, we recommend a J2EE 
Business Logic DMZ zone, where OC4J processes that must access the intranet are 
run. Thus, incoming messages are first processed in the Web Server zone and 
then forwarded using the AJP protocol to the J2EE zone for processing. OC4J 
processes may then call business databases in the intranet using SQL*Net.

We recommend that OC4J processors accessed from the Internet not be attached to 
the intranet. This provides intrusion containment in the event that an OC4J 
process is taken over. If an OC4J process were taken over, an OC4J processor 
attached to the intranet would have access to the entire intranet, since there 
would be no firewall protection.

Databases containing various types of metadata and the Oracle Internet 
Directory database are segregated in an Infrastructure DMZ zone. In previous 
releases, we recommended that processors containing this data reside in the 
intranet or in the same DMZ zone as HTTP servers. We now recommend placing 
these processors behind the Infrastructure DMZ firewall in the Infrastructure 
DMZ zone to protect their sensitive data in the event of Web server CPU 
takeover.

Other metadata files have been moved from the intranet to eliminate the 
requirement of direct HTTP Server-to--intranet access.

Some notes are appropriate:

   Applications that access the business database using mod_plsql in Oracle 
   HTTP Server require direct intranet access from the HTTP servers. In this 
   case, the J2EE firewall is eliminated because, with mod_plsql access to the 
   business data, that firewall must be configured to allow SQL*Net traffic in 
   any case (see Figure 3-3).
   
   These rules can be used for placing all components. For example, the 
   OracleAS Portal Parallel Page Engine runs as a servlet in the OC4J process. 
   Therefore, it should run in the J2EE business logic DMZ zone.

Hardware load balancers provide both scalability and high availability and are 
highly recommended when either of these requirements exists. Because load 
balancers and HTTPS-to-HTTP appliances are required in a high percentage of 
production sites, they are described in this chapter.

Generally, load balancers are needed only in front of OracleAS Web Cache, 
non-cached HTTP servers (including the OracleAS Single Sign-On Web server), and 
Oracle Internet Directory processes. This is because the Oracle infrastructure 
provides high scalability and high availability elsewhere, as shown in Figure 
3-2 and Figure 3-3.

Load balancers are often used with or contain HTTPS-to-HTTP protocol-converting 
appliances. These devices can be purchased from a number of vendors and can 
achieve rates of thousands of SSL key exchange sessions per second or higher. 
(By comparison, 500MHz Intel/UNIX systems can achieve only 20-30 SSL key 
exchanges per second, 60-90 exchanges if cryptography accelerator boards are 
used.) We strongly recommend HTTPS-to-HTTP protocol converting devices. Without 
these devices, as much as two-thirds of the CPU of a site's HTTP CPU cycles can 
be consumed by SSL operations—see the results of the SPECweb99_SSL benchmarks. 

J2EE applications form the heart of many production sites. A recommended 
architecture for J2EE applications, including Java Beans, servlets and JSPs, is 
shown in Figure 3-2.

The recommended architecture protects the intranet, because the only incoming 
access to the intranet is through OC4J processes. This discussion assumes that:

   The load balancer includes any HTTPS-to-HTTP appliances.
   
   No applications require mod_plsql access to the intranet. (Applications are 
   allowed mod_plsql access to the Infrastructure DMZ zone.)

Some applications require access to the corporate data on the intranet using 
mod_plsql modules in Oracle HTTP Server. For these applications, the J2EE zone 
does not provide any significant added security; the J2EE zone can be combined 
with the Web Server Tier zone. The reason a J2EE zone provides little added 
security is that its firewall must allow SQL*Net traffic through from the Web 
Server Tier. Because the reason for the J2EE zone's firewall is to block 
SQL*Net traffic, the justification for the firewall is eliminated.

Figure 3-3 provides a recommended architecture for applications that require 
mod_plsql access to the corporate data. This architecture is less secure than 
the architecture described in Figure 3-2, so application designers should 
consider alternatives where possible. One alternative is to access J2EE 
applications, which then make their own calls to SQL*Net. Where mod_plsql is 
used to access intranet metadata, customers might consider placing such 
metadata in the Infrastructure DMZ zone. 

Figure 3-3 assumes the following:

   Any HTTPS-to-HTTP appliances are included in the load balancers.

OracleAS Portal has special requirements because its Oracle HTTP Server process 
must be housed in the same processor box as its OC4J processes; this technical 
requirement is unique to OracleAS Portal. Figure 3-4 shows a recommended 
architecture for OracleAS Portal, as well as OracleAS Wireless and Business 
Intelligence Applications based on OracleAS Portal. Figure 3-4 assumes the 
following:

   Any HTTPS-to-HTTP appliances are included in the load balancers.
   
   OracleAS Portal metadata is housed within the Infrastructure DMZ zone.

Note:
   Because Oracle HTTP Server and OC4J are housed in the same processor box, a 
   separate zone for OC4J processes is impossible.

Figure 3-4 Portal, Wireless and Business Intelligence

   Note:455816.1 Web Cache And Portal Integration Concepts