Oracle Database Vault (DV) is one of the most misunderstood security features in the Oracle Database stack.
A lot of DBAs hear the words “separation of duties” and immediately assume Database Vault is going to break operations, complicate patching, lock down SYS, and create endless tickets from application teams. In fairness, some of those concerns are understandable.
Many Oracle environments still rely heavily on SYSDBA access for day-to-day administration. Some organizations have automation frameworks, operational scripts, monitoring platforms, provisioning systems, and deployment pipelines that all assume SYS can do virtually everything.
Then Database Vault gets enabled and suddenly, automation that has been working fine for years stops working. DBA’s can’t work with the database like they always have; now they have to jump through hoops just to get a simple task done. Frustration builds and DBA teams become unhappy
What usually happens – and I have seen it happen many times – is that either Database Vault never gets deployed, or it gets deployed poorly and then quietly disabled later.
Of course, neither outcome is good but the reality is that Database Vault is one of the most powerful controls available for protecting sensitive data from privileged insider access — including compromised DBA credentials. The problem is not the technology, the problem is that it clashes with the current operational practices of the organization and introduces a significant amount of operational friction in the early stages of adoption.
The goal of this post is to walk the reader through a practical Database Vault deployment model that minimizes operational disruption while still delivering meaningful security value.
Why Database Vault Exists
Traditionally, Oracle privileged users effectively bypassed almost every security boundary in the database. If you had SYSDBA access, you could:
- Read any table
- Modify any schema
- Grant yourself privileges
- Disable auditing
- Change security-sensitive parameters
- Create backdoor users
- Disable controls intended to stop you
That model does not align well with modern compliance frameworks or modern threat models. Today, organizations have to assume:
- Privileged credentials can be stolen
- Insider threats are real
- Administrator accounts cannot always be trusted with unrestricted data access
- Regulatory frameworks increasingly require separation of duties
This is where Database Vault becomes extremely valuable. I regularly observe organizations attempt to roll out tokenization or field level encryption solutions because they believe this is the only way to prevent privileged users from getting access to the sensitive data in the database. You don’t have to tokenize the data to keep privileged accounts away from it, you can do that with Database Vault; it’s native to the database and more performant than tokenization and should be easier to deploy if done right.
Database Vault introduces policy-based controls around privileged access. Most importantly, it allows you to protect sensitive schemas and data from powerful accounts like SYS, giving you the ability to control who can do what, even when they already possess powerful system privileges.
So, What Happens Immediately After Enabling Database Vault?
This is where most deployment challenges begin. The moment Database Vault is enabled, Oracle immediately applies a set of default protections and restrictions. The biggest operational shock is that SYS loses account management capabilities as well as several others that might be considered essential for daily activities.
Immediate Effects on SYS
| What Changes for SYS | What Stays the Same |
|---|---|
| Cannot CREATE / ALTER / DROP USER | Can still ALTER SYSTEM for operational parameters |
| Cannot CREATE / ALTER / DROP PROFILE | Can still STARTUP / SHUTDOWN |
| Cannot ALTER SYSTEM for certain security-sensitive parameters | Can still run RMAN backup / restore |
| Can still manage tablespaces, redo logs, and infrastructure |
This behavior catches many DBAs off guard. The important detail is that Database Vault is not trying to prevent normal database administration. It is specifically targeting operations that could weaken security boundaries. Things like:
- Creating rogue users
- Granting elevated privileges
- Disabling auditing
- Modifying protected schemas
- Bypassing separation-of-duty controls
What Database Vault Enables By Default
When Database Vault is enabled, Oracle automatically installs several default realms, command rules, and policies. These are geared around protecting the database and strengthening those security boundaries by implementing separation of duties.
Key to our success later in this post, is knowing this separation of duties is enforced primarily through the following Database Vault roles: DV_OWNER, DV_ACCTMGR and DV_PATCH_ADMIN. The table below will help to understand what these three roles are used for:
| DV Role | Responsibility | Example Operations |
|---|---|---|
| DV_OWNER | Security Policy Management | Create/modify/delete realms, command rules, policies, authorize users in realms |
| DV_ACCTMGR | User account management | CREATE/ALTER/DROP USER, profiles, password resets, GRANT CREATE SESSION |
| DV_PATCH_ADMIN (Usually granted temporarily ) | Database Infrastructure | ALTER SYSTEM, RMAN, patching, startup/shutdown |
Database Vault also permanently revokes several powerful privileges from Oracle-supplied roles.
Some examples include:
| Role | Privileges Revoked |
|---|---|
| DBA | BECOME USER, CREATE ANY JOB, EXECUTE ANY PROGRAM, MANAGE SCHEDULER, queue management privileges |
| IMP_FULL_DATABASE | BECOME USER, queue management privileges |
| EXECUTE_CATALOG_ROLE | Several LogMiner and file transfer package privileges |
| SCHEDULER_ADMIN | CREATE ANY JOB, EXECUTE ANY PROGRAM, MANAGE SCHEDULER |
Notice that SELECT ANY TABLE is not revoked and Database Vault does not automatically protect application schemas. This means SYS can still query any application schema that is not explicitly protected by Database Vault controls. Protecting those application schemas is typically done by creating realms and customers must create these after Database Vault is enabled.
It should be pretty obvious by now why that adoption friction exists, especially in organizations where SYS is still used for almost everything, automation assumes unrestricted SYS access and teams do not yet have mature separation-of-duty processes.
Implementing perfect separation of duties on day one is unrealistic and it’s also not the primary reason people want to use Database Vault, so why get hung up on it. The better approach is phased adoption where we ease that friction while still being able to protect that application data.
The Low Friction Deployment Model
The practical reality is that you can grant Database Vault roles back to SYS, and this is still a supported Oracle configuration. Is it ideal, no. Does it help? Absolutely!
This is where the SYS operations matrix becomes extremely useful.
Testing against Oracle 19c showed the following:
| Operation | SYS Default | + DV_ACCTMGR | + DV_PATCH_ADMIN | + DV_OWNER | + All Roles |
|---|---|---|---|---|---|
| CREATE USER | Blocked | Allowed | Allowed | Blocked | Allowed |
| ALTER USER (lock/unlock/password | Blocked | Allowed | Allowed | Blocked | Allowed |
| DROP USER | Blocked | Allowed | Allowed | Blocked | Allowed |
| CREATE / ALTER / DROP PROFILE | Blocked | Allowed | Allowed | Blocked | Allowed |
| DDL on non-realm protected schemas | Allowed | Allowed | Allowed | Allowed | Allowed |
| DDL on realm-protected schemas | Blocked | Blocked | Blocked | Blocked | Blocked |
| Manage DV controls (DBMS_MACADM) | Blocked | Blocked | Blocked | Allowed | Allowed |
| ALTER SYSTEM (normal params) | Allowed | Allowed | Allowed | Blocked | Allowed |
| ALTER SYSTEM (DV-protected params) | Blocked | Blocked | Blocked | Blocked | Blocked |
| SELECT on non-DV-protected schemas | Allowed | Allowed | Allowed | Allowed | Allowed |
| SELECT on DV-protected objects | Blocked | Blocked | Blocked | Blocked | Blocked |
| STARTUP / SHUTDOWN | Allowed | Allowed | Allowed | Allowed | Allowed |
| RMAN backup / restore | Allowed | Allowed | Allowed | Allowed | Allowed |
Granting DV roles back to SYS restores a huge amount of operational compatibility. But some critical protections still remain.
Even after granting all major DV roles to SYS:
- SYS still cannot access realm-protected data
- SYS still cannot perform DDL on realm-protected schemas
- SYS still cannot directly bypass certain DV-protected ALTER SYSTEM controls in 19c
I should point out there are many different database deployment models and versions (12c, 19c, 26ai, multi-tenant, Autonomous DB, etc) and different ways to configure Database Vault. Always test and validate in your own environment.
The Obvious Concern With Granting DV Roles to SYS
If SYS has:
- DV_OWNER
- DV_ACCTMGR
- DV_PATCH_ADMIN
there is nothing really stopping someone from maliciously abusing SYS. The most dangerous of those roles being DV_OWNER. This is the role that would enable SYS to enable/disable a realm, or simply add a new user as a realm authorized participant and bypass the realm completely.
With all three roles, a privileged administrator could:
- disable a realm
- modify a realm to temporarily weaken protections. i.e. remove a protected object from a realm.
- create a new user for themselves and add that as an authorized participant
- switch policies into simulation mode
So the question now becomes: What can we do to reduce the risk we have introduced?
A Practical Risk Mitigation Strategy
If your organization chooses to grant DV roles back to SYS during an initial rollout phase, compensating controls are not an option, they are a requirement. Below are some suggestions
No direct SSH as oracle user
I’d like to think most organizations are already enforcing this, but if yours is not, start right away. When users are allowed to SSH as oracle, it makes the task of tracing that activity back to an actual person more challenging. Anonymity and security don’t mix.
Audit All SYS Activity
If your database is still using traditional auditing, then you will need to enable Auditing of SYS operations with something like ALTER SYSTEM SET AUDIT_SYS_OPERATIONS = TRUE SCOPE=SPFILE; but if you have switched to Unified Audit, then SYS operations are audited for you. There are also pre-defined Unified Audit Policies for Database Vault here and here that you should review and use.
Alert on Every Realm Modification
To achieve this, your audit records will need to be forwarded out to, or collected into a central repository where alerting can be configured. Any modification to:
- realms
- command rules
- policies
- rule sets
- DV authorization state
should generate immediate audit records and alerts. If SYS modifies a realm at 2 AM, security teams should know immediately.
Alert on Policy State Changes
Any time a policy transitions to a new state:
- When policies are switched to SIMULATION mode
- When policies are DISABLED
- When policies are CREATED or ENABLED
should be audited and monitored aggressively.
A Realistic Path Forward
We’ve already established that perfect separation of duties on day one is not achievable in many environments and trying to force it immediately often results in failed deployments. That being said, granting these Database Vault roles back to SYS after enablement is not the end of the project, it’s really just Phase 1. I’ve tried to expand a little more on what a phased approach may look like here. It may not be 100% complete but it should be enough to get started on:
Phase 1
- Enable Database Vault
- Grant DV roles to back to SYS
- Protect the most sensitive schemas with your own custom realms
- Implement auditing and alerting
Phase 2
- Begin separating operational responsibilities
- Review existing DBA processes and automation that relies on SYS
- Ideally SYS should only be used for patching the database or Startup/Shutdown operations
- Move account management away from SYS
- Deploy Oracle Instant Client on DB servers and begin to use this Instant Client to connect to the DB rather than bequeathed connections using the client in the ORACLE_HOME
- Start using named DB accounts with appropriate privileges
- Introduce named DV_OWNER accounts
- Reduce dependence on shared privileged access
- Adjust Auditing and alerting as necessary
Phase 3
- Revoke DV roles from SYS
- Fully enforce separation of duties
- Implement contextual command rules and factors
- Adjust Auditing and alerting as necessary
Summary
Database Vault is not just another Oracle security feature. It fundamentally changes the privileged access model inside the Oracle Database and that can naturally create a lot of trouble during the adoption phase.
The answer is not to avoid Database Vault, nor is the answer is to deploy it recklessly without understanding operational realities.
The best deployments acknowledge both sides:
- DBAs still need to operate the database
- Security teams still need meaningful controls around privileged access
A low-friction deployment model allows organizations to start protecting sensitive data immediately while gradually maturing toward full separation of duties. Protect the data first. That is where Database Vault delivers the most value.
If SYS can no longer read your HR, PCI, healthcare, or financial schemas without explicit authorization, you have already materially improved your security posture. Everything beyond that becomes a maturity journey. And that journey is far easier when the operational teams are not fighting the technology from day one