Even if I didn’t work for Oracle, I would still want you to deploy Oracle Database Vault (DV). That’s because I want your data and your database to be secure. In my previous post, I described the value of DV as well as a deployment approach aimed at reducing operational friction while maximizing your success. Sticking with that theme, I want to use this post to explain the two different Realm Types that DV supports and arm you with the information necessary to decide which type is best to use in your scenario. I should also take a moment to note that this post focuses on user defined realms, not Oracle defined realms.
So, what is a realm? An Oracle Database Vault realm is a security boundary around sensitive database objects, such as schemas, tables, or roles. When created and enabled, it restricts access through powerful system privileges (such as SELECT ANY TABLE) and allows organizations to control which users or roles are authorized to access protected objects, including privileged database administrators.
Amongst other configuration options available when you create the realm, is Realm Type, and choosing Mandatory when Regular would suffice can create unnecessary operational friction. A Regular Realm primarily controls the use of powerful system privileges. A Mandatory Realm controls system privileges and normal object-level privileges. Practically, here’s what that looks like:
| Access Path | Regular Realm | Mandatory Realm |
| SELECT ANY TABLE | Realm authorization required | Realm authorization required |
| UPDATE ANY TABLE | Realm authorization required | Realm authorization required |
| Object owner accessing own table | Allowed | Realm authorization required |
User with direct SELECT grant | Allowed | Realm authorization required |
User with direct UPDATE grant | Allowed | Realm authorization required |
| DDL against protected object | Realm authorization required | Realm authorization required |
When to choose the Regular Realm
Just because it’s called a Regular Realm, doesn’t mean it’s weak. Regular Realms enable you to put a security boundary in place for privileged user access without necessarily redesigning application access. As you can see from the table above, Regular Realms don’t interfere with existing direct object grants which people have been relying on for decades and are usually already well established in the database. The outcome here is directly inline with my previous post around low-friction adoption. If your goal is to prevent privileged access, i.e. those users who have access to powerful ANY privileges (SYS, SYSTEM, anyone granted DBA role or anyone granted SELECT ANY TABLE), then a Regular Realm is the right choice.
This would be the right place for most organizations to start their journey with Database Vault. If you do nothing else after this, you’ve already done a lot, especially if you also have that data encrypted at rest. But, don’t stop there.
When to choose the Mandatory Realm
How does a Mandatory Realm differ from a Regular Realm? With a Mandatory Realm in place, database privileges alone are no longer sufficient for use or access of that realm protected object. Data access now requires a user to have the Oracle privilege to perform the operation AND be authorized to the Mandatory Realm. Said another way, traditional privileges say the user can perform an operation, Mandatory Realm asks whether the user is also authorized to perform it against this protected data. Using this feature, you now have a control point inside the database, close to the data, which you can leverage to tightly restrict data access. When used in conjunction with well structured separation of duties, organizations can assume more control for data access within their databases and no longer rely on trusting that privileged accounts won’t be abused to circumvent restrictions. If that additional layer of control sitting on top of traditional database privileges and roles sounds like what you need, then a Mandatory Realm is the right choice.
How does a Mandatory Realm affect object ownership
If you have made the decision to use Mandatory Realms, then you must also know that, when in place and enabled, they affect the normal Oracle ownership model in the database. Ordinarily, an object owner has inherent access to the objects it owns and does not require explicit object privileges to access them. Oracle does not need to grant the owner SELECT, INSERT, UPDATE, DELETE, ALTER, etc. on their own object. Those capabilities derive from ownership. And so, under a Mandatory Realm, even ownership itself is no longer sufficient for data access. The owner must satisfy Database Vault realm authorization in addition to possessing the underlying ability to perform the operation.
Imagine an application where APP_OWNER owns the tables, but the application normally accesses those tables through a separate runtime account or application path. Pretty easy to imagine as this is how most environments are setup. Without a Mandatory Realm, someone who can log in as APP_OWNER can manipulate those tables simply because the account owns them. With a Mandatory Realm, you can authorize the intended runtime identity/path while leaving the schema owner unauthorized.
Making The Right Choice
Choosing between a Regular and Mandatory Realm doesn’t need to be complicated. Start with the security outcome you’re trying to achieve. If the goal is to prevent privileged users from leveraging powerful system privileges to access sensitive data, a Regular Realm may be all you need and will introduce far less operational friction. If your requirements go further and you need Database Vault authorization to act as an additional control on top of traditional privileges, roles, and even object ownership, then a Mandatory Realm gives you that capability. Neither realm type is inherently better than the other, they just solve slightly different problems. Understand the access you’re trying to control, choose the realm that provides that control, and don’t unintentionaly introduce additional complexity.
If you are interested in trying this out on your own test database which has Database Vault already enabled, refer to the sample code in this GitHub repository.