DBMS_SQL_FIREWALL - Firewall dentro da Base de Dados (Parte I)

 



O SQL firewall é uma opção que nos permite detectar, bloquear e criar log sobre actividades anormais de SQL e de alguns contextos das sessões. No fundo permite que consigamos detectar e bloquear com mais facilidade actividades suspeitas na nossa base de dados.
Esta opção é introduzida na versão 23c da base de dados Oracle em forma de package (DBMS_SQL_FIREWALL).

Nesta primeira parte de diferentes textos, vou falar sobre como fazer o setup/configuração da SQL Firewall.

Vou começar por criar um novo user que será o administrador do SQL Firewall. Para isso existe um role chamado SQL_FIREWALL_ADMIN que contém todas as permissões necessárias a essa tarefa.
Existe um outro role, SQL_FIREWALL_VIEWER, que permite ter utilizadores mais orientados à auditoria e que terão acesso aos dados gerados pelo firewall para poderem analisar.
        
           
SQL> create user fwalladmin identified by oracle;

SQL> grant create session, sql_firewall_admin to fwalladmin;

Não é obrigatorio a criação deste utilizador, no entanto é uma boa prática fazer desta forma em vez de usar o sys ou o system, facilitando assim uma futura auditoria de actividaddes relacionadas com estas tarefas.

Em seguida teremos de activar o mecanismo de SQL Firewall. Isso é feito através do package DBMS_SQL_FIREWALL, que será usado para todas as actividades relacionadas com esta tecnologia.
O procedimento enable é o que nos permite activar esta opção, existindo o oposto, disable que nos permite a desactivação.
Junto com o package, são disponibilizadas um conjunto de views que nos permitem ter acesso à informação e que nos permitem gerir todo este processo. Para validar o status temos a view dba_sql_firewall_status
        
           
SQL> exec dbms_sql_firewall.enable;

SQL> select * from dba_sql_firewall_status;

STATUS     STATUS_UPDATED_ON                   EXCLUDE_JOBS    
__________ ___________________________________ _______________ 
ENABLED    11-OCT-23 10.30.47.616770000 GMT    Y


Depois da activação teremos de criar uma captura de actividade. Esta captura é feita ao nivel do user e da sua actividade. Ao fazer connect, será capturada a sua activade relacionada com comandos de SQL/PLSQL executados e guardados num log.
A activadde não é relacionada com os seus objectos, mas sim com os comandos de sql que vai executando, serão estes comandos que potencialmente terá permissão de executar depois de configurada toda a estrutura de SQL Firewall.
Teremos assim provavelmente tantas capturas quantos utilizadores diferentes se liguem à BD e queiramos controlar através do SQL Firewall.
        
           
exec dbms_sql_firewall.create_capture(username => 'HR', top_level_only => true, start_capture => false);

SQL> select * from dba_sql_firewall_captures;

USERNAME    TOP_LEVEL_ONLY    STATUS      LAST_STARTED_ON    LAST_STOPPED_ON    
___________ _________________ ___________ __________________ __________________ 
HR          Y                 DISABLED


Neste exemplo usei a procedimento create_capture que vai incidir sobre a actividade do utilizador HR, vai apenas apenas incidir sobre sql de top level, isto é sql executado directamente pelo utilizador, ignorando o SQL executado dentro de PLSQL (Falarei desta opção num outro texto).
O último dos parâmetros permite iniciar de imediato a captura ou não. No meu caso não iniciei para podermos ver o procedimento start_capture que permite iniciar uma captura no momento desejado.
        
           
SQL> exec dbms_sql_firewall.start_capture('HR');

PL/SQL procedure successfully completed.

SQL> select * from dba_sql_firewall_captures;

USERNAME    TOP_LEVEL_ONLY    STATUS     LAST_STARTED_ON                     LAST_STOPPED_ON    
___________ _________________ __________ ___________________________________ __________________ 
HR          Y                 ENABLED    11-OCT-23 11.19.57.512883000 GMT
 
A partir deste momento, qualquer actividade de sessões do utilizador 'HR', actuais ou novas, irão gerar um log de actividade dos comandos de SQL executados.
No próximo texto irei criar alguma actividade e ver todo o mecanismo de firewall a funcionar.



Comentários

Enviar um comentário

Mensagens populares deste blogue

DBMS_SQL_FIREWALL - Firewall dentro da Base de Dados (Parte IV)

Este será o ultimo texto sobre o SQL firewall. Irei ver como impedir um possível ataque de SQL injection através do uso da SQL Firewall Criei uma stored procedure que será usada nos diferentes testes, quer de execução quer de tentativa de SQL Injection e usarei ainda a opção de top_level_only a false para verificar o que é capturado com essa opção. Vou começar por criar um procedimento simples, no schema HR, que executa alguns selects depois de receber um parâmetro de entrada, devolvendo um valor relacionado. O execute immediate do final do procedimento está apenas como exemplo para ser usado com o top_level_only a false e fazer alguns testes.  create or replace procedure empname(lst_name in varchar2) is comando varchar2(2000); type c_ref is ref cursor; c c_ref; ult_nome employees.last_name%type; Begin comando :='select first_name from hr.employees '|| 'where last_nam...
Ler mais

DBMS_SQL_FIREWALL - Firewall dentro da Base de Dados (Parte III)

 No post anterior , vimos a possibilidade de restringir/autorizar a execução de SQL a um utilizador através de listas criadas numa captura de actividade. Durante a captura não são apenas registados os comandos de SQL, mas também outros dados, o endereço de IP a partir do qual o SQL foi executado, o programa a partir do qual foi executado o SQL e ainda o utilizador de sistema operativo que lançou esse programa. Este 3 dados adicionais são parte dos contextos que podem ser usados pela SQL Firewall. Além de restringir a execução de comandos de SQL, é possível limitar a execução através destes contextos, limitar o acesso a partir de um IP ou de um utiliazdor de SO ou até de uma aplicação especifica. Quando analisamos a lista criada durante a captura vemos que já existe essa informação armazenada. Podemos ver isso na view dba_sql_firewall_capture_logs . SQL> select username, command_type, client_program, os_user, ip_address from dba_sql_firewall_capture_logs; US...
Ler mais