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-familyacross the whole tenancy → Solution: Scope policies to a compartment, an environment, and a named group - Security Lists/NSGs left open on the DB listener port → Solution: Restrict ingress to only the app subnet or bastion, nothing broader
- Shared "admin" credentials used by multiple team members → Solution: Individual named accounts, tied to IAM identity, always
- DBAs hold both console access and unrestricted DB privileges → Solution: Separate cloud-infrastructure access from in-database privilege
- Automation scripts run with a personal user's credentials → Solution: Use Dynamic Groups and Instance Principals scoped to the task
- Break-glass/emergency access exists but isn't documented or logged → Solution: Define, log, and time-box emergency access explicitly
- Compartments are structured by cost center, not by access boundary → Solution: Let compartments reflect who should — and shouldn't — see what
- No one reviews who still has access after a project ends → Solution: 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 pressure → Solution: Treat IAM policy as a living artifact, reviewed every quarter
- Compartment structure was inherited from a POC, never redesigned → Solution: Re-architect compartments around production access boundaries
- Network security groups get one broad rule instead of several narrow ones → Solution: Write NSG rules per service, not per convenience
- Database roles mirror OS roles instead of business function → Solution: Design DB roles around what a job actually needs to do
- Dynamic Groups are underused, so scripts fall back to personal logins → Solution: Build automation identity into the architecture from day one
- Zero Trust is treated as a firewall concept, not an identity concept → Solution: Verify every request — user, service, or script — every time
- Access reviews happen only when an auditor asks for one → Solution: Make access recertification a scheduled operational task
- IAM and Database Vault are managed by two different teams that don't talk → Solution: Bring cloud IAM and in-database privilege under one access narrative
- "Temporary" access grants outlive the reason they were created → Solution: 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, notmanage), 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
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'
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)