DEV Community

Series Week 27/52 — Zero Trust for Databases: Rethinking Access in OCI

Series Week 27/52 — Zero Trust for Databases: Rethinking Access in OCI

{ Abhilash Kumar Bhattaram : Follow on LinkedIn }

This article focuses on access control in OCI, and how I help you rethink who — and what — actually gets to touch your database.

Database Access Control

Access control does not change because your database moved to the cloud. What changes is who's watching, and how many new doors got added along the way.

Least privilege isn't a policy statement — it's the difference between an incident and a headline.

Last week's post drew the line between Encryption, Masking, Redaction, and Database Vault. This week, I want to zoom out one layer — to who is even allowed to reach the database in the first place, before any of those four controls come into play. In OCI, that question has more moving parts than most CTOs expect: IAM policies, compartments, network security groups, dynamic groups, and the database's own privilege model all sit in the same access chain.

1. Ground Zero: Where Challenges Start

Let's start with a plain canvas and understand our ground zero — most access problems in OCI start as convenience decisions that were never revisited.

Weekend-access-panic causes & corresponding solutions:

  • "It's in the cloud, so IAM handles security"Solution: IAM controls who reaches the console/API — the database still has its own privilege model
  • One IAM policy grants manage database-family across the whole tenancySolution: Scope policies to a compartment, an environment, and a named group
  • Security Lists/NSGs left open on the DB listener portSolution: Restrict ingress to only the app subnet or bastion, nothing broader
  • Shared "admin" credentials used by multiple team membersSolution: Individual named accounts, tied to IAM identity, always
  • DBAs hold both console access and unrestricted DB privilegesSolution: Separate cloud-infrastructure access from in-database privilege
  • Automation scripts run with a personal user's credentialsSolution: Use Dynamic Groups and Instance Principals scoped to the task
  • Break-glass/emergency access exists but isn't documented or loggedSolution: Define, log, and time-box emergency access explicitly
  • Compartments are structured by cost center, not by access boundarySolution: Let compartments reflect who should — and shouldn't — see what
  • No one reviews who still has access after a project endsSolution: Run periodic access recertification, not just onboarding

This is where most access-related incidents begin — not with an attack, but with a door nobody remembered was open.

As you can see, we haven't even touched Zero Trust architecture yet — there's a lot of basic hygiene to close first.

Cloud access is not one control — it's a chain. And a chain is only as strong as the link nobody's checked in months.

2. Underneath Ground Zero: Finding the Real Problem

Once you've understood your Ground Zero problems, you need to move to why access sprawls so quickly in OCI specifically — it's rarely negligence, it's usually speed.

Why "we locked it down" often doesn't hold up under review:

  • IAM policies were written once, at go-live, under deadline pressureSolution: Treat IAM policy as a living artifact, reviewed every quarter
  • Compartment structure was inherited from a POC, never redesignedSolution: Re-architect compartments around production access boundaries
  • Network security groups get one broad rule instead of several narrow onesSolution: Write NSG rules per service, not per convenience
  • Database roles mirror OS roles instead of business functionSolution: Design DB roles around what a job actually needs to do
  • Dynamic Groups are underused, so scripts fall back to personal loginsSolution: Build automation identity into the architecture from day one
  • Zero Trust is treated as a firewall concept, not an identity conceptSolution: Verify every request — user, service, or script — every time
  • Access reviews happen only when an auditor asks for oneSolution: Make access recertification a scheduled operational task
  • IAM and Database Vault are managed by two different teams that don't talkSolution: Bring cloud IAM and in-database privilege under one access narrative
  • "Temporary" access grants outlive the reason they were createdSolution: Expire access by default; renew deliberately, not by accident

This gap is why access reviews so often turn into surprises.

As you can see, this is less about any single misconfiguration and more about access decisions made in isolation, by different teams, at different times — with no single owner tracking the whole chain.

3. Working Upwards: From Understanding to Solution

Zero Trust for databases isn't a product — it's a discipline of never assuming trust just because a request came from inside the tenancy. Here's what that looks like in OCI, in plain language.

What least-privilege access actually looks like in OCI:

  • IAM Policies — Scoped to a specific compartment and group, granting only the verbs a role needs (e.g. use, not manage), never tenancy-wide.
  • Compartments — Structured as access boundaries first, cost boundaries second — Prod, Non-Prod, and DR isolated from each other by design.
  • Network Security Groups — Attached to the database's VNIC directly, allowing traffic only from named application NSGs, not open CIDR ranges.
  • Dynamic Groups & Instance Principals — Automation (including TAB) authenticates as itself, not as a person, with policy scoped to exactly its task.
  • OCI Vault (Secrets) — Database credentials stored and rotated centrally, never hardcoded in scripts or shared in chat.
  • Database Vault (in-DB) — Even a valid, authenticated session is restricted by realm and command rule inside the database itself.

Zero Trust means every layer — IAM, network, automation identity, and the database itself — verifies independently. None of them trust the others to have already checked.

A quick look under the hood (for the technical conversation with your cloud team — not something a CTO needs to write, just recognize):

An OCI IAM policy scoped to one compartment, one group, one verb — not tenancy-wide:

Allow group DBA-Prod-Readonly to use database-family in compartment Prod-DB
Enter fullscreen mode Exit fullscreen mode

A Dynamic Group so automation authenticates as itself, not as a person:

Allow dynamic-group TAB-Automation to manage db-nodes in compartment Prod-DB
  where request.principal.tag.role='patching-agent'
Enter fullscreen mode Exit fullscreen mode

That's the whole idea — the automation gets exactly one job's worth of access, and nothing about a human's session is involved.

The point for a CTO isn't the syntax — it's that every one of these grants can be scoped down to a compartment, a group, and a verb. The default OCI experience nudges toward broad grants because they're faster to write. Zero Trust is choosing the narrower grant every time, even when it's slower.

Technical Issues:

  • Broad IAM policies written for convenience, never narrowed post-go-live — Solution: Audit and re-scope every policy to compartment + verb level
  • NSGs allow traffic from entire subnets instead of specific services — Solution: Rewrite rules to source from named application NSGs only
  • Automation scripts authenticate with personal credentials — Solution: Migrate every script to Dynamic Groups and Instance Principals
  • Database roles don't map to least-privilege job functions — Solution: Redesign roles around task, not convenience or legacy habit

Non-Technical Issues:

  • Cloud team and DBA team manage access in separate silos — Solution: Create one access map spanning IAM, network, and in-database privilege
  • Access reviews are reactive, triggered only by audits — Solution: Schedule recertification as a standing operational cadence
  • "Temporary" access has no expiry or ownership — Solution: Default every grant to expire; require deliberate renewal
  • No one can produce a single answer to "who can reach this database" — Solution: Maintain one living access inventory, reviewed and owned

Zero Trust isn't about distrusting your team — it's about never letting distance from the data become distance from accountability.

How Nabhaas helps you

If you've made it this far, you already sense there's a better way — in fact, you have a way ahead.

If you'd like Nabhaas to assist in your journey, remember — TAB is just one piece. Our Managed Delivery Service ensures your Oracle operations run smoothly between patch cycles, maintaining predictability and control across your environments.

TAB - Whitepaper ,
download here

Managed Delivery Services - Whitepaper ,
download here

Top comments (0)