Olá, pessoal! No post de hoje irei comentar sobre a diferença entre o Regular Realm e o Mandatory Realm no Oracle Database.
O que é um Realm?
Inicialmente, vale entendermos o que é um Realm e qual a função dele para a otimização da segurança do seu ambiente.
Um realm é semelhante a uma zona de proteção para os objetos do seu banco de dados. Os realms contêm objetos como tabelas, roles e packages. E são um dos principais componentes presentes no Database Vault e sua administração é feita através do usuário com a role DV_OWNER ou DV_ADMIN.
O realm protege os objetos contidos nele contra usuários que estejam exercendo privilégios, como SELECT ANY TABLE e SYSDBA. Portanto, qualquer usuário com tais privilégios deve ser definido como um participante do realm (ou possuir uma role participante do realm que tenha sido concedida a ele) para acessar os objetos protegidos.
Caso um usuário ou uma role já possua privilégios de objeto concedidos diretamente para acessar os objetos protegidos pelo realm, o realm não impedirá esse usuário de realizar consultas, caso seja um Regular Realm. Esses usuários ou roles poderão acessar os objetos da mesma maneira que faziam antes da existência do realm, a não ser que seja um Mandatory Realm, que nesse caso será necessário a adição do usuário como participante ou owner do Realm.
Como funciona a implementação de um Realm
Um Realm pode ser adicionado facilmente em um ambiente que possua o Database Vault, através do usuário com a role DV_OWNER ou DV_ADMIN, o comando é bem simples:
-- Para criar um Regular RealmSQL> CONNECT C##DBV_OWNER/[SENHA OCULTA]Connected.SQL> alter session set container=PDBPROD;Session altered.SQL> select user from dual;USER------------------------------------------------------------C##DBV_OWNERSQL> show con_nameCON_NAME------------------------------PDBPRODSQL> EXEC DVSYS.DBMS_MACADM.CREATE_REALM ( realm_name => 'HR Application', description => 'Realm to protect the HR application', enabled => DBMS_MACUTL.G_YES, audit_options => DBMS_MACUTL.G_REALM_AUDIT_FAIL + DBMS_MACUTL.G_REALM_AUDIT_SUCCESS, realm_type => 0)PL/SQL procedure successfully completed.SQL>
Após criado, já é possível validar a existência do Realm através da consulta abaixo:
SQL> select user from dual;USER------------------------------------------------------------C##DBV_OWNERSQL> show con_nameCON_NAME------------------------------PDBPRODSQL> SELECT name, realm_type, enabled 2 FROM dvsys.dba_dv_realm 3 WHERE name LIKE 'HR%';NAME REALM_TYPE E----------------------------------------------------------- ---------- -HR Application REGULAR YSQL>
Uma observação é que a consulta não funcionaria para o usuário SYS por exemplo, no meu caso, foi obrigatória a utilização do DV_OWNER
SQL> connect / as sysdbaConnected.SQL> alter session set container=PDBPROD;Session altered.SQL> select user from dual;USER------------------------------------------------------------SYSSQL> show con_nameCON_NAME------------------------------PDBPRODSQL> SELECT name, realm_type, enabled 2 FROM dvsys.dba_dv_realm 3 WHERE name LIKE 'HR%';FROM dvsys.dba_dv_realm *ERROR at line 2:ORA-01031: insufficient privilegesSQL>
Com o Realm criado, agora será necessário adicionar novos objetos a ele
SQL> select user from dual;USER------------------------------------------------------------C##DBV_OWNERSQL> show con_name;CON_NAME------------------------------PDBPRODSQL> EXEC DVSYS.DBMS_MACADM.ADD_OBJECT_TO_REALM( realm_name => 'HR Application', object_owner => 'HR', object_name => 'EMPLOYEES', object_type => 'TABLE');PL/SQL procedure successfully completed.SQL>
Agora isso significa que usuários administrativos do banco que não possuem um grant de acesso direto à tabela HR.EMPLOYEES, não conseguirão mais acessar os dados presentes nela, mesmo que o usuário em questão tenha um grant de SELECT ANY TABLE por exemplo
-- Acesso com o SYSTEMSQL> select user from dual;USER------------------------------------------------------------SYSTEMSQL> show con_name;CON_NAME------------------------------PDBPRODSQL> SELECT count(*) FROM hr.employees;SELECT count(*) FROM hr.employees *ERROR at line 1:ORA-01031: insufficient privilegesSQL>-- Acesso com o SYS SQL> show con_nameCON_NAME------------------------------PDBPRODSQL> select user from dual;USER------------------------------------------------------------SYSSQL> SELECT count(*) FROM hr.employees;SELECT count(*) FROM hr.employees *ERROR at line 1:ORA-01031: insufficient privilegesSQL>
Agora, o usuário HR (que é o OWNER do objeto e que possui o grant de select especificamente na tabela EMPLOYEES) conseguirá acessar suas informações
SQL> show con_nameCON_NAME------------------------------PDBPRODSQL> select user from dual;USER------------------------------------------------------------HRSQL> SELECT count(*) FROM hr.employees; COUNT(*)---------- 107SQL>
Porém, isso só é válido pois o Realm é Regular, mas agora e se mudarmos o realm type para um Mandatory Realm?
SQL> select user from dual;USER------------------------------------------------------------C##DBV_OWNERSQL> show con_nameCON_NAME------------------------------PDBPRODSQL> BEGIN 2 DVSYS.DBMS_MACADM.UPDATE_REALM( 3 realm_name => 'HR Application', 4 description => 'Realm to protect the HR application', 5 enabled => DBMS_MACUTL.G_YES, 6 audit_options => DBMS_MACUTL.G_REALM_AUDIT_FAIL + 7 DBMS_MACUTL.G_REALM_AUDIT_SUCCESS, 8 realm_type => 1 9 ); 10 END; 11 /PL/SQL procedure successfully completed.SQL> SELECT name, realm_type, enabled 2 FROM dvsys.dba_dv_realm 3 WHERE name LIKE 'HR%';NAME REALM_TYPE E----------------------------------------------------------- ---------- -HR Application MANDATORY YSQL>
O comando em si é bem parecido com o de criação do realm, o ponto fundamental aqui é o “realm_type => 1”
Agora vamos tentar o SELECT novamente com o usuário HR
SQL> select user from dual;USER------------------------------------------------------------HRSQL> show con_nameCON_NAME------------------------------PDBPRODSQL> SELECT count(*) FROM hr.employees;SELECT count(*) FROM hr.employees *ERROR at line 1:ORA-01031: insufficient privilegesSQL>
Por conta da alteração no tipo de Realm, o usuário HR já não consegue mais acessar as informações da tabela, mesmo sendo Owner dela.
Nesse caso, não teremos escolha a não ser adicionar o usuário HR como Participante do Realm
SQL> select user from dual;USER------------------------------------------------------------C##DBV_OWNERSQL> show con_nameCON_NAME------------------------------PDBPRODSQL> BEGIN 2 DVSYS.DBMS_MACADM.ADD_AUTH_TO_REALM( 3 realm_name => 'HR Application', 4 grantee => 'HR', 5 rule_set_name => NULL, 6 auth_options => DBMS_MACUTL.G_REALM_AUTH_PARTICIPANT 7 ); 8 END; 9 /PL/SQL procedure successfully completed.
Somente após essa autorização, o usuário HR conseguirá o mesmo acesso que ele possuía anteriormente com o Regular Realm
SQL> show con_nameCON_NAME------------------------------PDBPRODSQL> select user from dual;USER------------------------------------------------------------HRSQL> select count(*) from hr.employees; COUNT(*)---------- 107SQL>
Conclusão
Apesar de aumentar bastante o nível de segurança dos objetos pertencentes ao Realm, ainda vejo a escolha de um Mandatory Realm como algo muito específico e que precisa ser validada e bem analisada antes de ser implementada, principalmente em ambientes nos quais as contas da aplicação dependem diretamente do acesso aos objetos protegidos. Para uma implementação de Database Vault comum, vejo o Regular Realm sendo a escolha mais eficaz para a maioria dos casos, pois esta em si já possui um alto nível de proteção.
Iago DBA 