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

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                 STATU 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                 STATU 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:

Administration Task Oracle Database Vault operational controls required?
GENERAL DATABASE ADMINISTRATION TASKS
Starting up and shutting down the database NO
Creating databases NO
Configuring database network connectivity NO
Database cloning NO
Managing database initialization parameters YES
Scheduling database jobs YES
ADMINISTERING DATABASE USERS
Managing users and roles YES
Creating and modifying database objects YES
DATABASE BACKUP AND RECOVERY
Oracle Data Pump YES
Oracle RMAN NO
Oracle SQL*Loader NO
Flashback YES
Managing database storage structures YES
DATABASE REPLICATION
Oracle Data Guard YES
Oracle Streams YES
DATABASE TUNING
DBMS_STATS PL/SQL Package NO
Modifying database instance memory NO
Automatic database diagnostic monitor (ADDM) NO
Active session history (ASH) NO
Automatic workload repository (AWR) NO
SQL Tuning Advisor NO
EXPLAIN PLAN YES
ANALYZE TABLE YES
Maintaining indexes YES
DATABASE PATCHING AND UPGRADE
Performing database patching YES
Performing software upgrade NO
Performing database upgrade YES
ORACLE ENTERPRISE MANAGER
Configuring Oracle Enterprise Manager settings NO
Adding administrators in Oracle Enterprise Manager YES

 

 

 

 

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