mplementations
that require Secure Sockets Layer (SSL) to be utilized must decide
which method to use when implementing SSL. The three (3) most common
methods are SSL Offloading, SSL Terminated at the Web Server, and Full
SSL. There are additional options that can be selected in conjunction
with one of these primary methods. Those will be discussed later.
The simplest and thankfully most common method for implementing SSL with the EPM Suite is SSL Offloading. Offloading refers to moving the SSL Certificates to a Load Balancer. This is a physical device that is used for load balancing network traffic to the EPM System. Offloading requires no SSL specific configurations within the EPMS Suite. Placing the SSL Certificates on a physical device also eliminates any performance concerns that can sometime arise from the use of SSL. It also simplifies maintenance associated with SSL Certificates within an organization by keeping all SSL Certificates in a single location.
The second option, SSL Terminated at the Web Server is more involved, however still fairly straight forward. By default most of the EPM System web components are accessed through OHS (Oracle HTTP Server) through redirects within the OHS configuration. Oracle is working to integrate the remaining components into OHS. The few that are not currently accessed, FDM for example can be added to the OHS configuration by modeling existing redirects. This creates a single point of entry for all EPMS web applications. SSL Certificates are assigned to the OHS web server and entries are added to the OHS configuration to direct inbound traffic to use SSL (HTTPS). By securing communication between clients and the OHS server(s) using SSL, and blocking direct access to the WebLogic deployed applications through Firewalls or ACLs, the desired SSL configuration is achieved. This configuration allows for non-SSL communication between the OHS web servers and the WebLogic or IIS EPMS web applications. However as all of this communication is server è server, there is much less exposure to security threats. Let’s face it, if someone can trace your backend network traffic you have bigger concerns!
The final option and by far the most complex is using SSL for both client è server communication, as well as backend server è server communication. In addition to securing OHS using SSL, all communication between OHS and the WebLogic and IIS web applications is also secured. This requires creating SSL certificates for each WebLogic server and each IIS web server. The SSL certificates must then be added to the WebLogic and IIS configurations. The EPM System must also be configured to use HTTPS for all internal communication. Given the ‘chattiness’ of the EPMS internal communications using Full SSL can have a significant performance impact. This configuration also adds to the complexity of supporting Oracle EPMS and increases maintenance as SSL Certificates are typically good for 2 years or less.
There are two additional options for using SSL within an EPMS deployment. The first is using SSL between Oracle EPMS Shared Services and the corporate External Authentication Directory, MSAD or LDAP. This is typically not a decision made by the implementation team or project, but is more of a corporate standard. This simply secures communications between the Foundation Server and the Active Directory or LDAP servers within the corporate domain. Traffic between the EPMS Components and their RDBMS server can also be secured through SSL. This is less common and requires more setup on the RDBMS side than with the Oracle EPMS configuration. The connection string given to the EPMS implementation team must contain the correct SSL parameters, and the SSL certificates must be added to the RDBMS clients for each EPMS server.
SSL is becoming more and more common within the Oracle EPMS landscape. If you’re considering implementing SSL with you EPMS deployment, please consider carefully your choices as your decisions will affect more than the initial configuration. Keep in mind other security holes in your environment and how to get the best security for your efforts.
The simplest and thankfully most common method for implementing SSL with the EPM Suite is SSL Offloading. Offloading refers to moving the SSL Certificates to a Load Balancer. This is a physical device that is used for load balancing network traffic to the EPM System. Offloading requires no SSL specific configurations within the EPMS Suite. Placing the SSL Certificates on a physical device also eliminates any performance concerns that can sometime arise from the use of SSL. It also simplifies maintenance associated with SSL Certificates within an organization by keeping all SSL Certificates in a single location.
The second option, SSL Terminated at the Web Server is more involved, however still fairly straight forward. By default most of the EPM System web components are accessed through OHS (Oracle HTTP Server) through redirects within the OHS configuration. Oracle is working to integrate the remaining components into OHS. The few that are not currently accessed, FDM for example can be added to the OHS configuration by modeling existing redirects. This creates a single point of entry for all EPMS web applications. SSL Certificates are assigned to the OHS web server and entries are added to the OHS configuration to direct inbound traffic to use SSL (HTTPS). By securing communication between clients and the OHS server(s) using SSL, and blocking direct access to the WebLogic deployed applications through Firewalls or ACLs, the desired SSL configuration is achieved. This configuration allows for non-SSL communication between the OHS web servers and the WebLogic or IIS EPMS web applications. However as all of this communication is server è server, there is much less exposure to security threats. Let’s face it, if someone can trace your backend network traffic you have bigger concerns!
The final option and by far the most complex is using SSL for both client è server communication, as well as backend server è server communication. In addition to securing OHS using SSL, all communication between OHS and the WebLogic and IIS web applications is also secured. This requires creating SSL certificates for each WebLogic server and each IIS web server. The SSL certificates must then be added to the WebLogic and IIS configurations. The EPM System must also be configured to use HTTPS for all internal communication. Given the ‘chattiness’ of the EPMS internal communications using Full SSL can have a significant performance impact. This configuration also adds to the complexity of supporting Oracle EPMS and increases maintenance as SSL Certificates are typically good for 2 years or less.
There are two additional options for using SSL within an EPMS deployment. The first is using SSL between Oracle EPMS Shared Services and the corporate External Authentication Directory, MSAD or LDAP. This is typically not a decision made by the implementation team or project, but is more of a corporate standard. This simply secures communications between the Foundation Server and the Active Directory or LDAP servers within the corporate domain. Traffic between the EPMS Components and their RDBMS server can also be secured through SSL. This is less common and requires more setup on the RDBMS side than with the Oracle EPMS configuration. The connection string given to the EPMS implementation team must contain the correct SSL parameters, and the SSL certificates must be added to the RDBMS clients for each EPMS server.
SSL is becoming more and more common within the Oracle EPMS landscape. If you’re considering implementing SSL with you EPMS deployment, please consider carefully your choices as your decisions will affect more than the initial configuration. Keep in mind other security holes in your environment and how to get the best security for your efforts.
No comments:
Post a Comment