Oracle
 sql >> Base de Dados >  >> RDS >> Oracle

Segurança de banco de dados Oracle:auditoria de banco de dados


Neste artigo, continuarei com o Oracle Database Security e apresentarei alguns fatos importantes sobre auditoria de banco de dados padrão, gatilhos de auditoria e políticas de auditoria no Oracle. A auditoria de banco de dados tem dois componentes:monitoramento e registro persistente de conjuntos de atividades e eventos de banco de dados estabelecidos. As finalidades da auditoria de banco de dados são não repúdio, investigação de atividades suspeitas, detecção de problemas gerados por configurações de autorização (acesso a recursos), atendimento à legislação vigente e controle.

Auditoria padrão


Quais atividades auditamos? O início e a parada do banco de dados, bem como as conexões feitas pelo administrador do banco de dados, são auditadas implicitamente pelo Oracle e os dados são armazenados automaticamente no sistema operacional. A tabela abaixo mostra outras atividades que podem ser monitoradas:


Onde mantemos as atividades auditadas?

  • no banco de dados , usando a trilha de auditoria do banco de dados, onde temos duas possibilidades:
    • audit_trail =DB
      que pode ser feito com o seguinte código:
      alter system set audit_trail=db scope=spfile;
    • audit_trail =DB,EXTENDED
      usando o seguinte código:
      alter system set audit_trail= db, extended scope=spfile;

    A diferença entre DB e DB,EXTENDED é que o segundo preenche as colunas SQLBIND e SQLTEXT CLOB da tabela SYS.AUD$.
  • externa , usando a trilha de auditoria do sistema operacional, com as seguintes possibilidades:
    • audit_trail =SO
      e o código usado é:
      alter system set audit_trail=os scope=spfile;
    • audit_trail =XML e AUDIT_FILE_DEST =caminho do arquivo (implicitamente é $ORACLE_BASE/admin/$ORACLE_SID/adump)
      com o código:
      alter system set audit_trail=xml scope=spfile;

Para encontrar a configuração atual das atividades auditadas armazenadas, pode-se executar a seguinte consulta, escrita com letras minúsculas:
select value from v$parameter where name='audit_trail';

Comandos mais úteis:

[ID da tabela=43 /]

Agora vamos ter alguns exemplos de auditoria de banco de dados.

Aqui está um exemplo de uma auditoria padrão com informações auditadas armazenadas no banco de dados:

As informações auditadas consistem nas instruções SELECT executadas nas tabelas do banco de dados.

No SQL Developer, execute o seguinte script:
alter system set audit_trail= db, extended scope=spfile;
AUDIT SELECT TABLE;

Em seguida, o banco de dados deve ser reiniciado. Para isso, no terminal SQLPlus, conecte-se com o nome de usuário sys como sysdba/senha e execute as seguintes instruções:
SHUTDOWN IMMEDIATE
STARTUP



Observe que os tamanhos acima diferem de um sistema para outro.

Para verificar se a trilha de auditoria está definida corretamente, execute a seguinte consulta:
select value from v$parameter where name='audit_trail';



ou:
show parameter audit_trail;



Quando você quiser parar a auditoria, execute:
NOAUDIT SELECT TABLE;

Para visualizar quais declarações foram registradas pela auditoria, você pode usar:
select dbms_lob.substr( sqltext, 4000, 1 )
from SYS.AUD$
where OBJ$NAME IN ('EMPLOYEES','DEPARTMENTS','JOBS','LOCATIONS');

ou
select count(*), OBJ$NAME, USERID
from SYS.AUD$
where OBJ$NAME IN ('EMPLOYEES','DEPARTMENTS','JOBS','LOCATIONS')
group by rollup (OBJ$NAME, USERID);



Outro exemplo é para auditoria padrão com dados auditados armazenados em um arquivo XML, no caminho padrão.
alter system set audit_trail=xml scope=spfile;
AUDIT SELECT, INSERT, UPDATE, DELETE ON employees WHENEVER NOT
SUCCESSFUL;

Novamente, reinicie o banco de dados:conecte-se ao terminal SQLPlus com o nome de usuário sys como sysdba/senha e execute os comandos SHUTDOWN IMMEDIATE e STARTUP.

Então, cada vez que uma consulta selecionar, inserir, atualizar e excluir falha na tabela de funcionários, ela deve ser registrada no arquivo XML.

Quando queremos interromper a auditoria, executamos os seguintes comandos no ambiente de desenvolvimento do banco de dados:
NOAUDIT ALL;
NOAUDIT ALL ON DEFAULT;

E restaure a trilha de auditoria padrão:
alter system set audit_trail=db scope=spfile;

Abaixo está um exemplo de uma parte de um arquivo de auditoria XML:


Como excluímos as informações auditadas?


O volume dos dados auditados pode se tornar muito grande devido ao número de atividades auditadas e sua frequência. É por isso que é recomendado arquivar periodicamente os dados auditados e excluí-los do sistema de produção.

Se os dados auditados estiverem armazenados no banco de dados (trilha de auditoria do banco de dados), podemos usar instruções de exclusão (mas somente depois de arquivar os dados!):
DELETE FROM SYS.AUD$;

Você pode optar por excluir as informações auditadas de um objeto de banco de dados específico, por exemplo, uma tabela chamada produtos:
DELETE FROM SYS.AUD$ WHERE OBJ$NAME='PRODUCTS';

Acionadores de auditoria


Um gatilho é um bloco PL/SQL ou a instrução CALL de um procedimento PL/SQL que é executado automaticamente sempre que ocorre um evento. Existem dois tipos de gatilhos:no nível do banco de dados (instruções do banco de dados) e no nível do aplicativo (por exemplo, apertar um botão em um formulário Oracle). Os gatilhos usados ​​para auditoria são os gatilhos de nível de banco de dados. Eles se classificam nas seguintes categorias:
  • Acionadores DML – onde uma instrução DML é acionada em uma tabela. Esses gatilhos podem ser executados uma vez no nível de comando independentemente do número de registros (triggers no nível de instrução) ou podem ser executados PARA CADA LINHA (triggers no nível de registro). Tipos de gatilhos de nível de registro:ANTES DA DECLARAÇÃO, DEPOIS DA DECLARAÇÃO, ANTES DE CADA LINHA, DEPOIS DE CADA LINHA;
  • Acionadores INSTEAD OF – onde uma instrução DML é acionada em uma visualização;
  • Acionadores do SISTEMA – acionados por eventos como iniciar/parar o banco de dados, instruções DDL, login/logout do usuário. Tipos de acionadores do sistema:DEPOIS DO EVENTO, ANTES DO EVENTO.

Consultando o SYS.TRIGGER$ tabela ou ALL_TRIGGERS view oferece informações sobre todos os triggers de nível de banco de dados. Por exemplo, o tipo de gatilho distinto do banco de dados pode ser encontrado da seguinte forma:
SELECT DISTINCT TRIGGER_TYPE FROM ALL_TRIGGERS;



A visualização DBA_TRIGGERS oferece informações sobre os gatilhos criados automaticamente pelos produtos Oracle na instalação. Se quisermos encontrar informações sobre os gatilhos do SISTEMA ('BEFORE EVENT' e 'AFTER EVENT'), podemos executar a seguinte instrução:
SELECT SUBSTR(OWNER,1,20) OWNER ,SUBSTR(TRIGGER_NAME,1,30),
TRIGGER_NAME, SUBSTR(TRIGGERING_EVENT,1,30) TRIGGERING_EVENT,
TRIGGER_TYPE
FROM DBA_TRIGGERS
WHERE TRIGGER_TYPE='BEFORE EVENT' OR TRIGGER_TYPE='AFTER EVENT'
ORDER BY TRIGGER_TYPE DESC;

Além disso, na instalação, os gatilhos DML são criados automaticamente no esquema do usuário de RH:
SELECT SUBSTR(TABLE_NAME,1,20) TABLE_NAME,
SUBSTR(TRIGGER_TYPE,1,30) TRIGGER_TYPE,TRIGGER_BODY
FROM DBA_TRIGGERS
WHERE OWNER='HR';

Para auditoria, podemos criar gatilhos personalizados para registrar as informações desejadas, mas deve-se criar uma tabela especial para armazenar as informações auditadas.

É importante garantir que os gatilhos desenvolvidos não influenciem a atividade normal do banco de dados. O objetivo da auditoria é monitorar passivamente a atividade normal do banco de dados do dia a dia e armazená-la para análise posterior. Consequentemente, não é recomendado criar gatilhos INSTEAD OF para retornar os resultados das tabelas de destino para a tabela de auditoria.

Os gatilhos DML no nível da instrução podem coexistir com os gatilhos DML no nível do registro. A ordem de chamada é:
  • acionar a instrução BEFORE
  • para cada registro afetado
    • acionar ANTES do registro
    • ação DML atual
    • acionar APÓS o registro
  • trigger AFTER instrução

Os gatilhos definidos pelo usuário serão executados apenas se, de acordo com a Oracle, a instrução estiver correta e puder ocorrer. Para uma instrução DML errada ou que viole uma restrição, um erro será retornado e o gatilho não será executado. Portanto, para auditoria, é recomendável usar especialmente os gatilhos LMD no nível de instrução.

Exemplo de gatilho de auditoria:

Vamos supor que queremos criar um gatilho para registrar em uma tabela de auditoria (chamada TAB_AUDIT_EMP) informações sobre as declarações DML que estabelecem salários acima de 20.000 (a moeda não é importante aqui) para os funcionários da empresa. Queremos armazenar em TAB_AUDIT_EMP o número de sequência da consulta, o nome de usuário, a sessão, o host e a data.

Isso pode ser feito com o seguinte:
CREATE TABLE TAB_AUDIT_EMP

(secv_id NUMBER(3) PRIMARY KEY,
username VARCHAR2(20),
session_nr NUMBER(10),
hostname VARCHAR2(100),
query_date DATE
);

CREATE SEQUENCE secv_aud_emp START WITH 1 INCREMENT BY 1;
CREATE OR REPLACE TRIGGER huge_salary
AFTER INSERT OR UPDATE OR DELETE OF SALARY ON EMPLOYEES
FOR EACH ROW WHEN (NEW.salary>20000)
BEGIN
INSERT INTO TAB_AUDIT_EMP
VALUES(secv_aud_emp.NEXTVAL , sys_context('userenv', 'session_user'), sys_context('userenv', 'sessionid'), sys_context('userenv', 'host'), sysdate);
END;



Suponha que façamos uma modificação salarial para os funcionários de um departamento específico:
UPDATE EMPLOYEES
SET SALARY=25000
WHERE ID_DEPARTMENT = 1;

E então verificamos o monitoramento:
select secv_id, substr(username,1,20) username, session_nr, substr(hostname,1,30) hostname, query_date
from TAB_AUDIT_EMP;


Políticas de auditoria


O terceiro método de auditoria refere-se às políticas de auditoria. A definição de uma política de auditoria contém o seguinte:
  • especificação do objeto (esquema, nome do objeto, colunas) sujeito ao monitoramento
  • especificação das ações auditadas para um objeto (SELECT, INSERT, UPDATE, DELETE):implicitamente é SELECT
  • especificação das condições que devem ser cumpridas para registrar as informações auditadas, é feita na cláusula WHEN do gatilho e é opcional
  • um manipulador de eventos que também manipula o evento, o que é opcional.

Uma política de auditoria pode ficar ativa (status ENABLED) ou inativa (status DISABLED). A lista das políticas de auditoria pode ser obtida interrogando a visão ALL_AUDIT_POLICIES:
SELECT POLICY_TEXT, ENABLED
FROM ALL_AUDIT_POLICIES

Para administração da política de auditoria temos o pacote DBMS_FGA. Para utilizar este pacote, é necessário conceder privilégios aos usuários que irão escrever o código PL/SQL:
grant execute on dbms_fga to username;

Exemplo de política de auditoria:

Queremos criar uma política de auditoria para registrar as instruções DML que modificam os gerenciadores (MANAGER_ID) na tabela DEPARTMENTS. Podemos optar por criar um handler para a política, chamado proc_audit_alert, que nos informa sobre uma modificação em relação ao gerenciador:
CREATE OR REPLACE PROCEDURE proc_audit_alert ( object_schema VARCHAR2, object_name VARCHAR2, policy_name VARCHAR2 ) AS
BEGIN
DBMS_OUTPUT.PUT_LINE('Alert! Manager Changed !');
END;

E a política pode ser:
CREATE OR REPLACE PROCEDURE proc_audit_manager AS
BEGIN
DBMS_FGA.ADD_POLICY
(
object_schema=>'ADMINDB',
object_name=>'DEPARTMENTS',
policy_name=>'proc_audit_manager',
audit_column=>'ID_MANAGER',
enable=>false,
statement_types=>'UPDATE',
handler_module=>'proc_audit_alert'
);
DBMS_FGA.ENABLE_POLICY
( object_schema=>'ADMINDB',
object_name=>'DEPARTMENTS',
policy_name=>'proc_audit_manager');
END;

Observe que object_schema, object_name, policy_name, audit_column, statement_types e handler_module devem ser adaptados à política que você deseja escrever.

Em seguida, executamos o procedimento:
EXECUTE proc_audit_manager;

Podemos verificar se a política está habilitada:
SELECT ENABLED, POLICY_NAME
FROM ALL_AUDIT_POLICIES
WHERE OBJECT_NAME='DEPARTMENTS';



Em seguida, verifique se o procedimento e a política funcionam corretamente, executando uma atualização:
UPDATE DEPARTMENTS
SET ID_MANAGER=2
WHERE ID_DEPARTAMENT=1;



Concluindo, a auditoria é necessária para cada banco de dados e os métodos fornecidos acima ajudam você a encontrar uma atividade suspeita que possa afetar a segurança do banco de dados. Para obter mais detalhes sobre a auditoria de banco de dados Oracle, consulte a bibliografia abaixo.

Bibliografia:

  • http://www.datadisk.co.uk/html_docs/oracle/auditing.htm
  • http://docs.oracle.com/cd/B10501_01/server.920/a96521/audit.htm
  • https://docs.oracle.com/cd/E11882_01/server.112/e10575/tdpsg_auditing.htm#TDPSG50000