Zero Trust Packet Routing in Oracle Cloud: least privilege network in human understandable policies
ZPR (Zero-trust Packet Routing) is a new and free mechanism in Oracle Cloud Infrastructure to reduce the chances of unintended and potentially harmful network access. Normal network security hinges on network security rules, port settings and filters on protocol, origin and destination. This logic is typically implemented in terms of IP ranges or addresses, port numbers and other elements that are not intuitive and not always specific. Part of the logic can even play out as “traffic can happen unless it is explicitly disallowed”.
ZPR promises:
- least privilege principle: unless there is an explicit policy to allow a specific network connection, it can not be made
- policies expressed in logical, human readable attributes that are easy to create and interpret and that stay in effect across changes in IP, port, VCN and other network configuration aspects
When using ZPR we do a few things:
- indicate that a cloud resource is ZPR protected — this can be a Compute instance (VM), a database; when it is under ZPR protection, it can only ever be accessed when there is affirmation from a ZPR policy (in addition to regular network setup that still fully applies)
- add ZPR security attributes to resources such as Compute node, VCN, Database — and hopefully also Container, Function — to tag them and in doing so indicate their logical role
- define ZPR policies to specify which network interaction is intended; the policy is expressed in terms of the ZPR attributes. An example: “allow network traffic from app:CRM to database:customer-data with tcp to port 1521” ; only OCI resources with the ZPR attribute app:CRM assigned to them will be able to access an OCI resource with attribute database:customer-data (unless other ZPR policies have been defined)
ZPR Policies are enforced on top of normal network configuration. If a network connection cannot be made because ports are not open, firewalls do not allow it or IP addresses are private, then ZPR will never lower the barrier. It is the other way round: even if the network security rules seem to allow access, ZPR can still prevent the connection if there is no policy to explicitly make it happen.
Risks from forgotten firewall openings or VMs that are repurposed but not entirely reconfigured in network security rules are enormously reduced with ZPR. And the danger of misinterpretation or mistyping of network masks, IP numbers and other data not intuitive to most people is much smaller.
ZPR is free: “OCI ZPR is offered at no additional cost for OCI configuration and OCI activity across supported OCI services. This means you can leverage OCI ZPR’s robust security features without incurring extra charges, making it an accessible and cost-effective solution for enhancing your cloud security.” (source: FAQ).
Unfortunately, even though ZPR was announced at CloudWorld 2023 and again at CloudWorld 2024, ZPR is not yet (generally) available at the time or writing (16th September 2024). It may be a matter of just a few weeks.
There is a very good description of ZPR in this article (First Principles: Robust data breach protection with Zero Trust Packet Routing) : it made me really enthusiastic. And the ZPR Quick Start Guide has screenshots that give a very good idea of how to work with ZPR. But I cannot try out for real.
From that first article is this image:
I expect ZPR to be available on OCI in the very near future. And I expect any organization on OCI to very quickly start adopting it. It seems intuitive and straightforward. It adds easily understandable security from a least privilege principle approach. And it is free.
Edit (17–09): a next step I expect in ZPR is that security attributes and or policies will become dynamic. A policy then also looks at time or location, for example. This is a form of allowing/restricting that I think is difficult or impossible to set up with ‘traditional’ network security. This is part of the philosophy of Zero Trust Network Access (ZTNA), an important trend in how network access is thought about.
Another element in this — which I hope and expect will also come into ZPR — is that access is not assigned to a compute instance ( an IP address) but to an identity; an identity can also be an application, a container, a device or a person. I hope that in OCI, for example, we can assign a security attribute to Functions and Containers.