Realms get all the attention when people talk about Database Vault — I get it, they’re the easiest concept to explain in a five-minute meeting. But Realms are really only half the story. The other half, and honestly the part that took me longer to get comfortable with, is Factors, Rules, Rule Sets, and Command Rules. Once you understand how those pieces click together, you can build security policies that react to context instead of just checking a static grant.
That’s what this guide is about — how these components actually work together, with a few examples pulled from things I’ve configured over the years.
Factors: The Building Blocks of Context
A Factor is just a named attribute Database Vault can look at when it’s deciding whether to let something through. Nothing fancier than that. It might be the database username, the client IP, how the session authenticated, what time it is, which application connected, or which host the request came from.
Each factor carries a value — Oracle calls it the Identity — and that’s what gets evaluated at access time.
I usually explain it to clients this way: a privilege tells Oracle what you’re allowed to do. A factor tells Oracle something about the situation you’re doing it in. Database Vault needs both.
Why bother with any of this? Because privileges alone are blunt instruments. They don’t know or care whether you’re logging in from the office or from a hotel Wi-Fi at 3am. Factors let you build policies like “only from the corporate network,” or “only during business hours,” or “only from these specific application servers” — conditions that plain GRANT statements were never designed to express.
Stacking Factors for Multi-Factor Authorization
Once you have a handful of factors defined, you can combine them, and that’s where things get interesting. I’ve built policies that check username, client IP, and authentication method together before letting a sensitive operation through — not unlike how a bank won’t just take your card number, they want the PIN too, maybe a one-time code on top of that. Database Vault applies the same layered thinking to database access.
Command Rules: Controlling What SQL Can Even Run
A Command Rule sits at a different layer entirely — it doesn’t care about the object, it cares about the command itself. ALTER TABLE, DROP TABLE, ALTER SYSTEM, CREATE USER, even ordinary SELECT, DELETE, or UPDATE statements can all be gated this way.
Here’s the part that surprises people the first time they see it: a Command Rule can block a statement even when the user has every privilege they’d normally need. The privilege check passes, and Database Vault still says no, because the rule attached to that command evaluated to false.
Rules and Rule Sets, Stripped to Basics
A Rule is about as simple as database security gets — it’s one condition, and it comes back TRUE or FALSE. Is the user in a given role? Is it currently inside the maintenance window? Is the client IP on the trusted list? Each one of those, on its own, is a Rule.
A Rule Set is just a bundle of Rules, combined with AND or OR logic. If the combined result comes back TRUE, whatever SQL command it’s guarding is allowed to proceed. If not, it’s blocked — full stop, regardless of what privileges the user is sitting on.
How Oracle Actually Walks Through the Check
When someone fires off a SQL statement against a protected object, here’s the sequence Oracle runs through under the hood:
- Is the object inside a Realm at all?
- If so, is the session authorized within that Realm?
- Does the Realm have a Rule Set attached?
- Evaluate every Rule inside that Rule Set.
- Does the command itself have a Command Rule?
- Only if every single check comes back TRUE does the statement execute. Anything else, and it’s denied.
That layered sequence is really the whole value proposition of Database Vault in one paragraph — privileges are just the starting point, not the final word.
Command Rules Come in Three Flavors
System-level rules apply database-wide — restricting ALTER SYSTEM across the board is a typical example.
Schema-level rules narrow the scope to one schema. I’ve used this to block DROP TABLE across an entire HR schema without touching anything outside it.
Object-level rules go narrower still, down to a single table — say, allowing ALTER TABLE only on OE.ORDERS and nowhere else.
Stacking these levels is where the real control comes from. You’re not stuck picking one blanket policy for the whole database.
A Worked Example: Locking Down ALTER TABLE
Let me walk through a setup I’ve actually built before. User BOB gets a role called OE_ROLE, which carries ALTER privileges on OE.ORDERS. A Rule checks whether the session belongs to someone holding OE_ROLE, that Rule sits inside a Rule Set, and a Command Rule attaches that Rule Set to ALTER TABLE.
| User | Has OE_ROLE | ALTER TABLE Result |
|---|---|---|
| OE (table owner) | No | Denied |
| BOB | Yes | Allowed |
Notice what happens to OE here — the actual table owner gets denied, because ownership alone doesn’t satisfy the Rule Set. BOB, who doesn’t own a thing, gets through because he holds the role the rule is checking for. That inversion catches people off guard the first time they see it in a demo, and honestly it’s a good teaching moment for why Database Vault is a different animal from ordinary Oracle security.
Where I’ve Actually Used This in Production
Locking down roles themselves. Roles can sit inside a Realm too, not just tables. Do that, and only the Realm Owner can grant or revoke it — which shuts down a quiet privilege-escalation path a lot of teams never think to close.
Patching windows. During patching, admins sometimes need temporary access to application schemas they wouldn’t normally touch. Rather than opening everything up, I’ll drop the critical tables into a Mandatory Realm, allow access strictly to what the patch actually needs, and leave everything else sealed. Reduces the blast radius if something goes sideways mid-patch.
Keeping DBAs out of business data. Left alone, a DBA with the usual powerful roles can drop tables, alter objects, and read whatever business data they like. Wrap the relevant schemas in a Realm and that stops being true unless they’re explicitly authorized — which is really the whole pitch of Database Vault in a sentence.
Service-account-only access patterns. This one comes up constantly in real environments. Say you’ve got an HR schema, a SALES schema, and an APPS account that both feed into. Put HR and SALES behind a Mandatory Realm, authorize only the APPS account, and now direct logins to HR are dead, object privileges can’t be used to sneak around it, and the application account is the only path in. I’d guess this is the single most common Database Vault pattern I’ve deployed across different clients — it comes up almost every time.
Managing It All: DBMS_MACADM
Oracle gives you the DBMS_MACADM package to actually administer Database Vault. The procedures I reach for most:
| Procedure | Purpose |
|---|---|
| CREATE_REALM | Create a new Realm |
| UPDATE_REALM | Modify a Realm |
| ADD_OBJECT_TO_REALM | Protect an object |
| DELETE_OBJECT_FROM_REALM | Remove a protected object |
| ADD_AUTH_TO_REALM | Authorize a user |
| UPDATE_REALM_AUTH | Change an authorization |
| DELETE_AUTH_FROM_REALM | Remove an authorization |
| DELETE_REALM | Delete a Realm entirely |
Keeping Eyes on It
None of this is worth much if nobody’s watching it after the fact, so a few data dictionary views I check regularly:
DBA_DV_REALM tells you what Realms exist. DBA_DV_REALM_OBJECT shows what’s actually protected inside each one. DBA_DV_REALM_AUTH lists who’s authorized where. I’ll usually pull these during a quarterly access review just to make sure nothing’s drifted from what the documentation says it should be.
The Realms Oracle Sets Up for You
Worth knowing — Database Vault ships with a handful of predefined Realms the moment you configure it, and you didn’t have to lift a finger for these. The Database Vault Account Management Realm, the Oracle Enterprise Manager Realm, and the Oracle System Privilege and Role Management Realm all show up automatically, covering critical accounts, monitoring users, and administrative roles right out of the box.
A Few Things I’d Tell Anyone Starting Out
Lean on Factors for anything that needs to be context-aware rather than just identity-aware. Combine Rules into Rule Sets instead of trying to cram logic into one giant condition. Put Command Rules on the SQL operations that actually scare you, not everything indiscriminately — over-restricting tends to backfire and gets Database Vault turned off entirely by a frustrated ops team. Reserve Mandatory Realms for the schemas that genuinely warrant it. Keep Realm authorization tight and reviewed, not something that quietly accumulates over years. And check the audit trail regularly — a security control nobody monitors isn’t really a security control.
Wrapping Up
Realms get you most of the way to separation of duties, but Factors, Rules, Rule Sets, and Command Rules are what turn Database Vault from a static wall into something that actually reasons about context — who’s asking, from where, under what conditions, doing what. Once those pieces are working together, you’ve moved well past “does this user have the grant” and into something closer to real, adaptive database security. For anyone handling sensitive data under regulatory pressure, that difference tends to matter a lot more in an audit than it does on paper.
Oracle Database Vault Rule Sets Explained: Dynamic Security and Access Control
Comments 2