Many security incidents in cloud environments do not start at the perimeter. They start with a workload that has already been reached: a compromised instance, a leaked credential, or an overprivileged service account. Once a workload is compromised, the question becomes how far that foothold can be extended from there.

Oracle Cloud Infrastructure Zero Trust Packet Routing (OCI ZPR) is built around that question. Its operating principle is straightforward: access between workloads is determined by declared intent, not by network topology. What is permitted to communicate with what is expressed explicitly in policy, and anything not covered by a policy is not permitted. There is no implicit trust between workloads, and no assumption that traffic within the same VCN or subnet is safe by default.

Workload-to-workload communication is one surface. In practice, many enterprise customers also want to control how OCI services are accessed and from where, helping constrain access to services such as Oracle Cloud Infrastructure Object Storage to approved network paths and tenancy boundaries.

This is where Oracle Cloud Infrastructure Private Service Access (PSA) and IAM deny policies come in. Both are part of the recent OCI ZPR release and are designed to work alongside OCI ZPR as a cohesive set of controls, each operating at a different layer. PSA is designed to validate credentials used to interact with OCI services such as Object Storage at the service endpoint, helping prevent credentials issued in one tenancy from being used to access resources in another tenancy. IAM deny policies let you require that requests to OCI services arrive only through an approved private network path. Without that path, the request is denied, even if the credential itself is valid and would otherwise have permission. This helps address a common risk scenario in which a stolen or leaked API key could otherwise be used from outside an approved network path.

When these three controls are used together and configured as described, customers can strengthen their security posture at multiple levels simultaneously: workload communication governed by declared intent, service traffic constrained to the correct tenancy, and API access tied to an approved network path. The scenarios below walk through each control in a concrete situation, with the policy configuration and expected behavior for each.

Lateral Movement into the Database

Lateral movement is a common post-compromise concern in cloud environments, and it is the scenario OCI ZPR is most directly designed to help address. An attacker gains a foothold on a less-sensitive, externally reachable node, specifically a web-facing instance in the front-end tier, and then attempts to pivot from there toward the data. The web instance has a private IP address that is routable to the database subnet.

With OCI ZPR in place, the web node carries the attribute apps:frontend and the database carries apps:db. The policy for this environment permits only apps:backend endpoints to connect to apps:db endpoints on TCP/1521. There is no policy for apps:frontend to connect to apps:db. When the compromised web node attempts to connect to the database, OCI ZPR evaluates the attribute pair and finds no match. The connection attempt is not permitted at the network layer. In this example, the attacker does not complete a TCP handshake or receive an authentication prompt from the database.

The attribute is assigned to the resource, not its IP address. When instances are added or replaced during an autoscaling event, or when the VCN topology changes, the policy remains valid without modification. There are no IP lists to update and no security rules to revisit.

# ZPR policies for a three-tier application
in networks:app-vcn VCN allow apps:frontend endpoints to connect to apps:backend endpoints with protocol='tcp/443'
in networks:app-vcn VCN allow apps:backend  endpoints to connect to apps:db      endpoints with protocol='tcp/1521'
# No policy exists for: apps:frontend to apps:db

# Attacker on compromised web node attempts direct connection to DB:
$ nc -zv <db-private-ip> 1521
  => Connection refused   # ZPR: no matching policy for this attribute pair

# Legitimate backend node connecting to DB:
$ nc -zv <db-private-ip> 1521
  => Connection succeeded # ZPR: apps:backend to apps:db policy matched

Because enforcement is based on the attribute rather than the IP address, this protection can continue to apply across autoscaling events, instance replacements, and VCN topology changes without policy updates when IP addresses change.

Data Exfiltration to an External Tenancy

When workloads interact with OCI services, PSA can help require access to those services through a private endpoint inside your VCN. When PSA is configured, the Object Storage service hostname resolves to that private endpoint rather than the public objectstorage.<region>.oraclecloud.com address. At the endpoint, PSA validates the tenancy of the credentials in the request. Credentials that belong to a different tenancy are rejected before the request reaches the Object Storage service.

OCI ZPR adds a second, independent constraint: only nodes tagged with the apps:psa attribute are permitted to reach the PSA endpoint. A node without that attribute cannot make Object Storage API calls through PSA, regardless of the credentials it holds. Both conditions need to be satisfied.

# Attempt 1: Valid credentials, uploading to an external tenancy bucket
$ oci os object put --bucket-name attacker-bucket \
    --namespace external-tenancy --file records.csv
  => 403 Forbidden   # PSA endpoint: cross-tenancy credential rejected

# Attempt 2: Node without apps:psa attribute tries to reach the PSA endpoint
$ nc -zv <psa-objectstorage-endpoint> 443
  => Connection refused  # ZPR: no policy for this attribute to PSA endpoint

# Authorized: backend node tagged apps:psa, uploading to an internal tenancy bucket
$ oci os object put --bucket-name prod-reports \
    --namespace my-tenancy --file report.csv
  => 200 OK

Because the two controls operate independently, satisfying one is not sufficient. A valid credential without the right network path is rejected by PSA. A node with network access but without the permitted attribute cannot reach the endpoint through OCI ZPR. Both conditions need to be met.

Stolen Credentials Used from Outside OCI

Credential exposure can be one of the more damaging security risks in cloud environments, and it is a risk that IAM deny policies combined with PSA can help address. An OCI API key can be leaked through a committed ~/.oci/config file, a hard-coded secret in a CI/CD pipeline, a phished developer, or a misconfigured environment variable. Once the key is in an attacker’s hands, the traditional question is whether the key has the right IAM permissions. With IAM deny policies and PSA, there is a second question: is the request coming from the right place?

In this example, an IAM deny policy applied to the Object Storage namespace requires every request to arrive through a PSA gateway. The policy condition evaluates request.gateway.type. If the request arrives from the public internet, the gateway condition is not satisfied and the request is denied, regardless of whether the credential is valid, regardless of the IAM permissions attached to the user, and regardless of the resource being requested.

In this scenario, the denial returns a 404 Not Found rather than a 403 Forbidden. This is intentional: a 403 could confirm to the attacker that the bucket exists and that they lack permission. A 404 can help avoid confirming the existence of the bucket to an unauthorized requester.

The same credentials used by an authorized internal process, one whose traffic routes through the PSA gateway, continue to work as before. This is not a change to how authorized access works; it is an additional requirement on where that access can originate from.

# IAM Deny policy: applied to the Object Storage namespace
Deny any-user to inspect object-family in tenancy
  where any {
    not request.gateway.id,
    request.gateway.type != 'privateserviceaccess'
  }

# Attacker: valid API key, request sent from a laptop over the public internet
$ oci os object get --bucket-name prod-backups \
    --name data.sql.gz --file /tmp/local.gz
  => 404 Not Found   # IAM Deny triggered; bucket existence not confirmed

# Authorized internal process: same credentials, request routed via PSA
$ oci os object get --bucket-name prod-backups \
    --name data.sql.gz --file /var/backup/data.sql.gz
  => 200 OK          # PSA gateway present; IAM Deny condition not triggered

A valid API key used from outside the approved network path is not treated the same as one used from within it. The credential still needs to arrive through a PSA gateway for the IAM deny condition to be satisfied.

Putting It Together

OCI ZPR, PSA, and IAM deny policies each operate at a different layer: workload communication, service endpoint, and request path, respectively. Used together and configured as described, they help make network position alone, a valid credential alone, or access to the right endpoint alone insufficient. Each scenario requires a different combination of conditions to be satisfied simultaneously.

All three controls can produce entries in Oracle Cloud Infrastructure Audit logs. OCI ZPR security attributes are assigned through the Oracle Cloud Console, OCI CLI, or Terraform. PSA and IAM deny policies can be scoped to specific services and rolled out incrementally, starting with the most sensitive workloads.

For a broader overview of OCI ZPR and what this release covers, see the OCI ZPR release announcement.

Oracle Cloud Infrastructure Security | OCI ZPR Documentation | Private Service Access | Release Announcement