124 Part II: Oracle Database Vault
Creating Your First Realm
You can protect and audit access to sensitive financial data in a configuration with a few steps.
The protection offers compliance-focused safeguards against insider threats and elevates the
integrity posture of the data to avoid accidental or malicious destruction of the data. An example
shows how the protection is implemented by the security administrator and not the standard
database administrator, demonstrating how DBV satisfies separation of duty requirements.
The first step in naming a realm allows you to identify data boundaries, irrespective of
ownership or control, as in the case of the Order Management realm. Realms are also verifiable
from audit and compliance perspectives, because you can define the DBV auditing behavior
for any commands executed against objects protected by the realm when you define the realm.
Realm auditing can be configured for the realm so that audit records are generated if a command
is disallowed by the realm’s controls (called a realm violation).
Let’s look at a simple example creating a realm for the Sales History (SH) schema to remove
access to the Sales History data from an account such as SYSTEM and roles such as DBA. First, we
log into the database using the DBV owner account named DBVOWNER and create the realm:
dbvowner@aos> BEGIN
dbms_macadm.create_realm(
realm_name => 'Sales History'
, description =>
'Annual, quarterly, monthly, and weekly sales figures by product'
, enabled => dbms_macutl.g_yes
, audit_options => dbms_macutl.g_realm_audit_fail
);
END;
/
PL/SQL procedure successfully completed.
FIGURE 5-5 Sales History realm (all of one object owner)
Chapter 5: Database Vault Fundamentals 125
The DBVOWNER account was specified as the DBV owner during DBV installation and is
the initial account that can administer the DBV configuration. DBV realm configuration can be

performed using the DVA web application or the DVSYS.DBMS_MACADM administration
package discussed in Chapter 4. The PL/SQL package DVSYS.DBMS_MACUTL contains constants
and utility functions that are used by DBV. The constants are beneficial when using the DVSYS.
DBMS_MACADM package for administration because they avoid the need for you to remember
character or numeric values for DBV component configuration procedures. In this example, we
have simply created the realm and configured its default auditing behavior, which is to audit
when a realm authorization fails. We have not identified the actual objects in the SH schema
that will be protected by the realm, but this can be done with one command:
dbvowner@aos> BEGIN
dbms_macadm.add_object_to_realm (
realm_name => 'Sales History'
,object_owner => 'SH'
,object_name => '%'
,object_type => '%'
);
END;
/
PL/SQL procedure successfully completed.
Accessing Realm-Protected Objects
Once a schema or set of objects is protected by a realm, only the object owning account can issue
SELECT, Data Manipulation Language (DML), and EXECUTE statements on the objects. The object
owning account is not, however, allowed to execute Data Definition Language (DDL) statements
on the protected objects by default. Accounts and roles that have direct object privileges on a
realm-protected object can also access the objects protected in a realm for which they have object
privileges, shown in the GRANT SELECT ON sh.sales TO scott example.
For system ANY privilege usage, realms must have owners and participants established using
a realm authorization. One of the most beneficial aspects of realms is that you get security
enforcement immediately without needing to perform additional procedures. Another way to look
at this is that realms ensure that the ANY privileges are immediately controlled. A realm immediately
locks out users who were accessing the objects via the system ANY privileges—even sessions

operating with the SYSDBA privilege can no longer access the objects protected in a realm. The
DBV security administrator, such as DBVOWNER, must authorize an account or a role in a realm
before the account or role can use system ANY privileges against the objects protected in a realm.
At this point, we have defined the logical realm, its auditing characteristics, and the objects
that are to be protected in the SH object-owner account. We have not defined any explicit realm
authorizations for the Sales History realm. What this means is that any database administrator will
be prevented from accessing or manipulating objects in the realm. We can demonstrate this by
attempting to read the SH.SALES table again with the SYSTEM account:
system@aos> Attempt to query the sales data
system@aos>select cust_id, amount_sold from sh.sales;
select cust_id, amount_sold from sh.sales
*
ERROR at line 1:
ORA-01031: insufficient privileges
126 Part II: Oracle Database Vault
system@aos> Attempt to drop the sales data table
system@aos>drop table sh.sales;
drop table sh.sales
*
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-47401: realm violation for drop table on SH.SALES
ORA-06512: at "DVSYS.AUTHORIZE_EVENT", line 55
ORA-06512: at line 31
system@aos> Attempt to grant object privileges on the table to
system@aos> another account, which will fail due to realm protections
system@aos>grant select on sh.sales to scott;
grant select on sh.sales to scott
*
ERROR at line 1:

ORA-00604: error occurred at recursive SQL level 1
ORA-47401: realm violation for grant object privilege on SH.SALES
ORA-06512: at "DVSYS.AUTHORIZE_EVENT", line 55
ORA-06512: at line 31
system@aos> Attempt to query the sales data using direct object
system@aos> privileges granted to the account SCOTT.
system@aos> This is authorized in the default behavior of a realm
system@aos>connect scott
Enter password:
Connected.
scott@aos>select cust_id, amount_sold from sh.sales;
CUST_ID AMOUNT_SOLD

1258 23.75
1714 23.75
1842 23.75

Realm Audit Reporting
The DBV owner account DBVOWNER can use the DBA web application to run audit reports on
realm violations, as shown in Figure 5-6. The report demonstrates the failed attempts to query and
even drop the objects protected in the Sales History realm by the SYSTEM user.
This realm example demonstrates how simple it is to protect sensitive financial data using
just two configuration steps with the DBV administration capabilities. With respect to compliance
regulations, such as SOX, or an insider threat, you can see how easily we’ve addressed access
controls for privileged users to view financial data and audited attempts to access the data.
Furthermore, we’ve enforced this using a security administrator account (DBVOWNER) versus
a database administrator, satisfying our separation of duty requirements. Finally we’ve prevented a
database administrator from accidentally or maliciously destroying this financial data using a
privilege such as DROP ANY TABLE. This aspect of DBV protection avoids the need for additional
documentation during a compliance audit to describe the catastrophic event and elevates the

integrity posture of any system.
Chapter 5: Database Vault Fundamentals 127
Realm Components
This is a good jumping off point to delve into the details of the components of a realm and some
of the capabilities they provide. Earlier, we presented the creation of a logical realm name and
its default auditing characteristics. We will call this the “realm header,” and you should note that
the APIs used to maintain the realm header can also control the ability to enable and disable the
realm, which may be required in situations where database installation, upgrade, or maintenance
activities are required.
TIP
Use the disable and enable feature of a realm during installation,
upgrade, or maintenance activities.
Realm Objects
Realm configuration can be defined at the schema level, as demonstrated in the SH example, so
that all objects, no matter what type they are, will be protected. However, it is also possible to
configure the realm to protect specific objects by object type or by object name. Given our SH
example, it would be possible to protect only the tables in the SH schema as follows:
dbvowner@aos> BEGIN
dbms_macadm.add_object_to_realm (
realm_name => 'Sales History'
,object_owner => 'SH'
,object_name => '%'
,object_type => 'TABLE'
);
END;
/
PL/SQL procedure successfully completed.
FIGURE 5-6 DBV realm violation report
128 Part II: Oracle Database Vault
It is also possible to configure the realm to protect only the SALES table in the SH schema, as

follows:
dbvowner@aos> BEGIN
dbms_macadm.add_object_to_realm (
realm_name => 'Sales History'
,object_owner => 'SH'
,object_name => 'SALES'
,object_type => 'TABLE'
);
END;
/
The effect of this realm protection is immediate after the configuration step has been
executed, in the same way that revoking an object privilege takes effect immediately. Any schema
or a specific schema object can belong to multiple realms, so the OE.CUSTOMERS tables could
be protected by both the Order Management realm and the Sales History realm.
NOTE
An object can be protected by more than one realm to support
multiple application scenarios.
The intent here is that an object such as OE.CUSTOMERS may be required for SELECT access
by the database administrator of the Sales History realm, but we do not necessarily want to
authorize this database administrator in the Order Management realm, which would provide
the administrator access to more objects than requirements dictate.
Managing Role Provisioning with Database Vault Realms
In a special case, a database role is protected by a realm. To grant or revoke a role that is
protected by a DBV realm, the session user must be authorized as the realm owner of the realm
that is protecting the role. If you consider that a database administrator can grant or revoke any
role in the database to any other user or role in the database, the need to incorporate protection
of realms becomes clear.
Suppose the application developer had defined a database role named SALES_SELECT_ROLE
with SELECT privileges on the SH.SALES table and used this role as the only means to authorize
access to view this data. A database administrator account could circumvent the Sales History

realm controls if he were aware of the role and its privileges:
system@aos> Display the object privileges defined for the role
system@aos>SELECT grantee, privilege
FROM dba_tab_privs
WHERE owner = 'SH' AND table_name = 'SALES';
GRANTEE PRIVILEGE

BI SELECT
SALES_SELECT_ROLE SELECT
system@aos> Display the system (ANY) privileges the account has
system@aos> SELECT *
FROM session_privs
WHERE privilege LIKE '%ROLE%'
Chapter 5: Database Vault Fundamentals 129
ORDER BY 1;
PRIVILEGE

ALTER ANY ROLE
CREATE ROLE
DROP ANY ROLE
GRANT ANY ROLE
system@aos> Attempt to query sales data, the realm control prevents
system@aos>SELECT cust_id, amount_sold FROM sh.sales;
SELECT cust_id, amount_sold FROM sh.sales
*
ERROR at line 1:
ORA-01031: insufficient privileges
system@aos> Grant the role to view the sales data since
system@aos> as SYSTEM has the system privilege GRANT ANY ROLE
system@aos> through the DBA role

system@aos>GRANT sales_select_role TO system;
Grant succeeded.
system@aos> Set the role that allows us to view the sales data
system@aos>SET ROLE SALES_SELECT_ROLE;
Role set.
system@aos> Attempt to query the sales data using the
system@aos> direct object privileges provided by the role
system@aos>SELECT cust_id, amount_sold FROM sh.sales;
CUST_ID AMOUNT_SOLD

1258 23.75
1714 23.75
1842 23.75

With DBV, the security administrator can simply add the role as a realm object in the Sales
History realm as follows:
dbvowner@aos>BEGIN
dbms_macadm.add_object_to_realm (
realm_name => 'Sales History'
,object_owner => 'SH'
,object_name => 'SALES_SELECT_ROLE'
,object_type => 'ROLE'
);
END;
/
PL/SQL procedure successfully completed.
130 Part II: Oracle Database Vault
The next time a database administrator, such as SYSTEM, attempts to grant the role to himself
or revoke the role from a valid grantee, DBV will prevent the action and audit the event:
system@aos> Grant the role to view the sales data

system@aos>GRANT sales_select_role TO system;
system@aos>GRANT sales_select_role TO system
*
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-47401: realm violation for grant role privilege on SALES_SELECT_ROLE.
ORA-06512: at "DVSYS.AUTHORIZE_EVENT", line 55
ORA-06512: at line 31
system@aos> Attempt to revoke the role from an existing grantee
system@aos>REVOKE sales_select_role FROM sh;
REVOKE sales_select_role FROM sh *
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-47401: realm violation for revoke role privilege on SALES_SELECT_ROLE.
ORA-06512: at "DVSYS.AUTHORIZE_EVENT", line 55
ORA-06512: at line 31
Realm Authorizations
Realm authorizations define the accounts and roles that can use system ANY privileges on objects
protected by a realm. Realm authorizations can be declared as either a realm participant or a
realm owner. Both participants and owners can leverage system ANY privileges they have been
granted on objects protected by the realm. The difference between a realm participant and a
realm owner is that a realm owner can do the following but a participant cannot:
Grant or revoke object privileges on objects protected by the realm
Grant or revoke database roles that are protected in the realm
DBV realm authorizations can be configured by accounts with the DV_ADMIN or DV_
OWNER roles, like our example DBVOWNER account. Note that realm authorizations do
not grant system privileges or even object privileges when configured for a realm. Realm
authorizations allow the use of system ANY privileges on objects that are protected by the
realm. The underlying system ANY privileges still need to be granted to the account or role
being authorized in the realm. In other words, a realm participant needs to be granted the

SELECT ANY TABLE privilege explicitly to use a realm authorization, and a realm owner still
needs to be granted the GRANT ANY OBJECT PRIVILEGE to use a realm authorization.
NOTE
Realm authorizations do not implicitly or explicitly grant privileges.
They simply authorize the use of system ANY privileges.
The ability to grant system ANY privileges and system privileges is limited once DBV is
installed, using an out-of-the box realm called the Oracle Data Dictionary. The default owner of
■
■
Chapter 5: Database Vault Fundamentals 131
this realm is the SYS account and is the only account capable of granting these privileges because
DBV checks to see if the GRANT is performed by the owner of the Oracle Data Dictionary realm.
Realms and Direct Object Privileges
DBV will honor direct object privileges that are already granted (or are granted in the future) for
any object protected by the realm. For example, since the account SCOTT had been granted the
SELECT privilege on the SH.SALES table, the realm protections are not taken into consideration.
The design intent with DBV in this regard was to honor existing application security models,
where application developers had the foresight to grant specific object privileges as they were
required using a least privilege design. Object-level privileges are verifiable through database
dictionary views and extended through DBV privilege reports.
Realms and the DBV Administrators
For security reasons, the DBV roles DV_OWNER, DV_ADMIN, DV_SECANALYST, and DV_
ACCTMGR cannot be authorized in customer-defined realms. If this were allowed, the DBV
security administrator, such as our example DBVOWNER, would be able to authorize himself in
the Sales History realm, grant himself any realm-protected roles, and gain access to the sensitive
financial data. The following example helps illustrate this DBV control:
dbvowner@aos> DBV Security Administrator cannot authorize
dbvowner@aos> themselves in a realm
dbvowner@aos>BEGIN
dbms_macadm.add_auth_to_realm (

realm_name =>'Sales History'
, grantee => 'DBVOWNER'
, rule_set_name => NULL
, auth_options => dbms_macutl.g_realm_auth_owner );
END;
/
BEGIN
*
ERROR at line 1:
ORA-01031: insufficient privileges
ORA-06512: at "DVSYS.DBMS_MACUTL", line 10
ORA-06512: at "DVSYS.DBMS_MACUTL", line 367
ORA-06512: at "DVSYS.DBMS_MACADM", line 1728
ORA-06512: at line 2
Realm Authorizations and Object-owner Accounts
Object-owner accounts, such as SH, are not authorized in a realm by default when the objects
they own are protected by a realm. The object-owner accounts do have implicit direct object
privileges and DDL privileges for objects they own in the normal Oracle Database security
model. The DBV engine provides an implicit realm authorization for SELECT, DML, and
EXECUTE, based on the direct object privilege rule, to the object-owner account, but DDL
(ALTER, GRANT, AUDIT, and so on) statements are not implicitly authorized. This design allows
for existing application code to operate for most environments but maintains a security posture
around the structural integrity of the account’s objects. Object-owner accounts should have their
passwords expired and locked by default. You want to maintain an audit attribution account
model, using named administrators, as was discussed in Chapter 1. In this model, there is no
132 Part II: Oracle Database Vault
expectation that the account would be used directly to manage the objects it owns. The following
example shows this default behavior of application schemas being authorized for SELECT, but not
being automatically authorized in the realm for DDL:
sh@aos> Attempt to query the sales data as the object-owner SH

sh@aos>SELECT cust_id, amount_sold FROM sh.sales;
CUST_ID AMOUNT_SOLD

1258 23.75
1714 23.75
1842 23.75

sh@aos> Attempt to modify the SH.SALES table
sh@aos>ALTER TABLE sh.sales ADD extra_column VARCHAR2(100);
ALTER TABLE sh.sales ADD extra_column VARCHAR2 (100)
*
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-47401: realm violation for alter table on SH.SALES
ORA-06512: at "DVSYS.AUTHORIZE_EVENT", line 55
ORA-06512: at line 31
sh@aos> Attempt to grant the realm protected role
sh@aos>GRANT sales_select_role TO system;
GRANT sales_select_role TO system
*
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-47401: realm violation for grant role privilege on SALES_SELECT_ROLE.
ORA-06512: at "DVSYS.AUTHORIZE_EVENT", line 55
ORA-06512: at line 31
To authorize DDL commands for the object-owner account SH in the Sales History realm to
perform DDL, the following realm authorization must be configured:
dbvowner@aos>BEGIN
dbms_macadm.add_auth_to_realm (
realm_name =>'Sales History'

, grantee => 'SH'
, rule_set_name => NULL
, auth_options => dbms_macutl.g_realm_auth_owner );
END;
/
PL/SQL procedure successfully completed.
Named Accounts as Application DBAs for Realm Authorizations
To manage the objects in an object-owner account such as SH, it is recommended that you
use the application DBA pattern presented in Chapter 1. With this pattern, it would be more
appropriate to create a named database account—such as a senior database administrator named
MARY—to be the realm owner of the Sales History realm, and a realm participant—such as a
Chapter 5: Database Vault Fundamentals 133
junior database administrator named ANTHONY. This forces audit attribution to a named
individual (in other words, a real person) for any commands that are executed on objects
protected by the realm, regardless of the outcome of those commands.
The first step is to create the accounts. Recall from the DBV policy that is installed that the
DBV Account Administrator, DBVACCTMGR, has been granted the only role, DV_ACCTMGR,
authorized to use the CREATE USER privilege.
use the example DBV Account Administrator
to create the two new Application DBA accounts
dbvacctmgr@aos>CREATE USER mary IDENTIFIED BY <password>;
User created.
dbvacctmgr@aos>CREATE USER anthony IDENTIFIED BY <password>;
User created.
The SYS account is the only account authorized to manage system ANY privileges, such as
CREATE ANY TABLE, as well as powerful roles such as DBA that are protected by the default DBV
configuration. This SYS account is the realm owner of the Oracle Data Dictionary realm. The SYS
account can be used to grant the named accounts, MARY and ANTHONY, the underlying system
ANY privileges required to manage the objects protected by the Sales History realm. The DBA
role has been granted a number of system ANY privileges that help to demonstrate this approach

concisely.
dbvacctmgr@aos> grant these two new accounts the DBA role so they
dbvacctmgr@aos> have the underlying system ANY privileges that allow
dbvacctmgr@aos> them to manage objects protected in a realm
dbvacctmgr@aos> connect / as sysdba
Connected.
sys@aos>GRANT dba TO mary;
Grant succeeded.
sys@aos>GRANT dba TO anthony;
Grant succeeded.
Finally, we use the example DBV security administrator, DBVOWNER, to authorize the
accounts in the Sales History DBV realm as required:
sys@aos>CONNECT dbvowner
Enter password:
Connected.
dbvowner@aos> configure MARY as the realm owner
dbvowner@aos>BEGIN
dbms_macadm.add_auth_to_realm (
realm_name =>'Sales History'
, grantee => 'MARY'
, rule_set_name => NULL
, auth_options => dbms_macutl.g_realm_auth_owner );
END;
/
PL/SQL procedure successfully completed.
dbvowner@aos> configure ANTHONY as the realm participant
dbvowner@aos>BEGIN
dbms_macadm.add_auth_to_realm (