Design CloudGuard Network Security for Oracle Cloud Infrastructure and Secure Your Workloads

Move or extend any application workloads, such as Oracle E-Business Suite or PeopleSoft, in the cloud using Check Point CloudGuard Network Security to augment native security options without significant configuration, integration, or business process changes.

Security in the cloud is based on a shared responsibility model. Oracle is responsible for the security of the underlying infrastructure, such as data center facilities, hardware, and software to manage cloud operations and services. Customers are responsible for securing their workloads and configure their services and applications securely to meet their compliance obligations.

Oracle Cloud Infrastructure (OCI) offers best-in-class security technology and operational processes to secure its enterprise cloud services. Check Point CloudGuard Network Security for OCI provides advanced, multilayered security to protect applications from attacks, while enabling secure connectivity from enterprise and hybrid cloud networks. Together, they protect applications across on-premises data centers and cloud environments delivering scalable performance and bringing advanced security orchestration and unified threat protection.

The security controls include the following features:
  • Access controls (firewall)
  • Logging
  • Application control
  • URL filtering
  • Intrusion prevention (IPS)
  • Advanced threat prevention (Anti-virus, anti-bot, SandBlast zero-day protection)
  • Site-to-site virtual private network (VPN) for communication with the on-premises network
  • Remote access VPN for communication with roaming users
  • Network address translation for internet bound traffic

Architecture

This reference architecture illustrates how organizations can protect Oracle applications, like Oracle E-Business Suite, PeopleSoft and other applications deployed in OCI using Check Point’s CloudGuard Network Security with flexible network load balancer.

To protect these traffic flows, Check Point recommends segmenting the network using a north and south hub and spoke design:
  • The north hub protects publicly accessible resources from malicious inbound traffic. The north hub uses of the Oracle flexible network load balancer that allows organizations to create a scalable set of CloudGuard Network Security gateways that can be sized appropriately based on throughput requirements.
  • The south hub protects traffic between spokes, traffic egressing to the internet, traffic to the Oracle Services Network, and traffic to or from on-premise networks. We recommand that the south hub contains a highly available cluster of CloudGuard Network Security gateways, so that stateful failover can occur for traffic that's sensitive to interruption.
  • Deploy each tier of your application in its own virtual cloud network (VCN), which acts as a spoke. This separation allows for granular control of the traffic between spokes.
  • The north hub VCN connects incoming traffic from the internet to the various spoke VCNs through flexible network load balancer and dynamic routing gateway (DRG).
  • The south hub VCN connects to the spoke VCNs through the DRG. All outgoing traffic and traffic between spokes uses route table rules to route traffic through the DRG to the south hub for inspection by the CloudGuard Network Security cluster.
  • Use one of the following methods to manage the environment:
    • Centrally manage the environment with a Check Point Security management server or multidomain management server, deployed either in its own subnet in the north hub VCN or as a pre-existing customer deployment that's accessible to the security gateways.
    • Centrally manage the environment from Check Point Smart-1 Cloud management-as-a-service.

The following diagram illustrates this reference architecture.

Description of cloudguard-net-sec-arch.png follows
Description of the illustration cloudguard-net-sec-arch.png

For each traffic flow scenario, ensure that network address translation (NAT) and security policies are configured on the CloudGuard Network Security gateways. The currently supported Flexible Network Load Balancer use case requires that you enable source NAT on the firewalls from which traffic is exiting.

North-south inbound traffic flow through the north hub VCN

The following diagram illustrates how north-south inbound traffic accesses the web application tier from the internet:

Description of inbound-no-hub-vcn.png follows
Description of the illustration inbound-no-hub-vcn.png

North-south outbound traffic flow through the south hub VCN

The following diagram illustrates how outgoing connections from the web application and database tiers to the internet provide software updates and access to external web services:

Description of outbound-so-hub-vcn.png follows
Description of the illustration outbound-so-hub-vcn.png

East-west traffic flow (web to database) flow through the south hub VCN

The following diagram illustrates how traffic moves from the web application to the database tier:

Description of e-w-w2db-so-hub.png follows
Description of the illustration e-w-w2db-so-hub.png

East-west traffic flow (database to web) through the south hub VCN

The following diagram illustrates how traffic moves from the database tier to the web application:

Description of e-w-db2w-so-hub.png follows
Description of the illustration e-w-db2w-so-hub.png

East-west traffic flow (Web application to Oracle Services Network) through the south hub VCN

The following diagram illustrates how traffic moves from the web application to the Oracle Services Network:

Description of e-w-w2osn-so.png follows
Description of the illustration e-w-w2osn-so.png

East-west traffic flow (Oracle Services Network to web application) through the south hub VCN

The following diagram illustrates how traffic moves from the Oracle Services Network to the web application:

Description of e-w-osn2web-so.png follows
Description of the illustration e-w-osn2web-so.png

The architecture has the following components:
  • Check Point CloudGuard Network Security gateways

    Provides advanced threat prevention and cloud network security for hybrid clouds.

  • Check Point Security Management
    • Security management server
    • Multidomain management
    • Smart-1 Cloud management-as-a-service
  • Oracle E-Business Suite or PeopleSoft application tier

    Composed of Oracle E-Business Suite or PeopleSoft application servers and file system.

  • Oracle E-Business Suite or PeopleSoft database tier

    Composed of Oracle Database, but not limited to Oracle Exadata Database Cloud service or Oracle Database services.

  • Region

    An OCI region is a localized geographic area that contains one or more data centers, called availability domains. Regions are independent of other regions, and vast distances can separate them (across countries or even continents).

  • Availability domain

    Availability domains are standalone, independent data centers within a region. The physical resources in each availability domain are isolated from the resources in the other availability domains, which provides fault tolerance. Availability domains don’t share infrastructure, such as power or cooling, or the internal availability domain network. So, a failure at one availability domain is unlikely to affect the other availability domains in the region.

  • Fault domain

    A fault domain is a grouping of hardware and infrastructure within an availability domain. Each availability domain has three fault domains with independent power and hardware. When you distribute resources across multiple fault domains, your applications can tolerate physical server failure, system maintenance, and power failures inside a fault domain.

  • Virtual cloud network (VCN) and subnet

    A VCN is a customizable, software-defined network that you set up in an OCI region. Like traditional data center networks, VCNs give you complete control over your network environment. A VCN can have multiple non-overlapping CIDR blocks that you can change after you create the VCN. You can segment a VCN into subnets, which can be scoped to a region or to an availability domain. Each subnet consists of a contiguous range of addresses that don't overlap with the other subnets in the VCN. You can change the size of a subnet after creation. A subnet can be public or private.

  • North hub VCN

    The north hub VCN is a centralized network where Check Point CloudGuard Network Security gateways are deployed. It provides secure inbound connectivity to all spoke VCNs.

  • South hub VCN

    The south hub VCN is a centralized network where Check Point CloudGuard Network Security gateways are deployed in high availability cluster. It provides secure connectivity to all spoke VCNs, OCI services, public endpoints and clients, and on-premises data center networks.

  • Application tier spoke VCN

    The application tier spoke VCN contains a private subnet to host Oracle E-Business Suite or PeopleSoft components.

  • Database tier spoke VCN

    The database tier spoke VCN contains a private subnet for hosting Oracle databases.

  • Load balancer

    OCI Load Balancing service provides automated traffic distribution from a single-entry point to multiple servers in the backend end.

  • Flexible Network Load balancer

    OCI flexible network load balancer provides automated traffic distribution from one entry point to multiple backend servers in your VCNs. It operates at the connection level and load balancers incoming client connections to healthy backend servers based on Layer3 or Layer4 (IP protocol) data.

  • Security list

    For each subnet, you can create security rules that specify the source, destination, and type of traffic that must be allowed in and out of the subnet.

  • Route table
    Virtual route tables contain rules to route traffic from subnets to destinations outside a VCN, typically through gateways. In the north hub VCN, you have the following route tables:
    • The network load balancer route table attached to the network load balancer subnet pointing to the CIDR block of on-premises subnet through DRGs and has a default route to connect to internet gateway.
    • Frontend route table attached to the frontend subnet, which has a default route connected to internet gateway for routing traffic from the north hub VCN to internet or on-premises targets.
    • Backend route table attached to the backend subnet pointing to the CIDR block of the spoke VCNs through DRGs.
    In the south hub VCN, you have the following route tables:
    • Frontend route table attached to the frontend subnet which has a default route connected to internet gateway for routing traffic from the south hub VCN to internet or on-premises targets.
    • Backend route table attached to the backend subnet pointing to the CIDR block of the spoke VCNs through dynamic routing gateways.
    • South Hub VCN Ingress route table is attached to hub VCN attachment to send any incoming traffic from spoke VCNs through the dynamic routing gateway to secondary floating IP address of primary CloudGuard Network Security Gateway backend interface.
    • For each spoke attached to the North hub through dynamic routing gateways, a distinct route table is defined and attached to an associated subnet. That route table forwards all traffic (0.0.0.0/0) from the associated spoke VCN to dynamic routing gateways through the secondary floating IP address of primary CloudGuard Network Security Gateway backend interface, or you can define it at granular level too.
    • Oracle service gateway route table attached to the Oracle service gateway for Oracle Service Network communication. That route forwards all traffic (0.0.0.0/0) to the secondary floating IP address of primary CloudGuard Network Security gateway backend interface.
    • To maintain traffic symmetry, routes are also added to each Check Point’s CloudGuard Network Security gateway to point the CIDR block of spoke traffic to backend (internal) subnet’s default gateway IP (default gateway IP available in the backend subnet on the South hub VCN) and default CIDR block (0.0.0.0/0) pointing to the frontend subnet default gateway IP.
    On the DRG, you have the following route tables:
    • For each spoke VCN attachment, you have a DRG route table associated to ensure that traffic goes to south hub VCN. Add a route rule to ensure that traffic destined to backend subnet of north hub VCN follow the same path where traffic came from.
    • For the south hub VCN attachment, an associated DRG route table ensures that imported routes from each VCNs attached to DRG are part of this route table.
  • Internet gateway

    The internet gateway allows traffic between the public subnets in a VCN and the public internet.

  • NAT gateway

    The NAT gateway enables private resources in a VCN to access hosts on the internet, without exposing those resources to incoming internet connections.

  • Dynamic routing gateway (DRG)

    The DRG is a virtual router that provides a path for private network traffic between a VCN and a network outside the region, such as a VCN in another OCI region, an on-premises network, or a network in another cloud provider.

  • Service gateway

    The service gateway provides access from a VCN to other services, such as OCI Object Storage. The traffic from the VCN to the Oracle service travels over the Oracle network fabric and never traverses the internet.

  • FastConnect OCI

    FastConnect provides an easy way to create a dedicated, private connection between your data center and OCI. FastConnect provides higher-bandwidth options and a more reliable networking experience when compared with internet-based connections.

  • Virtual network interface card (VNIC)

    The services in OCI data centers have physical network interface cards (NICs). VM instances communicate using virtual NICs (VNICs) associated with the physical NICs. Each instance has a primary VNIC that's automatically created and attached during deployment and is available during the instance's lifetime. DHCP is offered to the primary VNIC only. You can add secondary VNICs after instance deployment. Set static IPs for each interface.

  • Private IPs

    A private IPv4 address and related information for addressing an instance. Each VNIC has a primary private IP, and you can add and remove secondary private IPs. The primary private IP address on an instance is attached during instance deployment and doesn’t change during the instance’s lifetime. Secondary IPs also belong to the same CIDR of the VNIC’s subnet. The secondary IP is used as a floating IP because it can move between different VNICs on different instances within the same subnet. You can also use it as a different endpoint to host different services.

  • Public IPs
    The networking services define a public IPv4 address chosen by Oracle that's mapped to a private IP. Public IPs have the following types: Ephemeral:
    • This address is temporary and exists for the lifetime of the instance.
    • Reserved: This address persists beyond the lifetime of the instance. You can unassign it and reassign it to another instance.
  • Source and destination check

    Every VNIC performs the source and destination check on its network traffic. Disabling this flag enables a Check Point CloudGuard Network Security gateway to handle network traffic that's not targeted for the firewall.

Recommendations

Use the following recommendations as a starting point to secure Oracle E-Business Suite or PeopleSoft workloads or application workloads on OCI using Check Point CloudGuard Network Security Gateway. Your requirements might differ from the architecture described here.
  • VCN

    When you create a VCN, determine the number of CIDR blocks required and the size of each block based on the number of resources that you plan to attach to subnets in the VCN. Use CIDR blocks that are within the standard private IP address space.

    Select CIDR blocks that don't overlap with any other network (in Oracle Cloud Infrastructure, your on-premises data center, or another cloud provider) to which you intend to set up private connections.

    After you create a VCN, you can change, add, and remove its CIDR blocks.

    When you design the subnets, consider your traffic flow and security requirements. Attach all the resources within a specific tier or role to the same subnet, which can serve as a security boundary.

    Use regional subnets and utilize whole VCN CIDR as part of subnet CIDR so all traffic from spoke VCNs gets inspected.

  • Check Point CloudGuard Network Security
    • Deploy a high availability cluster in the south hub.
    • Deploy a scalable set in the north hub.
    • Whenever possible, deploy in distinct fault domains at a minimum or different availability domains.
    • Ensure that MTU is set to 9000 on all VNICs.
    • Utilize SRIOV and VFIO interfaces (AMD shapes only).
    • Create a second hub-spoke topology in a separate region for disaster recovery or georedundancy.
    • Don’t restrict traffic through security lists or network security gateways (NSGs) because all traffic is secured by the security gateway.
    • By default, ports 443 and 22 are open on the gateway, and more ports are open based on security policies.
  • Check Point Security Management
    • If you’re creating a deployment hosted in OCI, create a dedicated subnet for management.
    • Deploy a secondary management server (management high availability) in a different availability domain or region.
    • Use security lists or NSGs to restrict inbound access to ports 443, 22, and 19009 sourced from the internet for administration of the security policy and to view logs and events.
    • Create either a security list or NSG allowing ingress and egress traffic to the security gateways from the security management server.
  • Check Point security policies

    Refer to the application documentation in the Explore more section for the most up-to-date information on required ports and protocols.

Considerations

When securing Oracle E-Business Suite or PeopleSoft workloads on OCI using Check Point CloudGuard Network Security gateway, consider the following factors:

  • Performance
    • Selecting the proper instance size, which is determined by the Compute shape, determines the maximum available throughput, CPU, RAM, and number of interfaces.
    • Organizations need to know what types of traffic traverses the environment, determine the appropriate risk levels, and apply proper security controls as needed. Different combinations of enabled security controls impact performance.
    • Consider adding dedicated interfaces for FastConnect or VPN services. Consider using large Compute shapes for higher throughput and access to more network interfaces.
    • Run performance tests to validate the design can sustain the required performance and throughput.
  • Security
    • Deploying Check Point Security Management in OCI allows for centralized security policy configuration and monitoring of all physical and virtual Check Point Security gateway instances.
    • For existing Check Point customers, migrating Security Management to OCI is also supported.
    • Define distinct Identity and Access Management (IAM) dynamic group or policy per cluster deployment.
  • Availability
    • Deploy your architecture to distinct geographic regions for greatest redundancy.
    • Configure site-to-site VPNs with relevant organizational networks for redundant connectivity with on-premises networks.
  • Cost
    • Check Point CloudGuard is available in bring-your-own-license (BYOL) and Pay As You Go (PAYG) license models for both Security Management and security gateways in the Oracle Cloud Marketplace.
    • Check Point CloudGuard Network Security gateway licensing is based on number of vCPUs (one OCPU is equivalent to two vCPUs).
    • Check Point BYOL licenses are portable between instances. For example, if you're migrating workloads from other public clouds that also use BYOL licenses, you don’t need to purchase new licenses from Check Point. Check with your Check Point representative if you have questions or need verification of your license status.
    • Check Point Security Management is licensed per managed security gateway. For example, two clusters count as four toward the Security Management license.

Deploy

The Terraform code for <briefly describe architecture> is available as a stack in Oracle Cloud Marketplace.You can also download the code from GitHub, and customize it to suit your specific business requirements.
  • Deploy by using the stack in Oracle Cloud Marketplace:
    1. Set up the required networking infrastructure as shown in the architecture diagram, to which you can refer as an example. For detailed instructions, see Set up a hub-and-spoke network topology.
    2. Deploy the application (Oracle E-Business Suite or PeopleSoft or required applications) on your environment.
    3. Oracle Cloud Marketplace has multiple listing for different configurations and licensing requirements. For example, the following listings feature bring your own licensing (BYOL). For each listing that you choose, click Get App and follow the on-screen prompts.
  • Deploy using the Terraform code in GitHub:
    1. Go to GitHub.
    2. Clone or download the repository to your local computer.
    3. Follow the instructions in the README document.