Oracle® Database Vault Administrator's Guide 11g Release 2 (11.2) Part Number E23090-05 |
|
|
PDF · Mobi · ePub |
The Oracle Database Vault objects include two schemas with database tables, sequences, views, triggers, roles, packages, procedures, functions, and contexts that support the administration and run-time processing of Oracle Database Vault.
Oracle Database Vault has the following schemas:
DVSYS Schema: Owns the Oracle Database Vault schema and related objects
DVF Schema: Owns the Oracle Database Vault functions that are created to retrieve factor identities
The DVSYS
schema contains Oracle Database Vault database objects, which store Oracle Database Vault configuration information and support the administration and run-time processing of Oracle Database Vault. In a default installation, the DVSYS
schema is locked. The DVSYS
schema also owns the AUDIT_TRAIL$
table.
Oracle Database Vault secures the DVSYS
schema by using a protected schema design. A protected schema design guards the schema against improper use of system privileges (for example, SELECT ANY TABLE
, CREATE ANY VIEW
, or DROP ANY
).
Oracle Database Vault protects and secures the DVSYS
schema in the following ways:
The DVSYS
protected schema and its administrative roles cannot be dropped. By default, the DVSYS
account is locked.
Statements such as CREATE USER
, ALTER USER
, DROP USER
, CREATE PROFILE
, ALTER PROFILE
, and DROP PROFILE
can only be issued by a user with the DV_ACCTMGR
role. SYSDBA
can issue these statements only if it is allowed to do so by modifying the Can Maintain Accounts/Profiles rule set.
The powerful ANY
system privileges for database definition language (DDL) and data manipulation language (DML) commands are blocked in the protected schema. This means that the objects in the DVSYS
schema must be created by the schema account itself. Also, access to the schema objects must be authorized through object privilege grants.
Object privileges in the DVSYS
schema can only be granted to administrative roles in the schema. This means that users can access the protected schema only through predefined administrative roles.
Only the protected schema account DVSYS
can issue ALTER ROLE
statements on predefined administrative roles of the schema. "Oracle Database Vault Roles" describes Oracle Database Vault administrative roles in detail.
Only the protected schema account DVSYS
can grant predefined roles to users along with the ADMIN OPTION
. This means that a grantee with the ADMIN OPTION
can grant the role to another user without the ADMIN OPTION
.
The SYS.DBMS_SYS_SQL.PARSE_AS_USER
procedure cannot be used to run SQL statements on behalf of the protected schema DVSYS
.
Note:
Database users can grant additional object privileges and roles to the Oracle Database Vault Administrative roles (DV_ADMIN
and DV_OWNER
, for example) provided they have sufficient privileges to do so.The DVF
schema is the owner of the Oracle Database Vault DBMS_MACSEC_FUNCTION
PL/SQL package, which contains the functions that retrieve factor identities. After you install Oracle Database Vault, the installation process locks the DVF
account to better secure it. When you create a new factor, Oracle Database Vault creates a new retrieval function for the factor and saves it in this schema.
This section describes the default roles Oracle Database Vault provides. It includes the following topics:
DV_GOLDENGATE_REDO_ACCESS Oracle GoldenGate Redo Log Access Role
DV_REALM_RESOURCE Database Vault Application Resource Owner Role
Oracle Database Vault provides a set of roles that are required for managing Oracle Database Vault.
Figure 11-1 illustrates how these roles are designed to implement the first level of separation of duties within the database. How you use these roles depends on the requirements that your company has in place.
See Also:
Oracle Database Security Guide for general guidelines on managing rolesFigure 11-1 How Oracle Database Vault Roles Are Categorized
Note:
You can grant additional object privileges and roles to the Oracle Database Vault roles to extend their scope of privileges. For example,SYSDBA
can grant object privileges to an Oracle Database Vault role as long as the object is not in the DVSYS
schema or realm.Table 11-1 summarizes the privileges available with Oracle Database Vault roles. (The DV_PATCH_ADMIN
, DV_STREAMS_ADMIN
, DV_XSTREAM
, DV_GOLDENGATE_ADMIN
, and DV_GOLDENGATE_REDO_ACCESS
roles are not included because they have no system privileges.)
Table 11-1 Privileges of Oracle Database Vault Roles
Privilege | DV_OWNER | DV_ADMIN | DV_MONITOR | DV_SECANALYST | DV_ACCTMGR | DV_REALM_OWNER | DV_REALM_RESOURCE | DV_PUBLIC |
---|---|---|---|---|---|---|---|---|
|
YesFoot 1 |
YesFoot 2 |
No |
No |
No |
No |
No |
No |
|
Yes |
Yes |
No |
No |
No |
No |
No |
No |
|
Yes |
Yes |
Yes |
Yes, on some Database Vault viewsFoot 3 |
No |
No |
No |
NoFoot 4 |
|
No |
No |
No |
No |
No |
No |
No |
No |
|
Yes |
No |
No |
No |
No |
No |
No |
No |
|
No |
No |
No |
Yes |
No |
No |
No |
No |
Monitor Database Vault |
Yes |
Yes |
Yes |
Yes |
No |
No |
No |
No |
Run Database Vault reports |
Yes |
Yes |
No |
Yes |
No |
No |
No |
No |
|
Yes |
No |
Yes |
Yes, on the same system views as |
No |
No |
No |
No |
|
No |
No |
No |
Yes, portions of |
No |
No |
No |
No |
|
No |
No |
No |
No |
Yes |
No |
No |
No |
Manage objects in schemas that define a realmFoot 6 |
No |
No |
No |
No |
No |
YesFoot 7 |
No |
No |
|
No |
No |
No |
No |
No |
No |
Yes |
No |
Footnote 1 Includes the EXECUTE
privilege on all Oracle Database Vault PL/SQL packages.
Footnote 2 Includes the EXECUTE
privilege on all Oracle Database Vault PL/SQL packages.
Footnote 3 DV_SECANALYST
can query DVSYS
schema objects through Oracle Database Vault-supplied views only.
Footnote 4 DV_PUBLIC
can query DVSYS
schema objects through Oracle Database Vault-supplied views only.
Footnote 5 This privilege does not include the ability to drop or alter the DVSYS
account, nor change the DVSYS
password.
Footnote 6 This privilege includes ANY
privileges, such as CREATE ANY
, ALTER ANY
, and DROP ANY
.
Footnote 7 The user with this role also must be the realm participant or owner to exercise his or her system privileges
Footnote 8 The RESOURCE
role provides the following system privileges: CREATE CLUSTER
, CREATE INDEXTYPE
, CREATE OPERATOR
, CREATE PROCEDURE
, CREATE SEQUENCE
, CREATE TABLE
, CREATE TRIGGER
, CREATE TYPE
.
Use the DV_OWNER
role to manage the Oracle Database Vault roles and its configuration. In this guide, the example account that uses this role is lbrown_dvowner
.
Privileges Associated with the DV_OWNER Role
The DV_OWNER
role has the administrative capabilities that the DV_ADMIN
role provides, and the reporting capabilities the DV_SECANALYST
role provides. It also provides privileges for monitoring Oracle Database Vault. It is created when you install Oracle Database Vault, and has the most privileges on the DVSYS
schema. In addition to DV_ADMIN
role, the DV_OWNER
role has the GRANT ANY ROLE
, ADMINISTER DATABASE TRIGGER
, and ALTER ANY TRIGGER
privileges.
Tip:
Consider creating a separate, named account for theDV_OWNER
user. This way, if the user is no longer available (for example, he or she left the company), then you can easily recreate this user account and then grant this user the DV_OWNER
role.To find the full list of system and object privileges associated with the DV_OWNER
role, log in to SQL*Plus with administrative privileges and then enter the following queries:
SELECT TABLE_NAME, OWNER, PRIVILEGE FROM DBA_TAB_PRIVS WHERE GRANTEE = 'DV_OWNER'; SELECT PRIVILEGE FROM DBA_SYS_PRIVS WHERE GRANTEE = 'DV_OWNER';
When you install and register Oracle Database Vault, the DV_OWNER
account is created. The user who is granted this role is also granted the ADMIN
option and can run any Oracle Database Vault roles (except DV_ACCTMGR
) without the ADMIN OPTION
to any account. Users granted this role also can run Oracle Database Vault reports and monitor Oracle Database Vault.
How Are GRANT and REVOKE Operations Affected by the DV_OWNER Role?
Anyone with the DV_OWNER
role can grant the DV_OWNER
and DV_ADMIN
roles to another user. The account granted this role can revoke any granted protected schema role from another account. Accounts such as SYS
or SYSTEM
, with the GRANT ANY ROLE
system privilege alone (directly granted or indirectly granted using a role) do not have the right to grant or revoke the DV_OWNER
role to or from any other database account. Note also that a user with the DV_OWNER
role cannot grant or revoke the DV_ACCTMGR
role.
Managing Password Changes for Users Who Have the DV_OWNER Role
Before you can change the password for another user who has been granted the DV_OWNER
role, you must revoke the DV_OWNER
role from that user account. However, be cautious about revoking the DV_OWNER
role. At least one user on your site must have this role granted. If another DV_OWNER
user has been granted this role and needs to have his or her password changed, then you can temporarily revoke DV_OWNER
from that user. Note also that if you have been granted the DV_OWNER
role, then you can change your own password without having to revoke the role from yourself.
To change the DV_OWNER
user password:
Log in to SQL*Plus using an account that has been granted the DV_OWNER
role.
Revoke the DV_OWNER
role from the user account whose password needs to change.
Connect as a user who has been granted the DV_ACCTMGR
role and then change the password for this user.
Connect as the DV_OWNER
user and then grant the DV_OWNER
role back to the user whose password you changed.
Alternatively, you can temporarily disable Oracle Database Vault, log on as a user who has been granted the ALTER USER
privilege, and then modify the DV_OWNER
user password. Afterward, re-enable Database Vault. See Appendix B, "Disabling and Enabling Oracle Database Vault," for more information.
What Happens When Oracle Database Vault Security Is Disabled?
The granting and revoking of all protected schema roles, including DV_OWNER
, is enforced only if Oracle Database Vault is enabled. If Oracle Database Vault is disabled, then any account with the GRANT ANY ROLE
system privilege can perform GRANT
and REVOKE
operations on protected schema roles.
Appendix B, "Disabling and Enabling Oracle Database Vault," explains how disable and enable Oracle Database Vault.
The DV_ADMIN
role controls the Oracle Database Vault PL/SQL packages.
Privileges Associated with the DV_ADMIN Role
The DV_ADMIN
role has the EXECUTE
privilege on the DVSYS
packages (DBMS_MACADM
, DBMS_MACSECROLES
, and DBMS_MACUTL
). DV_ADMIN
also has the capabilities provided by the DV_SECANALYST
role, which allow the user to run Oracle Database Vault reports and monitor Oracle Database Vault. During installation, the DV_ADMIN
role is granted to the DV_OWNER
role with the ADMIN OPTION
during installation.
To find the full list of system and object privileges associated with the DV_ADMIN
role, log in to SQL*Plus with administrative privileges and then enter the following queries:
SELECT TABLE_NAME, OWNER, PRIVILEGE FROM DBA_TAB_PRIVS WHERE GRANTEE = 'DV_ADMIN'; SELECT PRIVILEGE FROM DBA_SYS_PRIVS WHERE GRANTEE = 'DV_ADMIN';
How Are GRANT and REVOKE Operations Affected by the DV_ADMIN Role?
Accounts such as SYS
or SYSTEM
, with the GRANT ANY ROLE
system privilege alone do not have the rights to grant or revoke DV_ADMIN
from any other database account. The user with the DV_OWNER
or DV_ADMIN
role can grant or revoke this role to and from any database account.
Managing Password Changes for Users Who Have the DV_ADMIN Role
Before you can change the password for a user who has been granted the DV_ADMIN
role, you must revoke the DV_ADMIN
role from this account. If you have been granted the DV_ADMIN
role, then you can change your own password without having to revoke the role from yourself.
To change the DV_ADMIN
user password:
Log in to SQL*Plus using an account that has been granted the DV_OWNER
role.
Revoke the DV_ADMIN
role from the user account whose password needs to change.
Connect as a user who has been granted the DV_ACCTMGR
role and then change the password for this user.
Connect as the DV_OWNER
user and then grant the DV_ADMIN
role back to the user whose password you changed.
Alternatively, you can temporarily disable Oracle Database Vault, log on as a user who has been granted the ALTER USER
privilege, and then modify the DV_ADMIN
user password. Afterward, re-enable Database Vault. See Appendix B, "Disabling and Enabling Oracle Database Vault," for more information.
What Happens When Oracle Database Vault Security Is Disabled?
The granting and revoking of all protected schema roles, including DV_OWNER
, is enforced only if Oracle Database Vault is enabled. If Oracle Database Vault is disabled, then any account with the GRANT ANY ROLE
system privilege can perform GRANT
and REVOKE
operations on protected schema roles.
Appendix B, "Disabling and Enabling Oracle Database Vault," explains how disable and enable Oracle Database Vault.
The DV_MONITOR
role enables the Oracle Enterprise Manager Grid Control agent to monitor Oracle Database Vault for attempted violations and configuration issues with realm or command rule definitions. This enables Grid Control to read and propagate realm definitions and command rule definitions between databases.
Privileges Associated with the DV_MONITOR Role
There are no system privileges associated with the DV_MONITOR
role, but it does have some the SELECT
privilege on some SYS
and DVSYS
objects. To find the full list of DV_MONITOR
object privileges, log in to SQL*Plus with administrative privileges and then enter the following query:
SELECT TABLE_NAME, OWNER, PRIVILEGE FROM DBA_TAB_PRIVS WHERE GRANTEE = 'DV_MONITOR';
How Are GRANT and REVOKE Operations Affected by the DV_MONITOR Role?
By default, this role is granted to the DV_OWNER
role, the DV_ADMIN
role, the DV_SECANALYST
role, and the DBSNMP
user. Only a user who has been granted the DV_OWNER
privilege can grant or revoke the DV_MONITOR
role to another user. You cannot grant this role with the ADMIN
option.
What Happens When Oracle Database Vault Security Is Disabled?
The granting and revoking of all protected schema roles, including DV_OWNER
, is enforced only if Oracle Database Vault is enabled. If Oracle Database Vault is disabled, then any account with the GRANT ANY ROLE
system privilege can perform GRANT
and REVOKE
operations on protected schema roles.
Appendix B, "Disabling and Enabling Oracle Database Vault," explains how disable and enable Oracle Database Vault.
Use the DV_SECANALYST
role to run Oracle Database Vault reports and monitor Oracle Database Vault. This role is also used for database-related reports. In addition, this role enables you to check the DVSYS
configuration by querying the DVSYS
views described in "Oracle Database Vault Data Dictionary Views".
Privileges Associated with the DV_SECANALYST Role
There are no system privileges associated with the DV_SECANALYST
role, but it does have the SELECT
privilege for the DVSYS
object schema and portions of the SYS
and SYSMAN
schema objects for reporting on DVSYS
- and DVF
-related entities. To find the full list of DV_SECANALYST
object privileges, log in to SQL*Plus with administrative privileges and then enter the following query:
SELECT TABLE_NAME, OWNER, PRIVILEGE FROM DBA_TAB_PRIVS WHERE GRANTEE = 'DV_SECANALYST';
How Are GRANT and REVOKE Operations Affected by the DV_SECANALYST Role?
Any account, such as SYS
or SYSTEM
, with the GRANT ANY ROLE
system privilege alone does not have the rights to grant this role to or revoke this role from any other database account. Only the user with the DV_OWNER
role can grant or revoke this role to and from another user.
Managing Password Changes for Users Who Have the DV_SECANALYST Role
Before you can change the password for a user who has been granted the DV_SECANALYST
role, you must revoke the DV_SECANALYST
role from this account. If you have been granted the DV_SECANALYST
role, then you can change your own password without having to revoke the role from yourself.
To change the DV_SECANALYST
user password:
Log in to SQL*Plus using an account that has been granted the DV_OWNER
role.
Revoke the DV_SECANALYST
role from the user account whose password needs to change.
Connect as a user who has been granted the DV_ACCTMGR
role and then change the password for this user.
Connect as the DV_OWNER
user and then grant the DV_SECANALYST
role back to the user whose password you changed.
Alternatively, you can temporarily disable Oracle Database Vault, log on as a user who has been granted the ALTER USER
privilege, and then modify the DV_SECANALYST
user password. Afterward, re-enable Database Vault. See Appendix B, "Disabling and Enabling Oracle Database Vault," for more information.
What Happens When Oracle Database Vault Security Is Disabled?
The granting and revoking of all protected schema roles, including DV_OWNER
, is enforced only if Oracle Database Vault is enabled. If Oracle Database Vault is disabled, then any account with the GRANT ANY ROLE
system privilege can perform GRANT
and REVOKE
operations on protected schema roles.
Appendix B, "Disabling and Enabling Oracle Database Vault," explains how disable and enable Oracle Database Vault.
Grant the DV_STREAMS_ADMIN
role to any user who is responsible for configuring Oracle Streams in an Oracle Database Vault environment. This enables the management of Oracle Streams processes to be tightly controlled by Database Vault, but does not change or restrict the way an administrator would normally configure Oracle Streams.
Privileges Associated with the DV_STREAMS_ADMIN Role
There are no system privileges associated with the DV_STREAMS_ADMIN
role, but it does have the SELECT
privilege on DVSYS
objects. To find the full list of DV_STREAMS_ADMIN
object privileges, log in to SQL*Plus with administrative privileges and then enter the following query:
SELECT TABLE_NAME, OWNER, PRIVILEGE FROM DBA_TAB_PRIVS WHERE GRANTEE = 'DV_STREAMS_ADMIN';
Be aware that the DV_STREAMS_ADMIN
role does not provide a sufficient set of database privileges for configuring Oracle Streams. Rather, the DV_STREAMS_ADMIN
role is an additional requirement (that is, in addition to the privileges that Oracle Streams currently requires) for database administrators to configure Oracle Streams in an Oracle Database Vault environment.
How Are GRANT and REVOKE Operations Affected by the DV_STREAMS_ADMIN Role?
You cannot grant the DV_STREAMS_ADMIN
role with ADMIN OPTION
. Only users who have been granted the DV_OWNER
role can grant or revoke the DV_STREAMS_ADMIN
role to or from other users.
What Happens When Oracle Database Vault Security Is Disabled?
The granting and revoking of all protected schema roles, including DV_OWNER
, is enforced only if Oracle Database Vault is enabled. If Oracle Database Vault is disabled, then any account with the GRANT ANY ROLE
system privilege can perform GRANT
and REVOKE
operations on protected schema roles.
Grant the DV_XSTREAM_ADMIN
role to any user who is responsible for configuring XStream in an Oracle Database Vault environment. This enables the management of XStream processes to be tightly controlled by Database Vault, but does not change or restrict the way an administrator would normally configure XStream.
Privileges Associated with the DV_XSTREAM_ADMIN Role
There are no privileges associated with the DV_XSTREAM_ADMIN
role.
Be aware that the DV_XSTREAM_ADMIN
role does not provide a sufficient set of database privileges for configuring XStream. Rather, the DV_XSTREAM_ADMIN
role is an additional requirement (that is, in addition to the privileges that XStream currently requires) for database administrators to configure XStream in an Oracle Database Vault environment.
How Are GRANT and REVOKE Operations Affected by the DV_XSTREAM_ADMIN Role?
You cannot grant the DV_XSTREAM_ADMIN
role with ADMIN OPTION
. Only users who have been granted the DV_OWNER
role can grant or revoke the DV_XSTREAM_ADMIN
role to or from other users.
What Happens When Oracle Database Vault Security Is Disabled?
The granting and revoking of all protected schema roles, including DV_OWNER
, is enforced only if Oracle Database Vault is enabled. If Oracle Database Vault is disabled, then any account with the GRANT ANY ROLE
system privilege can perform GRANT
and REVOKE
operations on protected schema roles.
Grant the DV_GOLDENGATE_ADMIN
role to any user who is responsible for configuring Oracle GoldenGate in an Oracle Database Vault environment. This enables the management of Oracle GoldenGate processes to be tightly controlled by Database Vault, but does not change or restrict the way an administrator would normally configure Oracle GoldenGate.
Privileges Associated with the DV_GOLDENGATE_ADMIN Role
There are no privileges associated with the DV_GOLDENGATE_ADMIN
role.
Be aware that the DV_GOLDENGATE_ADMIN
role does not provide a sufficient set of database privileges for configuring Oracle GoldenGate. Rather, the DV_GOLDENGATE_ADMIN
role is an additional requirement (that is, in addition to the privileges that Oracle GoldenGate currently requires) for database administrators to configure XStream in an Oracle Database Vault environment.
How Are GRANT and REVOKE Operations Affected by the DV_GOLDENGATE_ADMIN Role?
You cannot grant the DV_GOLDENGATE_ADMIN
role with ADMIN OPTION
. Only users who have been granted the DV_OWNER
role can grant or revoke the DV_GOLDENGATE_ADMIN
role to or from other users.
What Happens When Oracle Database Vault Security Is Disabled?
The granting and revoking of all protected schema roles, including DV_OWNER
, is enforced only if Oracle Database Vault is enabled. If Oracle Database Vault is disabled, then any account with the GRANT ANY ROLE
system privilege can perform GRANT
and REVOKE
operations on protected schema roles.
Grant the DV_GOLDENGATE_REDO_ACCESS
role to any user who is responsible for using the Oracle GoldenGate TRANLOGOPTIONS DBLOGREADER
method to access redo logs in an Oracle Database Vault environment. This enables the management of Oracle GoldenGate processes to be tightly controlled by Database Vault, but does not change or restrict the way an administrator would normally configure Oracle GoldenGate.
Privileges Associated with the DV_GOLDENGATE_REDO_ACCESS Role
There are no privileges associated with the DV_GOLDENGATE_REDO_ACCESS
role.
Be aware that the DV_GOLDENGATE_REDO_ACCESS
role does not provide a sufficient set of database privileges for configuring Oracle GoldenGate. Rather, the DV_GOLDENGATE_REDO_ACCESS
role is an additional requirement (that is, in addition to the privileges that Oracle GoldenGate currently requires) for database administrators to configure Oracle Streams in an Oracle Database Vault environment.
How Are GRANT and REVOKE Operations Affected by the DV_GOLDENGATE_REDO_ACCESS Role?
You cannot grant the DV_GOLDENGATE_REDO_ACCESS
role with ADMIN OPTION
. Only users who have been granted the DV_OWNER
role can grant or revoke the DV_GOLDENGATE_REDO_ACCESS
role to or from other users.
What Happens When Oracle Database Vault Security Is Disabled?
The granting and revoking of all protected schema roles, including DV_OWNER
, is enforced only if Oracle Database Vault is enabled. If Oracle Database Vault is disabled, then any account with the GRANT ANY ROLE
system privilege can perform GRANT
and REVOKE
operations on protected schema roles.
Temporarily grant the DV_PATCH_ADMIN
role to any database administrator who is responsible for performing database patching or adding languages to Database Vault. After the patch operation or language addition is complete, you should immediately revoke this role.
Privileges Associated with the DV_PATCH_ADMIN Role
This role does not provide access to any secured data.
How Are GRANT and REVOKE Operations Affected by the DV_OWNER Role?
Only a user who has the DV_OWNER
role can grant or revoke the DV_PATCH_ADMIN
role to and from another user. You cannot grant the DV_PATCH_ADMIN
role with the ADMIN
option.
What Happens When Oracle Database Vault Security Is Disabled?
The granting and revoking of all protected schema roles, including DV_OWNER
, is enforced only if Oracle Database Vault is enabled. If Oracle Database Vault is disabled, then any account with the GRANT ANY ROLE
system privilege can perform GRANT
and REVOKE
operations on protected schema roles.
Appendix B, "Disabling and Enabling Oracle Database Vault," explains how disable and enable Oracle Database Vault.
Use the DV_ACCTMGR
role to create and maintain database accounts and database profiles. In this manual, the example DV_ACCTMGR
role is assigned to a user named amalcolm_dvacctmgr
.
Privileges Associated with the DV_ACCTMGR Role
A user who has been granted this role can use the CREATE
, ALTER
, and DROP
statements for users or profiles. However, a person who has been granted the DV_ACCTMGR
role cannot perform the following operations:
ALTER
or DROP
statements on the DVSYS
account
ALTER
or DROP
statements on users who have been granted the DV_ADMIN
, DV_OWNER
, DV_SECANALYST
, and DV_MONITOR
roles
Change passwords for users who have been granted the DV_ADMIN
, DV_OWNER
, DV_SECANALYST
, and DV_MONITOR
roles
To find the full list of system and object privileges associated with the DV_ACCTMGR
role, log in to SQL*Plus with administrative privileges and then enter the following queries:
SELECT TABLE_NAME, OWNER, PRIVILEGE FROM DBA_TAB_PRIVS WHERE GRANTEE = 'DV_ACCTMGR'; SELECT PRIVILEGE FROM DBA_SYS_PRIVS WHERE GRANTEE = 'DV_ACCTMGR';
Tips:
Oracle recommends that you add the user who has the DV_ACCTMGR
role to the data dictionary realm. See "Step 1: Adding the SYSTEM User to the Data Dictionary Realm" for an example.
If you want the DV_ACCTMGR
user to be able to grant other users ANY
privileges, then log in as user SYS
with the SYSDBA
privilege and grant this user the GRANT ANY PRIVILEGE
privilege.
Consider creating a separate, named account for the DV_ACCTMGR
user. This way, if this user forgets his or her password, you can log in as the original DV_ACCTMGR
account when you recreate the user's password. Otherwise, you must disable Oracle Database Vault, log in as SYS
or SYSTEM
to recreate the password, and then re-enable Database Vault.
How Are GRANT and REVOKE Operations Affected by the DV_ACCTMGR Role?
Any account, such as SYS
or SYSTEM
, with the GRANT ANY ROLE
system privilege alone does not have the rights to grant this role to or revoke this role from any other database account. The account with the DV_ACCTMGR
role and the ADMIN OPTION
can grant this role without the ADMIN OPTION
to any given database account and revoke this role from another account.
What Happens When Oracle Database Vault Security Is Disabled?
The granting and revoking of all protected schema roles, including DV_OWNER
, is enforced only if Oracle Database Vault is enabled. If Oracle Database Vault is disabled, then any account with the GRANT ANY ROLE
system privilege can perform GRANT
and REVOKE
operations on protected schema roles.
Appendix B, "Disabling and Enabling Oracle Database Vault," explains how disable and enable Oracle Database Vault.
Use the DV_REALM_OWNER
role to manage database objects in multiple schemas that define a realm. Grant this role to the database account owner who is responsible for managing one or more schema database accounts within a realm and the roles associated with the realm.
Privileges Associated with the DV_REALM_OWNER Role
A user who has been granted this role can use powerful system privileges like CREATE ANY
, ALTER ANY
, and DROP ANY
within the realm. However, before this user can exercise these privileges, you must make this user either a participant or an owner for the realm. See "Defining Realm Authorization" for instructions.
There are no object privileges granted to the DV_REALM_OWNER
role, but it does have some system privileges. To find the full list of DV_REALM_OWNER
system privileges, log in to SQL*Plus with administrative privileges and enter the following query:
SELECT PRIVILEGE FROM DBA_SYS_PRIVS WHERE GRANTEE = 'DV_REALM_OWNER';
How Are GRANT and REVOKE Operations Affected by the DV_REALM_OWNER Role?
The realm owner of the Oracle Data Dictionary realm, such as SYS
, can grant this role to any given database account or role. Note that though this role has system privilege grants that SYS
controls, it does not have the DV_OWNER
or DV_ADMIN
roles.
If you want to attach this role to a specific realm, then you must assign it to an account or business-related role, then authorize that account or role in the realm.
What Happens When Oracle Database Vault Security Is Disabled?
The granting and revoking of all protected schema roles, including DV_OWNER
, is enforced only if Oracle Database Vault is enabled. If Oracle Database Vault is disabled, then any account with the GRANT ANY ROLE
system privilege can perform GRANT
and REVOKE
operations on protected schema roles.
Appendix B, "Disabling and Enabling Oracle Database Vault," explains how disable and enable Oracle Database Vault.
Use the DV_REALM_RESOURCE
role for operations such as creating tables, views, triggers, synonyms, and other objects that a realm would typically use.
Privileges Associated with the DV_REALM_RESOURCE Role
The DV_REALM_RESOURCE
role provides the same system privileges as the Oracle RESOURCE
role. In addition, both CREATE SYNONYM
and CREATE VIEW
are granted to this role.
There are no object privileges granted to the DV_REALM_RESOURCE
role, but it does have some system privileges. To find the full list of DV_REALM_RESOURCE
system privileges, log in to SQL*Plus with administrative privileges and enter the following query:
SELECT PRIVILEGE FROM DBA_SYS_PRIVS WHERE GRANTEE = 'DV_REALM_RESOURCE';
Though this role has system privilege grants that SYS
controls, it does not have the DV_OWNER
or DV_ADMIN
role.
How Are GRANT and REVOKE Operations Affected by the DV_REALM_RESOURCE Role?
You can grant the DV_REALM_RESOURCE
role to a database account that owns database tables, objects, triggers, views, procedures, and so on that are used to support any database application. This is a role designed for a schema type database account. The realm owner of the Oracle Data Dictionary realm, such as SYS
, can grant this role to any database account or role.
What Happens When Oracle Database Vault Security Is Disabled?
The granting and revoking of all protected schema roles, including DV_OWNER
, is enforced only if Oracle Database Vault is enabled. If Oracle Database Vault is disabled, then any account with the GRANT ANY ROLE
system privilege can perform GRANT
and REVOKE
operations on protected schema roles.
Appendix B, "Disabling and Enabling Oracle Database Vault," explains how disable and enable Oracle Database Vault.
Use the DV_PUBLIC
role to grant privileges on specific objects in the DVSYS
schema. (Remember that in a default installation, the DVSYS
schema is locked.)
Privileges Associated with the DV_PUBLIC Role
The following Oracle Database Vault objects are accessible through DV_PUBLIC
:
PL/SQL procedures and functions, described in "Oracle Database Vault Run-Time PL/SQL Procedures and Functions". These enable access control and Oracle Label Security processing in an Oracle database.
PL/SQL factor functions, described in "Oracle Database Vault PL/SQL Factor Functions". For the DVF
schema, these are functions for each factor defined. These are functions that you can use in rule sets to inspect the SQL statement that you want the rule set to protect.
DVSYS.DBMS_MACSEC_ROLES
package, described in Chapter 13, "Using the DVSYS.DBMS_MACSEC_ROLES Package." This package enables you to check the authorization for a user or to set an Oracle Database Vault secure application role.
DVSYS.DBMS_MACUTL
package, described in Chapter 14, "Using the DVSYS.DBMS_MACUTL Package." This package is a set of general purpose utility functions that you can use throughout the application code you write for Oracle Database Vault.
There are no system privileges granted to the DV_PUBLIC
role, but it does have some object privileges. To find the full list of DV_PUBLIC
object privileges, log in to SQL*Plus with administrative privileges and enter the following query:
SELECT TABLE_NAME, OWNER, PRIVILEGE FROM DBA_TAB_PRIVS WHERE GRANTEE = 'DV_PUBLIC';
How Are GRANT and REVOKE Operations Affected by the DV_PUBLIC Role?
Oracle Database Vault does not enable you to directly grant object privileges in the DVSYS
schema to PUBLIC
. You must grant the object privilege on the DVSYS
schema object the DV_PUBLIC
role, and then grant DV_PUBLIC
to PUBLIC
. However, if you do this, it is important that you do not add more object privileges to the PUBLIC
role. Doing so may undermine Oracle Database Vault security.
What Happens When Oracle Database Vault Security Is Disabled?
The granting and revoking of all protected schema roles, including DV_OWNER
, is enforced only if Oracle Database Vault is enabled. If Oracle Database Vault is disabled, then any account with the GRANT ANY ROLE
system privilege can perform GRANT
and REVOKE
operations on protected schema roles.
Appendix B, "Disabling and Enabling Oracle Database Vault," explains how disable and enable Oracle Database Vault.
Oracle Database Vault prompts for two accounts during installation: Oracle Database Vault Owner and Oracle Database Vault Account Manager. You must supply an account name and password for the Oracle Database Vault Owner account during installation. Creating an Oracle Database Vault Account Manager is optional.
The Oracle Database Vault Owner account is granted the DV_OWNER
role. This account can manage Oracle Database Vault roles and configuration. (See "DV_OWNER Database Vault Owner Role" for detailed information about this role.)
The Oracle Database Vault Account Manager account is granted the DV_ACCTMGR
role. This account is used to manage database user accounts to facilitate separation of duties. (See "DV_ACCTMGR Database Vault Account Manager Role" for detailed information about this role.)
If you choose not to create the Oracle Database Vault Account Manager account during installation, then both the DV_OWNER
and DV_ACCTMGR
roles are granted to the Oracle Database Vault Owner user account.
Tip:
Oracle recommends that you grant theDV_OWNER
and DV_ACCTMGR
roles to existing user accounts. However, continue to maintain the original DV_OWNER
and DV_ACCTMGR
user accounts that you created during installation. This way, for example, if a user who has been granted one of these roles forgets his or her password, then you can log in as the original Database Vault Account Manager user and then recreate the password without having to disable Oracle Database Vault.Table 11-2 lists the Oracle Database Vault database accounts that are needed in addition to the accounts that you create during installation.
Table 11-2 Database Accounts Used by Oracle Database Vault
Database Account | Roles and Privileges | Description |
---|---|---|
Several system and object privileges are provided to support Oracle Database Vault. The ability to create a session with this account is revoked at the end of the installation, and the account is locked. |
Owner of Oracle Database Vault schema and related objects |
|
A limited set of system privileges are provided to support Oracle Database Vault. The ability to create a session with this account is revoked at the end of the installation, and the account is locked. |
Owner of the Oracle Database Vault functions that are created to retrieve factor identities |
|
This account is created when you install Oracle Label Security by using the Oracle Universal Installer custom installation option. (It is not created when you install Oracle Database Vault.) Do not drop or re-create this account. If you plan to integrate a factor with an Oracle Label Security policy, you must assign this user as the owner of the realm that uses this factor. See "Using Oracle Database Vault Factors with Oracle Label Security Policies" for more information. |
Owner of the Oracle Label Security schema |
You can create different database accounts to implement the separation of duties requirements for Oracle Database Vault. Table 11-3 lists some model database accounts that can act as a guide. (The accounts listed in Table 11-3 serve as a guide to implementing Oracle Database Vault roles. These are not actual accounts that are created during installation.)
Table 11-3 Model Oracle Database Vault Database Accounts
Database Account | Roles and Privileges | Description |
---|---|---|
|
|
Account that is the realm owner for the
|
|
|
Account for administration of database accounts and profiles. This account can:
Note: This account cannot create roles, or grant the |
|
|
Account to serve as the access control administrator. This account can:
Note: This account cannot directly update the |
|
|
Account for running Oracle Database Vault reports in the Oracle Database Vault Administration application. |
Oracle Database Vault provides a set of DBA
-style data dictionary views that can be accessed through the DV_SECANALYST
role or the DV_ADMIN
role. (Alternatively, you can run reports on Oracle Database Vault. See Chapter 17, "Oracle Database Vault Reports," for more information.) These views provide access to the various underlying Oracle Database Vault tables in the DVSYS
and LBACSYS
schemas without exposing the primary and foreign key columns that may be present. These views are intended for the database administrative user to report on the state of the Oracle Database Vault configuration without having to perform the joins required to get the labels for codes that are stored in the core tables or from the related tables.
This section contains:
The DBA_DV_CODE
data dictionary view lists generic lookup codes for the user interface, error messages, constraint checking, and so on. These codes are used for the user interface, views, and for validating input in a translatable fashion.
For example:
SELECT CODE, VALUE FROM DVSYS.DBA_DV_CODE WHERE CODE_GROUP = 'BOOLEAN';
Output similar to the following appears:
CODE VALUE ------- -------- Y True N False
Column | Datatype | Null | Description |
---|---|---|---|
CODE_GROUP |
VARCHAR(30) |
NOT NULL |
Displays one of the following code groups:
|
CODE |
VARCHAR(30) |
NOT NULL |
Boolean code used; either Y (yes) or N (no). |
VALUE |
VARCHAR(4000) |
Boolean value used; either True if the Boolean code is Y or False if the Boolean code is N . |
|
LANGUAGE |
VARCHAR(3) |
NOT NULL |
Language for this installation of Oracle Database Vault.
See Adding Languages to Oracle Database Vault for a list of supported languages. |
DESCRIPTION |
VARCHAR(1024) |
Brief description of the code group. |
The DBA_DV_COMMAND_RULE
data dictionary view lists the SQL statements that are protected by command rules. See Chapter 6, "Configuring Command Rules," for more information about command rules.
For example:
SELECT COMMAND, RULE_SET_NAME FROM DVSYS.DBA_DV_COMMAND_RULE;
Output similar to the following appears:
COMMAND RULE_SET_NAME --------------- ----------------------------- GRANT Can Grant VPD Administration REVOKE Can Grant VPD Administration ALTER SYSTEM Allow System Parameters ALTER USER Can Maintain Own Account CREATE USER Can Maintain Account/Profiles DROP USER Can Maintain Account/Profiles CREATE PROFILE Can Maintain Account/Profiles DROP PROFILE Can Maintain Account/Profiles ALTER PROFILE Can Maintain Account/Profiles
Column | Datatype | Null | Description |
---|---|---|---|
COMMAND |
VARCHAR(30) |
NOT NULL |
Name of the command rule. For a list of default command rules, see Default Command Rules. |
RULE_SET_NAME |
VARCHAR(90) |
NOT NULL |
Name of the rule set associated with this command rule. |
OBJECT_OWNER |
VARCHAR(30) |
NOT NULL |
The owner of the object that the command rule affects. |
OBJECT_NAME |
VARCHAR(128) |
NOT NULL |
The name of the database object the command rule affects (for example, a database table). |
ENABLED |
VARCHAR(1 ) |
NOT NULL |
Y indicates the command rule is enabled; N indicates it is disabled. |
The DBA_DV_FACTOR
data dictionary view lists the existing factors in the current database instance.
For example:
SELECT NAME, GET_EXPR FROM DVSYS.DBA_DV_FACTOR WHERE NAME = 'Session_User';
Output similar to the following appears:
NAME GET_EXPR ------------- --------------------------------------------- Session_User UPPER(SYS_CONTEXT('USERENV', 'SESSION_USER'))
Column | Datatype | Null | Description |
---|---|---|---|
NAME |
VARCHAR2(30) |
NOT NULL |
Name of the factor. See "Default Factors" for a list of default factors. |
DESCRIPTION |
VARCHAR2(4000) |
Description of the factor. | |
FACTOR_TYPE_NAME |
VARCHAR2(90) |
NOT NULL |
Category of the factor, which is used to classify the purpose of the factor. |
ASSIGN_RULE_SET_NAME |
VARCHAR2(90) |
Rule set used to control the identify of the factor. | |
GET_EXPR |
VARCHAR2(1024) |
PL/SQL expression that retrieves the identity of a factor. | |
VALIDATE_EXPR |
VARCHAR2(1024) |
PL/SQL expression used to validate the identify of the factor. It returns a Boolean value. | |
IDENTIFIED_BY |
NUMBER |
NOT NULL |
Determines the identity of a factor, based on the expression listed in the GET_EXPR column. Possible values are:
|
IDENTIFIED_BY_MEANING |
VARCHAR2(4000) |
Provides a text description for the corresponding value in the IDENTIFIED_BY column. Possible values are:
|
|
LABELED_BY |
NUMBER |
NOT NULL |
Determines the labeling the factor:
|
LABELED_BY_MEANING |
VARCHAR2(4000) |
Provides a text description for the corresponding value in the LABELED_BY column. Possible values are:
|
|
EVAL_OPTIONS |
NUMBER |
NOT NULL |
Determines how the factor is evaluated when the user logs on:
|
EVAL_OPTIONS_MEANING |
VARCHAR2(4000) |
Provides a text description for the corresponding value in the EVAL_OPTIONS column. Possible values are:
|
|
AUDIT_OPTIONS |
NUMBER |
NOT NULL |
Option for auditing the factor if you want to generate a custom Oracle Database Vault audit record. Possible values are:
|
FAIL_OPTIONS |
NUMBER |
NOT NULL |
Options for reporting factor errors:
|
FAIL_OPTIONS_MEANING |
VARCHAR2(4000) |
Provides a text description for the corresponding value in the FAIL_OPTIONS column. Possible values are:
|
The DBA_DV_FACTOR_LINK
data dictionary view shows the relationships of each factor whose identity is determined by the association of child factors. The view contains one entry for each parent factor and child factor. You can use this view to resolve the relationships from the factor links to identity maps.
For example:
SELECT PARENT_FACTOR_NAME, CHILD_FACTOR_NAME FROM DVSYS.DBA_DV_FACTOR_LINK;
Output similar to the following appears:
PARENT_FACTOR_NAME CHILD_FACTOR_NAME ------------------------------ ------------------------------ Domain Database_Instance Domain Database_IP Domain Database_Hostname
Column | Datatype | Null | Description |
---|---|---|---|
PARENT_FACTOR_NAME |
VARCHAR(30) |
NOT NULL |
Name of the parent factor. |
CHILD_FACTOR_NAME |
VARCHAR(30) |
NOT NULL |
Name of the child factor of the parent factor. |
LABEL_IND |
VARCHAR(1) |
NOT NULL |
Indicates whether the child factor that is linked to the parent factor contributes to the label of the parent factor in an Oracle Label Security integration. Possible values are:
|
The DBA_DV_FACTOR_TYPE
data dictionary view lists the names and descriptions of factor types used in the system.
For example:
SELECT * FROM DVSYS.DBA_DV_FACTOR_TYPE WHERE NAME = 'Hostname';
Output similar to the following appears:
NAME DESCRIPTION --------- ---------------------------------------------------------------------- Time Time-based factor
Column | Datatype | Null | Description |
---|---|---|---|
NAME |
VARCHAR(90) |
NOT NULL |
Name of the factor type. |
DESCRIPTION |
VARCHAR(1024) |
Description of the factor type. |
The DBA_DV_IDENTITY
data dictionary view lists the identities for each factor.
For example:
SELECT * FROM DVSYS.DBA_DV_IDENTITY WHERE VALUE = 'GLOBAL SHARED';
Output similar to the following appears, assuming you have created only one factor identity:
FACTOR_NAME VALUE TRUST_LEVEL ---------------- -------------- ------------ Identification_Type GLOBAL SHARED 1
Column | Datatype | Null | Description |
---|---|---|---|
FACTOR_NAME |
VARCHAR(30) |
NOT NULL |
Name of the factor. |
VALUE |
VARCHAR(1024) |
NOT NULL |
Value of the factor. |
TRUST_LEVEL |
NUMBER |
NOT NULL |
Number that indicates the magnitude of trust relative to other identities for the same factor. |
The DBA_DV_IDENTITY_MAP
data dictionary view lists the mappings for each factor identity. The view includes mapping factors that are identified by other factors to combinations of parent-child factor links. For each factor, the maps are joined by the OR
operation, and for different factors, the maps are joined by the AND
operation.
You can use this view to resolve the identity for factors that are identified by other factors (for example, a domain) or for factors that have continuous domains (for example, Age or Temperature).
For example:
SELECT FACTOR_NAME, IDENTITY_VALUE FROM DVSYS.DBA_DV_IDENTITY_MAP;
Output similar to the following appears:
FACTOR_NAME IDENTITY_VALUE ---------------- -------------------- Sector2_Program Accounting-Sensitive
Column | Datatype | Null | Description |
---|---|---|---|
FACTOR_NAME |
VARCHAR(30) |
NOT NULL |
Factor the identity map is for. |
IDENTITY_VALUE |
VARCHAR(1024) |
NOT NULL |
Value the factor assumes if the identity map evaluates to TRUE . |
OPERATION_VALUE |
VARCHAR(4000) |
Relational operator for the identity map (for example, <, >, =, and so on) | |
OPERAND1 |
VARCHAR(1024) |
Left operand for the relational operator; refers to the low value you enter. | |
OPERAND2 |
VARCHAR(1024) |
Right operand for the relational operator; refers to the high value you enter. | |
PARENT_FACTOR_NAME |
VARCHAR(30) |
The parent factor link to which the map is related. | |
CHILD_FACTOR_NAME |
VARCHAR(30) |
The child factor link to which the map is related. | |
LABEL_IND |
VARCHAR(1) |
Indicates whether the child factor being linked to the parent factor contributes to the label of the parent factor in an Oracle Label Security integration. Possible values are:
|
The DBA_DV_MAC_POLICY
data dictionary view lists the Oracle Label Security policies defined for use with Oracle Database Vault.
For example:
SELECT POLICY_NAME, ALGORITHM_CODE, ALGORITHM_MEANING FROM DVSYS.DBA_DV_MAC_POLICY;
Output similar to the following appears:
POLICY_NAME ALGORITHM_CODE ALGORITHM_MEANING --------------- ----------------- ----------------------- ACCESS_DATA LUI Minimum Level/Union/Intersection
Column | Datatype | Null | Description |
---|---|---|---|
POLICY_NAME |
VARCHAR(30) |
NOT NULL |
Name of the policy. |
ALGORITHM_CODE |
VARCHAR(30) |
NOT NULL |
Merge algorithm code used for the policy. See Table 12-57 for a listing of algorithm codes. |
ALGORITHM_MEANING |
VARCHAR(4000) |
Provides a text description for the corresponding value in the ALGORITHM_CODE column. See Table 12-57 for a listing of algorithm code descriptions. |
|
ERROR_LABEL |
VARCHAR(4000) |
Label specified for initialization errors, to be set when a configuration error or run-time error occurs during session initialization. |
The DBA_DV_MAC_POLICY
data dictionary view lists the factors that are associated with Oracle Label Security policies.
You can use this view to determine what factors contribute to the maximum session label for each policy using the DBA_DV_MAC_POLICY
view.
For example:
SELECT * FROM DVSYS.DBA_DV_MAC_POLICY_FACTOR;
Output similar to the following appears:
FACTOR_NAME MAC_POLICY_NAME -------------- ------------------ App_Host_Name Access Locations
Column | Datatype | Null | Description |
---|---|---|---|
FACTOR_NAME |
VARCHAR(30) |
NOT NULL |
Name of the factor. |
MAC_POLICY_NAME |
VARCHAR(30) |
NOT NULL |
Name of the Oracle Label Security policy associated with this factor. |
The DBA_DV_POLICY_LABEL
data dictionary view lists the Oracle Label Security label for each factor identifier in the DBA_DV_IDENTITY
view for each policy.
For example:
SELECT * FROM DVSYS.DBA_DV_POLICY_LABEL;
Output similar to the following appears:
IDENTITY_VALUE FACTOR_NAME POLICY_NAME LABEL ---------------- -------------- ---------------- --------- App_Host_Name Sect2_Fin_Apps Access Locations Sensitive
Column | Datatype | Null | Description |
---|---|---|---|
IDENTITY_VALUE |
VARCHAR(1024) |
NOT NULL |
Name of the factor identifier. |
FACTOR_NAME |
VARCHAR(30) |
NOT NULL |
Name of the factor associated with the factor identifier. |
POLICY_NAME |
VARCHAR(30) |
NOT NULL |
Name of the Oracle Label Security policy associated with this factor. |
LABEL |
VARCHAR(4000) |
NOT NULL |
Name of the Oracle Label Security label associated with the policy. |
The DBA_DV_PUB_PRIVS
data dictionary view lists data reflected in the Oracle Database Vault privilege management reports used in the Oracle Database Vault Administrator (DV_ADMIN
). See also "Privilege Management - Summary Reports".
For example:
SELECT USERNAME, ACCESS_TYPE FROM DVSYS.DBA_DV_PUB_PRIVS WHERE USERNAME = 'OE';
Output similar to the following appears:
USERNAME ACCESS_TYPE ----------- ----------------- OE PUBLIC
Column | Datatype | Null | Description |
---|---|---|---|
USERNAME |
VARCHAR(30) |
NOT NULL |
Database schema in the current database instance.acces |
ACCESS_TYPE |
VARCHAR(30) |
Access type granted to the user listed in the USERNAME column (for example, PUBLIC ). |
|
PRIVILEGE |
VARCHAR(40 ) |
NOT NULL |
Privilege granted to the user listed in the USERNAME column. |
OWNER |
VARCHAR(30) |
NOT NULL |
Owner of the database schema to which the USERNAME user has been granted privileges. |
OBJECT_NAME |
VARCHAR(30) |
NOT NULL |
Name of the object within the schema listed in the OWNER column. |
The DBA_DV_REALM
data dictionary view lists the realms created in the current database instance.
For example:
SELECT NAME, AUDIT_OPTIONS, ENABLED FROM DVSYS.DBA_DV_REALM WHERE AUDIT_OPTIONS = 'N';
Output similar to the following appears:
NAME AUDIT_OPTIONS ENABLED ----------------------------- ---------------- -------- Performance Statistics Realm N 1
Column | Datatype | Null | Description |
---|---|---|---|
NAME |
VARCHAR(90) |
NOT NULL |
Names of the realms created. See"Default Realms" for a listing of default realms. |
DESCRIPTION |
VARCHAR(1024 ) |
NOT NULL |
Description of the realm created. |
AUDIT_OPTIONS |
NUMBER |
NOT NULL |
Specifies whether auditing is enabled. Possible values are:
|
ENABLED |
VARCHAR(1) |
NOT NULL |
Specifies whether realm checking is enabled. Y (yes) indicates it is enabled; N (no) indicates it is not. |
The DBA_DV_REALM_AUTH
data dictionary view lists the authorization of a named database user account or database role (GRANTEE
) to access realm objects in a particular realm. See Defining Realm Authorization for more information.
For example:
SELECT REALM_NAME, GRANTEE, AUTH_RULE_SET_NAME FROM DVSYS.DBA_DV_REALM_AUTH;
Output similar to the following appears:
REALM_NAME GRANTEE AUTH_RULE_SET_NAME ---------------------------- --------- --------------------- Performance Statistics Realm SYSADM Check Conf Access
Column | Datatype | Null | Description |
---|---|---|---|
REALM_NAME |
VARCHAR(90) |
NOT NULL |
Name of the realm. |
GRANTEE |
VARCHAR(30) |
NOT NULL |
User or role name to authorize as owner or participant. |
AUTH_RULE_SET_NAME |
VARCHAR(90 ) |
Rule set to check before authorizing. If the rule set evaluates to TRUE , then the authorization is allowed. |
|
AUTH_OPTIONS |
VARCHAR(4000) |
Type of realm authorization: either Participant or Owner . |
The DBA_DV_REALM_OBJECT
data dictionary view lists the database schemas, or subsets of schemas with specific database objects contained therein, that are secured by the realms. See "Creating Realm-Secured Objects" for more information.
For example:
SELECT REALM_NAME, OWNER, OBJECT_NAME FROM DVSYS.DBA_DV_REALM_OBJECT;
Output similar to the following appears:
REALM_NAME OWNER OBJECT_NAME ---------------------------- -------- ----------- Performance Statistics Realm OE ORDERS
Column | Datatype | Null | Description |
---|---|---|---|
REALM_NAME |
VARCHAR(90) |
NOT NULL |
Name of the realm. |
OWNER |
VARCHAR(90) |
NOT NULL |
Database schema owner who owns the realm. |
OBJECT_NAME |
VARCHAR(90) |
NOT NULL |
Name of the object the realm protects. |
OBJECT_TYPE |
VARCHAR(90) |
NOT NULL |
Type of object the realm protects, such as a database table, view, index, or role. |
The DBA_DV_ROLE
data dictionary view lists the Oracle Database Vault secure application roles used in privilege management.
For example:
SELECT ROLE, RULE_NAME FROM DVSYS.DBA_DV_ROLE;
Output similar to the following appears:
ROLE RULE_NAME ------------------ -------------------- Sector2_APP_MGR Check App2 Access Sector2_APP_DBA Check App2 Access
Column | Datatype | Null | Description |
---|---|---|---|
ROLE |
VARCHAR(30) |
NOT NULL |
Name of the secure application role. |
RULE_NAME |
VARCHAR(90) |
NOT NULL |
Name of the rule set associated with the secure application role. |
ENABLED |
VARCHAR(1) |
NOT NULL |
Indicates whether the secure application role is enabled. Y (yes) enables the role; N (no) disables it. |
The DBA_DV_RULE
data dictionary view lists the rules that have been defined.
For example:
SELECT * FROM DVSYS.DBA_DV_RULE WHERE NAME = 'Maintenance Window';
Output similar to the following appears:
NAME RULE_EXP ------------------- ---------------------------------------------- Maintenance Window TO_CHAR(SYSDATE,'HH24') BETWEEN '10' AND '12'
To find the rule sets that use specific rules, query the DBA_DV_RULE_SET_RULE
view.
Column | Datatype | Null | Description |
---|---|---|---|
NAME |
VARCHAR(90) |
NOT NULL |
Name of the rule. |
RULE_EXPR |
VARCHAR(1024) |
NOT NULL |
PL/SQL expression for the rule. |
The DBA_DV_RULE_SET
data dictionary view lists the rules sets that have been created.
For example:
SELECT RULE_SET_NAME, HANDLER_OPTIONS, HANDLER FROM DVSYS.DBA_DV_RULE_SET WHERE RULE_SET_NAME = 'Maintenance Period';
Output similar to the following appears:
RULE_SET_NAME HANDLER_OPTIONS HANDLER ------------------- ---------------- ---------------------- Maintenance Period 1 dbavowner.email_alert
Column | Datatype | Null | Description |
---|---|---|---|
RULE_SET_NAME |
VARCHAR(90) |
NOT NULL |
Name of the rule set. |
DESCRIPTION |
VARCHAR(1024) |
Description of the rule set. | |
ENABLED |
VARCHAR(1) |
NOT NULL |
Indicates whether the rule set has been enabled. Y (yes) enables the rule set; N (no) disables it. |
EVAL_OPTIONS_MEANING |
VARCHAR(4000) |
For rules sets that contain multiple rules, determines how many rules are evaluated. Possible values are:
|
|
AUDIT_OPTIONS |
NUMBER |
NOT NULL |
Indicates when auditing is used. Possible values are:
|
FAIL_OPTIONS_MEANING |
VARCHAR(4000) |
Determines when an audit record is created for the rule set. Possible values are:
|
|
FAIL_MESSAGE |
VARCHAR(80) |
Error message for failure that is associated with the fail code listed in the FAIL_CODE column. |
|
FAIL_CODE |
VARCHAR(10) |
The error message number associated with the message listed in the FAIL_MESSAGE column. Possible values are in the ranges of -20000 to -20999 or 20000 to 20999. |
|
HANDLER_OPTIONS |
NUMBER |
NOT NULL |
Determines how error handling is used. Possible values are:
|
HANDLER |
VARCHAR(1024) |
Name of the PL/SQL function or procedure that defines the custom event handler logic. | |
IS_STATIC |
VARCHAR2(5) |
Indicates how often the rule set is evaluated during a user session. Possible values are:
|
The DBA_DV_RULE_SET_RULE
data dictionary view lists rules that are associated with existing rule sets.
For example:
SELECT RULE_SET_NAME, RULE_NAME, RULE_EXPR FROM DVSYS.DBA_DV_RULE_SET_RULE WHERE RULE_NAME = 'Is Security Officer';
Output similar to the following appears:
RULE_SET_NAME RULE_NAME RULE_EXP ---------------------------- ------------------ --------------------------------- Can Grant VPD Administration Is Security Owner DVSYS.DBMS_MACUTL.USER_HAS_ROLE_ VARCHAR('DV_OWNER',dvsys.dv_ login_user) = 'Y'
Column | Datatype | Null | Description |
---|---|---|---|
RULE_SET_NAME |
VARCHAR(90) |
NOT NULL |
Name of the rule set that contains the rule. |
RULE_NAME |
VARCHAR(90) |
NOT NULL |
Name of the rule. |
RULE_EXPR |
VARCHAR(1024) |
NOT NULL |
PL/SQL expression that defines the rule listed in the RULE_NAME column. |
ENABLED |
VARCHAR(1) |
Indicates whether the rule is enabled or disabled. Y (yes) enables the rule set; N (no) disables it. |
|
RULE_ORDER |
NUMBER |
NOT NULL |
The order in which rules are used within the rule set. Does not apply to this release. |
The DBA_DV_USER_PRIVS
data dictionary view lists the privileges for a database user account excluding privileges granted through the PUBLIC
role.
For example:
SELECT USERNAME, ACCESS_TYPE, PRIVILEGE FROM DVSYS.DBA_DV_USER_PRIVS;
Output similar to the following appears:
USERNAME ACCESS_TYPE PRIVILEGE --------- -------------------- ------------ DVSYS DV_PUBLIC EXECUTE DVOWNER DV_ADMIN SELECT SYS SELECT_CATALOG_ROLE SELECT ...
Column | Datatype | Null | Description |
---|---|---|---|
USERNAME |
VARCHAR(30) |
NOT NULL |
Name of the database schema account in which privileges have been defined. |
ACCESS_TYPE |
VARCHAR(30) |
Role the database user account listed in the USERNAME column uses to access the database. Oracle Database Vault accounts have direct access. |
|
PRIVILEGE |
VARCHAR(40) |
NOT NULL |
Privilege granted to the user listed in the USERNAME column. |
OWNER |
VARCHAR(30) |
NOT NULL |
Name of the database user account. |
OBJECT_NAME |
VARCHAR(30) |
NOT NULL |
Name of the PL/SQL function or procedure used to define privileges. |
The DBA_DV_USER_PRIVS_ALL
data dictionary view lists the privileges for a database account including privileges granted through PUBLIC
.
For example:
SELECT USERNAME, ACCESS_TYPE, PRIVILEGE FROM DVSYS.DBA_DV_USER_PRIVS;
Output similar to the following appears:
USERNAME ACCESS_TYPE PRIVILEGE ------------------- ------------ ----------------- AMALCOLM_DVACCTMGR CONNECT CREATE_SESSION LBROWN_DVOWNER DIRECT CREATE PROCEDURE ...
Column | Datatype | Null | Description |
---|---|---|---|
USERNAME |
VARCHAR(30) |
Name of the database schema account in which privileges have been defined. | |
ACCESS_TYPE |
VARCHAR(30) |
Role the database user account listed in the USERNAME column uses to access the database. Oracle Database Vault accounts have direct access. |
|
PRIVILEGE |
VARCHAR(40) |
Privilege granted to the user listed in the USERNAME column. |
|
OWNER |
VARCHAR(30) |
Name of the database user account. | |
OBJECT_NAME |
VARCHAR(30) |
Name of the PL/SQL function or procedure used to define privileges. |