Oracle Compute Cloud – Cloud Security
Oracle Compute Cloud Security
By: Pete Chen | Manager, Hosting Services
Hosting servers on a public cloud may seem like a scary concept. Everyone who has Internet access is a potential threat to corporate data security. In a local server cluster, a firewall can be set up to protect the servers from malicious outside traffic. The good news is Oracle Compute Cloud has included some security features to help secure their cloud environment. Setting up network security should be one of the first tasks for any environment.
Oracle Compute Cloud Service’s security is broken down into 4 pieces. Security applications are created to allow application-specific ports to remain open. Security lists are created to determine in general how incoming and outgoing traffic should be handled. Security rules are created to bridge a security application to a security list. Security IP lists are created to allow entry from specified IP addresses.
Security Applications
Security Applications can be created to specify the ports needed to gain access to the application. Supported port types are TCP, UDP, ICMP, and GRE and a range of ports can be used. In Oracle’s Middleware, WebLogic Server’s Admin Console typically runs on port 7001, or 7002 if secured through SSL. The port type would be set to TCP. Access to the console would be required prior to setting up SSL, so both ports should be included in the security application. The allowed port range would start at 7001, and end at 7002, or any other custom values given to WebLogic Server. The same would hold true for WebCenter Content and WebCenter Portal. Build a security application for each application installed in the environment.
Security Lists
Security Lists are the network security attribute assigned to a server instance. Security lists dictate how the network will respond to inbound and outbound traffic from a server instance. By default, Inbound packets are dropped with no reply given. This means an outside source sending information into the network will have that traffic stopped. The source will only know that the packet never reached its destination. The alternative is to drop the packets with a reply. This will let the source know that the packet was specifically dropped. The outbound traffic policy is set to Allow by default. This can be changed to Deny (drop packets with no reply), or Reject (drop packets with reply).
All server instances assigned to a specific security list can openly communicate to each other. An example of this is the communication between WebCenter Content and WebCenter Portal. The portal servers communicate with the content servers through port 4444. If both of the server instances are added to the same security list, they can communicate between the two servers without restrictions. Therefore, there isn’t a need to create a security application specifically for port 4444 on the content server.
Security Rules
Security Rules bind security applications to security lists. Each rule is created to allow specific traffic to a specific destination. After selecting the security application, a source must be provided. A source can be a security list created or a security IP list. Examples of a security IP list include an instance, ntp, powerbroker, public-internet, or a site. Afterwards, a destination must also be provided. Same as the source, the destination can be a security list or a security IP list. Security rules can be enabled or disabled based on the environment’s needs.
Security IP Lists
Security IP Lists allow for a block of IP’s to be grouped together. The default IP lists given are for the instance (IP block for server instances in the environment), ntp (network time protocol), powerbroker, public-internet, or site. To better secure an environment, specific IP addresses from known sources (office, VPN, or data center) can be added to an IP list. A security rule can be created to only allow traffic from these IP addresses to reach their destination. While it’s convenient to allow all public internet traffic to reach the server instances, it also leaves the environment vulnerable. Locking down the allowed IP traffic for each environment will help to ensure the environment remains safe and secure.
These tools help to protect an Oracle Compute Cloud Services environment from security breaches. Security applications help to define what ports should be opened, security lists define how traffic should be handled, security rules bridge the applications to the lists, and security IP lists help to decide what traffic is allowed. Best practices are available, but take some time to consider the overall security requirements of each environment. Map out the servers, plot out the ports, and specify the various IP addresses. Once the big picture is clear, setting up the security parameters will be easy.
Summation
Oracle Compute Cloud service offers complete security control over the environment, allowing administrators to fully protect their site. Start off by locking down all ports on incoming traffic, and restricting the IP addresses allowed to access the sites. Then define the ports to open by the applications installed. Finally, define which virtual instances require the security rules. Although not covered in this blog, there is an SSL certificate requirement to SSH into the server. Creating an SSL certificate should be done with a systems administrator, as there may be rules and standards on its creation, along with best practices.