Oracle® Application Server 10g Security Guide 10g (9.0.4) Part Number Part No. B10377-01 |
|
This chapter describes recommended architectures for deploying the Oracle Application Server 10g products to secure Internet access. These recommendations have been considerably changed since prior releases. For this reason, this chapter also includes significant detail regarding the criteria used to develop these new architectures.
This chapter presents both the criteria for configuration of firewalls and load balancers and recommended example architectures. You should focus on the criteria rather than the example architectures; although the example architectures will satisfy most customers, the criteria will help you understand how architectures are designed.
This chapter contains the following sections:
Security is becoming increasingly important as more and more Internet-accessible applications are deployed. In the past, nearly all applications were accessible only from intranets whose attackers were limited to employees or contractors. Compared to intranet-only accessible applications, Internet-accessible applications have far larger numbers of potential attackers, who have less to lose and who enjoy a greatly reduced chance of apprehension and punishment.
Internet-accessible sites must now defend themselves against attackers whom they have little chance of locating or punishing. These sites must therefore deploy firewalls and other measures to defend against determined attacks by highly skilled and knowledgeable people.
In addition to enhanced security requirements, Internet-accessible applications often have much higher scale and availability requirements than do intranet-only applications. Internet applications may be accessed by thousands of times more users, while requiring 24x7 operation to accommodate worldwide access. In response to these requirements, hardware load balancers have been developed to meet both the scale and high availability requirements of Internet-accessible applications.
This chapter presents recommended architectures for secure deployment of the core Oracle Application Server products. Although Oracle believes that these configurations will satisfy a large percentage of Oracle's customer base, Oracle makes no claims regarding the suitability of these architectures for specific customer situations. Site managers should use this chapter, especially the criteria noted for particular architectural decisions, as a guide in configuring appropriate architectures for their Internet-accessible applications.
This chapter addresses only application access originating from the Internet. It does not address test, development, or intranet-only applications configurations.
The general architectural recommendation is to use the well-known and generally accepted Internet-Firewall-DMZ-Firewall-Internet architecture shown in Figure 4-1.
In Oracle Application Server 10g, the concept of DMZ zones is introduced. In this architecture, the DMZ includes all the zones between the Internet and the intranet. These zones are separated by firewalls. This chapter names these firewalls to indicate the zone they protect from messages arriving from the Internet. Thus, the firewall between the DMZ and the Internet is called the DMZ firewall; the firewall between the DMZ and the Infrastructure databases and meta data is called the Infrastructure Firewall, and so on. (See Figure 4-2, following.)
Firewalls separating DMZ zones provide two essential functions:
We recommend that your DMZ zones satisfy the following criteria:
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.
Other metadata files have been moved from the intranet to eliminate the requirement of direct HTTP Server-to--intranet access.
Some notes are appropriate:
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 4-3).
In DMZ architectures, firewalls are deployed to ensure that only the traffic that the architecture expects is allowed to cross firewall boundaries. Firewalls also ensure that if intrusion attempts against DMZ processors are successful, the intrusion is contained within the DMZ and to as few holes in the intranet as possible. To achieve this, the component configuration must adhere to the following rules:
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 Webserver), and Oracle Internet Directory processes. This is because the Oracle infrastructure provides high scalability and high availability elsewhere, as shown in Figure 4-2 and Figure 4-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.
Text description of the illustration ascon047java_modplsql.gif
This section focuses on Enterprise Data Center topologies. These are topologies that are appropriate for production use of Internet-accessible applications. This discussion assumes that security is important and that protection of the intranet and its corporate data is essential.
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 4-2.
The recommended architecture protects the intranet, because the only incoming access to the intranet is through OC4J processes. This discussion assumes that:
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 4-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 4-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 4-3 assumes the following:
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 4-4 shows a recommended architecture for OracleAS Portal, as well as OracleAS Wireless and Business Intelligence Applications based on OracleAS Portal. Figure 4-4 assumes the following:
This section discusses deployment architectures for OracleAS Reports Services, OracleAS Forms Services and OracleAS Discoverer. All three of these products have similar architectures: they all use HTTP servers as listeners, use Java Servlets for control, and must communicate to C programs which must be co-located in the same CPU boxes as are the servlets.
In Figure 4-5 and Figure 4-6, the boxes labeled HTTP servers include Oracle HTTP Server, OracleAS Single Sign-On HTTP servers, and Oracle Application Server Web Cache. Load balancers, when required, would be included in front of the HTTP servers. The infrastructure databases, including meta-data repositories, are also part of the architecture.
The reports topology is represented in Figure 4-5. This shows the general infrastructure for J2EE applications, with the addition of the C reports engines.
There are two types of servlets. The first, the Reports servlet, provides control; the second, the Reports Server, communicates with the C Reports engines, which must be co-located with their associated servlets. The Reports engines prepare reports using input from various sources, including the Corporate Database, and then deliver the finished reports to the configured destinations using e-mail, printing, or HTTP.
Figure 4-5 shows a recommended architecture. Some configurations of OracleAS Reports Services include CGI processes rather than servlets. Because these configurations are for upward compatibility and not otherwise recommended, they are not shown here.
The OracleAS Forms Services recommended topology is similar to those for both OracleAS Reports Services and OracleAS Discoverer. In the case of OracleAS Forms Services, there are two types of servlet running in OC4J. One is the OracleAS Forms Services servlet, used for control. The second is the OracleAS Forms Services Listener servlet, used in the main data path to communicate with the OracleAS Forms Services process, which is written in C.
Figure 4-6 illustrates a recommended architecture.
OracleAS Forms Services requires that the Java and C programs must be co-located in the same CPU. However, there can be multiple CPUs containing the Java and associated C processes.
OracleAS Discoverer architecture has the same model as both OracleAS Forms Services and OracleAS Reports Services. However, it is a bit more complex because its Portlet Provider Servlet is used to provide Portal content. In addition to the Portlet Provider, OracleAS Discoverer also has a Main Servlet Viewer for browser clients and a Plus Servlet to accommodate browser palettes. All these servlets communicate to the OracleAS Discoverer server, a C program that generates the content.
OracleAS Discoverer allows both OracleAS Single Sign-On authentication and OracleAS Discoverer native authentication. OracleAS Single Sign-On authentication is recommended for OracleAS Discoverer, as it is for all Oracle Application Server products. The metadata, including the OracleAS Portal information for the Portlet Provider Servlet, is included in the Infrastructure Databases.
This section contains considerations for specific Oracle Application Server 10g components that were not covered in the previous discussions.
The Oracle Application Server Single Sign-On architecture consists of several components. These include Oracle Internet Directory; an Oracle HTTP Server which accommodates OracleAS Single Sign-On requests; OC4J processes where some of the logic is run; mod_plsql
calls to an infrastructure database; and an infrastructure database. Because OracleAS Single Sign-On is often a resource shared by multiple applications, many organizations may separate OracleAS Single Sign-On infrastructure from other applications. Where this is not done, OracleAS Single Sign-On should probably have its own processor box, so that it does not share a processor box with higher risk components, such as Oracle HTTP Server, OC4J, or the Oracle Internet Directory server, if that server is in the Web Server Tier DMZ zone.
We recommend that OracleAS Single Sign-On be configured for high availability, especially where it protects multiple applications. Although this is not a security concern, the failure of OracleAS Single Sign-On means that no OracleAS Single Sign-On-protected application can be accessed by new requestors. You should provide fault-tolerant load balancers for OracleAS Single Sign-On's Oracle HTTP Server processes, and configure Oracle Internet Directory and other infrastructure for high availability.
OracleAS Web Cache provides caching, proxy, and load balancing facilities. OracleAS Web Cache should forward HTTP and HTTPS requests only to HTTP servers within the Web Server Tier. The OracleAS Web Cache proxy facility does not protect HTTP servers against many of the common HTTP server attacks, such as cross-site scripting, double encoding, and directory traversal.
|
![]() Copyright © 2003 Oracle Corporation. All Rights Reserved. |
|