An Oracle White Paper June Exalogic Security

Transcription

1 An Oracle White Paper June 2012 Exalogic Security

2 Disclaimer The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle s products remains at the sole discretion of Oracle.

3 Executive Overview... 3 Introduction... 4 Objective / Scope... 4 General Approach to Security... 4 Compliance... 5 Assumptions... 6 Overview of Exalogic... 7 Use Cases... 7 Implementing Exalogic in an Existing Infrastructure... 8 Recommendations Overview of Control Techniques... 9 Network Operating Systems Storage Systems Management Oracle Traffic Director Conclusion References... 25

4 Executive Overview The Oracle Exalogic Elastic Cloud is an Engineered System designed to consolidate and optimize the performance of Oracle middleware and application workloads. It is composed of compute nodes, the Oracle Sun ZFS Storage Appliance, and a converged InfiniBand I/O backplane for storage and networking and the Exalogic Elastic Cloud software. Working in concert, the Oracle Exalogic system s components, when properly configured, offer the necessary level of security needed for organizations to store and process sensitive information. The Oracle Exalogic Elastic Cloud presents a level of security synergy not often found in today s systems. As a truly Engineered System, its security state is greater than the sum of its individual components. The carefully considered, designed and tested integration between the application nodes, network and storage components of Exalogic makes this possible. This paper is the introduction for the series on Exalogic security. It is the first in a series that discusses the security best practices that are recommended for an Exalogic implementation in an existing IT environment. These best practices are developed in consideration of the performance and availability requirements typical of most organizations. 3

5 Introduction The goal of this paper is to cover various use cases regarding the role of security controls in an Exalogic system and highlight Oracle recommended security practices with the intention of reducing Exalogic s overall attack surface. As with any system handling sensitive information, it should have the security controls and processes appropriate to reducing risk of loss or destruction of information to an acceptable level. As such, it should be physically secure, networked to ensure availability without exposing sensitive information, have access controls in place so that only authorized users can gain access, and have appropriate administrative and management controls. In support of this Exalogic is delivered from Oracle with various security controls that can be leveraged according to the individual needs of an organization. Objective / Scope The objective of this paper is to describe security features and practices specific to Exalogic that can be used to reduce risks to organizations through various means including security hardening, minimization, separation and isolation techniques. As there are a number of different configurations that an Exalogic solution can take, these security practices should be considered a generic baseline and not a prescriptive solution set. The scope of this paper covers the platform infrastructure components of Exalogic including: Hardware Operating System Network Storage Note that subsequent releases of this paper will discuss additional platform and application security features and their configurations as they become available. General Approach to Security Designing, implementing, and managing security for an integrated environment such as Oracle s Exalogic system requires an organization to support a framework for architecting and governing security. The general approach to security described here aligns with those contained in common standards such as those from the International Standards Organization (ISO) or those found in the Information Technology Infrastructure Library (ITIL). To ensure a comprehensive and cost effective security approach, the following should be considered: 4

6 The context of the Exalogic solution. An Exalogic system should be implemented within the context of an existing security architecture that exhibits a defense in depth strategy and a need toknow access policy. Questions such as where will the Exalogic systems reside relative to one's IT environment, from a physical and logical perspective will need to be considered. Perform a risk assessment. The only viable way to identify and implement appropriate security controls is to perform a risk assessment of the Exalogic system relative to its placement and use within an organization s larger IT infrastructure i.e., what data will it process and how will it be integrated into the overall IT architecture? Governance and management. Controls need to be implemented within an associated management infrastructure to ensure effectiveness of those controls. The management infrastructure is the governance framework that represents an organizations overall processes and methods for ensuring controls address identified risks, accountability is maintained and data confidentiality, integrity and availability are supported. ITIL and ISO offer examples of information technology and security governance frameworks. Apply appropriate security controls. Although the minimum threshold for security controls can change from one environment to another, applying a common baseline of security controls within an Exalogic system is recommended. Audit, monitor and manage all security, system changes and related activities. Default settings for items such as preconfigured user ID s and their passwords should be changed as soon as practical. Maximize the use of separation techniques to ensure the isolation of data as much as possible. Compliance A primary goal of this paper is to enable organizations to address various compliance mandates. Compliance requirements have become all pervasive in today s data processing environment and should be considered critical business drivers. These can range from legal and regulatory mandates such as HIPAA, SOX and GLBA to industry developed standards such as PCI, ISO and ANSI. Following the recommendations in this paper should help enable organizations to address different compliance requirements. For example, the guidance in this document, if followed should enable an organization to address those portions of the PCI standard applicable to separation and security of data and processing resources within the Exalogic Engineered System. Note that this does not imply that an organization would be fully compliant with PCI as the standard mandates the use of other security controls that are beyond the scope of Exalogic. As security baselines, the US Defense Information Systems Agency (DISA) UNIX Security Technical Implementation Guide (STIG), the US National Security Agency (NSA) Guide to the Secure Configuration of Red Hat Enterprise Linux or the Center for Internet Security (CIS) recommendations should be 5

7 considered. These offer guidance in areas such as: discretionary access controls, general security, file and directory permissions, system access, network services, network based authentication, restriction of services, logging, tools and backup. All of these topics should be considered when securing a UNIX based system and tailored according to the needs and security policy of a particular organization. Assumptions It is important to understand that Engineered Systems are not standalone and independently secured systems; rather as noted above, implementing security for an Exalogic system should be done within the context of a specific security architecture and overall governance framework that conforms to an organization s security policy. As such, customers should consider various security measures beyond those available and incorporated into Exalogic, to ensure the confidentiality, integrity and availability of their systems and data. Additional security measures can include external firewalls, identity and access management, intrusion detection system and cryptographic functionality. The extent of the security services implemented will depend upon which data and services are exposed by the Exalogic machine. Additional assumptions include: This paper applies to the currently released Exalogic version 1.0 and the Exalogic Elastic Cloud System release 2.0. This paper represents an approach to risk management. That means our intent is to reduce risk (or the overall attack surface as mentioned above) to a manageable level without impacting service levels. It is assumed that Exalogic is implemented in a physically secure environment so that only authorized users can access the physical servers, interfaces, cabling, consoles and other components. It is assumed that the Exalogic system can leverage standard security controls typically found within an IT infrastructure including systems management, identity provisioning, access control, monitoring and auditing, etc. That is, Exalogic does not replace existing security services and so, may rely on those already implemented by an organization as part of an existing security architecture. 6

8 Overview of Exalogic Oracle Exalogic is an Engineered System with integrated hardware and software designed to provide a complete platform for a wide range of application types and widely varied workloads. An Exalogic system is intended for large scale, performance sensitive, mission critical application deployments. It combines Oracle Fusion Middleware software and industry standard hardware to enable a high degree of isolation between concurrently deployed applications, which have varied security and availability requirements. Exalogic is designed to fully leverage an internal InfiniBand fabric that connects all of the processing, storage, memory and external network interfaces within an Exalogic machine to form a single, large computing device. Each Exalogic machine is connected to the customer's data center networks via 10 GbE (client traffic) and GbE (management) interfaces. If you are using applications that follow Oracle's best practices for highly scalable, fault tolerant systems, you do not need to make any application architecture or design changes to benefit from Exalogic. You can connect many Exalogic machines or a combination of Exalogic machines and Oracle Exadata Database Machines to develop a single, large scale environment. The Oracle Exalogic documentation noted in the reference can be found here: Use Cases Use cases provide scenarios for security controls to be implemented in an Exalogic environment. The below use cases are a sampling of activities where security plays a role. These use cases are presented to provide a guideline for developing security controls within an IT infrastructure that incorporates Exalogic. The recommendations below have been developed in consideration of these use cases. 1. Enable security and isolation of applications and processes so users cannot access any other application or process including their data and processing resources, nor even have a comprehension of their existence. 2. Enable security and isolation of administrative functions such that system administrators may only perform those functions they are authorized to perform, i.e., implement a security policy of least privilege and need to know. 3. Enable security and isolation of development, test, quality assurance and production environments run on Exalogic systems. 4. Enable and support compliance to various security standards such as PCI and HIPAA that require the confidentiality and integrity of sensitive data and processing resources. 7

9 Implementing Exalogic in an Existing Infrastructure The diagram below illustrates how Exalogic exists within the context of a security architecture. For example, a firewall DMZ has been implemented here to interrogate network traffic from the Internet and after the Oracle HTTP servers and SSL has been implemented that support the confidentiality of data. This is typical of separation in a tiered architecture where a web, application, and data tiers exist. Notice also that encryption has been implemented via HTTPS to ensure data confidentiality.. Diagram 1. Sample of an Existing Security Architecture 8

10 Recommendations Overview of Control Techniques Security and risk mitigation techniques fall into a number of broad categories. In this paper these are outlined in terms of where they apply in a traditional IT infrastructure: Network Operating System Storage Systems Management The controls described here should be integrated into either an organization's existing security architecture or within an Exalogic system itself. These represent current recommended practices from Oracle and are further elaborated below. The below diagram illustrates the primary components of Exalogic as described in the network, operating system and storage sections below. As previously noted these recommendations are not intended to be prescriptive in nature. 9

11 Diagram 2. Sample Exalogic System and Connections using InfiniBand 10

12 Network From a security standpoint a network is a means to transport data in a secure fashion. This can be accomplished through several mechanisms including cryptography (e.g., IPSec, SSH, SSL, etc) via isolation (e.g., VLANs, vnic, etc) or via firewalls since they are typically used to inspect network traffic and look for and filter out abnormal conditions. Separation, which is a basic security tenet, can be implemented for data transiting a network in an Exalogic environment through the use of VLANs. The creation and management of VLANs is beyond the scope of this document but is described in detail in the Sun Network QDR InfiniBand Gateway Switch Administration Guide noted in the reference section. One of the most common models for application isolation involves multiple IP subnetting, in which the most mission-critical applications are assigned their own IP subnets layered above the default IPoIB link of InfiniBand fabric. In this model, some subnets may also contain applications that have less stringent or otherwise different resource requirements. Other subnets may host WebLogic domains, which contain multiple applications, such as those dedicated to a given department or line of business. It is recommended that IP subnetting be implemented to provide logical network separation for Exalogic systems. The detailed procedures for setting up IP subnets are found in the Exalogic Enterprise Deployment Guide and the Exalogic Machine Owner s Guide noted in the Reference section. An Exalogic system is pre-configured to support network isolation to ensure the security of data transiting the network. The primary networks of an Exalogic system provide separation of different types of network traffic as noted below. Each network must be on a distinct and separate subnet from the others and all IP addresses must be statically assigned IP addresses, not dynamically assigned (DHCP) addresses. The diagram below provides a general schematic of the Exalogic network environment and its primary components. Each of the connections between the different nodes and switches should be secured, typically through the use of secure protocols that utilize cryptography, e.g., SSL or SSH. 11

13 Diagram 3. Example of Exalogic Networking 12

14 Management network: This required network connects to an existing management network, and is used for administrative work for all components of Exalogic. It connects ILOM, compute nodes, server heads in the storage appliance, and switches connected to the Ethernet switch in the Exalogic machine rack. This management network is in a single subnet. ILOM connectivity uses separate ILOM ports. For multi-rack configurations it is recommended to configure a single subnet per configuration. The management network should be secured for confidentiality and integrity via the implementation of SSH. It is further recommended that specific roles be defined within the management network to ensure isolation of administrative functions. InfiniBand private network: This required network connects the compute nodes and the Sun ZFS Storage 7320 appliance through the BOND0 interface to the InfiniBand gateway switches on the Exalogic rack. It is the default IP over InfiniBand (IPoIB) subnet created automatically during the initial configuration of the Exalogic machine. The InfiniBand private network is a non-routable network fully contained in the Exalogic machine, and it does not connect to ones existing network. The InfiniBand private network within the Exalogic rack functions as a backplane between nodes and can be considered to be physically secured. Client access network: This required network connects the compute nodes to your existing client network through the BOND1 interface and is used for client access to the compute nodes. Each Exalogic compute node has a single default client access (edge network) to an external 10 Gb Ethernet network through a Sun Network QDR InfiniBand Gateway Switch. This enables isolation of network traffic for each compute node. The logical network interface of each compute node for client access network connectivity is bonded. Bond1 consists of 2 vnics (Ethernet over IB vnics). To enable network separation, each vnic is mapped to a separate Sun Network QDR InfiniBand Gateway Switch and each host EoIB vnic is associated with a different HCA IB port. Secure Network Protocols Network communications that require confidentiality are recommended to implement secure protocols such as IPSec, SSL or SSH. These protocols implement encryption to prevent the disclosure of information transiting networks. For example, SSL can be used between clients and applications to prevent disclosure of sensitive information. Likewise, SSH can be used to secure communications between system administrators and those systems they are managing. SSL and SSH are both integrated into the Exalogic bootstrapping process. It is recommended that all client traffic that contains sensitive information use secure protocols. It is likewise recommended that all administrative and system management traffic use secure protocols. Note that in Exalogic, insecure protocols such as FTP and Telnet are disabled by default. 13

15 Firewalls From a networking perspective, an enterprise deployment architecture is secured because every functional group of software components can be isolated, and all traffic can be restricted by protocol and port. It is recommended that Exalogic systems be implemented behind a firewall complex external to the Exalogic system, with the characteristics noted here: Configure external load balancers to redirect all external communication received on port 80 to port 443. Communication from external clients does not go beyond the Load Balancing Router level. No direct communication from the Load Balancing Router to the data tier is allowed. Components are separated in different protection zones: the web tier, application tier, and the data tier. Direct communication between two firewalls at any one time is prohibited. If communication begins in one firewall zone, it must end in the next firewall zone. All communication between components across protection zones is restricted by port and protocol, according to firewall rules. In addition to a firewall complex external to Exalogic, firewall capabilities can be implemented internally through use of IPtables. IPtables is a form of IP filter that can be implemented with the operating system to perform interrogation (packet filtering inspection) of network traffic (at layers 2 and 3). This can be a useful tool for filtering and blocking network to traffic destined for a specific port. IPtables are set up within the operating system via rules that detail the filtering to be performed as well as how inspected traffic will be subsequently routed. IPtables can thus be used to enforce separation, for example, between a production and a test system. Besides the use of IPtables the Exalogic 10 GbE Switch 72p has the ability to perform packet filtering and inspect layer 2, 3 and 4 header fields. This allows an organization to evaluate and make permit/deny decisions based upon protocol, source, destination and other parameters. For example, the port, IP address and MAC address can all be interrogated. Optionally a firewall could be implemented between Exalogic and external systems such as Exadata and other 3 rd party solutions. In such a case, network traffic would communicate over the 10GbE interface rather than the Infiniband interface. InfiniBand The InfiniBand fabric is inherently secure as it functions as an internal backplane between different nodes with no opportunity for data leakage or compromise. This allows for secure network communications between an Exalogic application node and a storage node for example. As such, no additional security controls are recommended for use with InfiniBand on an Exalogic system. Note that this does not preclude 14

16 users from implementing other security mechanisms. For example, encryption could be implemented at the application layer and simply transported by the InfiniBand network. The critical concerns of security, quality of service and application workload isolation are dealt with in the most efficient manner possible directly in the firmware of the devices that implement the fabric, i.e., the InfiniBand fabric's native capabilities are more secure, reliable with better performance. It is recommended that organization utilize IP subnets over the default IP over InfiniBand (IPoIB) link where network separation is desired, e.g., to separate data and applications of similar risk profiles. [When you create IP subnets, ensure that each of the interfaces per Exalogic compute node for these additional IP subnets above the default IPoIB subnet is bonded.] For additional information, see the Oracle Exalogic Enterprise Deployment Guided noted in the Reference section. InfiniBand Partitioning Exalogic's implementation of InfiniBand supports partitioning. An InfiniBand partition defines a group of InfiniBand nodes that are allowed to communicate with one another. Partitions can be set up for Exalogic's private InfiniBand fabric or to one's client network for EoIB using VLANs and VNICs to the edge network. IB partitioning allows users to isolate network traffic as one would do with VLAN's. Unique partitions are defined through the definition of pkeys. By enabling multiple partitions users can support more fine grained access control over the data transiting their Infiniband fabric. For example, different Exalogic compute nodes can be associated with different IB partitions. This could thus allow an Exalogic rack to support multiple compute nodes for different functions such as development, test and production and then associated with different IB partitions; effectively isolating the network traffic of each of these from one another. This is shown in the network diagram above where PCI applications are separated from other applications, each on their own partition. InfiniBand partitions are created via the assignment of partition keys. The partition key is a 16-bit hexadecimal value that defines a unique partition. When a packet arrives at a compute node, the partition key of the packet is matched with the Subnet Manager configuration. This validation prevents a compute node from communicating with another compute node outside of its partition. Note that Exadata machines only support the default Infiniband partition. 15

17 Operating Systems Exalogic supports both Linux and Solaris operating systems. Both of these operating systems are rich in security features that can be used to ensure the confidentiality, integrity and availability of the data resident on Exalogic as well as control over the administrative and operational aspects of it. Because the applications that are run on Exalogic are unique, the specific operating system controls utilized may be different from implementation to implementation. For this reason, we only provide general guidance by way of security principles, as to the use of operating system controls and do not offer a prescriptive list. Note that it is also recommended that organizations evaluate the management and administrative workload needed to implement these controls to ensure that the appropriate balance between security and usability are met. The basic security principles recommended for securing Exalogic include: Minimize the system by deleting unnecessary packages and services to reduce vulnerabilities Ensure file and directory permissions are secured for need to know based access Isolate networks and functions according to similar risk profiles Implement a least privilege security policy and associated password rules Support confidentiality through the use of encryption Restrict access to special privileges and processes through the use of roles Secure and review audit logs on a regular basis Do not access the system via root unless absolutely necessary Ensure the system is as up to date as possible and apply patches accordingly Ensure file systems with user-writable directories are mounted on separate partitions Ensure default user ID and passwords are modified as soon as practical Hardening / Minimization Hardening and minimization represents a security strategy to reduce the overall attack surface of an operating system, that is, make it less susceptible to threats that may compromise the security and integrity of the operating system functions as well as the data being processed. (Hardening is the securing of system and other resources through the use of access control and other methods. Minimization is the removal of unnecessary programs and functions.) All hardware including application compute nodes, storage nodes and network switches are recommended to be hardened such that they implement a need to know and least privilege security policy. This can be accomplished through different means but should only be undertaken after an organization performs a risk analysis of their IT infrastructure and determines what functionality and system functions are required to enable the underlying business application systems to perform their defined tasks. Because different applications may require different functionality and services from the operating system, more specific hardening and minimization recommendation are beyond the scope of this paper. A 16

18 review of the most applicable controls relevant to securing an Exalogic system is described in brief below. Note that this is not an exhaustive list and further, such controls must be implemented in a mutually beneficial manner according to a defined security architecture. Both supported operating systems can be hardened and minimized using various scripts and tools. Specific guidance on hardening and minimization can be found in the documentation found in the reference section below. These offer recommendations in areas such as: discretionary access controls, general security, file and directory permissions, system access, network services, network based authentication, restriction of services, logging, tools and backup. All of these topics should be considered when hardening a UNIX based system and tailored according to the needs of a particular organization. Operating System Data Confidentiality Data confidentiality applies to protecting data in transit over a network or at rest in storage, from unauthorized disclosure, typically using encryption technology. Within the operating systems of Exalogic, this primarily applies to system management functions performed by administrators. Administrative communications issued by system administrators, database administrators and others should be encrypted. In Exalogic, such administrative information may be used to access server or storage systems via Oracle Embedded Integrated Lights Out Manager (ILOM), directly via Ethernet ports on those systems or via the Oracle Enterprise Manager / Ops Center. [The InfiniBand switches incorporated into Exalogic may also be accessed via Ethernet ports.] It is recommended that for ensuring confidentiality over administrative functions within the scope of managing the operating systems on Exalogic, all administrative functions should be encrypted using secure protocols such as SSL or SSH. ILOM Integrated Lights Out Management (ILOM) is used for remote systems management. ILOM comes preconfigured on all Exalogic systems. ILOMs are used by system administrators to manage systems and require confidentiality when commands are issued. It is recommended that ILOMs be secured using SSH to ensure the confidentiality of administrative actions. 17

19 Separation of Duties Separation of duties for system administrators is used to reduce the risk of fraud, collusive behavior and prevent inadvertent errors. Separation of duties is a technique for ensuring that no single user or administrator can perform more functions than necessary to complete their assigned duties. It is recommended that a security policy of least privilege be implemented while configuring an Exalogic system. Separation of duties should be enforced at the operating system whether Oracle Linux or Oracle Solaris are used. Technologies used for enforcing separation of duties should be used in concert with logging of all privileged actions. It is recommend that no privileged action be executed anonymously (i.e. using root account) and every privileged action should be logged using the syslog facility. Both operating systems used in the Exalogic nodes (Oracle Linux and Oracle Solaris) allow enforcing separation of duties as described below. In Oracle Linux sudo is recommended for all privileged operations. Here are several recommendations for using sudo in Oracle Linux: Configure /etc/sudoers file so that users with administrative responsibilities on the operating system will have access to the appropriate commands used to fulfill those responsibilities. Do not use the ALL keyword when configuring /etc/sudoers, be specific about the rights you grant to certain users. Use a separate file for logging sudo events; do not mix sudo messages with other system messages. Use logfile directive for that purpose. Use groups instead of individual users to simplify the management of privileged operations. Use the secure_path directive to make sure you execute commands from the trusted path. If your system has SELinux configured sudo can use its roles in /etc/sudoers file. In systems where Oracle Solaris is the base operating system, sudo can be used as well. Additionally, Solaris has a flexible Role Base Access Control (RBAC) subsystem. RBAC is deeply integrated into the Solaris kernel which makes it very robust from a security standpoint. Solaris RBAC uses concept of roles to avoid executing commands as root user as much as possible. In Solaris 11 default installations root exists only as a role, i.e., one cannot login as root. These security features eliminate the anonymous execution of privileged commands and access to system files. 18

20 Oracle Virtual Machine Oracle VM is an enterprise class server virtualization solution that allows organizations to separate applications and operating system instances from one another on the same physical machine. Oracle VM delivers virtualization through the use of a hypervisor that enables the support of multiple domains within which an organization can isolate and run their applications. The hypervisor runs directly on the hardware serving as the abstraction layer for all hardware operations from the guest OS such as CPU, I/O, and disk requests. By separating the guest VMs from the hardware, the hypervisor is able to run multiple operating systems securely and independently. This has the security benefit of ensuring the isolation of data and processes such that only those users, applications and other entities that are authorized to access specific data and processes can do so. Organization that desire to comply with PCI for example, and as illustrated in diagram 3, benefit from using Oracle VM to enable separation of their PCI applications from other non-pci applications. Note that only the Exalogic guest base image for Oracle Linux UEK bit is currently supported. Additional Operational Considerations If an organization desires more robust operational security there are additional recommendations that can be considered such as: Display an appropriate login banner prior to allowing any login actions. Lock user accounts after a reasonable number (e.g., 3) failed login attempts. Lock terminals after a period (e.g., 15 minutes) of inactivity and a password should be used to reactivate the terminal. If any applications are continuously in use, they must not be run as root, any display terminal must be in a controlled access area, and the use of the application must have a written justification. Regularly scan the installed Exalogic system to ensure that previously unknown threats and vulnerabilities can be discovered. The ownership, permissions and location of files with the sgid or suid bit set should be documented. Any world writable directories should be public directories. The same security standards that apply to one s production system should also apply to their development systems. Separate file system partitions should be used for /home, /exporthome and /var where possible and exceptions documented. Rule of thumb: if it s shared, make it a separate mount-point. 19

21 Storage The Sun 7320 ZFS Storage Appliance (ZFSSA) that is utilized by an Exalogic system offer several security related controls that we recommend. The primary controls that can be leveraged on the storage appliance include administrative controls and share access. Administrative Controls Administrative controls include the use of SSL or SSH to protect the communications that a system administrator has with the storage appliance. In addition, as the storage appliance runs Solaris, Solaris based controls such as user and privilege rights management supporting Role Based Access Control (RBAC) can be implemented to provide separation of duties at the administrative level. Isolation via Shares Access to shares [shares are filesystems and LUNs that are exported over supported data protocols to clients of the appliance] on the storage appliance can be controlled by IP address, network groups and users to provide compartmentalized data access. Fine-grained access on files and directories is managed via Access Control Lists (ACLs). An ACL describes what permissions are granted, if any, to specific users or groups. This can support the implementation of a need to know access policy and ensures that only authorized users can access specific data. It is recommended that organizations isolate data in storage by controlling access to shares by the specific IP Addresses of their compute nodes as well as through the implementation of ACL's. Security related configuration settings The Networking Configuration features permit creation of a variety of advanced networking setups out of physical network ports, including link-aggregations, virtual LANs (VLANs), and multipathing groups. Diagram 4. The Sun ZFS Storage Appliance Configuration Menu 20

22 Several security related recommendations can be considered such as: Access to the ZFSSA is enabled via the Cisco Ethernet management switch 1GbE management network and physical network connections are in place. Ensure port 215 on the ZFSSA is open for browser user interface access and to enable the use of the SSH client. The Sun ZFS Storage 7320 appliance within Exalogic has four 1 Gigabit Ethernet ports. In the current configuration two ports are used for managing the ZFSSA. Optionally ports can be setup for disaster recovery purposes. Disabling the management options on the two ports used for replication ensures the separation of the replication traffic from the management traffic. See Disaster Recovery for Exalogic Elastic Cloud as noted in the reference section for additional details. The replication control protocol used in ZFSSA is secured with SSH. Data can optionally be protected with SSL as well. Always enable SSL when replication is across a wide-area-network. Any user on the operating system of an Exalogic compute node should have the same user ID as the user created on the storage appliance while creating a new file system. For example, one can use account weblogic to perform WebLogic Server product installation and configuration tasks. Do not perform these tasks as a root user. The user weblogic should have read-write permissions to relevant shares. Ensure that the shares created on ZFSSA are mounted using the nfsv4 protocol. Mount options to mount file systems are specified by /etc/fstab entries. Recommended settings need to be as detailed in Oracle Exalogic Enterprise Deployment Guide. Ensure DNS service is online on ZFSSA to allow mapping NFSv4 user and group identities based on DNS domain name. See the diagram below for the recommended directory and system settings. Diagram 5. Exalogic Directory and System Settings Setup of an appropriate directory server such as Active Directory or LDAP and access to these servers from ZFSSA need to be secured. Alternately, Network Information Service (NIS) name service for centralized management can be setup. If used, the NIS server must be setup on Exalogic 21

23 compute nodes to allow for file permissions to be reflected correctly with user and group permission on ZFSSA shares. The ZFSSA also supports Kerberos network authentication mechanism. The NTP service must be configured before configuring Kerberized NFS. After setting NFS properties for Kerberos, change the Security mode on the shares to a mode using Kerberos. To secure your storage shares ensure that FTP & HTTP share modes are set to none (neither read only nor read/write). Ensure that NTP server system setting on ZFSSA specifies NTP authentication keys. These keys are not used to encrypt traffic, and they are not used to authenticate the client; they are only used by the NTP client (i.e., the appliance) to authenticate the NTP server. To associate a private key with an NTP server, the private key must first be specified. After the keys have been specified, an NTP server can be associated with a particular private key. For a given key, all of the key number, key type and private key values must match between client and server for an NTP server to be authenticated. Systems Management The systems management controls noted in this section play a support role for security on an Exalogic system. These should be considered when implementing Exalogic to ensure that it is implemented, managed and maintained in a secure state. Operational Security A comprehensive change control and patch management process should be implemented to ensure that an Exalogic system has patches and changes applied in a timely manner. It is assumed that an organization's existing change control and patch management capabilities would be leveraged. The use of an automated enterprise management system such as the Oracle Enterprise Manager in conjunctions with Oracle Ops Center are useful for implementing change control and patch management. Note that a change control and patch management process as well as other operational processes should exist within a security governance framework such as those described in ISO or ITIL. For examples the ISO standards recommends an Information Security Management System (ISMS) as the vehicle for designing, implementing and managing an organization s security policies and procedures. 22

24 Monitoring and Management Monitoring and managing an Exalogic environment should be done in a holistic and integrated fashion. It is recommended that you set up and use a monitoring and management system such as Oracle Enterprise Manager to more efficiently monitor and manage operating systems, software components, including Oracle WebLogic domains, application deployments, Coherence Clusters, and hosts. If used, Oracle Enterprise Manager Grid Control requires an Oracle Enterprise Management Agent and the Oracle Management Service (OMS). A single Oracle Enterprise Management Agent, required as Master Agent, is installed on the Sun ZFS Storage 7320 appliance. This master agent, which is on the shared storage, is used by all compute nodes in the Oracle Exalogic machine. To ensure that controls are applied in a consistent and comprehensive manner, Enterprise Manager and Oracle Ops Center (or equivalents) are recommended to be used to monitor and manage hardware, automate patch management and support configuration and compliance reporting. This is especially important as controls such as those applied to the different operating system instances across multiple nodes can be managed much more effectively and efficiently using these facilities. Patch Management Patch management is a key element of any organization s best practices for their application deployments. It is important to apply recommended patches periodically; recommended patches typically contain critical bug fixes including updates that address security vulnerabilities. A number of independently patchable hardware and software components come together in an Exalogic rack, all engineered to work together in an optimized manner. To ensure that the Exalogic system continues to perform optimally, Oracle provides comprehensive and well-tested patches to the system as a whole periodically. An Exalogic Patch Set Update (EL PSU) is released quarterly with the following features: The patch set update is a single download that contains patches for all Exalogic components (firmware/software/os) as necessary The patch set update is a highly recommended update for all Exalogic customers In addition to patches/updates for the Exalogic Infrastructure components (on-node components such as Operating System, ILOM, InfiniBand and RAID controller cards, and off-node components such as InfiniBand switches and ZFS Storage Appliance), patches for middleware components (WLS, Coherence, JDK) are included as well. Exalogic customers should ensure that they align their systems with Oracle s Exalogic releases and recommended patch levels and should refrain from applying patches which are outside of recommendations for Exalogic. For instance, if a new version of the ZFS Storage Appliance software is released and is not part of an Exalogic recommended patch or PSU, customers should not uptake it for their racks, since it may adversely affect not only functionality but also performance of the Exalogic Engineered System. 23

25 Oracle Traffic Director The Oracle Traffic Director (OTD) is a layer 7 load balancer. It can be used to front end application and web servers in an Exalogic environment as illustrated in diagram 3 above. OTD also support SSL and can be used as the primary landing or termination point for encrypted network traffic. The recommended implementation for OTD is in a high availability or HA configuration. From a security standpoint OTD currently offers two primary features: Reverse proxy. By serving as an intermediary between clients outside the network and servers in the back end, Oracle Traffic Director masks the names of servers in the back end and provides a single point for tracking client access to multiple servers in the back end. A reverse proxy functions as a forwarding agent and provides the benefit of essentially hiding the Exalogic internal network from outside of its perimeter. Support for SSL 3.0 and TLS 1.0. You can configure SSL/TLS-enabled HTTP listeners for Oracle Traffic Director instances, using either certificates issued by commercial CAs such as VeriSign or RSA- and ECCtype self-signed certificates with key sizes of up to 4096 bits. SSL and TLS provide for the confidentiality of data transiting the network through the use of encryption. Conclusion As delivered, Exalogic is a robust system that has a great deal of inherent security. Such security allows Exalogic to be used for mission critical applications and the processing of sensitive information. This paper has provided the introduction of security as a critical component of an Exalogic system. Organizations should consider their current security maturity level, their current threat profile and trust model to determine if their existing security architectures is satisfactory and how an Exalogic system would exist in that environment; and then apply additional security as is warranted. 24

26 References 1. Oracle Fusion Middleware Exalogic Machine Owner's Guide EL X Oracle Fusion Middleware Exalogic Enterprise Deployment Guide EL X Sun ZFS Storage 7000 Appliance Installation Guide 4. Sun ZFS Storage 7000 Appliance Administration Guide 5. Sun Network QDR InfiniBand Gateway Switch Administration Guide 6. The Center for Internet Security: Security Configuration Benchmark for Red Hat Enterprise Linux 5 V 1.1.2, The Center for Internet Security: Security Configuration Benchmark for Solaris 10 11/06 through 10/09 V 5.0.0, Defense Information Systems Agency UNIX Security Technical Implementation Guide, Version 5, Release 1, National Security Agency (NSA) Guide to Secure Configuration of Red Hat Enterprise Linux 5 Revision 4.1, Oracle Exalogic Elastic Cloud: A Brief Introduction, Oracle VM 3: Architecture and Technical Overview,

27 Exalogic Security June, 2012 Author: Joel Weise Contributors: Teju Ajani, Pavel Anni, Latha Krishnaswamy, Dev Prabhu, Richard Wark Version: 1.0 Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA U.S.A. Copyright 2012, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only and the contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or fitness for a particular purpose. We specifically disclaim any liability with respect to this document and no contractual obligations are formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without our prior written permission. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. UNIX is a registered trademark licensed through X/Open Company, Ltd Worldwide Inquiries: Phone: Fax: oracle.com