|
Oracle® Application Server Security Guide
10g Release 2 (10.1.2) B13999-03 |
|
 Previous |
 Next |
|
Oracle® Application Server Security Guide
10g Release 2 (10.1.2) B13999-03 |
|
|
Previous |
Next |
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 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:
OracleAS Forms Services, OracleAS Reports Services, and OracleBI Discoverer Developer Topology
OracleAS Single Sign-On and OracleAS Web Cache Considerations
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-Intranet architecture shown in Figure 3-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 metadata is called the Infrastructure Firewall, and so on. (See Figure 3-2, following.)
Firewalls separating DMZ zones provide two essential functions:
Blocking any traffic types that are known to be illegal
Providing intrusion containment, should successful intrusions take over processes or processors
We recommend that your DMZ zones satisfy the following criteria:
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.
|
Note: If direct Oracle Internet Directory access is required from the Internet, then Oracle Internet Directory servers 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.
|
Note: Oracle Internet Directory servers should be placed in the Infrastructure DMZ zone if they are not directly accessed from the Internet. If directly accessed from the Internet, they should be placed in the Web Server Tier zone. |
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).
From a security sense, it is acceptable for intranet-originating traffic to access HTTP servers in the Web Server Tier Zone of the DMZ. This is also true of intranet access to the Oracle Internet Directory servers, either in the Web Server Tier zone or in the Infrastructure DMZ zone. (The general rule is that outgoing messages can always go from more secure to less secure regions.)
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.
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:
No site processors are directly connected to the Internet. All incoming traffic must first be processed by DMZ-attached devices.
DMZ-attached devices are attached using switched connections, not bussed connections. This ensures that DMZ processes cannot view traffic that does not concern them. Switches that allow IP port and protocol restrictions between each pair of processors, as well as to the Internet and intranet, are best.
The Internet-to-DMZ firewall does not allow incoming Internet traffic that has sender addresses of DMZ hardware.
The Internet-to-DMZ firewall prohibits all traffic that does not match the IP port and protocol types expected by the site applications.
The DMZ-to-intranet firewall allows incoming DMZ-to-intranet messages only if they have DMZ sender addresses.
The DMZ-to-intranet firewall allows only expected traffic from specific DMZ IP addresses to specific intranet IP port addresses, using the correct protocols for each port.
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.
Figure 3-3 mod_plsql Access to Business Data
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 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.)
If X.509 client certificates are used, OracleAS Web Cache and Oracle HTTP Server are configured to permit passing certificate information from OracleAS Web Cache to Oracle HTTP Server. The exact configuration differs if OracleAS Web Cache is included in the Oracle HTTP Server processor boxes, as opposed to housing OracleAS Web Cache and Oracle HTTP Server in different processor boxes. For details, see the Oracle Application Server Installation Guide.
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.
If X.509 client certificates are used, OracleAS Web Cache and Oracle HTTP Server are configured to permit passing certificate information from OracleAS Web Cache to Oracle HTTP Server. The exact configuration differs if OracleAS Web Cache is housed in the same processor box as Oracle HTTP Server, as opposed to housing OracleAS Web Cache and Oracle HTTP Server in different processor boxes. For details, see the Oracle Application Server Installation Guide.
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.
If X.509 client certificates are used, OracleAS Web Cache and Oracle HTTP Server are configured to permit passing certificate information from OracleAS Web Cache to Oracle HTTP Server. The exact configuration differs if OracleAS Web Cache is housed in the same processor as Oracle HTTP Server, as opposed to housing OracleAS Web Cache and Oracle HTTP Server in different processors. For details, see the Oracle Application Server Installation Guide.
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
This section discusses deployment architectures for OracleAS Reports Services, OracleAS Forms Services and OracleBI 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 3-5 and Figure 3-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.
|
Note: Although the diagrams do not show this, AJP is used for communication between HTTP servers and OC4J. In the Oracle Application Server 10g release, AJP can be SSL-protected with both client-side and server-side authentication. |
The reports topology is represented in Figure 3-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 3-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 OracleBI 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 3-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.
OracleBI Discoverer architecturehas 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, OracleBI Discoverer also has a Main Servlet Viewer for browser clients and a Plus Servlet to accommodate browser palettes. All these servlets communicate to the OracleBI Discoverer server, a C program that generates the content.
Figure 3-7 Oracle Business Intelligence Discoverer
OracleBI Discoverer allows both OracleAS Single Sign-On authentication and OracleBI Discoverer native authentication. OracleAS Single Sign-On authentication is recommended for OracleBI 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.
