Demo Oracle Database Vault

Introduction

Access to information stored in database tables can roughly speaking be granted in two ways. First there is the object grant. The owner of an objects executes for example "GRANT SELECT ON HR.EMPLOYEES TO OE" to grant the user OE the select privilege on the table EMPLOYEES in the HR schema.

The second form of privilege is a so called system privilege. A good example is "GRANT SELECT ANY TABLE TO HR_DBA".  HR_DBA can now select all data from any table in the database.

Introducing the REALM

Oracle Database Vault has introduced the concept of REALMS. A realm can conceptually be seen as a vault within the database. Inside this realm the system privileges granted to users are not valid. For an applications DBA to be able to maintain the tables for a realm protected schema the realm can have so called realm authorizations. For users who have been given the realm authorization system privileges do provide access to the schema objects.

Any realm violation event will be recorded in the DVYS.AUDIT_TRAIL$ table.

The demo

I have recorded a demo to show the concept of a realm in Database Vault. This demo is accessible on youtube via this link.

The demo is divided in five sections:

• show user privileges
• query table with no realm enabled
• create realm
• query table with realm enabled 
• show audit information

Show user privileges

The following users are performing the same query on the HR.EMPLOYEES table.

SYS as SYSDBA: the SYS user is the most powerful user in the database as he has all privileges that give access to all content of any table.

FBORDEN: this user has SELECT ANY TABLE privilege. This is a generic DBA account who ideally would not have access to our applications tables, but without Database Vault there is no way to limit the "SELECT ANY TABLE" privilege of this user.

HR_DBA: this is a so called apps DBA. This user should have access to the HR schema objects even when Database Vault has been configured.

HR: the owner schema of the EMPLOYEES table used in the demo

HR_USER: this user has been granted the HR_ROLE providing SELECT privileges on the HR.EMPLOYEES table. This is typically the user used to connect the application to the database.

OE: this user has been granted SELECT ON HR.EMPLOYEES (object privilege) and will not be limited by the configuration of Database Vault. This user has a helpdesk role and I have configured Data Redaction such that OE will see the columns LAST_NAME, EMAIL and SALARY in a redacted form. 

Query table with no realm enabled

In the first part of the demo there is no realm defined in Database Vault. All users mentioned above will execute the same query

select user,first_name, last_name, email, salary from hr.employees where salary > 100000; 

As all users have either object or system privilege the data will be visible.

Create realm

The administration of Database Vault is shown from Oracle Enterprise Manager 12c. I am logged on as Database Vault administrator. Using the create realm wizard it is really straight forward to create the realm I need to protect the HR data.

The first step in creating the realm has some generic properties for the realm like name, description and under which condition to register an audit event. Also in this step for Database 12c there is a new option called "Mandatory Realm". Mandatory realms block system privilege-based access as well as object privilege-based access. This means that even the object owner cannot have access if he or she is not authorized to access the realm. Users can access secured objects in the mandatory realm only if the user or role is authorized to do so.

The second step in defining a realm is to determine which objects to protect with the realm. There can be multiple  entries in this step. In the demo I add all objects in the HR schema to the realm.

In the next step the realm authorization (optional) can be defined. As I want HR_DBA to be able to access the HR.EMPLOYEES table using the "SELECT ANY TABLE" privilege I have added HR_DBA to the realm authorization. Optionally there can be an authorization rule defined that will determine under which conditions the HR_DBA does have access to the realm. This way we could have added a rule that gives the access to the realm only during the maintenance window.

This  is it. The realm has been defined. Next step is tho show the result.

Query table with realm enabled 

The same query is used to show the result of enabling a realm for the HR schema.

The users that are able to select the information from the HR.EMPLOYEES table are shown first in the demo. These users are HR, HR_USER and HR_DBA. The latter has the realm authorization so database vault grants access. 

FBORDEN as generic DBA and SYS are shown next and they will be confronted with an ORA-1031: Insufficient Privileges error message. 

Show audit information

The final part of the demo shows the audit information. In the Oracle Enterprise Manager user interface we see the top 5 violations and the top 5 violators. Clicking on the top violation for the HR realm the details become visible.

In the report the information about the violation shows thing like the following:

• Database user trying to access the protected object
• OS user for the violation
• IP address from which the violation was attempted
• Program name
• Statement of the violation attempt 

Conclusion

This concludes the demo. It was an attempt to show how easy it is to protect sensitive information in your Oracle Database by configuring Oracle Database Vault.