Traditional network architecture-based approaches to security are complex with numerous points of configuration, which are difficult to fully understand and create potential gaps that can be exploited. To help strengthen cloud security posture, Oracle Cloud Infrastructure (OCI) is introducing a new solution for separating network security from network architecture.
Securing your OCI application is like being a city planner. You’re responsible for securing sensitive parts of the city like the airport and a military base. If you use the road network alone, you end up with convoluted suburbs, endless intersections, and small islands of limited use. These architectures are onerous to build and impossible to maintain as requirements change over time. You must add guards to check IDs and ensure that only the right folks are allowed access to sensitive things. Now, you have a complicated road network and endless checkpoints.
Today, modern network design is the same: Network architects have one set of tools (road building) to deliver availability and security. Far too often this process ends in either network disruption or security breaches through configuration mistakes leading to accidental exposures.
Network architecture and network security are bound together because the architecture itself defines the network security posture. Creating a security boundary for data requires a detailed understanding of network topology, which becomes complex as the cloud footprint, users, and data grows. If the new applications require changes to the network architecture, it can result in an unexpected change in security posture. For example, if multiple applications share the same subnet and one of them requires internet access, the network architecture change for that one application can affect the network security of the other applications on that same subnet.
Customers need a way to describe their network security intent independently from their network architecture. The security intent needs to translate into policies managing network access so that restricts access to sensitive data via specific network paths. This intent should avoid data movement between unauthorized resources, even for the users with the legitimate privileges, because it can help prevent exfiltration using stolen credentials.
Enter OCI Zero Trust Packet Routing
In collaboration with Applied Invention, Oracle is proud to announce OCI Zero Trust Packet Routing (ZPR), pronounced “zipper.” ZPR is our first step to improving the separation between network architecture and network security and making security expressible in an intent-focused language.
OCI ZPR is a user-friendly solution that empowers customers to define security intent by creating security policies in natural language and vocabulary, making it easier to restrict access to sensitive data through specific access pathways. Separating network architecture and network security by removing the outdated reliance on routing tables and IP addresses reduces risks from human error and configuration drift.
Network architecture changes don’t impact OCI ZPR polices and don’t expose sensitive data. OCI ZPR policies are also much easier to audit because they’re in a readable language and don’t rely on understanding each layer of network architecture.
OCI ZPR is comprised of two main components: Security attributes and ZPR policy. Security attributes are applied to the Compute instances, virtual cloud networks (VCNs), and databases and tell ZPR which resources to protect. ZPR policy statements are human-readable rules that describes how OCI resources (compute and database in the first release) with security attributes can connect to each other.
How to use OCI ZPR to improve your network security.
Implementing OCI ZPR always follows a general process. Before you start implementing OCI ZPR, ensure that you understand your desired data flows. For example, we have an organization, CarCo, that needs to protect sensitive customer information in their backend database. CarCo application clients make legitimate requests to the database, and all other connections should be prevented. Before OCI ZPR, CarCo's security team relied on their network architecture team to assist with configuration of subnets, CIDR blocks, network security groups (NSGs), which are rules based on IP, port, and protocol, and firewall rules that define ingress and egress restrictions.

To implement this design with OCI ZPR, create security attributes for each component of your system. A security attribute is like a label that the OCI ZPR policy uses to identity which resources a ZPR policy controls. We recommend reusing the Oracle-zpr security attribute namespace at the beginning because it makes the ZPR policy easier to read. For our CarCo example, implement these security attributes: applications:carco for the frontend Compute instances, customer-data:carco for the database, and networks:db for the VCN.
OCI ZPR’s first release supports many Oracle databases, including Autonomous Database on dedicated infrastructure, Autonomous Database Serverless, Exadata Database Service and Base Database Service. In this example, we’re using (Database type>).
First, we create the policy, “in networks:db VCN allow db:app1 endpoints to connect to all-osn-services,” to ensure that the database can connect to OCI services to work with patching, Key Management Service (KMS), and other OCI services.
Next, create the ZPR policy, “in networks:db VCN allow applications:carco endpoints to connect to customer-data:carco,” which secures the database against unwanted connections while allowing it to communicate to CarCo application. This ZPR policy statement only allows access from Compute instances with the applications:carco security attribute to connect to resources with the customer-data:carco security attribute.
After the ZPR policy statements are created, apply the security attributes to both the frontend client apps and the database through the ZPR UX or by using the details page of the compute or database.
Using OCI ZPR to protect access when using a web server

In the previous steps, we secured an application communicating to a database. Now, we need to add a web application that end users can use. The webserver should only access the database through the CarCo application servers.
Exposing a webserver typically means attaching an internet gateway (IGW) to the VCN and Compute instances on the public subnet. Adding an IGW always adds risk, and this change requires careful review to ensure that the database wasn’t accidentally exposed to the internet. However, the ZPR policy ensures that users can access the database only from CarCo application and not from the internet, even with compromised credentials.
The requirements have changed, and now the application must have internet-facing web servers as the frontend of this application. We follow the previous process to secure the web servers.
Create a new security attribute, “applications:web-app,” in the Oracle-ZPR security attribute namespace. Then, add the line of policy, “in networks:db VCN allow applications:web-app endpoints to connect to applications:carco endpoints.” This addition allows only the web app servers (applications:web-app) to access the applications:carco app. Even if the network architecture changes, the database can’t be accessed through the internet or anything except applications:carco, because of the ZPR policy written in the first example.
Then, add a line of policy to allow the web-app endpoints to receive traffic from the internet: “in networks:db VCN allow all-endpoints to connect to applications:web-app endpoints.” This ZPR policy allows any internet connection to connect to only the applications:web-app endpoints. Even if the database is incorrectly placed on the public subnet, it isn’t exposed to the internet.
Finally, apply the “applications:web-app” security attribute to the Compute instances in the public subnet. At this point, only the web servers are accessible from the internet. The database continues to be accessible only from the application servers.
Looking forward
In these examples, we used OCI ZPR to separate the network security intent from the network architecture by creating ZPR policy and applying security attributes. The application now strictly defines the exact connections allowed and protects the data in the database from unexpected access from the internet.
This blog post explained the general approach of understanding the design, creating security attributes, creating ZPR policies, and applying security attributes to the components of the application. The result is an application with improved network security.
Oracle Cloud Infrastructure Zero Trust Packet Routing is just the first step in a broader security strategy for Oracle, where customers express their security intent and the cloud automatically integrates this intent into the correct architecture and configuration.
For more information, see the following resources: