X

Cloud Security Perspectives and Insights

What you need to know about patching 12.1.0.2 multi-tenant databases with Database Vault

All my customer demo databases always have Database Vault configured and enabled, and that fact requires a few extra gymnastics when patching, especially in 12.1.0.2 with root container and PDBs.

If Database Vault is selected during DB installation of a multi-tenant (MTA) database via DBCA (Database Configuration Assistant), you are prompted to create two common users, let's call them C##SEC_ADMIN_OWEN (this user will be the Database Vault 'Owner'), and C##ACCTS_ADMIN_ACE, the DBVault Account Manager; the Oracle Installer will grant the common roles DV_OWNER and DV_ACCT_MNGR to them, but the grant command is executed without the 'CONTAINER = ALL' clause, which means C##SEC_ADMIN_OWEN and C##ACCTS_ADMIN_ACE exist in all present and future PDBs, but their DBVault specific roles are only granted to them in the root container.

First, confirm that Database Vault is correctly setup; run this in the root container and all PDBs:

SQL> select * from dba_ols_status order by 2 desc;
NAME                  STATUS  DESCRIPTION
--------------------- ------- --------------------------------------
OLS_CONFIGURE_STATUS  TRUE    Determines if OLS is configured
OLS_ENABLE_STATUS     TRUE    Determines if OLS is enabled
OLS_DIRECTORY_STATUS  FALSE   Determines if OID is enabled with OLS

Only the OLS_CONFIGURE_STATUS and OLS_ENABLE_STATUS rows need to be TRUE. The fact that OLS policies can be stored in Oracle Internet Directory is irrelevant in the context of DBVault.

SQL> select * from dba_dv_status;
NAME                      STATUS
------------------------- -------
DV_CONFIGURE_STATUS       TRUE
DV_ENABLE_STATUS          TRUE

Most likely you see TRUE in the root container, and FALSE in the PDBs.  If this is the case, execute the following in all PDBs:

SQL> EXEC LBACSYS.CONFIGURE_OLS;
SQL> EXEC LBACSYS.OLS_ENFORCEMENT.ENABLE_OLS;

That turns on Oracle Label Security in so far as it is used by Oracle Database Vault internally.

Confirm with:
SQL> select * from dba_ols_status order by 2 desc;

Then, turn on Database Vault; execute in all PDBs:

SQL> GRANT CREATE SESSION, SET CONTAINER TO C##SEC_ADMIN_ROOT, C##ACCTS_ADMIN_ROOT CONTAINER = CURRENT;
SQL> exec dvsys.configure_dv('C##SEC_ADMIN_ROOT', 'C##ACCTS_ADMIN_ROOT');
SQL> @?/rdbms/admin/utlrp.sql
C##SEC_ADMIN_ROOT> EXEC DBMS_MACADM.ENABLE_DV;

Confirm with:
SQL> select * from dba_dv_status;

For patching, we don't need to turn off, or disable, Database Vault anymore; instead, the DV Owner executes:

C##SEC_ADMIN_OWEN:CDB$ROOT> grant DV_PATCH_ADMIN to SYS container = ALL;

That would allow the changed SQL to be applied to the root container and all open PDBs. But, DV Owner doesn't have the proper privilege as I explained earlier.

To confirm in the root container:

SYS:CDB$ROOT> SELECT granted_role, username FROM USER_ROLE_PRIVS where granted_role like '%PATCH%';
GRANTED_ROLE    USERNAME
--------------- ---------
DV_PATCH_ADMIN  SYS

Confirm in the PDBs:

SYS:FINPDB> SELECT granted_role, username FROM USER_ROLE_PRIVS where granted_role like '%PATCH%';
no rows selected

C##SEC_ADMIN_OWEN:FINPDB> grant DV_PATCH_ADMIN to sys container = current;

You would need to execute that step in all PDBs across the container.  Of course the 'container = current' part of the command is not needed as this is the default when executed in a PDB, I added it here for clarity.

Confirm:
SYS:FINPDB> SELECT granted_role, username FROM USER_ROLE_PRIVS where granted_role like '%PATCH%';
GRANTED_ROLE    USERNAME
--------------- ---------
DV_PATCH_ADMIN  SYS

Voilà, now you can run 'opatchauto' or 'datapatch' and the changed SQL will be applied to root container and all open PDBs.

After successful patching, you would revoke the granted patching privilege from SYS (execute in root container and all PDBs):
C##SEC_ADMIN_OWEN:CDB$ROOT> revoke DV_PATCH_ADMIN from sys container = current;
C##SEC_ADMIN_OWEN:FINPDB> revoke DV_PATCH_ADMIN from sys [container = current];

But there is more ... you want to audit what SYS is doing with that new privilege; is it only used for patching, or will that user do something else while s/he has the extra powers?

Find out with:
C##SEC_ADMIN_OWEN:CDB$ROOT> EXEC DBMS_MACADM.ENABLE_DV_PATCH_ADMIN_AUDIT; in the root container and
C##SEC_ADMIN_OWEN:FINPDB> EXEC DBMS_MACADM.ENABLE_DV_PATCH_ADMIN_AUDIT; in all PDBs.

The audit events are written to dvsys.audit_trail$.

When you are done patching, you can turn auditing off, but I would leave it running for the next patch cycle.

Happy patching,

Peter

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.