Beyond IP Rules: Securing the Enterprise Cloud with OCI Zero Trust Packet Routing (ZPR) and IAM Deny Policies

For years, securing cloud workloads meant living in spreadsheets of IP addresses, CIDR blocks, security lists, and NSGs. It works, until it doesn't. One misconfigured rule or one leaked credential, and an attacker can start moving sideways through your network toward your data.

Oracle Cloud Infrastructure (OCI) now offers a better way: Zero Trust Packet Routing (ZPR) and IAM Deny Policies. Instead of tying security to fragile IP layouts, you write guardrails in plain language that describe what you actually intend.

Why traditional perimeter security struggles

If an attacker compromises a workload or steals valid credentials, they can often hop across VCNs as long as the network paths and firewall rules allow it.

Teams try to contain this with micro-segmentation, but managing thousands of IP-based rules is painful. It's easy to get wrong, hard to audit, and tied to infrastructure that keeps changing. When IPs shift or auto-scaling spins up new instances, static rules break, and the usual fix is to loosen them.

So what is ZPR?

ZPR separates what you want to allow from how your network happens to be laid out. Instead of asking "which IPs can reach this port?", you ask "which workloads should be allowed to access this type of data or service?"

A few things make it stand out:

• Readable policies: Rules are built on security attributes, not subnets or IP ranges, so anyone on the team can understand them.
• Default deny: Even if a workload is compromised, the network fabric blocks unauthorized lateral movement unless a policy explicitly allows it.
• Continuous verification: ZPR works with Private Service Access (PSA) and OCI IAM, so checks extend down to individual data and service endpoints.

IAM Deny statements: the other half

ZPR protects the network. IAM Deny statements tighten control on the identity side.

OCI IAM has traditionally been deny by default, with allow policies granting access. That's fine for simple setups, but large enterprises with delegated, multi-tenant administration want firmer top-down control. Deny statements give you that:

• They win over Allow: An explicit DENY overrides any conflicting ALLOW.
• Tenancy-wide boundaries: Admins can set hard limits, like "nobody provisions resources outside approved regions," while still handing day-to-day management to compartment admins.

Setting it up, step by step

Step 1: Enable ZPR and create security attributes

1. In the OCI Console, go to Identity & Security → Zero Trust Packet Routing.
   
   
   
   
   
2. Click Enable ZPR. This creates the default Oracle-zpr security attribute namespace in your root compartment.
   
   
   
   
   
   
   
3. Under Security Attribute Namespaces, click Create Security Attribute to define your tags.

Path: Identity & Security → Zero Trust Packet Routing → Security Attribute Namespaces

Step 2: Tag your resources

Apply attributes straight to the workloads you care about (Compute instances, Autonomous Databases, VCNs) instead of fiddling with subnet ranges.

1. Open Compute → Instances (or Oracle Database → Autonomous Database).
2. Select the resource, then open Security Attributes from the left menu (or the Security section) and click Add Security Attribute.
3. Assign your attributes. For example, Sensitivity = DB for databases and Sensitivity = WebApp for frontend compute.

Path: Compute / Database → [Select Resource] → Security Attributes → Add Security Attributes

Step 3: Write your ZPR policies and IAM Deny rules

ZPR policy:

1. Go to Identity & Security → Zero Trust Packet Routing → Policies.
2. Click Create Policy and use either the Policy Builder or the Manual Editor.
3. Write your intent, for example:

in VCN allow app:frontend to connect to app:database with protocol='tcp/1521'

IAM Deny:

1. Go to Identity & Security → Policies.
2. Add top-level DENY guardrails to catch permission creep across compartments, for example:

DENY group NetworkAdmins to manage vcn-security-lists in tenancy where request.region != 'us-ashburn-1'

How to check that it's working

Once everything is in place, confirm that traffic actually follows your policies.

1. Network Path Analyzer

1. Go to Networking → Network Path Analyzer, or pick Path Analysis from a resource's action menu under Protected Resources in the ZPR console.
2. Choose a source (say, an app instance) and a destination (say, your database endpoint).
3. Walk through the hop-by-hop results. You'll see the route and Security List status, plus the ZPR evaluation result showing whether a matching policy allowed or denied the connection.

2. Live testing and logs

• Try to break in: Attempt an SSH or SQL connection from an untagged instance or an unapproved subnet. It should time out or be refused at the network fabric layer, even if your NSG rules on port 1521 or 22 would have allowed it.
• Check the logs: Go to Logging → Log Groups and review VCN Flow Logs or Audit Logs. Look for dropped-packet events tagged ZPR_DENY or POLICY_EVALUATION_FAILURE to spot attempted lateral movement.

The takeaway

ZPR and IAM Deny policies move cloud security from "who has which IP" to "who should have access to what." That means fewer brittle rules, clearer audits, and a much smaller blast radius when something goes wrong.