No Oracle 26ai foi introduzido um novo nível de privilégios, os privilégios de schema, que permitem que certos privilégios de sistema sejam concedidos a um usuário para um schema específico. Essa nova implementação facilita o gerenciamento de privilégios, pois não existe a necessidade de concessão de privilégios para cada novo objeto criado no schema, uma vez que os privilégios de schema servem para os objetos atuais e futuros desse schema.
Por exemplo, para permitir que um usuário ou role tenha a permissão de consulta e criação de índices em qualquer tabela do schema HR, usaríamos:
GRANT SELECT ANY TABLE, CREATE ANY INDEX ON SCHEMA hr TO my_user;
As informações sobre os privilégios de schema podem ser consultados nas views *_SCHEMA_PRIVS:
SQL> SET LINES WINDOW SQL> COL SCHEMA FOR A10 SQL> SELECT PRIVILEGE, SCHEMA FROM DBA_SCHEMA_PRIVS WHERE GRANTEE='MY_USER'; PRIVILEGE SCHEMA ---------------------------------------- ---------- CREATE ANY INDEX HR SELECT ANY TABLE HR
Por si só, os privilégios de schema já são uma implementação que resolve o problema das releases anteriores, de que a cada adição de objetos precisamos adicionar os grants necessários aos usuários dependentes. Entretanto, pensando em um usuário dentro do banco de dados, que adminstra o schema, executando DDLs em atualizações, através de Schema Migration Tools (como o Flyway e o Liquibase), podemos necessitar que esses privilégios só sejam concedidos em condições específicas. Por exemplo: digamos que por algum motivo o desenvolvedor tenha a senha desse usuário que administra o schema, mas que por regras da companhia, as modificações nesse schema só podem ser feitas via migration. Caso esses privilégios sejam concedidos diretamente ao usuário ou através de uma role comum, o desenvolvedor teria o mesmo nível de acesso do migration e poderia executar alterações manualmente, aumentando o risco operacional de quebrar algo no processo.
Mas então, como podemos fazer o uso de privilégios de schema com um condicionamento? A resposta é: usando Secure Application Roles.
Secure Application Roles
As Secure Application Roles são um tipo de role que são habilitadas através de uma procedure, diferente das roles comuns, que podem ser habilitadas com o comando SET ROLE. Para a criação de uma Secure Application Role, uma procedure é apontada na cláusula IDENTIFIED USING do comando CREATE ROLE:
SQL> CREATE ROLE hr_admin IDENTIFIED USING system.admin_role_check; Role created.
Para esse exemplo, usei o schema SYSTEM para armazenar a procedure, mas é possível utilizar qualquer outro schema para este fim. Na sequência, os privilégios de schema são adicionados à role:
SQL> GRANT CREATE ANY TABLE, ALTER ANY TABLE, DROP ANY TABLE, CREATE ANY INDEX, CREATE ANY SEQUENCE ON SCHEMA hr TO hr_admin; Grant succeeded.
E agora, a principal diferença entre a role comum e a Secure Application Role: a definição da procedure utilizada no comando CREATE ROLE:
SQL> CONN system@orclpdb
Enter password:
Connected.
SQL> CREATE OR REPLACE PROCEDURE admin_role_check
AUTHID CURRENT_USER
AS
BEGIN
IF (SYS_CONTEXT ('userenv','session_user') = 'HR_EMPLOYEE_ADMIN'
AND
SYS_CONTEXT ('userenv','ip_address') IN ('192.168.1.148'))
THEN
EXECUTE IMMEDIATE 'SET ROLE hr_admin';
END IF;
END;
/
Procedure created.
Alguns pontos importantes sobre a procedure:
- Precisa setar a propriedade AUTHID para CURRENT_USER, fazendo com que os privilégios sejam resolvidos no contexto do usuário que executa a procedure, e não de quem a criou;
- Precisa incluir uma ou mais validações de segurança, utilizando o SYS_CONTEXT;
- Precisa executar o comando SET ROLE (através do EXECUTE IMMEDIATE) ou o DBMS_SESSION.SET_ROLE, caso o usuário passe nas validações.
No exemplo da procedure criada, a role será habilitada para o usuário apenas se o seu username for “HR_EMPLOYEE_ADMIN” e se o IP do client for 192.168.1.148.
Criada a procedure, é necessário conceder o privilégio de execução dela ao usuário administrador do schema:
SQL> GRANT EXECUTE ON admin_role_check TO hr_employee_admin; Grant succeeded.
Para que o usuário consiga executar ações que dependam de privilégios contidos na Secure Application Role, é necessário executar a procedure antes de executá-las. Sendo assim, se todas as validações contidas na procedure passarem, o usuário terá a role habilitada para a sua sessão:
SQL> CONN hr_employee_admin@orclpdb
Enter password:
Connected.
SQL> CREATE INDEX idx_teste ON hr.employees(first_name, last_name);
CREATE INDEX idx_teste ON hr.employees(first_name, last_name)
*
ERROR at line 1:
ORA-00942: table or view "HR"."EMPLOYEES" does not exist
Help: https://docs.oracle.com/error-help/db/ora-00942/
SQL> EXECUTE system.admin_role_check;
PL/SQL procedure successfully completed.
SQL> CREATE INDEX idx_teste ON hr.employees(first_name, last_name);
Index created.
Em ferramentas de migration, existe a possibilidade de configurar scripts que serão executados assim que a conexão com o banco é obtida, que é onde pode ser adicionada a execução desta procedure.
Algo óbvio, mas que precisa ser dito, é que como esse tipo de role não é concedida diretamente ao usuário através do comando GRANT, uma tentativa de habilitar a role através do comando SET ROLE, diretamente da sessão do usuário, irá falhar com o ORA-01924:
SQL> CONN hr_employee_admin@orclpdb Enter password: Connected. SQL> SET ROLE hr_admin; SET ROLE hr_admin * ERROR at line 1: ORA-01924: Role "HR_ADMIN" not granted or does not exist. Help: https://docs.oracle.com/error-help/db/ora-01924/
Conclusão
A junção dos privilégios de schema com as Secure Application Roles são uma combinação perfeita para cenários onde apenas determinadas origens de conexão podem executar determinadas ações no banco de dados.
Voltando para o exemplo do desenvolvedor com acesso à senha do usuário administrador do schema, mesmo que ele tente realizar alguma alteração, ele estará impossibilitado de fazê-lo, uma vez que seu client não está homologado a acessar a role.