3 Getting Started with Oracle Database Vault
Before you can start using Oracle Database Vault, you must configure and enable it with the Oracle database.
- About Configuring and Enabling Oracle Database Vault in Oracle Database
Oracle Database includes Database Vault when you choose to include a default database in the installation process, but you must configure and enable it before you can use it. - Configuring and Enabling Oracle Database Vault with an Oracle Database in a Multitenant Environment
You can configure and enable Oracle Database Vault in a multitenant environment based on several scenarios. - Registering Oracle Database Vault in a Non-Multitenant Environment
After you register the users, you should create a profile to protect these accounts. - Configuring and Enabling Oracle Database Vault in an Oracle Real Application Clusters Environment
You can configure Oracle Database Vault for an Oracle Real Application Clusters (Oracle RAC) environment, including each Oracle RAC node. - Verifying That Database Vault Is Configured and Enabled
TheDBA_DV_STATUS
,CDB_DV_STATUS
,DBA_OLS_STATUS
, andCDB_OLS_STATUS
data dictionary views verify if Oracle Database is configured and enabled. - Logging in to Oracle Database Vault from Oracle Enterprise Cloud Control
Oracle Enterprise Manager Cloud Control (Cloud Control) provides pages for managing Oracle Database Vault. - Quick Start Tutorial: Securing a Schema from DBA Access
This tutorial shows how to create a realm around theHR
schema.
3.1 About Configuring and Enabling Oracle Database Vault in Oracle Database
Oracle Database includes Database Vault when you choose to include a default database in the installation process, but you must configure and enable it before you can use it.
Oracle Database includes Database Vault when you choose to include a default database in the installation process, but you must register it before you can use it. If you create a custom database, then you can use DBCA to install and enable Database Vault for it. The registration process enables Oracle Label Security if it is not already enabled. Oracle Label Security is required for Oracle Database Vault but it does not require a separate license unless you begin using Oracle Label Security separately and create Oracle Label Security policies. This procedure applies to the CDB root, application root, and the current pluggable database (PDB), as well as to both single-instance and Oracle Real Application Clusters (Oracle RAC) installations. In a multitenant database, Database Vault must be configured with the CDB root before any of the PDBs can configure Database Vault.
As part of the configuration process, you created the Database Vault administrative accounts. These are accounts that hold the Database Vault roles DV_OWNER
and DV_ACCTMGR
. Use these accounts initially to provision the roles to named users with administrative privileges. Maintaining a backup account will allow you to recover from the named user losing or somehow misplacing their credentials because SYS
will not be able to reset these passwords for users with these roles.
You can register Oracle Database in both multitenant and non-multitenant environments. For multitenant environments, you have several methods to choose from for the registration.
Note:
If you have upgraded from a release earlier than Oracle Database 12c, and if the earlier Oracle Database Vault had been enabled in that earlier release, then after the upgrade process is complete, you must enable Oracle Database Vault by using theDBMS_MACADM.ENABLE_DV
procedure.
In a multitenant environment, if you are migrating a non-Database Vault registered Oracle database from a release earlier than release 12c, then you must perform a manual installation of Database Vault.
Related Topics
Parent topic: Getting Started with Oracle Database Vault
3.2 Configuring and Enabling Oracle Database Vault with an Oracle Database in a Multitenant Environment
You can configure and enable Oracle Database Vault in a multitenant environment based on several scenarios.
- About Configuring and Enabling Database Vault in a Multitenant Environment
You must configure and enable Oracle Database Vault in the CDB root before you can perform the same action in any of the associated PDBs. - Configuring and Enabling Database Vault in the CDB Root
In a multitenant environment, you configure and enable Oracle Database Vault with common users who will use the Database Vault-enforced roles in the CDB root. - Registering Database Vault Common Users to Manage Specific PDBs
In a multitenant environment, you must register Oracle Database Vault in the root first, then in the PDBs afterward. - Configuring and Enabling Database Vault Local Users to Manage Specific PDBs
In a multitenant environment, you must configure and enable Oracle Database Vault in the root first, and then in the PDBs afterward. - Creating a Profile to Protect the DV_OWNER and DV_ACCTMGR Users
A profile provides additional protection for users who have been granted theDV_OWNER
andDV_ACCTMGR
roles. - Plugging in a Database Vault-Enabled PDB
From SQL*Plus, in a multitenant environment, you can plug in a database that already has Database Vault enabled. - Manually Installing Oracle Database Vault in a Multitenant Environment
Under certain conditions, for a multitenant environment, you must manually install Oracle Database Vault. For example, a release 11g Oracle database without Database Vault is upgraded to release 12c, then converted to a PDB to be plugged into a 12c Database Vault-enabled database.
Parent topic: Getting Started with Oracle Database Vault
3.2.1 About Configuring and Enabling Database Vault in a Multitenant Environment
You must configure and enable Oracle Database Vault in the CDB root before you can perform the same action in any of the associated PDBs.
The common users who have been assigned the DV_OWNER
and DV_ACCTMGR
roles in the CDB root can also have the same role in the PDBs. PDBs can have Database Vault configured and enabled using the same common users or use separate PDB local users. The DV_ACCTMGR
role is granted commonly to the common user in the CDB root. You can grant DV_OWNER
locally or commonly to the CDB root common user when you configure and register Database Vault with the CDB root. Granting DV_OWNER
locally to the common user prevents the common DV_OWNER
user from using this role in any PDB.
3.2.2 Configuring and Enabling Database Vault in the CDB Root
In a multitenant environment, you configure and enable Oracle Database Vault with common users who will use the Database Vault-enforced roles in the CDB root.
Related Topics
- Verifying That Database Vault Is Configured and Enabled
- Oracle Database Vault Roles
- Logging in to Oracle Database Vault from Oracle Enterprise Cloud Control
- DV_PATCH_ADMIN Database Vault Database Patch Role
- CONFIGURE_DV General System Maintenance Procedure
- Configuring and Enabling Oracle Database Vault in an Oracle Real Application Clusters Environment
3.2.3 Registering Database Vault Common Users to Manage Specific PDBs
In a multitenant environment, you must register Oracle Database Vault in the root first, then in the PDBs afterward.
ORA-47503: Database Vault is not enabled on CDB$ROOT
error appears.
Related Topics
- Verifying That Database Vault Is Configured and Enabled
- Oracle Database Vault Roles
- Logging in to Oracle Database Vault from Oracle Enterprise Cloud Control
- DV_PATCH_ADMIN Database Vault Database Patch Role
- CONFIGURE_DV General System Maintenance Procedure
- Configuring and Enabling Database Vault in the CDB Root
3.2.4 Configuring and Enabling Database Vault Local Users to Manage Specific PDBs
In a multitenant environment, you must configure and enable Oracle Database Vault in the root first, and then in the PDBs afterward.
ORA-47503: Database Vault is not enabled on CDB$ROOT
error appears.
Related Topics
3.2.5 Creating a Profile to Protect the DV_OWNER and DV_ACCTMGR Users
A profile provides additional protection for users who have been granted the DV_OWNER
and DV_ACCTMGR
roles.
DV_OWNER
or DV_ACCTMGR
roles are considered critical, privileged, accounts. Typically, these accounts should be considered service accounts and exempt from password lockout requirements. Oracle recommends that you create a custom profile that prevents the account from being locked. In addition, you should audit failed login attempts for these Database Vault-related accounts.
- Log into the database instance as a user who has the
CREATE PROFILE
system privilege.- For common
DV_OWNER
andDV_ACCTMGR
users: Log in to the root of the database instance. - For local
DV_OWNER
andDV_ACCTMGR
users: Log in to the PDB in which you created the users.
- For common
- Create a profile similar to the following:
- For common
DV_OWNER
andDV_ACCTMGR
users: In the root, create the profile similar to the following:CREATE PROFILE c##dv_profile limit FAILED_LOGIN_ATTEMPTS UNLIMITED PASSWORD_VERIFY_FUNCTION ORA12C_VERIFY_FUNCTION PASSWORD_LOCK_TIME UNLIMITED CONTAINER=CURRENT;
- For local
DV_OWNER
andDV_ACCTMGR
users: In the PDB, create the profile similar to the following:CREATE PROFILE dv_profile limit FAILED_LOGIN_ATTEMPTS UNLIMITED PASSWORD_VERIFY_FUNCTION ORA12C_VERIFY_FUNCTION PASSWORD_LOCK_TIME UNLIMITED CONTAINER=CURRENT;
- For common
- Update the
DV_OWNER
andDV_ACCTMGR
user accounts to use this profile.- For common
DV_OWNER
andDV_ACCTMGR
users:ALTER USER c##sec_admin_owen PROFILE c##dv_profile CONTAINER=ALL; ALTER USER c##dbv_owner_root_backup PROFILE c##dv_profile CONTAINER=ALL; ALTER USER c##accts_admin_ace PROFILE c##dv_profile CONTAINER=ALL; ALTER USER c##dbv_acctmgr_root_backup PROFILE c##dv_profile CONTAINER=ALL;
- For local
DV_OWNER
andDV_ACCTMGR
users:ALTER USER sec_admin_owen PROFILE dv_profile CONTAINER=CURRENT; ALTER USER dbv_owner_backup PROFILE dv_profile CONTAINER=CURRENT; ALTER USER accts_admin_ace PROFILE dv_profile CONTAINER=CURRENT; ALTER USER dbv_acctmgr_backup PROFILE dv_profile CONTAINER=CURRENT;
- For common
- Connect as a user who has been granted the
AUDIT_ADMIN
role. - Create and enable a unified audit policy to track failed logins by any user who has been granted the
DV_OWNER
orDV_ACCTMGR
role.- For common
DV_OWNER
andDV_ACCTMGR
users: In the root, create a policy similar to the following:CREATE AUDIT POLICY c##dv_logins ACTIONS LOGON; AUDIT POLICY c##dv_logins BY USERS WITH GRANTED ROLES DV_OWNER, DV_ACCTMGR WHENEVER NOT SUCCESSFUL;
- For local
DV_OWNER
andDV_ACCTMGR
users: In the PDB, create a policy similar to the following:CREATE AUDIT POLICY dv_logins ACTIONS LOGON; AUDIT POLICY dv_logins BY USERS WITH GRANTED ROLES DV_OWNER, DV_ACCTMGR WHENEVER NOT SUCCESSFUL;
- For common
3.2.6 Plugging in a Database Vault-Enabled PDB
From SQL*Plus, in a multitenant environment, you can plug in a database that already has Database Vault enabled.
In this scenario, the plugged in database has its own local Database Vault accounts. Be aware that if you plug a Database Vault-enabled database into a CDB that is not Database Vault enabled, then the PDB will remain in restricted mode until you enable Database Vault in the CDB and then restart the CDB. If you plug a non-Database Vault-enabled PDB into a CDB that is Database Vault enabled, then the PDB remains in restricted mode until you enable Database Vault in the PDB and then restart the PDB. This plugged in non-Database Vault enabled PDB can still be used. However, if the CDB is Database Vault enabled with the strict option set, then the PDB must be Database Vault enabled.
Before you plug in a Database Vault-enabled PDB and if the Database Vault roles are granted to common users, ensure that you understand fully how plugging in PDBs affect common users.
3.2.7 Manually Installing Oracle Database Vault in a Multitenant Environment
Under certain conditions, for a multitenant environment, you must manually install Oracle Database Vault. For example, a release 11g Oracle database without Database Vault is upgraded to release 12c, then converted to a PDB to be plugged into a 12c Database Vault-enabled database.
3.3 Registering Oracle Database Vault in a Non-Multitenant Environment
After you register the users, you should create a profile to protect these accounts.
- Registering Database Vault Users
You can register Oracle Database Vault using SQL*Plus. - Creating a Profile to Protect the DV_OWNER and DV_ACCTMGR Users
A profile provides additional protection for users who have been granted theDV_OWNER
andDV_ACCTMGR
roles.
Parent topic: Getting Started with Oracle Database Vault
3.3.2 Creating a Profile to Protect the DV_OWNER and DV_ACCTMGR Users
A profile provides additional protection for users who have been granted the DV_OWNER
and DV_ACCTMGR
roles.
DV_OWNER
or DV_ACCTMGR
roles are considered critical, privileged, accounts. Typically, these accounts should be considered service accounts and exempt from password lockout requirements. Oracle recommends that you create a custom profile that prevents the account from being locked. In addition, you should audit failed login attempts for these Database Vault-related accounts.
3.4 Configuring and Enabling Oracle Database Vault in an Oracle Real Application Clusters Environment
You can configure Oracle Database Vault for an Oracle Real Application Clusters (Oracle RAC) environment, including each Oracle RAC node.
Related Topics
Parent topic: Getting Started with Oracle Database Vault
3.5 Verifying That Database Vault Is Configured and Enabled
The DBA_DV_STATUS
, CDB_DV_STATUS
, DBA_OLS_STATUS
, and CDB_OLS_STATUS
data dictionary views verify if Oracle Database is configured and enabled.
SYS
user and users who have been granted the DBA
role can query these views.
-
For Database Vault:
-
If you want to find the Database Vault status for a non-multitenant database, or in a multitenant environment for the root only or an individual PDB, then depending on who you are connected to the database as, query the
DBA_DV_STATUS
orSYS.DBA_DV_STATUS
view. Examples are as follows:- If you are connected as a user who has the
DBA
role or theSYSDBA
administrative privilege:SELECT * FROM DBA_DV_STATUS;
- If you are connected as a user who has the
DV_OWNER
orDV_ADMIN
role:SELECT * FROM SYS.DBA_DV_STATUS;
Output similar to the following appears:
NAME STATUS -------------------- ----------- DV_APP_PROTECTION NOT CONFIGURED DV_CONFIGURE_STATUS TRUE DV_ENABLE_STATUS TRUE
DV_APP_PROTECTION
refers to operations control, which automatically restricts common users from accessing PDB local data in autonomous, regular Cloud, or on-premises environments. - If you are connected as a user who has the
-
If you want to find the Database Vault status of all PDBs in a multitenant environment, as a common user with administrative privileges, then query
CDB_DV_STATUS
, which provides the addition of a container ID (CON_ID
) field.
-
-
For Oracle Label Security, query the following data dictionary views, which are similar to their Database Vault equivalent views:
-
DBA_OLS_STATUS
-
CDB_OLS_STATUS
-
3.6 Logging in to Oracle Database Vault from Oracle Enterprise Cloud Control
Oracle Enterprise Manager Cloud Control (Cloud Control) provides pages for managing Oracle Database Vault.
3.7 Quick Start Tutorial: Securing a Schema from DBA Access
This tutorial shows how to create a realm around the HR
schema.
- About This Tutorial
In this tutorial, you create a realm around for theHR
sample database schema by using the Oracle Database Vault PL/SQL packages. - Step 1: Log On as SYSTEM to Access the HR Schema
You must enable theHR
schema for this tutorial. - Step 2: Create a Realm
Realms can protect one or more schemas, individual schema objects, and database roles. - Step 3: Create the SEBASTIAN User Account
At this stage, there are no database accounts or roles authorized to access or otherwise manipulate the database objects the realm will protect. - Step 4: Have User SEBASTIAN Test the Realm
At this stage, userSEBASTIAN
can test the realm by trying to query theHR.EMPLOYEES
table. - Step 5: Create an Authorization for the Realm
Next, userSEBASTIAN
must be granted authorization to the HR Apps realm, so that he can access theHR.EMPLOYEES
table. - Step 6: Test the Realm
To test the realm, you must try to access theEMPLOYEES
table as a user other thanHR
. - Step 7: If Unified Auditing Is Not Enabled, Then Run a Report
Because you enabled auditing on failure for the HR Apps realm, you can generate a report to find any security violations. - Step 8: Remove the Components for This Tutorial
You can remove the components that you created for this tutorial if you no longer need them.
Parent topic: Getting Started with Oracle Database Vault
3.7.1 About This Tutorial
In this tutorial, you create a realm around for the HR
sample database schema by using the Oracle Database Vault PL/SQL packages.
In the HR
schema, the EMPLOYEES
table has information such as salaries that should be hidden from most employees in the company, including those with administrative access. To accomplish this, you add the HR
schema to the secured objects of the protection zone, which in Oracle Database Vault is called a realm, inside the database. Then you grant limited authorizations to this realm. Afterward, you test the realm to make sure it has been properly secured. And finally, to see how Oracle Database Vault provides an audit trail on suspicious activities like the one you will try when you test the realm, you will run a report.
Parent topic: Quick Start Tutorial: Securing a Schema from DBA Access
3.7.2 Step 1: Log On as SYSTEM to Access the HR Schema
You must enable the HR
schema for this tutorial.
HR
sample schema is installed. Oracle Database Sample Schemas describes how to install the sample schemas.
Parent topic: Quick Start Tutorial: Securing a Schema from DBA Access
3.7.3 Step 2: Create a Realm
Realms can protect one or more schemas, individual schema objects, and database roles.
HR
schema.
At this stage, you have created the realm but you have not assigned any authorizations to it. You will take care of that later on in this tutorial.
Parent topic: Quick Start Tutorial: Securing a Schema from DBA Access
3.7.4 Step 3: Create the SEBASTIAN User Account
At this stage, there are no database accounts or roles authorized to access or otherwise manipulate the database objects the realm will protect.
So, the next step is to authorize database accounts or database roles so that they can have access to the schemas within the realm. You will create the SEBASTIAN
user account.
Do not exit SQL*Plus; you will need it for Step 6: Test the Realm, when you test the realm.
Parent topic: Quick Start Tutorial: Securing a Schema from DBA Access
3.7.5 Step 4: Have User SEBASTIAN Test the Realm
At this stage, user SEBASTIAN
can test the realm by trying to query the HR.EMPLOYEES
table.
SEBASTIAN
has the READ ANY TABLE
system privilege, he cannot query the HR.EMPLOYEES
table, because the HR Apps realm takes precedence over the READ ANY TABLE
system privilege.
Parent topic: Quick Start Tutorial: Securing a Schema from DBA Access
3.7.6 Step 5: Create an Authorization for the Realm
Next, user SEBASTIAN
must be granted authorization to the HR Apps realm, so that he can access the HR.EMPLOYEES
table.
SEBASTIAN
to use the READ ANY TABLE
system privilege on the HR.EMPLOYEES
table that is protected by this realm.
Parent topic: Quick Start Tutorial: Securing a Schema from DBA Access
3.7.7 Step 6: Test the Realm
To test the realm, you must try to access the EMPLOYEES
table as a user other than HR
.
SYSTEM
account normally has access to all objects in the HR
schema because it has the SELECT ANY TABLE
privilege, but now that you have safeguarded the EMPLOYEES
table with Oracle Database Vault, this is no longer the case.
Parent topic: Quick Start Tutorial: Securing a Schema from DBA Access
3.7.8 Step 7: If Unified Auditing Is Not Enabled, Then Run a Report
Because you enabled auditing on failure for the HR Apps realm, you can generate a report to find any security violations.
For example, you could generate a report for the violation that you attempted in Step 6: Test the Realm.
Oracle Database Vault generates a report listing the type of violation (in this case, the SELECT
statement entered in the previous section), when and where it occurred, the login account who tried the violation, and what the violation was.
Parent topic: Quick Start Tutorial: Securing a Schema from DBA Access
3.7.9 Step 8: Remove the Components for This Tutorial
You can remove the components that you created for this tutorial if you no longer need them.
-
Drop user
SEBASTIAN
.In SQL*Plus, log on as the Oracle Database Vault account manager (for example,
accts_admin_ace
) and then dropSEBASTIAN
as follows:sqlplus accts_admin_ace -- Or, CONNECT bea_dvacctmgr@hrpdb Enter password: password DROP USER SEBASTIAN;
-
Delete the HR Apps realm.
-
In Cloud Control, ensure that you are logged in as a user who has the
DV_OWNER
role. -
In the Database Vault Home page, click Administration.
-
In the Realms page, select
HR Apps
from the list of realms. -
Click Delete, and in the Confirmation window, click Yes.
-
-
If necessary, in SQL*Plus, lock and expire the
HR
account.- Connect as a user who has the
DV_ACCTMGR
role (for example, useraccts_admin_ace
). - Execute the following
ALTER USER
statement:ALTER USER HR ACCOUNT LOCK PASSWORD EXPIRE;
- Connect as a user who has the
Parent topic: Quick Start Tutorial: Securing a Schema from DBA Access