Overview of Zero Trust Packet Routing

With Zero Trust Packet Routing (ZPR), you can create security attribute namespaces  to organize security attributes  that you create to assign to the resources that you want to protect such as databases and compute instances. Then, using the security attributes, you create ZPR policies using Zero Trust Packet Routing Policy Language (ZPL) to express security intent about who can access those resources, and where the data can go. The policy engine compiles the intent into appropriate rules which are applied at policy enforcement points.

For example, a customer wants to protect their sensitive data from unauthorized access and exfiltration. The customer applies a Sensitive security attribute to their sensitive data stored in databases, and a Trusted security attribute to their front end applications. The customer then writes a ZPR policy that protects the data from any unauthorized access.

Allow Trusted hosts to send-receive Sensitive data over internal networks.

ZPR enforces the ZPR policy at the network level so that only those clients with the appropriate Trusted security attribute may access data with the Sensitive security attribute according to the ZPR policy.

When a client makes a request to the application servers, ZPR checks the network packets for security attributes. As the packets route through the network, the service checks the security attributes on both the source and the destination against the ZPR policy, and either blocks the request or allows the request based on the ZPR policy.

The following concepts are key to understanding the Zero Trust Packet Routing (ZPR) service.

security attribute

A label that can be referenced in ZPR policy to control access to supported resources.

security attribute namespace

A container for a set of security attributes.

ZPR policy

A rule that governs the communication between specific endpoints identified by their security attributes.

ZPR policy language (ZPL)

A language that defines authorized data flows between data sources by evaluating security attributes.

You can access Zero Trust Packet Routing (ZPR) using the Console (a browser-based interface), the command line interface (CLI), or the REST API. Instructions for the Console, CLI, and API are included in topics throughout this guide.

To access the Console, you must use a supported browser. To go to the Console sign-in page, open the navigation menu at the top of this page and click Oracle Cloud Console. You're prompted to enter a cloud tenant, username, and password.

For a list of available SDKs, see SDKs and the CLI. For general information about using the APIs, see REST API documentation.

Learn about per-resource limits on security attributes, and what characters are supported in security attribute strings.

• Security attributes per tenancy: unlimited
• Security attributes per VCN: 1
• Security attributes per resource (other than VCNs): 3
• Number of predefined values for a security attribute key: 100 per list
• Statements per policy object: 50
• Default policy objects per tenancy: 100
• Statements per tenancy (across all policy object): 1000

The following table lists resources that support Zero Trust Packet Routing (ZPR) security attributes. This table is updated as security attribute support is added for more resources.

Zero Trust Packet Routing (ZPR) policies coexist with existing OCI IAM policies to offer a more complete security posture.

ZPR policies and IAM policies differ in the following ways:

• ZPR policy is a network layer (L4) control similar to Network Security Groups (NSG)  and security lists  that defines connections between compute instances and databases in a tenancy.
• IAM policy is an application level (L7) policy language that controls which principals (groups or resource principals) can access which OCI resources using specific permissions, after a network layer connection has been established.

The biggest difference between ZPR policy and IAM policy is that ZPR policy addresses the networking aspect of a connection, namely, the security attributes of the source and the targets (compute or database), the ip address, the protocol, and the port. ZPR policy doesn't understand or evaluate the principal, the OCI resource types, or the permissions.

With OCI authorization, for example, when a user wants to delete an existing database instance they sign in to the OCI Console (or use the CLI or SDK) using an OCI username and password, then issue the command to delete the OCI resource (database). At this point the OCI IAM policy is used to decide if the user has permissions to take that action based on IAM policy.

IAM policy and ZPR policy are both important, and both can be used to offer a more complete security posture.

A security list  lets you define and apply a set of security rules to all resources in a single VCN or subnet of a VCN. A compute instance or other resource can't opt in or out of the rules in place for the subnet or VCN it's using for connectivity. For more about security lists, see Security Lists.

A network security group (NSG)  lets you define and apply a set of security rules to a group of chosen virtual network interface cards (VNICs)  in a VCN. The VNICs can be in different subnets and some VNICs in a subnet can use only a security list while others use both a security list and an NSG. An NSG uses rules identical in structure to security lists. A VNIC can be set to join or leave an NSG from the VNIC's management details page in the Console, but you can't add or remove a VNIC from the NSG's management page in the Console. For more about NSGs, see Network Security Groups. For a more detailed comparison of security lists and NSGs, see Comparison of Security Lists and Network Security Groups.

ZPR policy  lets you define and apply a set of security rules to a wider variety of resources that aren't necessarily all in a single VCN, so your security posture is even less tied to your network's structure. The possible rules can be more granular and complex, and don't share the structure used by NSGs and security lists. You can set a resource to use a ZPR policy by adding a security attribute to it from the protected resources page in the Console, or you can add or remove a resource from the ZPR policy's details page in the Console.

ZPR policies let you apply security attributes directly to the VNIC or any other resources that you manage and define ZPR policies that reference the following items:

• The security attributes
• The host making the request
• The network the request is traveling on
• Whether an action is allowed

Traffic that's not allowed by policy can't travel on the network. Any resource that has the security attribute applied to it is subject to the ZPR policies that reference it. A resource can have a maximum of three security attributes.

We recommend using ZPR because ZPR lets you define more granular security requirements. For more information, see If You Use Zero Trust Packet Routing with Other Security Methods.

If You Use Zero Trust Packet Routing with Other Security Methods

Any VNIC or endpoint must have VCN or subnet security list rules that allow it to communicate. An NSG can add more rules on top of the security list rules for selected resources anywhere in a VCN. A ZPR policy can be layered on top of both security lists and NSG rules, or the ZPR policy can be in addition to a security list alone.

The following diagram is an illustration of the idea.

When you use ZPR with NSGs and security lists, the set of rules that apply to a particular resource include the following items:

• Zero Trust Packet Routing policies
• Security rules in all NSGs that the resource's VNIC belongs to
• Security lists rules relevant to all VNICs or endpoints in the VCN or subnet (every VNIC or endpoint has at least one relevant security list)