When security rules grow faster than your ability to understand them, you don’t have security—you have the illusion of it. That’s the challenge one Oracle Cloud customer faced before adopting Zero Trust Packet Routing (ZPR) and Private Service Access (PSA). This demonstrates how they went from sprawling, brittle security lists to a clean, workload-centric policy model that is easier to audit, harder to abuse, and designed to scale.
The Problem: Security Lists That Nobody Could Explain
The customer’s environment was typical of many mature cloud deployments: a multi-region architecture with separate control plane and data plane VCNs with compute, load balancers, scanning tools, bastion hosts and service gateway connection for access to Oracle Services Network resources like object storage, logging, and authentication.
On paper, it was well-structured. In practice, the security rules that governed it had become a maintenance burden with real security implications.
Security List Pain Points
- Rule sprawl and intent disconnect: over 150 security rules including unexplained CIDR sources, destinations and duplications
- Subnet-centric, not workload-centric: Segmentation was tied to network topology, not to what workloads needed to communicate with each other.
- Audit overhead: Verifying least-privilege access was a slow, manual process – resource intensive and error-prone, typically taking external audit teams weeks to verify intent.
OSN Access Pain Points
- Broad access by default: The standard pattern allows workloads access to all OSN services, providing far more access than needed.
- Port ambiguity: Many Oracle services share tcp/443, so a single permissive rule could grant access to services the workload should never touch.
- Exfiltration potential: Broad access to all OSN services without local credential enforcement could provide vectors for data exfiltration.
The Solution: Workload Identity Meets Policy-Driven Enforcement
The target architecture replaced CIDR-based rules and broad SGW access with a ZPR and PSA model built around ZPR Security Attributes applied to workloads that describe what they are, not where they sit on the network.
The new model: Enhanced security with Zero Trust Packet Routing, Private Service Access and IAM Deny
The new model introduced these changes:
- Workloads were given identities (Security Attributes): Each resource was tagged with attributes describing its role (e.g., app, DB, bastion).
- Service access was made explicit (PSA): Instead of broad access to OSN, PSA endpoints were created only for the services used. No other services were allowed.
- Local credential authentication required: PSA enforces strict local credential usage by default.
- IAM Deny: made PSA usage mandatoryand effectively disabled broad access through service gateway.
- Human readable policies declared intent: ZPR policies replaced CIDR-based rules with attributes providing better security that was easily auditable.
Key Changes in the Target Architecture
- Namespaces and Security Attributes defined for every workload in both the control plane and data plane VCNs, organized by resource types.
- Using PSA endpoints, workloads can ONLY talk to the prescriptive services it needs, nothing more.
- IAM deny policies block service gateway access, forcing all traffic through PSA endpoints.
- ZPR policies replace security lists with explicit allow rules using natural language attributes—every permitted communication path is named and intentional.
- PSA endpoints inherently require local credentials, neutralizing the cross-tenancy credential abuse vector.
One of the most powerful properties of this model: once ZPR SAs and policies are in place, the underlying network topology can be reconfigured, such as changed IP address or subnet reconfiguration, without touching any policy rules. The security model travels with the workload identity, not the network.
What Actually Improved
The biggest change wasn’t just fewer rules—it was that the system became explainable again.
- You can look at a policy and understand exactly what communication it allows.
- Service access is scoped to specific endpoints, not entire service network.
- Credential use is constrained to the local tenancy by design.
- Security is no longer tied to where something lives in the network. Workloads can be moved or change addresses without rewriting security policy.
Before (Security Lists + Service Gateway)
Innocent, but problematic
Looks fine, but in reality, the app subnet is being allowed egress access to ALL OSN services. If we look at this example and say that the apps should only have access to IAM, Logging, Auditing, and Certificate services, there isn’t a way to block access to Object Storage or Functions.
Attack Vector
If an attacker is able to gain access to one of the app servers, they can use that same OSN access to run remote Functions or access any Object Storage buckets they want to with foreign credentials from any other tenancy, allowing them to exfiltrate data to any bucket they want.
After (ZPR + PSA)
More specific policies and access
With ZPR, the policy is human readable and attached to the workload identity. With PSA and IAM deny, access to Oracle services is explicit and required and there isn’t a way to access more services than expressly allowed. Even though the example shows all PSAs having the same security attribute (grouped for policy rule optimization), each PSA still provides a restricted access path that only allows service calls to that one specific service.
Same attack vector – No exfiltration
If an attacker gains access to one of the app servers, they can’t use that same OSN access to run remote Functions or access any Object Storage buckets, and they must have local credentials to try to access any of the specific services that are allowed. Therefore, even if they can use a vulnerability to get root access to one of the compute instances, they don’t have local credentials to use for direct Object Storage access, so exfiltration to and external bucket fails. Now we have a hard security boundary for service access, not a best effort one.
Similarly, broad subnet-based rules previously allowed unintended lateral movement. With ZPR, communication is scoped to workload roles—only explicitly defined interactions are possible.
The Journey: A Tabletop Exercise to Map the Path Forward
Moving from the old model to the new one required a structured process. The team developed a Tabletop Exercise methodology to safely plan the migration without disrupting production workloads.
Step 1: Automated Inventory Extraction
Starting from the customer’s existing Terraform state files, a deterministic LLM-based analysis tool produced a structured inventory of every VCN, subnet, IP address, compute instance, and service.
Step 2: Security Attribute Assignment
Once the inventory was validated, the team assigned SAs to each resource using a prescriptive naming scheme. This assignment could be done manually or via automation, with the prescriptive SA names enabling consistency across teams.
Step 3: Policy Translation
The tool then produced a direct, 1:1 translation of every existing Security List and NSG rule into ZPR policy statements. This is a handy first step before optimization. The team has a policy set that exactly represents what was permitted before expressed in the new, ZPR language. From that we see a comprehensive—if verbose—policy set that mirrors the original intent of the security lists.
Step 4: Optimization and Abstraction
The real value emerges in the post-translation review, where the optimization can combine SAs and policies where commonality exists. Consider the scan subnet rules where every resource got its own rule:
- in app-dp-prod.network:cp vcn allow ‘10.0.128.0/24′ to connect to app-cp-prod.app:cp endpoints with protocol=’tcp’
- in app-dp-prod.network:cp vcn allow ‘10.0.128.0/24′ to connect to app-dp-prod.app:dp endpoints with protocol=’tcp’
- in app-dp-prod.network:cp vcn allow ‘10.0.128.0/24′ to connect to app-tool-prod.app:tool endpoints with protocol=’tcp’
By introducing a single SA app-ccommon.scan:target for everything that needs to be scanned, those rules can be collapsed:
- in app-dp-prod.network:dp vcn allow ‘10.0.128.0/24‘ to connect to app-ccommon.scan:target endpoints with protocol=’tcp’
Similar optimizations can be applied to common components like PSAs, bastions, etc.
The Results: What ZPR Actually Delivered
The work done through the exercise with this customer delivered:
- Fewer, more readable intent
- Equivalent security rules in 79 human-readable ZPR policy statements vs 151 security list rules with only IP addresses.
- Explicit access to OSN services
- Without PSA, customers typically open broad access to all OSN for all protocols drastically decreasing security posture.
- With PSA, OSN access is now prescriptive, delivered per-service, enforces better hygiene and lowers chance of exfiltration.
- Eliminated foreign credential usage and object storage exfiltration
- Because prescriptive, per-service access is provided with PSA there is no opportunity for an attacker to exfiltrate data via object storage.
- PSAs require local-tenancy-only credentials for service access. No attacker can bring their own credentials and access foreign object storage with foreign credentials.
- Simplified, readable policy audits
- ZPR rule structure makes security policy human readable and easier to audit at a glance.
- Security policy independence from network topology
What This Means for Your Environment
This customer’s journey illustrates something important: the security complexity that accumulates in cloud environments doesn’t have to be inevitable. When used together, ZPR and PSA can eliminate the conditions that create complexity without compromise, making both accidental over-permission and intentional abuse become dramatically harder.
For more information, see the following resources: