I had a client once ask me, half joking, “so is Database Vault just a fancier GRANT statement?” No — and Rule Sets are exactly the piece that proves it. Roles and privileges answer one question: can this user do this thing. Rule Sets answer a completely different one: should this happen, right now, given everything else going on. That distinction is where a lot of the real security value in Database Vault actually lives.
This one’s going to focus purely on Rule Sets — how they’re built, how they interact with Realms and Command Rules, and a few configurations I’ve actually deployed.
What is a Rule Set, Really?
Strip away the terminology and a Rule Set is just a bundle of individual Rules. Each Rule is nothing more than a condition that comes back TRUE or FALSE, and Database Vault stitches them together with either AND or OR logic to reach a final verdict. That verdict decides whether the protected operation goes ahead or gets slammed shut.
Working Through the Logic
Say you’ve got three rules attached to one Rule Set — the first two come back TRUE, the third comes back FALSE.
Use AND, and you’re stuck: TRUE AND TRUE AND FALSE collapses to FALSE, so access gets denied even though two out of three conditions were satisfied. Switch to OR instead, and the same three rules produce TRUE, so access goes through.
It sounds almost too simple written out like that, but this is genuinely the mechanism behind most of the sophisticated policies I’ve built for clients over the years.
Where You Can Actually Attach a Rule Set
Once you’ve built one, it’s not locked to a single use. I’ve attached the same Rule Set to Realms, Command Rules, Factors, and Secure Application Roles — which means you write the logic once and reuse it everywhere it’s relevant, instead of rebuilding the same condition four different times.
Rule Sets Layered on Top of Realm Authorization
Here’s something people often miss — a Rule Set can sit on top of ordinary Realm authorization rather than replacing it. Database Vault isn’t just checking “is this user allowed in this Realm,” it’s also running whatever Rule Set you’ve attached. Something like: is the user in the Realm, is it business hours right now, is the connection coming from the corporate network. All three have to land on TRUE before access is granted.
The Rule Sets Oracle Hands You for Free
You don’t have to build everything from scratch — Database Vault ships with a set of predefined Rule Sets, and honestly, my advice is to leave them alone unless you have a genuinely good reason not to. Oracle recommends the same thing, for what it’s worth.
Allow System Parameters governs whether anyone can touch system initialization parameters.
Can Grant VPD Administration controls who’s allowed to grant or revoke EXECUTE on DBMS_RLS — the package behind Oracle’s Virtual Private Database feature.
Can Maintain Accounts/Profiles gates the usual account management commands — CREATE USER, ALTER USER, DROP USER, plus the profile equivalents. Nobody touches these unless they’re specifically authorized.
Enabled is about as blunt as it gets — the rule inside is literally 1 = 1, always TRUE, no conditions attached.
Disabled is its mirror image, always FALSE, which effectively kills access outright. I’ve reached for this exact Rule Set during an actual incident once, to slam a door shut fast without having to think through a custom condition under pressure.
Watching Can Maintain Accounts/Profiles in Action
This one surprises people the first time they see it live. With Database Vault enabled, even SYS can’t just create a user:
CREATE USER KRIS IDENTIFIED BY password;
comes back with:
ORA-01031: insufficient privileges
Even for SYS. The reason is the Can Maintain Accounts/Profiles Rule Set, which checks whether the session holds DV_ACCOUNT_MANAGER and whether user management is currently permitted. Neither condition is met by default, so the Rule Set evaluates FALSE and the command dies right there — no matter how powerful the account attempting it.
Grant the role —
GRANT DV_ACCOUNT_MANAGER TO SYS;
— and the exact same CREATE USER statement now succeeds, because SYS finally satisfies what the Rule Set is checking for.
Adding Your Own Conditions on Top
You’re not stuck with what Oracle ships. I’ve added a custom rule called ONLY_EVENING before, built on:
EXTRACT(HOUR FROM CURRENT_TIMESTAMP) > 20
Bolt that onto Can Maintain Accounts/Profiles and now there are three conditions instead of two — the role, the permission, and the clock. Try to run CREATE USER at 10am and it fails, full stop, even for SYS, even with DV_ACCOUNT_MANAGER granted. The rule doesn’t care who you are if the clock says the wrong thing.
Test Before You Trust
I never push a rule expression straight into production without validating it first. A quick way to sanity-check the logic:
SELECT 1
FROM dual
WHERE <rule_expression>;
Get a row back and the rule evaluates TRUE. No rows, and it’s FALSE. An error means there’s a syntax problem worth fixing before it locks somebody out unexpectedly at 2am.
Auditing — Don’t Skip This Part
By default, Database Vault logs a Rule Set the moment it evaluates FALSE — that’s your failed-authorization trail. Under traditional auditing that lands in the Database Vault audit trail automatically. Under Unified Auditing, though, you have to build and enable the audit policies yourself before those evaluations get captured anywhere useful. I’ve seen this catch teams off guard during an audit prep — they assumed logging was automatic and it wasn’t, because nobody had switched over the policy after a Unified Auditing migration.
Event Handlers, for When You Want a Reaction
Rule Sets can also kick off a custom procedure whenever they’re evaluated — either only on failure, or every single time. I’ve used this for firing off an email alert on a failed Rule Set, writing custom audit entries, or triggering a broader security notification. Just remember the handler needs to be an autonomous PL/SQL procedure, or you’ll run into transaction issues fast.
Rule Sets and Realms, Working Together
This combination is where things get genuinely useful. Take an HR schema locked inside a Realm, so only authorized HR admins can touch HR tables. Layer a Rule Set on top that only permits access on weekdays, and now Monday at 10am sails through while Sunday gets denied outright — same user, same authorization, different day.
Or take a reporting role, NIGHT_REPORTS, granted to whoever’s running the heavy analytical queries outside business hours. A Rule Set checks for that role before letting anyone touch the reporting tables during off-hours — keeping the daytime OLTP workload from getting crowded out by long-running reports at the wrong time.
Reports Worth Checking Periodically
Oracle bundles a few reports that I run through during quarterly reviews — the Rule Set Configuration Issues Report, the Secure Application Configuration Issues Report, and the Command Rule Configuration Issues Report. They flag disabled Rule Sets, Rule Sets with nothing actually attached to them, and other misconfigurations that tend to slip through unnoticed until someone finds them the hard way.
Views Worth Knowing
For querying this stuff directly: DBA_DV_RULE_SET holds the Rule Set definitions themselves, DBA_DV_RULE lists the individual Rules, and DBA_DV_RULE_SET_RULE maps which Rules belong to which Rule Set. Same data’s available through Enterprise Manager Cloud Control if you’d rather click through a UI than write SQL.
Managing Rule Sets Through DBMS_MACADM
Everything here is scriptable through the Database Vault API — creating, updating, renaming, and deleting Rule Sets, plus adding or removing individual Rules from them. Full programmatic control, which matters if you’re trying to keep security configuration under version control the way you would with anything else.
A Few Habits Worth Keeping
Stick with Oracle-defined Rule Sets where they cover what you need — don’t touch the predefined ones unless there’s a real reason. Test every rule expression before it goes anywhere near production. Pair Rule Sets with Realms whenever you want layered protection instead of a single point of failure. Turn on auditing so failed authorizations don’t disappear into the void. Check the configuration reports on a regular cadence, not just when something breaks. And keep coming back to least privilege as the baseline assumption, not the exception.
Where This Leaves You
Rule Sets are, in my experience, the piece of Database Vault that turns it from “another layer of privileges” into something that actually reasons about context — time, role, network origin, whatever conditions matter to your environment. Combine them with Realms, Command Rules, Factors, and Secure Application Roles, and you end up with a security model that adapts to the situation instead of just checking a static grant. For anyone under real compliance pressure, that adaptability is usually exactly what closes the gap between “we have security controls” and “we have security controls an auditor will actually sign off on.
Oracle Database Vault Rule Sets, Factors & Command Rules: Complete Security Guide
Comments 2