Implementação da feature de segurança Oracle Database Vault em Oracle 12c

Por Adriano Alves Bonacin
Postado em Abril 2016

Revisado por Marcelo Pivovar - Solution Architect

Este artigo visa ser um primeiro passo na implementação da feature de segurança Oracle Database Vault em Oracle 12c, assim como as principais mudanças por ele provocadas no dia a dia do DBA.

INTRODUÇÃO
Vamos falar um pouco sobre um componente de segurança do Oracle chamado Oracle Database Vault (ODV) e como ele influencia as tarefas rotineiras de um DBA.

O Database Vault é uma feature que visa principalmente retirar "todo o poder" de um DBA e demais usuários "super" privilegiados e entregar para outras mãos as questões relacionadas a segurança do banco de dados. Obviamente que isso não nos cheira bem, a princípio, mas com o tempo vamos entendendo e concordando que realmente tem uma grande utilidade e eficácia. Imagine o quão trágico pode ser o vazamento de uma conta do usuário SYS ou SYSTEM.

É difícil encontrar, atualmente, quem nunca tenha feito uma compra pela internet (pelo menos entre seus amigos). Em algum lugar no meio de um storage possivelmente estarão todos seus dados pessoais, bancários, de cartão de crédito e as vezes muito mais do que imaginamos. Também não é raro encontrar pessoas que tiveram o cartão de crédito extraviado. E, infelizmente, com apenas uma porção de números qualquer pessoa pode fazer compras por aí e deixar conosco a conta.

Uma dúvida já deve ter vindo a mente de muita gente: o quão seguro estão estes dados? Quantos desenvolvedores/analistas/DBAs podem consultá-los diretamente no banco de dados?

Perceba que o ponto onde quero chegar é que nem sempre as coisas “erradas” são feitas de má fé. O PC de um usuário com muitos privilégios pode ser invadido e, sem seu dono saber, lá se vão um punhado destas informações para destino não muito agradável.

Há uma preocupação internacional especificamente com as informações de cartão de crédito e alguns padrões são sugeridos (às vezes exigidos) pelo PCI Security Standards Council (https://www.pcisecuritystandards.org). Entre os pontos em destaque, estão a criptografia dos dados, máscara, permissão de acesso, entre outras.

Com o aumento das normatizações, a tecnologia avança e ajuda a nos proteger. Neste artigo busca-se mostrar, no bom e velho SQL*Plus, como implementar algumas políticas de segurança relacionadas ao ODV. Abordaremos também, algumas das principais mudanças no desempenhar das atividades do DBA.

A bagunça entre português e o inglês será um pouco comum aqui, o objetivo é não traduzir alguns termos técnicos bastante difundidos. Eu prefiro assim desde a primeira vez que me perguntei o que é um "Espaco de Tabela".

Em [1] há uma boa contextualização (em português) para o caso de interesse em um pouco mais além de instruções de como proceder com a instalação no Oracle 11g.

Neste artigo abordaremos superficialmente algumas features que o Database Vault nos disponibiliza e para isso, usaremos uma instalação default do Oracle 12c Enterprise Edition. Nos próximos artigos detalharemos features como Realm, Ruleset, entre outras.

INSTALAÇÃO E CONFIGUÇÃO
No Oracle 12c, o Oracle Label Security (OLS) (pre-req para o Oracle Database Vault) e o Oracle Database Vault vem instalado por default. Instalados, mas não configurados.

Começaremos por aí e, para ilustrar, utilizaremos o procedimento para habilitar o Vault e posteriormente como é possível desabilitá-lo.

Utilizamos:

SYS@cdb1> select version from v$instance;

VERSION
-----------------
12.1.0.2.0

Após a instalação default, entre outras coisas teremos:

SYS@cdb1> col version for a12
SYS@cdb1> col comp_name for a30
SYS@cdb1> select COMP_NAME, VERSION, STATUS from dba_registry 
          where COMP_NAME in ('Oracle Database Vault','Oracle Label Security');

COMP_NAME                      VERSION      STATUS
------------------------------ ------------ -----------
Oracle Database Vault          12.1.0.2.0   VALID
Oracle Label Security          12.1.0.2.0   VALID

E também podemos notar que já existem diversas roles que falaremos a seguir[2].

SYS@cdb1> col role for a25

SYS@cdb1> select ROLE, COMMON from dba_roles where role like 'DV%';

ROLE                       COM
-------------------------- ---
DV_ACCTMGR                 YES
DV_ADMIN                   YES
DV_OWNER                   YES
DV_SECANALYST              YES

... e várias outras

Para verificar se o DB Vault está habilitado, basta consultar se a option está com valor TRUE. Porém, em um ambiente multitenant, você deve estar atento também com o escopo em que o ODV e o OLS serão habilitados/configurados, já que podem ser utilizados a nível de CDB ou PDB. Aqui criaremos no contêiner root, mas geralmente aplicar tais regras aqui não fazem muito sentido (quando permitidas). Posteriormente habilitaremos em um PDB e analisaremos algumas mudanças nos procedimentos que os DBAs estão acostumados.

SYS@cdb1> SELECT VALUE FROM V$OPTION WHERE PARAMETER = 'Oracle Database Vault';

VALUE
---------------
FALSE

Assim, comecemos pelo procedimento para habilitá-lo e, a partir dos erros, seguiremos pelos passos necessários para a configuração. Criamos um usuário e concedemos o maior privilégio do Vault, DV_OWNER [2], que é necessário para Enable/Disable.

SYS@cdb1> create user C##DBV_OWNER identified by oracle;
User created.

SYS@cdb1> grant create session, dv_owner to C##DBV_OWNER;
Grant succeeded.

SYS@cdb1> conn C##DBV_OWNER/oracle
Connected.

C##DBV_OWNER@cdb1> EXEC DBMS_MACADM.ENABLE_DV;
BEGIN DBMS_MACADM.ENABLE_DV; END;
*
ERROR at line 1:

ORA-12459: Oracle Label Security not configured 
ORA-06512: at "LBACSYS.OLS_ENFORCEMENT", line 3
ORA-06512: at "LBACSYS.OLS_ENFORCEMENT", line 25
ORA-06512: at "DVSYS.DBMS_MACADM", line 2068
ORA-06512: at line 1

Primeiro problema encontrado: o Oracle Label Security não está configurado. Também podemos consultar a view v$option para ver que o VALUE está FALSE.

SYS@cdb1> SELECT VALUE FROM V$OPTION WHERE PARAMETER = 'Oracle Label Security';

VALUE
-----------
FALSE

Vale chamar a atenção que há uma outra view que trata especificamente dos componentes do OLS:

SYS@cdb1> select NAME, STATUS, DESCRIPTION from dba_ols_status;

NAME                 STATUS DESCRIPTION
-------------------- ------ -------------------------------------
OLS_CONFIGURE_STATUS FALSE  Determines if OLS is configured
OLS_DIRECTORY_STATUS FALSE  Determines if OID is enabled with OLS
OLS_ENABLE_STATUS    FALSE  Determines if OLS is enabled

Nela podemos notar que o OLS não está configurado, muito menos habilitado. Para configurar e habilitar o OLS é necessário restart da base e precisamos, com o SYS, executar os seguintes procedimentos [3]:

SYS@cdb1> EXEC LBACSYS.CONFIGURE_OLS;
PL/SQL procedure successfully completed.

SYS@cdb1> EXEC LBACSYS.OLS_ENFORCEMENT.ENABLE_OLS;
PL/SQL procedure successfully completed.

SYS@cdb1> shutdown immediate;
SYS@cdb1> startup;

Checando novamente os status, podemos ver que agora o OLS está configurado e habilitado.

SYS@cdb1> set lines 200
SYS@cdb1> set pages 200
SYS@cdb1> select NAME, STATUS, DESCRIPTION from dba_ols_status;

NAME                  STATUS  DESCRIPTION
--------------------  ------  -------------------------------------
OLS_CONFIGURE_STATUS  TRUE    Determines if OLS is configured
OLS_DIRECTORY_STATUS  FALSE   Determines if OID is enabled with OLS
OLS_ENABLE_STATUS     TRUE    Determines if OLS is enabled

O LBACSYS é o master user do OLS e uma boa prática é deixá-lo como backup (com a senha em local seguro) e apenas conceder a role LBAC_DBA para os usuários DBAs que atuarão neste componente. Ele vem lockado e expirado.

SYS@cdb1> create user C##LBAC identified by oracle;
User created.

SYS@cdb1> grant LBAC_DBA to C##LBAC;
Grant succeeded. 

Agora podemos verificar que o status do OLS mudou. Porém, o ODV segue na mesma.

SYS@cdb1> SELECT VALUE FROM V$OPTION WHERE PARAMETER = 'Oracle Label Security';

VALUE
----------
TRUE

SYS@cdb1> SELECT VALUE FROM V$OPTION WHERE PARAMETER = 'Oracle Database Vault';

VALUE
----------
FALSE

Ao tentar habilitar o ODV, temos novamente um problema. Agora nos informa que o ODV ainda não está configurado.

SYS@cdb1> EXEC DBMS_MACADM.ENABLE_DV;
BEGIN DBMS_MACADM.ENABLE_DV; END;
*
ERROR at line 1:

ORA-47502: Database Vault is not yet configured. 
ORA-06512: at "DVSYS.DBMS_MACADM", line 2059
ORA-06512: at "DVSYS.DBMS_MACADM", line 2069
ORA-06512: at line 1 

Para configurá-lo precisamos de um master user (C##DBV_OWNER, já criado) – que possuirá a role DV_OWNER e, opcionalmente, um que atue como account manager (C##DBV_MANAGER) – que possuirá a role DV_ACCTMGR. Eles devem ser criados antes da operação de configuração. Como SYS, crie o usuário e execute o procedimento informando-os.

SYS@cdb1> create user C##DBV_MANAGER identified by oracle;
User created.

SYS@cdb1> BEGIN
2  DVSYS.CONFIGURE_DV (
3    dvowner_uname         => 'C##DBV_OWNER',
4    dvacctmgr_uname       => 'C##DBV_MANAGER');
5  END;
6  /

PL/SQL procedure successfully completed.

Neste ponto, é possível notar no alert algumas mudanças relativas à segurança:

Tue Mar 22 23:19:47 2016
ALTER SYSTEM SET audit_sys_operations=TRUE SCOPE=SPFILE;

Tue Mar 22 23:19:47 2016
ALTER SYSTEM SET os_roles=FALSE SCOPE=SPFILE;

Tue Mar 22 23:19:47 2016
ALTER SYSTEM SET recyclebin='OFF' SCOPE=SPFILE;

Tue Mar 22 23:19:47 2016
ALTER SYSTEM SET remote_login_passwordfile='EXCLUSIVE' SCOPE=SPFILE;

Tue Mar 22 23:19:47 2016
ALTER SYSTEM SET sql92_security=TRUE SCOPE=SPFILE;
 

Agora basta executar utlrp.sql para recompilar os objetos que eventualmente tenham ficados inválidos.

SYS@cdb1> @?/rdbms/admin/utlrp.sql

Aqui o ODV está configurado, mas não habilitado. Habilitar ou desabilitar, precisa ser feito com algum usuário com privilégio de DV_OWNER. Vamos aqui deixar os users C##DBV_OWNER e C##DBV_MANAGER como backup e vamos criarmos usuários para administração, concedendo apenas os privilégios DV_OWNER e DV_ACCTMGR.

SYS@cdb1> create user C##DONO identified by oracle;
User created.

SYS@cdb1> create user C##CONTAS identified by oracle;
User created.

SYS@cdb1> grant create session, DV_OWNER to C##DONO container=ALL; 
Grant succeeded.

SYS@cdb1> grant create session, DV_ACCTMGR to C##CONTAS container=ALL;
Grant succeeded.

E com o C##DONO, vamos habilitar o ODV.

SYS@cdb1> conn C##DONO/oracle
Connected.
C##DONO@cdb1> EXEC DBMS_MACADM.ENABLE_DV;

PL/SQL procedure successfully completed.

No alert vemos:

Tue Mar 22 23:37:56 2016
Database Vault is enabled.

Agora, para que as alterações tenham efeito, vamos restartar a base. Após aberta, basta consultar novamente a option.

SYS@cdb1> shutdown immediate;
SYS@cdb1> startup;
Database opened.

SYS@cdb1> SELECT VALUE FROM V$OPTION WHERE PARAMETER = 'Oracle Database Vault';

VALUE
----------
TRUE

Voltando a discussão a respeito do escopo em que o Vault é aplicado, note que fizemos a alteração no CBD e com isso, o PDB segue sem o ODV desabilitado. Veja:

SYS@pdb1>  SELECT VALUE FROM V$OPTION WHERE PARAMETER = 'Oracle Database Vault';

VALUE
---------------
FALSE

SYS@cdb1>  SELECT VALUE FROM V$OPTION WHERE PARAMETER = 'Oracle Database Vault';

VALUE
---------------
TRUE

Ou seja, todos os passos anteriores devem ser refeitos a nível do PDB (ou mesmo ser feito exclusivamente nele) que deseja proteger. Basta repetir os passos anteriores, restartar o PDB e o ODV estará habilitado.

SYS@pdb1> EXEC LBACSYS.CONFIGURE_OLS;
PL/SQL procedure successfully completed.

Se for feito diretamente no PDB, será necessário restart da base. Basta sempre consultar o VALUE da option.

SYS@pdb1> EXEC LBACSYS.OLS_ENFORCEMENT.ENABLE_OLS;
PL/SQL procedure successfully completed.
SYS@pdb1> BEGIN
DVSYS.CONFIGURE_DV (
dvowner_uname         => 'C##DBV_OWNER',
dvacctmgr_uname       => 'C##DBV_MANAGER');
END;
/  
PL/SQL procedure successfully completed.

C##DBV_OWNER@pdb1> EXEC DBMS_MACADM.ENABLE_DV;

PL/SQL procedure successfully completed.

SYS@pdb1> shutdown immediate;
Pluggable Database closed.

SYS@pdb1> startup
Pluggable Database opened.

SYS@pdb1> SELECT VALUE FROM V$OPTION WHERE PARAMETER = 'Oracle Database Vault';

VALUE
---------
TRUE

O QUE MUDA?
Após checar os status, basta descobrir o que “parou de funcionar” (e olha que a coleção é grande). Um dos pontos principais, como já discutido, é a segregação de tarefas entre os users. Agora, alguns pontos relativos à segurança saem da alçada do DBA e vão para baixo dos users recém criados para o Database Vault. Se preferir, eles podem ficar sob custódia do time de segurança.

Antes, em um procedimento amplamente conhecido e que viola boas práticas de segurança, um DBA poderia alterar a senha de qualquer usuário do DB, fazer uso desta conta e depois voltar para senha original desde que ele tenha o valor antigo na sys.user$.spare4[4]. E agora, é possível?

Vamos tentar alterar a senha de um usuário:

SYS@pdb1> select USERNAME, ACCOUNT_STATUS, COMMON from dba_users where username = 'SCOTT';

USERNAME     ACCOUNT_STATUS                   COM
------------ -------------------------------- ---
SCOTT        EXPIRED & LOCKED                 NO

SYS@pdb1> alter user scott identified by tiger;
alter user scott identified by tiger
*
ERROR at line 1:
ORA-01031: insufficient privileges 
 

Como é possível o SYS não poder alterar a senha de um usuário? Pois é, o SYS teve alguns privilégios “removidos”. Destaco o “removidos” devido ao fato de ele ainda possuir o privilégio em todos os containers:

SYS@cdb1> select * from dba_sys_privs where grantee = 'SYS' and privilege like '%USER%';

GRANTEE      PRIVILEGE       ADM COM
------------ --------------- --- ---
SYS          DROP USER       NO  YES
SYS          CREATE USER     NO  YES
SYS          ALTER USER      NO  YES
SYS          BECOME USER     NO  YES

E o privilégio de criação, também foi removido? Também!

SYS@cdb1> create user C##USUARIO identified by oracle;
create user C##USUARIO identified by oracle
*
ERROR at line 1:
ORA-01031: insufficient privileges

A partir de agora, os users que gerenciam contas (users, profiles) são aqueles que possuem a role DV_ACCTMGR. Apenas eles poderão criar novos users, alterar senha, profiles. Veja só:

C##CONTAS@pdb1> alter user scott identified by tiger account unlock;
User altered.
C##CONTAS@cdb1> create user C##USUARIO identified by oracle;
User created.

Mas as coisas novas não param por aí. Power users do ODV não podem ter suas senhas alteradas a menos que sejam por eles mesmos. Por exemplo, C##DBV_OWNER não pode alterar a senha do C##DBV_MANAGER e vice-versa e o SYS não altera de ninguém. Neste ponto é importante um pouco mais de atenção e a explicação será dada no momento de desabilitar o ODV.

SYS@cdb1> alter user C##DBV_OWNER identified by oracle;
alter user C##DBV_OWNER identified by oracle
*
ERROR at line 1:
ORA-01031: insufficient privileges

SYS@cdb1> alter user C##DBV_MANAGER identified by oracle;
alter user C##DBV_MANAGER identified by oracle
*
ERROR at line 1:
ORA-01031: insufficient privileges

SYS@cdb1> conn C##DBV_MANAGER/oracle
Connected.
C##DBV_MANAGER@cdb1> alter user C##DBV_OWNER identified by oracle2;
alter user C##DBV_OWNER identified by oracle
*
ERROR at line 1:
ORA-01031: insufficient privileges

C##DBV_MANAGER@cdb1> alter user C##DBV_MANAGER identified by oracle;
User altered.

C##DBV_MANAGER@cdb1> conn C##DBV_OWNER/oracle
Connected.
C##DBV_OWNER@cdb1> alter user C##DBV_MANAGER identified by oracle;
alter user C##DBV_MANAGER identified by oracle
*
ERROR at line 1:
ORA-01031: insufficient privileges

C##DBV_OWNER@cdb1> alter user C##DBV_OWNER identified by oracle;
User altered.

Incomodado com isso, você pode pensar: vou fazer um export, levar os dados para outro DB e lá faço o que eu quiser. Ok, vamos tentar.

[oracle@host ~]$ expdp system@pdb1 directory=MYDIR full=y DUMPFILE=full.dmp LOGFILE=expdp_full.log

Export: Release 12.1.0.2.0 - Production on Wed Mar 23 12:14:34 2016

Copyright (c) 1982, 2014, Oracle and/or its affiliates.  All rights reserved.

Password:

Connected to: Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production

With the Partitioning, Automatic Storage Management, Oracle Label Security, OLAP,

Advanced Analytics, Oracle Database Vault and Real Application Testing options

Starting "SYSTEM"."SYS_EXPORT_FULL_01":  system/********@pdb1 directory=MYDIR 
full=y DUMPFILE=full.dmp LOGFILE=expdp_full.log

ORA-39327: Oracle Database Vault data is being stored unencrypted in dump file set.

Estimate in progress using BLOCKS method...

Processing object type DATABASE_EXPORT/EARLY_OPTIONS/VIEWS_AS_TABLES/TABLE_DATA

Processing object type DATABASE_EXPORT/NORMAL_OPTIONS/TABLE_DATA

Processing object type DATABASE_EXPORT/NORMAL_OPTIONS/VIEWS_AS_TABLES/TABLE_DATA

Processing object type DATABASE_EXPORT/SCHEMA/TABLE/TABLE_DATA

Total estimation using BLOCKS method: 305.2 MB

Processing object type DATABASE_EXPORT/PRE_SYSTEM_IMPCALLOUT/MARKER

Processing object type DATABASE_EXPORT/PRE_INSTANCE_IMPCALLOUT/MARKER

ORA-39126: Worker unexpected fatal error in KUPW$WORKER.FETCH_XML_OBJECTS [MARKER]

ORA-01031: insufficient privileges 

ORA-06512: at "SYS.DBMS_SYS_ERROR", line 95

ORA-06512: at "SYS.KUPW$WORKER", line 11259

O ODV também impede expdp full do banco de dados, mas você pode fazer export de apenas um schema caso ele não esteja protegido por Realm (falaremos detalhadamente em um próximo artigo):

[oracle@host ~]$ expdp system@pdb1 directory=MYDIR schemas=SCOTT 
dumpfile=scott.dmp logfile=expdp_scott_01.log

Export: Release 12.1.0.2.0 - Production on Mon Mar 28 12:04:40 2016

Copyright (c) 1982, 2014, Oracle and/or its affiliates.  All rights reserved.
Password:

Connected to: Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, Automatic Storage Management, Oracle Label Security, OLAP,
Advanced Analytics, Oracle Database Vault and Real Application Testing options
Starting "SYSTEM"."SYS_EXPORT_SCHEMA_01":  system/********@pdb1 directory=MYDIR 
schemas=SCOTT DUMPFILE=scott.dmp LOGFILE=expdp_scott_01.log
ORA-39327: Oracle Database Vault data is being stored unencrypted in dump file set.
Estimate in progress using BLOCKS method...
Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA
Total estimation using BLOCKS method: 192 KB
...
Processing object type SCHEMA_EXPORT/POST_SCHEMA/PROCACT_SCHEMA
. . exported "SCOTT"."DEPT"                              6.031 KB       4 rows
. . exported "SCOTT"."EMP"                               8.781 KB      14 rows
. . exported "SCOTT"."SALGRADE"                          5.960 KB       5 rows
. . exported "SCOTT"."BONUS"                                 0 KB       0 rows
Master table "SYSTEM"."SYS_EXPORT_SCHEMA_01" successfully loaded/unloaded
******************************************************************************
Dump file set for SYSTEM.SYS_EXPORT_SCHEMA_01 is:
/u01/dpump/scott.dmp
Job "SYSTEM"."SYS_EXPORT_SCHEMA_01" completed with 1 error(s) at Mon Mar 28 12:05:11 2016 elapsed 0 00:00:29

Embora ele alerte que o dumpfile não está criptografado, o procedimento é concluído com sucesso. Basta realizar o impdp e temos o user em outro DB.

[oracle@prod ~]$ impdp system@prod1  directory=MYDIR schemas=SCOTT remap_schema=SCOTT:SCOTT_VAULT 
DUMPFILE=scott.dmp LOGFILE=impdp_scott_01.log

Import: Release 12.1.0.2.0 - Production on Mon Mar 28 12:12:30 2016

Copyright (c) 1982, 2014, Oracle and/or its affiliates.  All rights reserved.
Password:

Connected to: Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, Automatic Storage Management, OLAP, Advanced Analytics
and Real Application Testing options
Master table "SYSTEM"."SYS_IMPORT_SCHEMA_01" successfully loaded/unloaded
Starting "SYSTEM"."SYS_IMPORT_SCHEMA_01":  system/******** directory=MYDIR schemas=SCOTT 
remap_schema=SCOTT:SCOTT_VAULT DUMPFILE=scott.dmp LOGFILE=impdp_scott_01.log
Processing object type SCHEMA_EXPORT/USER
Processing object type SCHEMA_EXPORT/SYSTEM_GRANT
...
Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA
. . imported "SCOTT_VAULT"."DEPT"                        6.031 KB       4 rows
. . imported "SCOTT_VAULT"."EMP"                         8.781 KB      14 rows
. . imported "SCOTT_VAULT"."SALGRADE"                    5.960 KB       5 rows
. . imported "SCOTT_VAULT"."BONUS"                           0 KB       0 rows
Processing object type SCHEMA_EXPORT/TABLE/INDEX/INDEX
...
Processing object type SCHEMA_EXPORT/POST_SCHEMA/PROCACT_SCHEMA
Job "SYSTEM"."SYS_IMPORT_SCHEMA_01" successfully completed at Mon Mar 28 12:12:59 2016 elapsed 0 00:00:22

Por sorte, nada mudou nos backups com RMAN. Você continua fazendo backup e restore/recover como sempre fez. A ideia é que a administração do banco de dados, do ponto de vista físico (datafiles, controlfile... ), continue exatamente igual e apenas tarefas que comprometam a segurança dos dados sejam protegidas.

Porém, nem tudo são flores. Há mudanças que interferem no dia a dia do DBA. Por exemplo:

- Alterar o db_recovery_file_dest,

SYS@cdb1> alter system set db_recovery_file_dest='+DATA';
alter system set db_recovery_file_dest='+DATA'
*
ERROR at line 1:
ORA-01031: insufficient privileges

- Alterar o destino de criação de redo onlines,

SYS@cdb1> alter system set db_create_online_log_dest_1='+DATA';
alter system set db_create_online_log_dest_1='+DATA'
*
ERROR at line 1:
ORA-01031: insufficient privileges

- Alterar o destino dos audit files já precisa de disposição,

SYS@cdb1> alter system set audit_file_dest='/u01' scope=spfile;
alter system set audit_file_dest='/u01' scope=spfile
*
ERROR at line 1:
ORA-01031: insufficient privileges

- Recyclebin então, nem pensar:

SYS@cdb1> alter system set recyclebin=on scope=spfile;
alter system set recyclebin=on scope=spfile
*
ERROR at line 1:
ORA-01031: insufficient privileges 

Em [5] há detalhadamente as operações que sofreram alteração. A tabela abaixo foi retirada de [6] e é um resumo:

HABILITAR E DESABILITAR
Caso seja necessário desabilitar o ODV por algum motivo, ele só pode ser feito com users que possuam privilégios DV_OWNER e o DB precisa necessariamente ser reiniciado [7]. É de extrema importância esta observação, pois a perda da senha da conta C##DBV_ONWER (no caso deste artigo) e todos os outros que possuam DV_OWNER impede que o ODV seja desabilitado. Portando, considere guardar esta senha em local seguro e utilizar outros users com tais privilégios.

Os passos são os seguintes, com algum master user:

C##DONO@pdb1> SELECT VALUE FROM V$OPTION WHERE PARAMETER = 'Oracle Database Vault';

VALUE
-------------
TRUE

C##DONO@pdb1> EXEC DBMS_MACADM.DISABLE_DV;

PL/SQL procedure successfully completed.

E em seguida, com o SYS, restart do DB.

SQL> conn sys/oracle@pdb1 as sysdba
Connected.

SYS@pdb1> shutdown immediate;
Pluggable Database closed.

SYS@pdb1> startup;
Pluggable Database opened.

SYS@pdb1> SELECT VALUE FROM V$OPTION WHERE PARAMETER = 'Oracle Database Vault';

VALUE
------------
FALSE

O procedimento para habilitar, como já discutido, é análogo, porém utilizando o DBMS_MACADM.ENABLE_DV e também exige o restart.

SQL> conn C##DONO/oracle@pdb1
Connected.

C##DONO@pdb1> SELECT VALUE FROM V$OPTION WHERE PARAMETER = 'Oracle Database Vault';

VALUE
---------------
FALSE

C##DONO@pdb1> EXEC DBMS_MACADM.ENABLE_DV;
 PL/SQL procedure successfully completed.

SQL> conn sys/oracle@pdb1 as sysdba
Connected.

SYS@pdb1> shutdown immediate;
Pluggable Database closed.

SYS@pdb1> startup;
Pluggable Database opened.

SYS@pdb1> SELECT VALUE FROM V$OPTION WHERE PARAMETER = 'Oracle Database Vault';

VALUE
-------------
TRUE

CONCLUSÃO
Vimos como realizar os primeiros passos com o ODV, como habilitá-lo e desabilitá-lo e algumas das principais mudanças provocadas no dia a dia do DBA. O próximo passo será descrever como aproveitaremos os pontos fortes que ele disponibiliza e então poderemos entender as configurações default e como podemos barrar privilégios mesmo tendo privilégios (caso do SYS que possui o privilégio de sistema ALTER ANY USER). 

REFERENCIAS
[1] http://www.oracle.com/technetwork/pt/articles/idm/proteger-database-com-oracle-vault-2390952-ptb.html
[2] https://docs.oracle.com/database/121/DVADM/db_objects.htm
[3] https://docs.oracle.com/database/121/OLSAG/getting_started.htm
[4] http://www.dba-oracle.com/t_spare4.htm
[5] https://docs.oracle.com/database/121/DVADM/dba.htm
[6] http://www.oracle.com/technetwork/database/security/twp-databasevault-dba-bestpractices-199882.pdf
[7] https://docs.oracle.com/database/121/DVADM/dvdisabl.htm

Adriano Bonacin, graduado e mestre em física, é especialista em banco de dados Oracle com foco em alta disponibilidade (RAC, Dataguard, GoldenGate, etc), segurança (ODV, TDE, etc), Tuning, Backup & Recovery e administração em geral. Possui certificações OCP DBA e OCP PL/SQL.

Este artigo foi revisto pela equipe de produtos Oracle e está em conformidade com as normas e práticas para o uso de produtos Oracle.