OCI ZPR with X-VCN for Building Robust, Layered Network Security

In 2024, Zero Trust Packet Routing was announced. This service focuses on protecting sensitive data in the cloud, with primary concerns being data leaks and breaches.

OCI ZPR allows customers to define human-readable security policies that capture how data should flow within their network, independent of IP addresses or network topology. These policies are managed separately from network configurations, so that network changes don’t unintentionally affect security. Enforced at the network layer, OCI ZPR confirms that all traffic aligns with defined security intentions while continuously monitoring for changes that could impact the overall security posture.

ZPR continues to evolve, enhancing its current capabilities by introducing new features such as NPA integration, expanded support for additional services, and X-VCN support. With the new ZPR X-VCN feature, a single ZPR policy can include security attributes from resources across multiple VCNs.

Simplified Network, robust security

Security is as complex as it is critical. To meet the strictest requirements and regulations, it must follow a layered approach. Each layer serves a specific purpose, working together to protect systems and data from potential threats.

Complex network architectures can pose significant security challenges. When security layers are not properly focused on their intended purpose, it can lead to sub-optimal designs and overlapping security policies. This overlap increases operational complexity and ultimately reduces the overall effectiveness of the security posture.

OCI Network Security Layered approach

The new ZPR enhancements further simplify network architectures while strengthening the security posture of each layer.

Let’s take a look at how this will look with a customer example.

Customer A has different web applications, the application are web based, exposed to the Internet and follow a split stack architecture. For this scenario it is common to have an OCI Hub and Spoke VCN architecture with an OCI Network Firewall in the Hub. Let’s break the different security layers

Security Lists and Network Security Groups ‘NSGs’

A security list consists of a set of ingress and egress rules that apply to all VNICs within a subnet. The primary objective of security lists is to control and filter traffic based on subnet boundaries and their specific purposes. To achieve this effectively, the network architecture should be carefully designed with dedicated subnets that align with different functions, workloads, environments or security requirements.

Network Security Groups (NSGs), unlike Security Lists, are applied to a specific VNIC or a defined set of VNICs, enabling more granular  traffic control.

An important point to remember is that NSGs and Security Lists are evaluated together, meaning their rules are effectively combined at resource level. If you need granular filtering via NSGs, ensure the specific rule exists only in the relevant NSG and is not permitted in the subnet’s Security List.

Security Lists and NSGs are both VCN-scoped resources. For simpler management and more granular, workload-specific control, NSGs are generally recommended over Security Lists.

In this example Load Balancer NSGs must be configured in Hub and Spoke VCNs.

In the Hub VCN, attach NSGs to the load balancers to allow internet ingress to the LBs. In each Spoke VCN, attach NSGs to the application VMs and databases to allow traffic from the load balancers to the app tier, and from the app tier to the database tier, respectively.

Firewall policies

At this stage, resources are isolated at the network level through specific port restrictions; however, additional advanced threat protection and prevention capabilities are still needed. Capabilities such as SSL inspection, intrusion detection and prevention, and custom URL and FQDN filtering are key features of the OCI Network Firewall.

To get the most value from the OCI Network Firewall and reduce operational complexity the Network Firewall should be primarily focused on these advanced security functions.

An OCI Network Firewall policy for this scenario could be defined as follows

For intrusion prevention to effectively inspect encrypted traffic, a decryption rule with the action “Decrypt traffic with SSL inbound inspection” must be created. A decryption profile and a mapped secret are required for each web application.

ZPR policies

Up to this point, an internet user can securely connect to the application layer. However, there are still potential security concerns.

Preventing the load balancer for Application A from reaching the VMs for Application B can’t be achieved with Security Lists. With NSGs, you can implement this by using separate, application-specific NSGs, one for App A and one for App B.

NSG rules allow the source type to be a CIDR, an Oracle service, or another NSG. However, because NSGs are scoped to a single VCN, the only practical option for a Multi-VCN architecture is to use CIDR based rules, which can be more complex to manage and more prone to errors.

This could lead to unintended access and lateral movement. This is where the ZPR security layer comes into play, enforcing segmentation and controlling access.

In this example, a namespace named app (Identity & Security > Zero Trust Packet Routing > Security Attribute Namespace):

 will be created with the following security attributes

• vcn: Value type List (hub-vcn, spoke-vcn)
• lb: Value type List (App-A, App_B)
• instance: Value type List (App-A, App-B)
• db: Value type List (DB-A, DB-B)

With the new ZPR X-VCN feature, ZPR policies are simplified by eliminating the need to define CIDR ranges in policies and instead leveraging security attributes through a human-readable, intent-based approach, ultimately strengthening the overall security posture

When a ZPR attribute is applied, traffic is denied by default and must be explicitly allowed by a ZPR policy, even if it’s permitted by NSG or Security List rules. That said, you still need NSGs or Security Lists in place. Use NSGs/SLs for foundational, network-level controls, and ZPR policies to granular attribute-based network layered security.

The proposed ZPR policy for app-A is (Identity & Security > Zero Trust Packet Routing > Policies):

In app.vcn:hub-vcn VCN allow '0.0.0.0/0' to connect to app.lb:App-A endpoints with protocol='tcp/443'

allow app.lb:App-A endpoints in app.vcn:hub-vcn VCN to connect to app.instance:App-A endpoints with protocol='tcp/443' in app.vcn:spoke-vcn VCN

In app.vcn:spoke-vcn VCN allow app.instance:App-A endpoints to connect to app.db:DB-A endpoints with protocol='tcp/1521'

The proposed ZPR policy for app-B is (Identity & Security > Zero Trust Packet Routing > Policies):

In app.vcn:hub-vcn VCN allow '0.0.0.0/0' to connect to app.lb:App-B endpoints with protocol='tcp/443'

allow app.lb:App-B endpoints in app.vcn:hub-vcn VCN to connect to app.instance:App-B endpoints with protocol='tcp/443' in app.vcn:spoke-vcn VCN

In app.vcn:spoke-vcn VCN allow app.instance:App-B endpoints to connect to app.db:DB-B endpoints with protocol='tcp/1521'

With these policies in place, Application A and Application B remain fully isolated. The ZPR network becomes resilient to misconfiguration and cloud infrastructure changes. Routing updates won’t weaken the security posture, and any new resources, regardless of the subnet or VCN in which they’re deployed, will be permitted to connect only to what is explicitly allowed by the ZPR policies.

Developers can then focus on building the applications by simply assigning the appropriate security attributes to OCI resources, they help ensure each service has the required connectivity and security isolation without complex routing changes or intricate security configurations.

References

• Introducing Zero Trust Packet Routing (ZPR) with Cross-VCN Support
• Policy Syntax for Endpoints in Two VCNs