Prepare Zero Trust Packet Routing Components for Securing Oracle Analytics Services

This diagram depicts an OCI region in a customer’s cloud account (tenancy) before ZPR is applied. The resources depicted include load balancers, compute instances, OAS instances, OAC endpoints, and ADW (Autonomous Data Warehouses).

This diagram depicts the ZPR components necessary to secure Oracle Analytics services.

A policy consists of one or more policy rules. A policy rule grants a group privileges to interact with resources in a tenancy or compartment.

You have the necessary privileges if you are an OCI Administrator. If not, a ZPR administrator needs the following:

• Privileges that allow managing the resources that ZPR protects.
• Allow group ZPR_SecurityAdmins to manage zpr-configuration in tenancy
• Allow group ZPR_SecurityAdmins to manage security-attribute-namespace in tenancy
• Allow group ZPR_SecurityAdmins to manage zpr-policy in tenancy
• Allow group ZPR_SecurityAdmins to manage all-resources in Compartment ZPR_Compartment

ZPR is disabled by default. Enabling it in a tenancy creates a default Oracle-ZPR security attribute namespace and allows you to begin using it.

Oracle recommends separate compartments for ZPR namespaces for the separation of duties. For example, a Human Resources ZPR security administrator may not be a Financials ZPR administrator.

Compartments organize and isolate cloud resources. They span all subscribed regions in the tenancy.

A ZPR policy is a container for ZPR policy statements. ZPR policy statements are rules that specify what resources can access other resources. A ZPR policy is based on an Attribute Based Access Control (ABAC) authorization model that evaluates attributes (or characteristics) to determine resource access.

Several frameworks exist to deploy the components:

A typical provisioning sequence using the OCI console follows:

1. Create or ensure that ZPR administrators have the necessary privileges granted via OCI policies.
2. Enable ZPR in your tenancy.
   • Navigate from the menu to Identity & Security > Zero Trust Packet Routing.
   • Click Enable ZPR.
   • Click Enable ZPR again to confirm.
     

     

3. Create a ZPR compartment, namespace, and attributes.
   • Create a ZPR compartment for each planned ZPR functional area, e.g., HR, ERP, etc.
     • Create a ZPR namespace in the ZPR compartment.
       • Navigate from the menu to Identity & Security > ZPR Security Attribute Namespace.
       • Select the ZPR Compartment.
       • Click Create Security Attribute Namespace.
         • Enter a Name and Description, and click Create.
           

           

     • Create ZPR attributes in the ZPR namespace. The example policy uses three attributes: app, network, and database.
       • Navigate to the ZPR namespace and click on it.
         • Click Create Security Attribute.
           • Enter a Name and Description, and click Create.
           • Repeat for the other attributes.

Caution! The attributes and attribute values assigned to resources like OAC and ADW must first be referenced in a policy statement. Assigning attributes to resources without a corresponding reference renders them inaccessible.

Using your ZPR namespace requires the namespace to precede security attributes. An example policy statement that allows OAC to connect to an ADW is:
in ceal_zpr.network:zpr-vcn VCN allow ceal_zpr.app:zpr-oac endpoints to connect to ceal_zpr.database:zpr-adw:enforce endpoints

In the above statement, ceal_zpr is a ZPR namespace, network, app, and database are ZPR attributes, and zpr-vcn, zpr-oac, and zpr-adw are attribute values.

4. Create a ZPR policy.
   • Familiarize yourself with ZPR policy basics before creating a policy.
   • Navigate from the menu to Identity & Security > ZPR Policies, and click Create Policy.
     • Enter a Name and Description, and then click Add Policy Statements.
       • Add policy statements using the Manual Policy Builder.
       • Click Add.
     • Click Create Policy.

The next step in the ZPR journey is to assign ZPR attributes to the analytics and supporting resources. The processes differ depending on the use case and are described in companion posts of this series.