Oracle recommends that you do not use these top-level accounts for regular administration tasks; instead, you should give the DV_OWNER and DV_ACCTMGR role to individual administrators who secure them with their own password. If the top-level passwords were forgotten, you could no longer enable or disable Database Vault. This course uses LEO_DVOWNER and BEA_ACCTMGR as sample users.
These two roles are very different. The DV_OWNER role is able to change the Database Vault configuration, thus affecting which users can access what data. The DV_ACCTMGR role is able to create new users and modify the passwords of existing users, including those with the DV_MONITOR, DV_SECANALYST, and DV_AUDIT_CLEANUP roles. Having a separate user with the DV_ACCTMGR role—which means that this user is the only user who can create new users— provides a separation of duties.
- Because of the delivered configuration of Database Vault, the SYS user can no longer create users, but it can grant system privileges.
- To ensure proper security, users with the DV_ACCTMGR role are not allowed to change the password of security administrators who have the DV_OWNER role.
All this works together to provide strong controls inside the database over who can do what and controls over when and how applications, data, and databases can be accessed.
Database Vault creates ten new roles to support its functionality. Users with the following security administrative roles can perform various tasks in Database Vault Administrator:
- DV_OWNER: This role is for the Database Vault owner. It represents a version of the DV_ADMIN role that is able to grant itself and the DV_ADMIN role to others. It has all the security administrative roles (DV_ADMIN, DV_MONITOR, DV_SECANALYST, DV_STREAMS_ADMIN, and DV_PATCH_ADMIN) and has the most privileges on the DVSYS schema.
- DV_ADMIN: This role allows the execution of administrative tasks, including monitoring and viewing of reports. It has the DV_SECANALYST role.
- DV_MONITOR: This role enables the Oracle Enterprise Manager Cloud Control agent to monitor Database Vault for attempted violations and configuration issues with realm or command rule definitions.
- DV_SECANALYST: This role allows monitoring and running of reports, also in Cloud Control if set up as an EM_USER. It does not allow execution of any other tasks.
- DV_STREAMS_ADMIN: This role should be granted to any user who is responsible for configuring Oracle Streams in the Database Vault environment.
- DV_XSTREAM_ADMIN: Grant this role to any user who is responsible for configuring Oracle XStream in the Database Vault environment.
- DV_GOLDENGATE_ADMIN: Grant this role to any user who is responsible for configuring Oracle GoldenGate in a Database Vault environment.
- DV_GOLDENGATE_REDO_ACCESS: Grant this role to any user who is responsible for using the Oracle GoldenGate TRANLOGOPTIONS DBLOGREADER method to access redo logs in a Database Vault environment.
- DV_AUDIT_CLEANUP: Grant this role to any user who is responsible for purging the Database Vault audit trail in a non-unified auditing environment.
- DV_PATCH_ADMIN: Grant this role temporarily to any database administrator who performs database patching. After the patch is complete, you should immediately revoke this role.
For managing accounts, the following role is created:
DV_ACCTMGR: This is the only role that allows creating and altering users and profiles. This role is granted to the user that you specify as the Database Vault Account Manager during installation. If you do not specify a user (not recommended), this role is granted to the Database Vault Owner user, effectively making that user the one that manages the accounts. In addition to maintaining users and profiles, this role can grant CONNECT and itself (the DV_ACCTMGR role).
For establishing users who manage realms, you can use the following roles:
- DV_REALM_OWNER: This role is used for managing database objects in multiple schemas that define an application or a realm. The role should be granted to the database account owner who would manage several schema database accounts within a realm and the roles associated with the realm. A user who is granted this role can use powerful privileges, such as CREATE ANY, ALTER ANY, and DROP ANY system privileges within the realm. Note that although this role has system privileges that the SYS user controls, it does not have the DV_OWNER or DV_ADMIN privileges, which means that it cannot change the Database Vault configuration.
- DV_REALM_RESOURCE: This role provides system privileges similar to those that exist in the Oracle RESOURCE role (which allows users to create objects in their own schema). The role can be granted to a database account that owns the database tables, objects, triggers, views, procedures, and so on that support a database application. The role is geared toward a schema type database account. As with the DV_REALM_OWNER role, the role does not have the DV_OWNER or DV_ADMIN privilege. The SYS user is the only one who can grant this role.
To support public permissions, use the following role:
DV_PUBLIC: The only permissions granted to this role upon installation are several EXECUTE permissions on the Database Vault procedures. These procedures are benign in that they do nothing to reconfigure the system without the appropriate checks being done. Most of them are simple interrogation routines to retrieve information about the components or the environment.