Oracle Cloud Zero Trust Packet Routing Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Security, Identity, and Compliance

1. Introduction

Important service-name clarification (read first): As of the latest publicly available Oracle Cloud Infrastructure (OCI) documentation available up to my knowledge cutoff (2025-08), there is no clearly documented, standalone OCI product page for a service explicitly named “Zero Trust Packet Routing.” If you received this name from an internal roadmap, a partner brief, a tenancy-specific feature flag, or an Oracle sales/security architecture deck, verify the exact product name and scope in your Oracle Cloud Console and the official OCI documentation before treating it as a discrete service.

Given that limitation, this tutorial treats Zero Trust Packet Routing as a practical OCI security architecture pattern: routing packets through controlled, inspectable enforcement points and allowing traffic only when it is explicitly authorized by identity, context, and policy—implemented using existing, generally available OCI networking and security services (for example, VCN routing, Network Security Groups, OCI Network Firewall (if available in your region), Logging/Flow Logs, and Cloud Guard).

What this service is (in practical OCI terms)

Zero Trust Packet Routing is an approach to designing OCI networks so that no network path is implicitly trusted. Instead of assuming “inside the VCN is safe,” you route traffic through explicit policy enforcement points (firewall/inspection subnets, gateway controls, micro-segmentation boundaries) and you deny by default, allowing only the minimum required flows.

Simple explanation (one paragraph)

Think of Zero Trust Packet Routing as building an OCI network where every packet must earn permission to move. Workloads don’t get broad access just because they’re on the same subnet or VCN. You use routing, segmentation, and inspection so only approved traffic reaches its destination, and everything else is blocked and logged.

Technical explanation (one paragraph)

Technically, Zero Trust Packet Routing in Oracle Cloud is implemented by combining VCN route tables, subnet design, Network Security Groups (NSGs) (and optionally OCI Network Firewall for stateful inspection), plus centralized logging and audit. You create controlled traffic paths (service chaining through an inspection layer), minimize lateral movement with micro-segmentation, enforce policy as code where possible, and continuously validate using Flow Logs, Logging, and Cloud Guard detections.

What problem it solves

It addresses common cloud security failures such as: – Flat networks that enable lateral movement after a single compromise. – Overly broad “allow VCN” rules and unmanaged east-west traffic. – Lack of consistent inspection and logging across subnets/environments. – Weak separation between app tiers, shared services, and administrative access. – Compliance demands for segmentation, auditing, and least-privilege access.

2. What is Zero Trust Packet Routing?

Official purpose (what can be verified)

OCI’s official materials strongly support Zero Trust architecture principles (least privilege, continuous verification, segmentation, auditability), but “Zero Trust Packet Routing” is not consistently presented as an independent, documented OCI service name in public docs (verify in official docs).

So, in an OCI context, the purpose of Zero Trust Packet Routing (as a pattern) is to: – Enforce deny-by-default traffic movement. – Make allowed paths explicit and inspectable. – Reduce blast radius with micro-segmentation and service-controlled routing. – Improve audit readiness with central logs and flow evidence.

Core capabilities (pattern-level, implemented with OCI services)

Explicit routing paths using VCN route tables and subnet design.
Segmentation and micro-segmentation using NSGs and subnet separation.
Centralized enforcement/inspection using OCI Network Firewall (where available) or vetted third-party NVAs (network virtual appliances) in an inspection subnet.
Controlled ingress/egress using internet gateways, NAT gateways, service gateways, and routing rules.
Visibility and audit using VCN Flow Logs, OCI Logging, and Audit.
Governance using compartments, tagging, and (optionally) Security Zones/Cloud Guard (verify applicability in your tenancy).

Major components (OCI building blocks you’ll use)

VCN (Virtual Cloud Network): your private IP space and network constructs.
Subnets: separate tiers and create inspection boundaries.
Route tables: force traffic through inspection paths.
NSGs (Network Security Groups): workload-level security policy (micro-segmentation).
OCI Network Firewall (optional but ideal): managed stateful traffic inspection (verify region availability and exact capabilities).
Bastion (recommended): reduce SSH exposure (verify Bastion service availability and features).
Logging & Flow Logs: visibility into accept/deny traffic and network flows.
IAM: least-privilege control over who can change routing and security rules.

Service type

Because “Zero Trust Packet Routing” is not clearly published as a discrete OCI service, treat it as a security architecture pattern within the Security, Identity, and Compliance category—implemented via OCI networking and security services.

Scope (regional/global/project-scoped/account-scoped)

The scope depends on the underlying OCI services: – VCN, subnets, NSGs, route tables: regional constructs inside a compartment. – OCI Network Firewall: typically regional (verify in docs/console). – Logging, Audit, Cloud Guard: tenancy/region-dependent (verify).

Fit in the Oracle Cloud ecosystem

Zero Trust Packet Routing ties together: – OCI Networking (VCN, gateways, DRG, route tables, NSGs) – OCI Security services (Network Firewall, Cloud Guard, Security Zones, Vault, Bastion) – Operations (Logging, Flow Logs, Monitoring, Events) – Identity (IAM policies, dynamic groups, instance principals)

3. Why use Zero Trust Packet Routing?

Business reasons

Reduces breach impact: limits lateral movement and isolates sensitive systems.
Improves audit outcomes: makes segmentation and policy enforcement demonstrable.
Standardizes security across teams and environments (dev/test/prod).
Enables safer cloud adoption by replacing implicit trust with controlled patterns.

Technical reasons

Deny-by-default network posture.
Clear traffic paths: app → inspection → DB, instead of “anything talks to anything.”
Easier threat containment: segmented tiers and controlled egress.
Better defense-in-depth: NSGs + routing + firewall inspection + logging.

Operational reasons

Repeatable architecture: can be templatized with Terraform.
Central change control: routing and firewall policies can be governed.
Improved troubleshooting: Flow Logs + centralized enforcement helps root cause.

Security/compliance reasons

Supports controls commonly expected in frameworks such as:
Network segmentation, least privilege, audit trails, change control
Helps satisfy internal security requirements around:
“No direct internet exposure”
“All egress inspected”
“Administrative access via controlled entry points”

Scalability/performance reasons

Scales by:
Segmenting domains (app tiers, shared services, admin, data)
Using distributed NSGs for micro-segmentation
Introducing dedicated inspection layers only where required
Performance tradeoff: centralized inspection can add latency; design for scale and avoid hairpinning where unnecessary.

When teams should choose it

Choose Zero Trust Packet Routing patterns when you need: – Multi-tier apps with sensitive data – Strong segmentation between environments/tenants – Centralized visibility into east-west traffic – Controlled egress for compliance – Reduced blast radius for high-risk workloads

When they should not choose it

Avoid overengineering if: – You run a tiny, low-risk sandbox with no sensitive data. – Latency budgets cannot tolerate inspection hops and you can’t architect around it. – You don’t have operational maturity to manage routing/firewall policy safely. – Your region lacks required primitives (for example, managed Network Firewall availability)—you may need alternative designs or third-party NVAs.

4. Where is Zero Trust Packet Routing used?

Industries

Financial services and fintech (segmentation, auditability)
Healthcare and life sciences (privacy and access controls)
Government and regulated public sector (strong boundary control)
Retail/e-commerce (protect payment systems and customer data)
SaaS providers (tenant isolation patterns)
Manufacturing/industrial (segmented OT/IT integration points)

Team types

Cloud platform engineering teams
Network engineering and cloud networking teams
Security engineering / SecOps
SRE and operations teams
DevOps teams implementing infrastructure as code

Workloads

Multi-tier web apps (web/app/db)
API platforms and microservices
Shared services (CI/CD, artifact repositories)
Data platforms (ETL, analytics)
Legacy apps migrated to OCI where segmentation is needed

Architectures

Hub-and-spoke VCN designs with shared inspection
Per-application VCN with strict inter-VCN routing via DRG
Multi-environment segregation (dev/test/prod in separate compartments/VCNs)
“No inbound internet” designs using private endpoints and controlled ingress

Real-world deployment contexts

Production: strict routing, inspection, centralized logging, change control
Dev/test: lighter inspection but still deny-by-default and micro-segmentation
M&A: isolate acquired environments and route through controlled gateways
Incident response: quickly quarantine segments by changing NSG/route/firewall policy

5. Top Use Cases and Scenarios

Below are realistic scenarios you can implement in Oracle Cloud using Zero Trust Packet Routing patterns.

1) Force all outbound internet traffic through an inspection layer

Problem: Instances egress directly via NAT, making policy enforcement inconsistent.
Why this fits: Route tables can direct 0.0.0.0/0 to an inspection subnet/firewall.
Example: All app subnets route internet-bound traffic to OCI Network Firewall; only approved domains/ports are allowed (verify firewall rule capabilities).

2) Micro-segment east-west traffic between app tiers

Problem: “Allow VCN internal” rules permit lateral movement.
Why this fits: NSGs enable per-workload rules; route design enforces tier boundaries.
Example: Web tier can only reach app tier on 8443; app tier can only reach DB on 1521; everything else denied and logged.

3) Build a “shared services” VCN that cannot be reached directly

Problem: Shared services become a pivot point if reachable broadly.
Why this fits: Control access via explicit routes and NSGs; require Bastion for admin.
Example: CI runners in a shared VCN can reach build targets, but app workloads cannot reach CI subnet directly.

4) Enforce segmentation between environments (dev/test/prod)

Problem: Developers can accidentally reach production databases.
Why this fits: Separate compartments/VCNs and tightly controlled interconnect routes.
Example: Only a specific migration service subnet can route from dev to prod DB during a change window.

5) Centralize ingress through a controlled gateway path

Problem: Multiple public endpoints increase attack surface.
Why this fits: Consolidate ingress to one path and apply consistent policy.
Example: Internet → WAF/LB (if used) → inspection → private app subnets, with NSGs limiting reachability.

6) Enforce partner/VPN traffic restrictions

Problem: Partner networks connected over VPN get broad reachability.
Why this fits: DRG route tables + NSGs allow exact prefixes/ports only.
Example: Partner CIDRs can only reach a single API subnet on 443; no access to internal admin subnets.

7) Quarantine a compromised subnet quickly

Problem: Incident response needs fast containment.
Why this fits: Zero trust posture makes isolation straightforward (deny-by-default).
Example: Update NSG/route/firewall policy to block egress and east-west from the suspected subnet while keeping logging on.

8) Protect administrative access (SSH/RDP) without public IPs

Problem: Direct public IP access increases risk and audit burden.
Why this fits: Bastion + private subnets + NSGs enforce controlled entry.
Example: Admins connect using OCI Bastion to private instances; no inbound SSH from the internet.

9) Route database access through a narrow control plane

Problem: Many apps connect to DBs from many subnets; hard to audit.
Why this fits: Explicit routing + NSG rules define allowed sources.
Example: Only the app subnet NSG can reach DB subnet NSG on DB ports; Flow Logs provide evidence.

10) Create a compliant landing zone with enforced network guardrails

Problem: Teams deploy insecure networks by default.
Why this fits: Standard patterns + compartments + policies + detection.
Example: Use standardized VCN templates, mandatory logging, and governance checks (Cloud Guard/Security Zones—verify availability).

11) Multi-tenant SaaS isolation

Problem: Tenant A must never access Tenant B resources.
Why this fits: Per-tenant segmentation via NSGs/subnets/VCNs; explicit routing boundaries.
Example: Each tenant has its own app subnet and DB subnet; only tenant-specific routes and rules exist.

12) Data exfiltration risk reduction for sensitive workloads

Problem: Malware attempts to exfiltrate data via uncommon ports/destinations.
Why this fits: Restrict egress to required destinations and log all denies.
Example: DB subnet has no internet route; app subnet can only egress to specific update repositories.

6. Core Features

Because “Zero Trust Packet Routing” is treated here as an OCI implementation pattern, the “features” below map to what you can accomplish using current OCI networking/security capabilities.

Feature 1: Deny-by-default segmentation with NSGs

What it does: Controls inbound/outbound at the VNIC level by attaching NSGs to instances.
Why it matters: Prevents “flat network” lateral movement.
Practical benefit: You can express policies like “only app servers can talk to DB on 1521.”
Limitations/caveats: NSGs are not a replacement for L7 security inspection; they primarily enforce L3/L4 rules (verify current capabilities).

Feature 2: Explicit traffic paths with route tables

What it does: Routes traffic out of subnets to specific next hops (IGW/NAT/DRG/private IP targets depending on design).
Why it matters: Enforces that traffic takes an intended path.
Practical benefit: You can design “all egress must go through inspection.”
Limitations/caveats: OCI routing is destination-based; advanced “policy-based routing” is limited. Design carefully and verify supported next-hop targets in OCI route rules.

Feature 3: Central inspection with OCI Network Firewall (optional)

What it does: Provides managed firewalling/inspection capabilities in OCI (verify exact inspection features, rule types, and region support).
Why it matters: Adds stateful controls and potentially deeper inspection than NSGs.
Practical benefit: Consolidated policy and logging for traffic crossing inspection points.
Limitations/caveats: Service availability and capabilities vary; confirm in official docs for your region and tenancy.

Feature 4: Controlled ingress/egress with gateways

What it does: Uses Internet Gateway, NAT Gateway, Service Gateway, and DRG attachments to control north-south and on-prem connectivity.
Why it matters: Removes accidental internet exposure and restricts egress paths.
Practical benefit: Private subnets can remain private while still accessing required services.
Limitations/caveats: Misconfigured route tables can create unexpected egress paths; test regularly.

Feature 5: Auditability with VCN Flow Logs and OCI Logging

What it does: Captures flow-level data and logs for network troubleshooting and investigations.
Why it matters: Zero trust is incomplete without visibility.
Practical benefit: You can prove segmentation, investigate denies, and support compliance evidence.
Limitations/caveats: Logging has cost and retention implications; protect sensitive logs and tune retention.

Feature 6: Governance with compartments, tagging, and (optionally) Cloud Guard/Security Zones

What it does: Organizes resources, enforces guardrails, and detects misconfigurations.
Why it matters: Prevents drift and insecure exceptions.
Practical benefit: Standard naming/tagging and compartment boundaries simplify auditing.
Limitations/caveats: Guardrail features vary by tenancy configuration; verify what’s enabled.

Feature 7: Reduced admin exposure with Bastion (recommended)

What it does: Provides controlled administrative access to private resources without public IPs (verify service availability and exact workflow).
Why it matters: Eliminates broad inbound SSH/RDP exposure.
Practical benefit: Central audit trail and temporary, policy-based access.
Limitations/caveats: Still requires IAM discipline and key/session management.

Feature 8: Change control via infrastructure as code

What it does: Manages routing/segmentation consistently (commonly via Terraform; OCI Resource Manager can run Terraform—verify in official docs).
Why it matters: Network policy changes are high-risk; IaC adds review and repeatability.
Practical benefit: Pull-request review for route/firewall/NSG changes.
Limitations/caveats: Requires disciplined state management and approvals.

7. Architecture and How It Works

High-level architecture

A typical Zero Trust Packet Routing design in Oracle Cloud: 1. Place workloads in private subnets. 2. Use NSGs to enforce least-privilege traffic between tiers. 3. Force specific traffic (often egress or inter-tier) through an inspection layer: – OCI Network Firewall (managed), or – A third-party NVA in an “inspection subnet” (only if required and approved). 4. Turn on Flow Logs and central Logging for audit and troubleshooting. 5. Use IAM and compartments to control who can change routes and security rules.

Data flow vs control flow

Data flow: Packets between instances/subnets/VCNs traverse route tables, are allowed/denied by NSGs, and may pass through inspection points.
Control flow: Administrators define policies in IAM, configure VCN/NSGs/routes, manage firewall policies, and configure logging/monitoring.

Integrations with related OCI services (common)

Compute: instances that generate/receive traffic.
Load Balancer (optional): controlled ingress to private services.
Bastion (recommended): admin access to private instances.
Vault (recommended): store secrets/keys (if needed for apps/automation).
Logging, Monitoring, Events: operational telemetry and alerting.
Cloud Guard (optional): posture management and detections (verify tenancy configuration).
DRG/VPN/FastConnect (optional): connect to on-prem and other networks.

Dependency services (typical)

VCN, subnets, route tables
NSGs/security lists
Gateways (NAT/IGW/Service Gateway)
Logging + policies allowing log ingestion

Security/authentication model

IAM users/groups/policies govern who can modify network/security resources.
Instance principals / dynamic groups can be used for automation (verify official docs).
Audit logs capture API calls and changes.

Networking model

OCI uses destination-based routing in VCN route tables.
Micro-segmentation is typically done via NSGs.
Central inspection is implemented through managed firewall or NVA patterns (be careful with single points of failure and throughput sizing).

Monitoring/logging/governance considerations

Enable:
VCN Flow Logs for relevant subnets (especially inspection and sensitive tiers).
OCI Audit (enabled by default in many tenancies—verify).
Firewall logs (if using OCI Network Firewall—verify setup).
Define:
Log retention requirements and access controls (logs may contain sensitive IPs/metadata).
Alert on:
Route table changes
NSG rule changes
Unexpected internet gateways or public IP associations

Simple architecture diagram (Mermaid)

flowchart LR
  U[Admin/User] -->|HTTPS/SSH via approved path| EP[Entry Point\n(Bastion or LB)]
  EP --> APP[App Subnet\nPrivate Instances]
  APP -->|Allowed ports only| DB[DB Subnet\nPrivate DB/Instances]
  APP -->|Egress| INSPECT[Inspection Layer\n(OCI Network Firewall or NVA)]
  INSPECT --> NAT[NAT/IGW as needed]
  APP -. logs .-> LOG[Logging + Flow Logs]
  INSPECT -. logs .-> LOG

Production-style architecture diagram (Mermaid)

flowchart TB
  subgraph Tenancy[Oracle Cloud Tenancy]
    subgraph CompartmentProd[Compartment: prod]
      subgraph VCNHub[Hub VCN]
        DRG[DRG Attachment]
        INSUB[Inspection Subnet]
        NFW[OCI Network Firewall\n(or approved NVA cluster)]
        NAT[NAT Gateway]
        SGW[Service Gateway]
        LOG[OCI Logging / Log Groups]
      end

      subgraph VCNSpokeA[Spoke VCN: App A]
        AWEB[Web Subnet\n(private)]
        AAPP[App Subnet\n(private)]
        ADB[DB Subnet\n(private)]
      end

      subgraph VCNSpokeB[Spoke VCN: Shared Services]
        CI[CI/CD Subnet\n(private)]
        MON[Monitoring Tools\n(private)]
      end
    end
  end

  Internet((Internet)) -->|Ingress (optional)| WAF[WAF/LB if used]
  WAF --> AWEB

  AWEB --> AAPP
  AAPP --> ADB

  AAPP -->|Egress + controlled east-west| DRG
  DRG --> NFW
  NFW --> NAT
  NFW --> SGW

  NFW -. firewall logs .-> LOG
  AAPP -. flow logs .-> LOG
  DRG -. audit events .-> LOG

8. Prerequisites

Tenancy/account requirements

An active Oracle Cloud tenancy.
Ability to create and manage networking and compute resources in a compartment.

Permissions / IAM roles

For a lab, use an account with permissions to: – Create/manage VCNs, subnets, route tables, gateways – Create/manage NSGs and security rules – Create/manage compute instances – Enable/configure logging/flow logs – Create/manage OCI Network Firewall (if you use it)

Least-privilege IAM policy statements vary by resource type and OCI’s policy grammar. For production, verify exact IAM policy requirements in official OCI docs for each service you use.

Billing requirements

A billing-enabled tenancy (Pay As You Go or equivalent).
Some elements (Compute, Load Balancer, Network Firewall, Logging ingestion/retention) incur charges.

Tools needed

OCI Console access (browser)
Optional:
OCI CLI (for verification/automation): https://docs.oracle.com/en-us/iaas/Content/API/SDKDocs/cliinstall.htm
SSH client
Terraform (if you want IaC)

Region availability

Core networking (VCN, NSG, route tables) is broadly available.
OCI Network Firewall availability varies by region and tenancy. Verify in your Oracle Cloud Console and official docs.

Quotas/limits

Service limits apply for VCNs, subnets, route rules, NSGs, firewall instances, logging resources, etc.
Check: OCI Service Limits in Console (Tenancy Administration) and official docs.

Prerequisite services

For this tutorial you will use: – OCI Networking (VCN, subnets, gateways, route tables) – Compute (2 instances) – NSGs – Logging and VCN Flow Logs (recommended) – Optional: OCI Network Firewall (if available)

9. Pricing / Cost

Current pricing model (accurate framing)

Because “Zero Trust Packet Routing” is not a standalone, published OCI service SKU (verify), you don’t pay for “Zero Trust Packet Routing” directly. You pay for the underlying OCI resources you deploy to implement the pattern.

Pricing dimensions (typical cost components)

Common cost drivers include:

Compute instances – Charged per instance shape and runtime. – Also consider boot volumes and any attached block volumes.
OCI Network Firewall (optional) – Managed firewall pricing typically includes:
- Hourly (or per-time-unit) firewall instance cost
- Data processing cost (per GB processed)
- Verify the exact pricing dimensions on the official pricing page for your region.
Network egress – Internet egress is commonly billed per GB. – Inter-region traffic can be billed. – Some intra-region traffic within OCI can be free/cheaper depending on path—verify OCI networking pricing.
Logging and Flow Logs – Costs can include log ingestion, storage/retention, and querying/analytics (depending on services enabled). – High-volume subnets can generate large flow logs.
Load Balancer / WAF / Bastion (optional) – Load balancer pricing is typically per hour + bandwidth/LCUs (verify OCI LB pricing model). – WAF is typically per policy and request volume (verify). – Bastion may have its own pricing model (verify).

Free tier (if applicable)

OCI has a Free Tier program, but eligibility and included services vary. Verify current Oracle Cloud Free Tier coverage and whether it includes the services you plan to use (especially managed firewalls and logging).

Hidden or indirect costs

Log retention: keeping Flow Logs for long periods can cost more than expected.
Data processing: inspection layers may charge per GB; heavy east-west traffic can become expensive.
Operational overhead: time spent maintaining policies, troubleshooting, and change management.

Network/data transfer implications

Forcing traffic through inspection can:
Increase total bytes processed by inspection services.
Increase cross-subnet hops (latency and potentially billed traffic depending on model—verify).

How to optimize cost

Start with NSGs + minimal routing; add managed firewall inspection only where required.
Enable Flow Logs on sensitive subnets first; tune retention.
Avoid hairpin routing (sending traffic through inspection unnecessarily).
Use compartments and tagging to track spend per environment and team.
Consider separate “prod” and “non-prod” policies to reduce inspection overhead in dev/test.

Example low-cost starter estimate (no fabricated numbers)

A low-cost starter lab typically includes: – 2 small compute instances (always-free or low-cost shapes if eligible) – 1 VCN with 2–3 subnets – NSGs and route tables (no direct cost) – Minimal logging (short retention) – No managed firewall (or a short-lived firewall test, if allowed)

Exact totals vary by region, shapes, and log volume. Use: – Oracle Cloud Pricing: https://www.oracle.com/cloud/pricing/ – OCI Cost Estimator (official): https://www.oracle.com/cloud/costestimator.html (verify URL if it redirects)

Example production cost considerations

Production implementations often add: – Managed firewall with HA considerations (if supported/required) – Higher logging retention and possibly centralized logging analytics – Load balancers, WAF, bastion, backups – Multiple VCNs and DRG attachments – Larger compute shapes and more east-west traffic

Production cost is driven more by throughput (GB processed), egress, and log volume than by the number of route rules.

10. Step-by-Step Hands-On Tutorial

This lab is designed to be safe and low-cost while still demonstrating real, executable Zero Trust Packet Routing principles in Oracle Cloud.

If OCI Network Firewall is available in your region, you’ll add it as an optional step. If it isn’t available, you will still achieve a strong baseline using segmentation + explicit routing + logging.

Objective

Implement a small OCI network that demonstrates Zero Trust Packet Routing by: – Creating two private application tiers (App + DB). – Enforcing deny-by-default with NSGs. – Allowing only the minimum required traffic: – SSH from your admin IP (or Bastion, if you prefer) to App – App to DB on a single port – Enabling Flow Logs for visibility. – (Optional) Introducing an inspection layer using OCI Network Firewall.

Lab Overview

You will create: – 1 VCN: ztpr-lab-vcn (CIDR 10.0.0.0/16) – 2 private subnets: – app-subnet (10.0.1.0/24) – db-subnet (10.0.2.0/24) – 2 compute instances: – app-vm in app subnet – db-vm in db subnet – 2 NSGs: – app-nsg – db-nsg – Flow Logs enabled on both subnets (or at least the DB subnet)

Expected outcome: – app-vm can reach db-vm only on the allowed port. – Lateral movement is limited (other ports fail). – Flow logs provide evidence of allowed/blocked flows.

Step 1: Create a compartment (recommended)

Console path: Tenancy/Identity → Compartments (exact navigation can vary)

Create a compartment named: ztpr-lab
(Optional) Add tags like: – env=lab – owner=<your-name>

Expected outcome: You have an isolated place to create and clean up resources easily.

Step 2: Create a VCN and subnets

Console path: Networking → Virtual Cloud Networks → Create VCN

Create VCN: – Name: ztpr-lab-vcn – CIDR: 10.0.0.0/16
Create subnets (private): – app-subnet: 10.0.1.0/24 (Private subnet, no public IP assignment) – db-subnet: 10.0.2.0/24 (Private subnet, no public IP assignment)
Create or confirm route tables: – Each subnet should have its own route table (recommended for clarity), e.g.:
- app-rt
- db-rt

Expected outcome: VCN exists with two private subnets and associated route tables.

Verification: – Confirm both subnets show “Private”. – Confirm no internet gateway route is attached to these subnets.

Step 3: Create NSGs (micro-segmentation)

Console path: Networking → Network Security Groups → Create

Create two NSGs: – app-nsg – db-nsg

Now add security rules. The exact UI fields can vary, but conceptually:

3A) App NSG rules

Ingress rule (admin SSH) – Source: your public IP /32 (recommended)
If you don’t have a stable IP, consider OCI Bastion instead (recommended). – Protocol: TCP – Destination port: 22
Egress rule (to DB on app port) – Destination: db-nsg (NSG as destination, if console supports NSG-to-NSG referencing) – Protocol: TCP – Destination port: 15432 (example port for lab)
You can choose 1521 (Oracle DB) or 5432 (Postgres) if you actually run those—here we keep it simple with a custom port.

3B) DB NSG rules

Ingress rule (from App to DB port) – Source: app-nsg – Protocol: TCP – Destination port: 15432
Ingress rule (optional: SSH for break-glass) – Source: your public IP /32 (or better: Bastion subnet/NSG) – Protocol: TCP – Destination port: 22

Expected outcome: Only explicitly allowed flows are possible between tiers.

Verification: – Ensure there are no overly broad rules like 0.0.0.0/0 to all ports. – Ensure DB allows inbound only from App on the required port.

Step 4: Create two compute instances (App and DB)

Console path: Compute → Instances → Create instance

Create app-vm: – Name: app-vm – Subnet: app-subnet – Public IP: No (keep private) – NSG: attach app-nsg – Image: Oracle Linux (or another supported Linux) – Shape: small/low-cost – Add your SSH public key

Create db-vm: – Name: db-vm – Subnet: db-subnet – Public IP: No – NSG: attach db-nsg – Image: Oracle Linux – Shape: small/low-cost – Add your SSH public key

Expected outcome: Two private instances exist, one per subnet, each governed by its NSG.

Verification: – Confirm both instances have private IPs only. – Confirm the attached NSGs are correct.

Step 5: Provide admin access (choose one)

Option A (recommended): OCI Bastion

Use OCI Bastion to reach private instances without public IPs. – Verify Bastion setup steps in official docs because workflows and prerequisites vary. – Ensure NSGs allow SSH only from the bastion session source (preferred), not from the internet.

Option B (simpler lab approach): Temporary public IP on app-vm

If you can’t use Bastion quickly: 1. Assign a public IP temporarily to app-vm (or create a temporary jump box in a public subnet). 2. Restrict SSH ingress to your IP /32. 3. Remove the public IP after you finish.

Expected outcome: You can SSH to app-vm to run connectivity tests.

Step 6: Configure a simple “DB listener” service on db-vm

SSH to db-vm (via Bastion or via app-vm jump) and run a simple TCP listener on port 15432.

On db-vm:

sudo dnf -y install nc || sudo yum -y install nc
sudo firewall-cmd --add-port=15432/tcp --permanent 2>/dev/null || true
sudo firewall-cmd --reload 2>/dev/null || true

# Run a simple listener (foreground)
sudo nc -lvnp 15432

Leave it running.

Expected outcome: db-vm is listening on TCP/15432.

Verification on db-vm:

ss -lntp | grep 15432

Step 7: Test allowed and blocked traffic from app-vm

SSH to app-vm.

Test the allowed port to DB:

DB_IP="<db-vm-private-ip>"
nc -vz $DB_IP 15432

Expected: success (connected).

Test a blocked port (should fail):

nc -vz $DB_IP 15433

Expected: timeout or connection refused (depending on OS firewall vs NSG behavior). If NSG blocks, you typically see timeout.

Test SSH from app-vm to db-vm (should be blocked unless you explicitly allowed it):

nc -vz $DB_IP 22

Expected: blocked (unless you allowed 22 from app-nsg to db-nsg).

Expected outcome: Only the explicitly allowed DB port works.

Step 8: Enable VCN Flow Logs for visibility

Console path (typical): Networking → Virtual Cloud Networks → Subnets → (select subnet) → Flow Logs

Enable Flow Logs for: – app-subnet – db-subnet

Choose: – Log group: create ztpr-lab-log-group (or use an existing one) – Log retention: short for lab (for example, days not months)

Expected outcome: OCI starts collecting flow logs for these subnets.

Verification: – Generate traffic again (Step 7). – Go to Logging → Search logs and filter for your flow log source. – Confirm you can see flows corresponding to allowed and denied attempts.

Step 9 (Optional): Add an inspection layer with OCI Network Firewall

Do this only if: – OCI Network Firewall is available in your region, and – You understand the pricing and intend to delete it afterward.

High-level approach (verify exact steps in official docs): 1. Create an inspection subnet (e.g., 10.0.10.0/24) in the same VCN (or in a hub VCN). 2. Create OCI Network Firewall and attach it to the inspection subnet. 3. Create a firewall policy that: – Allows required traffic (e.g., app → db:15432) – Logs/blocks everything else 4. Update route tables so that targeted traffic flows through the firewall.

Expected outcome: Traffic must traverse the firewall to reach its destination, and firewall logs show allowed/blocked flows.

Caveat: OCI routing and firewall insertion patterns require precise configuration. Follow the official Network Firewall deployment patterns for your topology (single VCN vs hub/spoke). Verify in official docs: – Network Firewall documentation: https://docs.oracle.com/en-us/iaas/Content/network-firewall/home.htm (verify)

Validation

Use this checklist:

Segmentation works – From app-vm → db-vm:15432 succeeds. – From app-vm → db-vm:15433 fails. – From app-vm → db-vm:22 fails (unless explicitly allowed).
No public exposure – db-vm has no public IP. – app-vm has no public IP (or only temporary and restricted).
Evidence exists – Flow logs show the allowed flow for port 15432. – Flow logs show denies/timeouts for blocked attempts (depending on how denies are recorded).

Troubleshooting

Issue: `nc -vz $DB_IP 15432` fails from app-vm

Check: 1. NSG attachments – app-vm must have app-nsg – db-vm must have db-nsg 2. NSG rules – App egress to DB on 15432 – DB ingress from App on 15432 3. OS firewall on db-vm – Ensure local firewall allows inbound 15432 or disable for lab testing: bash sudo systemctl stop firewalld || true 4. Listener running – Confirm nc -lvnp 15432 is still running.

Issue: Flow logs show nothing

Check: – Flow Logs enabled on correct subnet(s) – You’re searching the correct log group/compartment/region – Wait a few minutes; log pipelines can have delay – Ensure IAM permissions allow viewing logs

Issue: You can reach DB on more ports than expected

Check: – DB subnet security list rules (if used) are not overly permissive – DB NSG doesn’t have broad ingress from VCN CIDR – You didn’t accidentally attach a permissive NSG

Cleanup

To avoid ongoing costs, delete in this order: 1. OCI Network Firewall resources (if created) 2. Compute instances (app-vm, db-vm) 3. Flow Logs configurations (if they keep generating billable logs) 4. NSGs (app-nsg, db-nsg) 5. Subnets (app-subnet, db-subnet, inspection subnet if any) 6. VCN (ztpr-lab-vcn) 7. Log group (if created solely for this lab) 8. Compartment (optional, after everything inside is removed)

11. Best Practices

Architecture best practices

Prefer private subnets for workloads; use controlled entry points (LB/Bastion).
Separate tiers into different subnets and NSGs:
web, app, data, shared services, admin
Use hub-and-spoke when many VCNs need consistent inspection and governance.
Avoid unnecessary hairpin routing; inspect what matters most (egress, sensitive east-west paths).

IAM/security best practices

Apply least privilege:
Separate roles for network admins vs app operators.
Restrict who can change route tables, gateways, and NSGs.
Require MFA and strong authentication for administrators.
Use compartments to isolate prod/non-prod and limit blast radius of misconfigurations.

Cost best practices

Turn on Flow Logs strategically (sensitive subnets, chokepoints) and tune retention.
Be careful with “inspect everything” if inspection pricing is per GB.
Tag resources (env, cost-center, owner, app) and enforce budgets/alerts.

Performance best practices

Keep latency-sensitive east-west traffic local where possible; inspect selectively.
Size inspection components to your throughput requirements.
Test throughput and failure behavior before production rollouts.

Reliability best practices

Avoid single points of failure in inspection paths.
Use redundancy patterns recommended by OCI for any centralized enforcement layer.
Treat route table and firewall policy changes as high-risk; implement staged rollouts.

Operations best practices

Enable Audit and monitor changes to:
Route tables
NSGs
Internet/NAT gateways
Firewall policies
Create runbooks:
“How to quarantine a subnet”
“How to roll back a route change”
“How to interpret flow logs”
Regularly validate segmentation with automated tests (e.g., scheduled connectivity checks).

Governance/tagging/naming best practices

Use consistent naming:
env-app-tier-region pattern
Use tags to enforce:
ownership
data classification
lifecycle (lab/dev/prod)
Standardize baseline NSGs and route patterns via IaC modules.

12. Security Considerations

Identity and access model

OCI IAM controls all API-level changes.
Critical controls:
Restrict “network admin” privileges.
Use compartments and policy boundaries.
Log and alert on network/security policy changes.

Encryption

Network segmentation doesn’t replace encryption.
Use TLS for service-to-service communications.
Use OCI Vault for secrets (where applicable) and rotate credentials.

Network exposure

Avoid public IPs on workloads.
Use Bastion or private connectivity.
Minimize internet gateways; prefer NAT for outbound only, and restrict egress destinations.

Secrets handling

Don’t embed keys in user-data scripts or images.
Use instance principals + Vault where supported and appropriate.

Audit/logging

Ensure OCI Audit is enabled and retained according to policy (verify tenancy defaults).
Centralize Flow Logs and firewall logs.
Restrict access to logs (they may expose sensitive topology and metadata).

Compliance considerations

Zero trust routing patterns support common requirements: – segmentation – least privilege – auditability – change management evidence

But compliance is program-specific—map controls to your framework and verify OCI services meet required certifications for your region/tenancy.

Common security mistakes

Overly broad NSG rules like “VCN CIDR to all ports”
Allowing SSH from 0.0.0.0/0
Forgetting egress controls (data exfiltration path remains open)
Missing logs or short retention that fails audit requirements
No alerting on route table changes

Secure deployment recommendations

Default deny between tiers; explicitly allow only needed ports.
Require bastion/jump patterns for admin access.
Implement change approvals for route/NSG/firewall updates.
Use Cloud Guard/Security Zones if available and aligned with your governance model (verify).

13. Limitations and Gotchas

Known limitations (pattern-level realities)

Destination-based routing can limit complex “policy-based routing” designs.
Central inspection can create bottlenecks if not sized/architected properly.
Over-segmentation can slow delivery if rules are not templatized and automated.

Quotas and limits

NSG rules and route rules have service limits.
Flow logs and logging resources can have limits.
Firewall instance counts and throughput limits may apply. Check OCI Service Limits for your region/tenancy.

Regional constraints

OCI Network Firewall may not be available everywhere.
Some governance/security services vary by region. Always verify availability in the OCI Console for your target region.

Pricing surprises

Flow logs can generate large data volumes.
Firewall inspection may charge per GB processed (verify).
Internet egress charges can be significant.

Compatibility issues

Some third-party NVAs require specific routing patterns and careful HA design.
If you use Kubernetes or service meshes, you must reconcile L3/L4 controls with service-to-service identity and mTLS policies.

Operational gotchas

A small route table change can cause widespread outage.
Emergency changes during incidents should be runbook-driven and auditable.
Logging without a retention plan becomes costly and noisy.

Migration challenges

Legacy apps often assume flat networks; segmentation may break hardcoded dependencies.
Discovery of required ports can take time; use flow logs to learn and iterate.

Vendor-specific nuances

OCI constructs (NSGs, security lists, route tables, DRG) differ from AWS/Azure/GCP equivalents. Don’t copy designs without translating semantics.

14. Comparison with Alternatives

Nearest services in Oracle Cloud

Since “Zero Trust Packet Routing” is best understood here as a pattern, the closest OCI services/patterns include: – Network Security Groups (NSGs) for micro-segmentation – OCI Network Firewall for managed inspection (verify capabilities) – Security Lists (subnet-level rules; generally less flexible than NSGs) – WAF for L7 web protection (different scope than packet routing) – Service Mesh (workload identity + mTLS at the application layer; different control plane than packet routing)

Nearest services in other clouds (conceptual equivalents)

AWS: Security Groups + Network ACLs + AWS Network Firewall (+ Gateway Load Balancer patterns)
Azure: NSGs + Azure Firewall + Virtual WAN routing
GCP: VPC firewall rules + hierarchical firewall policies + Cloud Armor (for web) + third-party inspection patterns

Open-source/self-managed alternatives

pfSense/OPNsense, iptables/nftables (host-based)
Suricata (IDS/IPS), Zeek (network analysis)
Cilium (Kubernetes network policy / eBPF)
Istio/Linkerd (service mesh for identity and L7 controls)

Comparison table

Option	Best For	Strengths	Weaknesses	When to Choose
Zero Trust Packet Routing pattern on OCI (NSGs + routes + logs + optional Network Firewall)	Teams needing segmentation + auditability in Oracle Cloud	Works with native OCI constructs; strong segmentation and governance; adaptable	Requires careful design; inspection adds cost/latency; not a single “one-click” service	When you want OCI-native, auditable network segmentation and controlled traffic paths
OCI NSGs + Flow Logs only (no centralized firewall)	Cost-sensitive teams or simpler environments	Low cost; simple; good baseline security	Limited deep inspection; relies on L3/L4 rules	When micro-segmentation is enough and deep inspection isn’t required
OCI Network Firewall (managed inspection)	Regulated workloads needing centralized inspection	Managed service; consistent enforcement and logs	Availability/pricing considerations; must design routing carefully	When you need centralized inspection and can justify cost/ops
WAF + LB (edge protection)	Web apps exposed to internet	Great for HTTP(S) protections; reduces app-layer attacks	Doesn’t solve east-west segmentation; not packet routing	When primary risk is web threats at ingress
Service mesh (e.g., OCI Service Mesh where applicable)	Microservices needing identity-based service-to-service controls	Strong workload identity and mTLS; fine-grained policy	Doesn’t replace network routing; learning curve	When you need application-layer zero trust between services
Third-party NVAs (self-managed firewall/IDS)	Specialized inspection requirements	Flexible feature sets; vendor-specific controls	Operational overhead; HA complexity; patching	When managed services don’t meet requirements or aren’t available

15. Real-World Example

Enterprise example: Regulated financial services segmentation and egress control

Problem: A bank runs customer-facing apps on OCI. Auditors require proof of segmentation, restricted egress, and change control over network paths.
Proposed architecture:
Hub-and-spoke VCNs across compartments (prod/non-prod separated).
Shared inspection layer in hub (OCI Network Firewall if available; otherwise approved NVA cluster).
Spokes for app domains; strict NSG micro-segmentation within each spoke.
Central logging: Flow Logs + firewall logs to OCI Logging; alerts on route/NSG changes.
Why this service/pattern was chosen:
OCI-native constructs provide clear boundaries and audit trails.
Central inspection meets policy requirements.
Micro-segmentation reduces lateral movement risk.
Expected outcomes:
Reduced blast radius for compromised workloads.
Documented, repeatable network policy and routing changes.
Faster audit responses due to centralized evidence.

Startup/small-team example: SaaS with tenant isolation

Problem: A small SaaS team hosts multiple tenants on OCI and wants to prevent accidental cross-tenant access while keeping costs low.
Proposed architecture:
Separate compartments per environment; per-tenant NSG segmentation.
Private subnets for app and data tiers; no public IPs on databases.
Flow logs enabled only on sensitive subnets and ingress/egress points.
Minimal inspection (NSGs + logging) to start; add firewall later if needed.
Why this service/pattern was chosen:
Low-cost baseline with clear segmentation.
Easy to templatize with Terraform as the product grows.
Expected outcomes:
Strong tenant isolation boundaries.
Lower risk of data exposure incidents.
Scalable approach that can add centralized inspection later.

16. FAQ

1) Is “Zero Trust Packet Routing” an official OCI service?

Not clearly, in publicly indexed OCI docs up to 2025-08. Treat it as an OCI architecture pattern unless your Oracle tenant/docs explicitly show it as a named service. Verify in official docs and your OCI Console.

2) What OCI services implement this pattern?

Commonly: VCN, subnets, route tables, NSGs, gateways, Flow Logs/Logging, and optionally OCI Network Firewall and Bastion.

3) Do I need OCI Network Firewall to do Zero Trust Packet Routing?

No. You can achieve strong segmentation with NSGs + explicit routing + logging. A managed firewall is useful when you need centralized inspection and policy enforcement beyond basic L3/L4.

4) What’s the difference between NSGs and security lists?

NSGs are typically workload/VNIC-oriented and more flexible for micro-segmentation. Security lists are subnet-oriented. Many teams prefer NSGs for tier-based controls.

5) How do I prove segmentation for audits?

Use: – NSG rules (documented policy) – Route tables (documented paths) – Flow logs and firewall logs (evidence of enforcement) – Audit logs (evidence of changes and approvals)

6) Will Flow Logs increase my bill?

Yes, potentially. Flow logs generate ingest and retention costs depending on your logging configuration. Enable strategically and tune retention.

7) Does routing everything through inspection hurt performance?

It can. Centralized inspection adds hops and potential throughput constraints. Inspect the flows that matter most (egress, sensitive boundaries) and avoid unnecessary hairpinning.

8) How do I restrict outbound internet access from private subnets?

Use NAT Gateway for outbound, restrict NSG egress, and optionally route egress through an inspection layer. Also avoid adding broad IGW routes to private subnets.

9) How do I handle patching and updates without opening broad egress?

Allow only required destinations/ports (for example, OS repositories) and consider using private mirrors or OCI services reachable through Service Gateway where applicable.

10) Can I do this across multiple VCNs?

Yes. Many production designs use hub-and-spoke with DRG. You centralize inspection and logging in the hub and keep workloads isolated in spokes.

11) How do I prevent developers from weakening network security?

Use compartments, least-privilege IAM, and approvals for changes to routes/NSGs/firewall policies. Add detection/alerting for drift.

12) Is Zero Trust only networking?

No. Networking is one layer. Zero Trust also includes identity, device posture, continuous verification, and application-layer controls like mTLS and service identity.

13) Should I use a service mesh instead of network controls?

They solve different problems. Service mesh helps with service identity and L7 policy between services, while packet routing and segmentation control network-level reachability.

14) What’s the safest “starter” design?

Private subnets, NSGs deny-by-default, Bastion for admin access, minimal egress via NAT, Flow Logs enabled on key subnets, and strict IAM change control.

15) How do I roll this out without outages?

Start by observing traffic with Flow Logs, model required flows, implement changes in stages, and keep rollback plans for route table and NSG changes.

16) What’s the biggest operational risk?

Misconfiguration of routing and security rules. Treat them like code: review, test, stage, and monitor changes.

17) How does this relate to OCI Security Zones and Cloud Guard?

They are governance/posture layers. They don’t route packets, but they can help prevent insecure configurations and detect risky changes (verify features enabled in your tenancy).

17. Top Online Resources to Learn Zero Trust Packet Routing

Because “Zero Trust Packet Routing” is not a clearly documented standalone service name, the best learning path is through OCI networking + OCI security services that implement the pattern.

Resource Type	Name	Why It Is Useful
Official documentation	OCI Documentation home: https://docs.oracle.com/en-us/iaas/Content/home.htm	Entry point for all OCI service docs
Official documentation	OCI Networking overview (VCN): https://docs.oracle.com/en-us/iaas/Content/Network/Concepts/overview.htm (verify)	Core concepts: VCNs, subnets, gateways, routing
Official documentation	Network Security Groups: https://docs.oracle.com/en-us/iaas/Content/Network/Concepts/networksecuritygroups.htm (verify)	Micro-segmentation and least-privilege security rules
Official documentation	VCN Flow Logs: https://docs.oracle.com/en-us/iaas/Content/Network/Concepts/vcnflowlogs.htm (verify)	Visibility into network flows for auditing and troubleshooting
Official documentation	OCI Logging: https://docs.oracle.com/en-us/iaas/Content/Logging/home.htm (verify)	Central log collection, retention, and search
Official documentation	OCI Audit: https://docs.oracle.com/en-us/iaas/Content/Audit/home.htm (verify)	Tracks changes to critical network/security resources
Official documentation	OCI Network Firewall: https://docs.oracle.com/en-us/iaas/Content/network-firewall/home.htm (verify)	Managed inspection option for centralized enforcement
Official documentation	OCI Bastion: https://docs.oracle.com/en-us/iaas/Content/Bastion/home.htm (verify)	Private administrative access without public IPs
Official pricing	Oracle Cloud Pricing: https://www.oracle.com/cloud/pricing/	Official pricing entry point
Official pricing tool	OCI Cost Estimator: https://www.oracle.com/cloud/costestimator.html (verify)	Estimate costs for firewall, compute, logging, egress
Official architecture center	OCI Architecture Center: https://docs.oracle.com/solutions/	Reference architectures and best practices
Official tutorials	Oracle Learn (tutorials): https://docs.oracle.com/en/learn/	Guided labs and OCI how-tos (search for networking/security)
Official samples	Oracle Learning Library (GitHub): https://github.com/oracle/learning-library	Many OCI labs and examples (verify relevance)

18. Training and Certification Providers

The following providers may offer training relevant to Oracle Cloud networking/security and Zero Trust concepts. Verify current course catalogs directly on their websites.

Institute	Suitable Audience	Likely Learning Focus	Mode	Website URL
DevOpsSchool.com	DevOps engineers, SREs, platform teams	DevOps + cloud operations + security fundamentals (verify OCI coverage)	check website	https://www.devopsschool.com/
ScmGalaxy.com	Beginners to intermediate engineers	SCM/DevOps tooling, CI/CD, automation fundamentals	check website	https://www.scmgalaxy.com/
CLoudOpsNow.in	Cloud operations and platform teams	CloudOps practices, monitoring, governance (verify OCI modules)	check website	https://www.cloudopsnow.in/
SreSchool.com	SREs, operations engineers	Reliability engineering, incident response, observability	check website	https://www.sreschool.com/
AiOpsSchool.com	Ops/SRE and automation teams	AIOps concepts, automation, operational analytics	check website	https://www.aiopsschool.com/

19. Top Trainers

These sites appear to be training resources/platforms. Verify instructor credentials, course outlines, and Oracle Cloud specificity directly on each site.

Platform/Site	Likely Specialization	Suitable Audience	Website URL
RajeshKumar.xyz	DevOps/cloud training resources (verify scope)	Beginners to intermediate	https://rajeshkumar.xyz/
devopstrainer.in	DevOps training (verify OCI content)	DevOps engineers, platform teams	https://www.devopstrainer.in/
devopsfreelancer.com	Freelance DevOps help/training (verify offerings)	Teams needing hands-on assistance	https://www.devopsfreelancer.com/
devopssupport.in	DevOps support and training resources (verify)	Ops/DevOps teams	https://www.devopssupport.in/

20. Top Consulting Companies

Neutral overview of organizations that may provide consulting related to cloud networking/security, DevOps, and implementation support. Verify service offerings, references, and OCI specialization on their websites.

Company	Likely Service Area	Where They May Help	Consulting Use Case Examples	Website URL
cotocus.com	Cloud/DevOps consulting (verify details)	Architecture, automation, migration support	Designing OCI landing zones; IaC rollout; logging/monitoring setup	https://cotocus.com/
DevOpsSchool.com	DevOps and cloud consulting/training (verify)	Platform engineering enablement, DevOps processes	Building CI/CD guardrails; operational runbooks; security best practices adoption	https://www.devopsschool.com/
DEVOPSCONSULTING.IN	DevOps consulting (verify scope)	Implementation support and operations improvement	Infrastructure automation; observability; environment standardization	https://www.devopsconsulting.in/

21. Career and Learning Roadmap

What to learn before this service/pattern

OCI fundamentals – Compartments, IAM basics, regions/availability domains
OCI Networking – VCNs, subnets, route tables, gateways (IGW/NAT/Service Gateway), DRG
Network security basics – CIDR, TCP/UDP, stateful vs stateless filtering, least privilege
Linux basics – SSH, firewall basics, basic troubleshooting (ss/netstat, curl, nc)

What to learn after

Centralized security operations – Logging pipelines, SIEM integration, alerting and incident response
Governance – Cloud Guard, Security Zones (verify), policy-as-code practices
Advanced architectures – Hub-and-spoke with DRG, multi-region DR, private connectivity
Application-layer zero trust – mTLS, service identity, service mesh, API gateways

Job roles that use it

Cloud Network Engineer (OCI)
Cloud Security Engineer
Platform Engineer
DevSecOps Engineer
SRE / Operations Engineer
Solutions Architect

Certification path (if available)

Oracle certifications change over time. Start by checking Oracle University’s OCI certification paths and select tracks related to: – OCI Architect Associate/Professional (if current) – OCI Security specialty certifications (if available) Verify current certifications: https://education.oracle.com/ (navigate to OCI)

Project ideas for practice

Build a three-tier app network (web/app/db) with strict NSGs and Flow Logs.
Implement a hub-and-spoke VCN architecture with centralized egress inspection.
Create automated tests that validate “only approved ports work” between tiers.
Implement alerting on NSG/route table changes and demonstrate rollback.
Build a “quarantine playbook” that isolates a compromised subnet in minutes.

22. Glossary

Zero Trust: Security model that assumes no implicit trust; access is continuously verified and least privilege is enforced.
Packet routing: Network forwarding decisions based on destination and routing tables.
VCN (Virtual Cloud Network): OCI virtual network that contains subnets, routing, and gateways.
Subnet: A range of IPs within a VCN where resources are placed.
Route table: Defines where traffic destined for certain CIDRs is sent.
NSG (Network Security Group): Virtual firewall rules applied to VNICs/instances for micro-segmentation.
Security list: Subnet-level security rules (less granular than NSGs in many designs).
East-west traffic: Traffic between workloads inside cloud networks (lateral movement).
North-south traffic: Traffic entering/leaving the cloud network (internet/on-prem).
Inspection layer: Firewall/NVA or service that inspects and enforces policy on traffic.
OCI Network Firewall: Managed firewall service in OCI (availability and features vary; verify).
VCN Flow Logs: Logs describing network flows for visibility and troubleshooting.
OCI Logging: Service to collect, store, and search logs.
OCI Audit: Records API calls and changes for governance and compliance.
Compartment: OCI tenancy construct to isolate and organize resources and IAM policies.
Bastion: Controlled access method to reach private instances without public IPs.
DRG (Dynamic Routing Gateway): OCI virtual router for connecting VCNs and on-prem networks.

23. Summary

Zero Trust Packet Routing in Oracle Cloud is best approached as an architecture pattern (unless your tenancy explicitly exposes it as a named service): you design networks so that every traffic path is explicit, least-privileged, and observable. In the Security, Identity, and Compliance context, it is implemented using OCI building blocks such as VCN routing, NSG micro-segmentation, centralized inspection (optionally OCI Network Firewall), and Flow Logs/Logging/Audit.

Key takeaways: – Security: Deny-by-default segmentation and controlled routing drastically reduce lateral movement risk. – Cost: Major cost drivers are inspection throughput, log volume/retention, and internet egress—not route rules themselves. – Operations: Treat NSGs and routing like code: review, test, monitor changes, and keep rollback plans. – When to use: Use this pattern for regulated, sensitive, or multi-tenant workloads, or any environment needing strong segmentation and auditability.

Next learning step: Deepen OCI networking fundamentals (VCN, NSGs, route tables, DRG) and then add centralized visibility (Flow Logs, Logging, Audit) and optional inspection (OCI Network Firewall) as your requirements demand.

rajeshkumar

Category