Oracle Database Vault: A Complete Hands-On Guide to Locking Down Privileged Access (CDB, PDB, Realms & Unified Audit)
Locking Down the Database from the Inside: My Hands-On Implementation of Oracle Database Vault
Munish Kumar Karna | Senior Database Solution Architect & Oracle DBA
Every DBA eventually confronts an uncomfortable truth: the biggest risk to a “secure” database is often the person with the keys to it. Firewalls, network segmentation, and encryption all assume the threat is outside the perimeter — but SYSDBA, SYSTEM, and other privileged accounts sit squarely inside it. Over the past few weeks I implemented Oracle Database Vault end-to-end — from installing the option to enforcing a working security Realm with full audit visibility — and I want to walk through exactly how it was done, screenshots and SQL included, for anyone evaluating this for their own environment.
Why Oracle Database Vault Matters
Oracle Database Vault addresses insider threats and privileged account abuse by restricting access inside the database itself. A few reasons it belongs in any serious data-security strategy:
- Privileged User Access Control: Prevents DBAs, SYS, SYSTEM, and compromised superusers from querying sensitive application data while preserving their ability to perform routine database maintenance, patching, and backups.
- Separation of Duties: Enforces security governance by splitting superuser authority into dedicated roles — restricting DBAs from managing security policies (DV_OWNER) or creating accounts (DV_ACCTMGR).
- Securing Multi-Tenant Environments: Establishes boundaries around PDBs and schemas in consolidated CDB/PDB databases, ensuring DBAs or local administrators cannot cross into unauthorized tenant realms.
- Dynamic Context Rules: Restricts execution of SQL commands using runtime factors such as IP address, time window, client application, or authentication method through Command Rules.
- Regulatory & Compliance Assurance: Fulfills mandatory data isolation and privileged user monitoring requirements across compliance frameworks like PCI-DSS, HIPAA, GDPR, and SOX.
- Zero Application Impact: Enforces security controls transparently at the database tier without requiring source code modifications to existing applications.
Implementation Walkthrough
Here is the full build, step by step, exactly as I ran it — first enabling the option at the CDB level, then at the PDB level, then proving it works with a real application schema, a Realm, and Unified Audit.
1. Install the Database Vault Packages
Verify the package installed correctly:
SELECT owner, object_name, object_type, status FROM dba_objects WHERE
object_name LIKE '%CONFIGURE_DV%';
2. Enable Database Vault at the CDB Level
CREATE USER c##dbv_owner IDENTIFIED BY "Pass0_Pass_123#" CONTAINER =
ALL;
GRANT CREATE SESSION, SET CONTAINER TO c##dbv_owner CONTAINER = ALL;
CREATE USER c##dbv_acctmgr IDENTIFIED BY "Pass0_Pass_123#" CONTAINER =
ALL;
GRANT CREATE SESSION, SET CONTAINER TO c##dbv_acctmgr CONTAINER = ALL;
-- 2. Configure DV at Root Level
BEGIN
DVSYS.CONFIGURE_DV (
dvowner_uname => 'C##DBV_OWNER',
dvacctmgr_uname => 'C##DBV_ACCTMGR'
);
END;
/
-- 3. Enable DV at Root Level
CONNECT c##dbv_owner/"Pass0_Pass_123#"
EXEC DBMS_MACADM.ENABLE_DV;
3. Enable Database Vault at the PDB Level
-- Create pdbDV Owner
CREATE USER demo_dbv_owner IDENTIFIED BY "Pass0_Pass_123#";
GRANT CREATE SESSION TO demo_dbv_owner;
-- Create Local DV Account Manager
CREATE USER demo_dbv_acctmgr IDENTIFIED BY "Pass0_Pass_456#";
GRANT CREATE SESSION TO demo_dbv_acctmgr;
Enabling DV at the PDB level:
And verifying the enablement:
4. Create a Sample FIN Schema to Protect
To make the Realm meaningful, I built out a small financial application schema — customers and accounts — that Database Vault would later shield from privileged access.
-- Create the user
CREATE USER fin IDENTIFIED BY fin
DEFAULT TABLESPACE users
TEMPORARY TABLESPACE temp;
-- Grant essential privileges
GRANT CREATE SESSION, CREATE TABLE TO fin;
ALTER USER fin QUOTA UNLIMITED ON users;
-- Table 1: Customers
CREATE TABLE customers (
customer_id NUMBER GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
first_name VARCHAR2(50) NOT NULL,
last_name VARCHAR2(50) NOT NULL,
email VARCHAR2(100) UNIQUE,
created_at DATE DEFAULT SYSDATE
) tablespace users;
-- Insert sample rows into Customers
INSERT INTO customers (first_name, last_name, email) VALUES ('Alice',
'Smith', 'alice.smith@example.com');
INSERT INTO customers (first_name, last_name, email) VALUES ('Bob',
'Jones', 'bob.jones@example.com');
INSERT INTO customers (first_name, last_name, email) VALUES
('Charlie', 'Brown', 'charlie.b@example.com');
-- Table 2: Accounts
CREATE TABLE accounts (
account_id NUMBER GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
customer_id NUMBER REFERENCES fin.customers(customer_id),
account_type VARCHAR2(20) CHECK (account_type IN ('Checking',
'Savings', 'Investment')),
balance NUMBER(15,2) DEFAULT 0.00,
status VARCHAR2(10) DEFAULT 'Active'
) tablespace users;
-- Insert sample rows into Accounts
INSERT INTO accounts (customer_id, account_type, balance) VALUES (1,
'Checking', 5420.50);
INSERT INTO accounts (customer_id, account_type, balance) VALUES (1,
'Savings', 125000.00);
INSERT INTO accounts (customer_id, account_type, balance) VALUES (2,
'Checking', 350.00);
INSERT INTO accounts (customer_id, account_type, balance) VALUES (3,
'Investment', 45000.75);
-- Commit the changes to save the data
COMMIT;
5. Step-by-Step Realm Creation & Verification
To test and put Database Vault to work in PDB26AI, I followed this sequence to create a local Realm that protects a target application schema from SYSDBA and privileged users.
Connect as Local Database Vault Owner
Log in directly to PDB26AI using the local Database Vault owner account created during configuration:
Create the Local Security Realm
Define a new Realm to protect the application objects:
Add Schema Objects to the Realm
6. Auditing Database Vault Realm Violations with Unified Audit
To record realm violations without triggering ORA-46401, I created and enabled a Unified Audit Policy specifically targeting Database Vault events.
Grant the required privilege:
Create the policy for Database Vault (as SYS):
CREATE AUDIT POLICY dv_realm_audit_pol
ACTIONS COMPONENT = DV Realm Violation ON
"Fincial_App_Protection_Realm";
Enable the DV policy:
AUDIT POLICY dv_realm_audit_pol;
Verify the audit policy is enabled:
SELECT policy_name, enabled_option FROM audit_unified_enabled_policies
WHERE policy_name IN ( 'DV_REALM_AUDIT_POL');
7. Verification — Proving the Realm Blocks Privileged Access
As SYS:
As SYSTEM:
Querying the unified audit trail confirms the violation is fully captured:
SELECT event_timestamp,
dbusername,
action_name,
return_code,
system_privilege_used,
sql_text
FROM unified_audit_trail
WHERE dv_action_name IS NOT NULL
OR return_code = 47401
ORDER BY event_timestamp DESC;
8. Confirming the Realm Configuration
Find the Realm that was created and confirm it is enabled:
select name,description, enabled FROM dba_dv_realm where
name='Fincial_App_Protection_Realm';
SELECT realm_name,
grantee,
auth_options,
auth_rule_set_name
FROM dba_dv_realm_auth where
realm_name='Fincial_App_Protection_Realm';
Other Useful Views for Ongoing Governance
A short reference of the dictionary views I lean on most once Database Vault is live:
View Rule Sets & Security Factors Attached to Realms:
- DBA_DV_RULE_SET: Lists available security rule sets, their evaluation logic (All_True or Any_True), and their active statuses.
- DBA_DV_RULE: Lists individual rules and the actual SQL/PL-SQL expressions used to evaluate them.
- DBA_DV_RULE_SET_RULE: Maps which individual rules belong to which master rule sets.
View Global Command & Privilege Protections:
- DBA_DV_COMMAND_RULE: Lists SQL statements (like GRANT, ALTER USER, DROP TABLE) that are intercepted globally by Database Vault, independent of specific realms.
- DBA_DV_PRIV_GRANT_CONTROL: Tracks restrictions placed on who can execute standard database grants or role assignments.
Closing Thoughts
What stands out after running this end-to-end is how little Database Vault asks of the applications sitting on top of it. The controls live entirely at the database tier: no code changes, no connection-string rewrites — just a Realm, a Command Rule, and an audit policy standing between a privileged credential and the data it was never meant to touch. For any organization handling regulated data under PCI-DSS, HIPAA, GDPR, or SOX, that combination of separation of duties and tamper-evident auditing is hard to replicate any other way.
I'll be writing up Command Rules and Factor-based access policies next. If you're running Database Vault in production — or considering it — I'd love to hear how you've approached Realm design and audit strategy. Drop a comment or connect.
Munish Kumar Karna — Senior Database Solution Architect / Oracle DBA (16+ years) | Oracle RAC, ASM, Data Guard, GoldenGate, OCI
Comments
Post a Comment