Secure Oracle Analytics Cloud using Zero Trust Packet Routing

November 18, 2024 | 11 minute read
Text Size 100%:
rw

Published November 18, 2024 v3

Introduction Oracle Analytics Platform

The Oracle Analytics platform comprises OAC (Oracle Analytics Cloud) and OAS (Oracle Analytics Server). It supports the efforts of every analytics user role. AI and ML are embedded throughout the platform to accelerate productivity and power better business decisions. Features include:

  • Data visualization and storytelling
  • Machine learning
  • Mobile analytics
  • Open data source connectivity
  • Data preparation and enrichment
  • Enterprise data modeling

OAC PLATFORM


This post guides you in securing OAC (Oracle Analytics Cloud) using ZPR (Zero Trust Packet Routing). It is part of the Analytics Zero Trust Packet Routing series and a companion post to Secure Oracle Analytics Server using Zero Trust Packet Routing. It includes architectural diagrams, component descriptions, deployment scenarios, and links to other references.

Prerequisites

Following the guidance in this post requires:

  • An existing OCI tenancy.
  • An OCI Administrator with the authority to:
    • Manage Resources in Compartments
    • Manage ZPR Policies in the Tenancy
  • The ZPR components introduced in the Prepare Zero Trust Packet Routing Components for Securing Oracle Analytics Services  post:
    • An OCI compartment for ZPR
    • OCI Policies that allow the management of resources in the OCI compartment
    • ZPR Namespace
    • ZPR attributes
    • An understanding of ZPR policy statements
  • A VCN (Virtual Cloud Network).
  • A functioning ADW (Autonomous Data Warehouse) with a private endpoint in the VCN.
  • Two functioning OAC instances: one with a public endpoint and one with a private endpoint. Both must have PAC (Private Access Channel) enabled and have all endpoints in the same VCN as the ADW.
  • The OAC instances must be accessible.
    • Proxy resources, NLBs (Network Load Balancers), exist to support Internet access if necessary.
    • The DNS (Domain Name System) is configured to resolve the OAC and ADW hostnames.
    • The security lists and route tables are configured to allow ingress from users and egress to the ADW.
    • Connections exist to the ADW.

Synopsis

The OCI Zero Trust Packet Routing documentation provides an excellent introduction and a short video.

ZPR helps prevent unauthorized access to data by decoupling network security policies from the underlying network architecture. Using an easily understood, intent-based policy language, functional security administrators can define specific access pathways for data that build upon the foundation of network firewalls, route tables, and security lists managed by network administrators.

ZPR policies require that the network administration components exist but take precedence over them. For example, security lists and route tables in a VCN (Virtual Cloud Network) secure OAC resources. ZPR policies restrict access to only the resources explicitly assigned to ZPR security attributes referenced in a ZPR policy.

ZPR is VCN-centric. Components secured with ZPR security attributes must reside in the same VCN.

The public OAC instance is in the Oracle Services Network and accessible from the Internet. Because it is not in the VCN, it cannot be secured directly with ZPR.
This post shows an alternative where the public OAC instance is accessed via an NLB in the VCN. This alternative enables ZPR to secure it.


Topics
rw
Architecture
Initial State

This diagram depicts a VCN in an OCI region containing ADW and OAC private endpoints and public NLBs to support Internet access.

ZPR OAC Initial State


Prepared State

This diagram depicts the ZPR components necessary to secure the NLBs, OAC services, and the ADW.

ZPR OAC Secrued State

rw
Components

The secured architecture has these additional components:

  • ZPR Attribute Values
  • ZPR Policy Statements
  • ZPR Resource Assignments

User DeviceA device with an IP address that is used to connect to the OAC instances.


ZPR Attribute Values

ZPR security attribute values are referenced in ZPR policies to control access to supported resources.  The examples in Prepare Zero Trust Packet Routing Components for Securing Oracle Analytics Services have the following ZPR security attributes defined:

  • app (application)
  • network
  • database

This post uses the following values:

  • network:zpr-vcn
  • database:zpr-adw
  • app:zpr-oac
  • app:zpr-nlb

External resources outside the VCN must be referenced using CIDR blocks ( A CIDR block is a collection of IP addresses that share the same network prefix ). This post uses the following:

  • '138.1.8.16/32' for the public OAC instance
  • '10.20.0.0/16' for the user devices.

The following table shows the ZPR security attributes and values.

External

App Database Network
'138.1.8.16/32' '10.20.0.0/16'
zpr-nlb zpr-oac
zpr-adw zpr-vcn

ZPR Policy Statements

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.

The following statements are used in this post (ceal_zpr is the ZPR namespace):

in ceal_zpr.network:zpr-vcn VCN allow '10.20.0.0/16' to connect to ceal_zpr.app:zpr-nlb endpoints
in ceal_zpr.network:zpr-vcn VCN allow ceal_zpr.app:zpr-nlb endpoints to connect to ceal_zpr.app:zpr-oac endpoints
in ceal_zpr.network:zpr-vcn VCN allow ceal_zpr.app:zpr-oac endpoints to connect to ceal_zpr.database:zpr-adw endpoints
in ceal_zpr.network:zpr-vcn VCN allow ceal_zpr.app:zpr-nlb endpoints to connect to '138.1.49.233'  

ZPR Protected Resources

Protected resources are OCI services, i.e., OAC, NLB, ADW, with assigned ZPR attribute values.

The protected resources in this post are:

  • An NLB for the public OAC instance.
  • An NLB for the private OAC instance.
  • The private OAC ingress endpoint.
  • The public and private PAC egress endpoints.
  • The private ADW endpoint.
rw
Deployment Scenarios Frameworks

Several frameworks exist to deploy the components:

OCI Terraform

The OCI Terraform provider allows you to use Terraform to interact with OCI resources.

OCI Console

The OCI Console provides a single interface to manage all cloud services.

OCI APIs (Application Programming Interface)

The OCI APIs are REST APIs that use HTTPS requests and responses.

OCI CLI (Command Line Interface)

The OCI CLI is a small footprint tool that can be used alone or with the OCI Console to complete OCI tasks. The CLI provides the same core functionality as the Console, plus additional commands. Some of these, such as the ability to run scripts, extend Console functionality.


Provisioning Sequence

The provisioning sequence assumes the ZPR compartment, namespace, and attributes exist.

Caution! The attribute values assigned to resources 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.

A typical provisioning sequence for the components in this post follows:

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

ZPR_OAC_Policy

  1. Protect Resources
    • Navigate to Identity & Security > ZPR Protected Resources, and click Add security attribute to resources.
      • Select the VCN. and click Next.
        • Select the Security attribute namespace, e.g., ceal_zpr, and the Security attribute, e.g., network, from the dropdowns.
        • Enter the Security attribute value, e.g., zpr-vcn, and click Next.
        • Review the added resource and click Submit.
        • Click Close.
    • Click Add security attribute to resources.
      • Select the private ADW and click Next.
        • Select the Security attribute namespace, e.g., ceal_zpr, and the Security attribute, e.g., database, from the dropdowns.
        • Enter the Security attribute value, e.g., zpr-adw, and click Next.
        • Review the added resource and click Submit.
        • Click Close.
    • Click Add security attribute to resources.
      • Select the two NLBs and click Next.
        • Select the Security attribute namespace, e.g., ceal_zpr, and the Security attribute, e.g., app, from the dropdowns.
        • Enter the Security attribute value, e.g., zpr-nlb, and click Next.
        • Review the added resources and click Submit.
        • Click Close.
    • Click Add security attribute to resources.
      • Select the two OACs and click Next.
        • Select the Security attribute namespace, e.g., ceal_zpr, and the Security attribute, e.g., app, from the dropdowns.
        • Enter the Security attribute value, e.g., zpr-oac, and click Next.
        • Review the added resources and click Submit.
        • Click Close.

Protect_OAC


The next step in the ZPR journey is to assign ZPR attributes to other services, e.g., OAS and supporting resources. The processes differ depending on the use case and are described in companion posts in this series.

rw

Validation

Ensure that users can access the OAC instances and that the OAC connections to the ADW function correctly.

Ensure that ancillary connections that use the ZPR-protected resources function correctly.

Note. Once a ZPR attribute value is assigned to a resource, all ingress and egress to and from that resource is restricted. Assigning a value to an NLB and then creating a statement allowing it to connect to OAC is not enough.  You must also write statements for the users and resources connected to the NLB.
For example, assume the same NLB is used as a proxy for SQL*Developer connections to the ADW. This post adds an attribute value to the NLB and policy statements that allow the NLB to connect to OAC and user devices to connect to it.  Because there is no statement allowing the NLB to connect to the ADW, SQL*Developer sessions now fail.

rw

Explore More Explore more about Oracle Analytics by visiting the community, blogs, and library.
Explore more about ZPR
Explore Analytics Platform Features rw

 

Dayne Carley


Previous Post

Register and Invoke Custom Document Understanding Models in Oracle Analytics Cloud

Next Post


Unlocking Custom Visualizations in Oracle Analytics: A Guide to Building Your First D3.js Bar Chart - Part 1

Prasenjit Thakur | 5 min read
Oracle Chatbot
Disconnected