Auditoria Oracle

A Oracle apresenta vários dispositivos de segurança, divididos em três categorias:

Autenticação - identidade digital do usuário que acessa o banco de dados. Essas informações de autenticação ficam armazenadas em tabelas na tablespace SYSTEM.

Autorização - determina determinados privilégios de Sistema (Permitem executar determinados comandos) de objetos (acesso com uso de SELECT, INSERT, EXECUTE, etc)

Auditoria - é o exame das atividades desenvolvidas no ambiente de banco de dados de estão de acordo com a política da empresa.

O foco do trabalho é apresentar tipos de Auditoria no banco de dados da Oracle. Não faz parte relatar os impactos negativos. Somente os tipos de Auditoria que são:

SYSDBA - rastrear as atividades executa pelo DBA ou qualquer um que tenha acesso SYSDBA.

Banco de Dados - rastreia o uso de certos privilégios, a execução de alguns comandos, acesso de tabelas ou tentativa de logon.

Trigger - Auditoria baseada em valor.

FGA (Fine Grained Auditing) - permite controlar acesso a tabela de acordo as linhas e/ou colunas foram acessadas.

Ativando os parametros:
AUDIT_SYS_OPERATIONS, o qual grava cada instrução executada por usuário conectado como SYSDBA ou SYSOPER.
AUDIT_FILE_DEST (figura1 e figura2). Para que os registros de auditoria possam ser gravados pela instância é necessário que o proprietário do Oracle tenha, somente, permissão de gravação no diretório de destino

OBS: Os comandos show parameter da figura 1 são utilizados para verificar onde o relatório será armazenado e se a auditora de DBA está habilitada. E, os comandos alter system set são aplicados para alterar o diretório de armazenamento do relatório e habilitar a auditoria, após esses comandos é necessário aplicar-se shutdown immediate para atualizar as configurações (figura 2).

Deve-se configurar o parâmetro de instância AUDIT_TRAIL. Na versão do Oracle 11g já vem configurado por padrão o tipo DB.

Customizar auditoria com 6 tipos de parâmetros:

ONE (ou FALSE) : desativa a auditoria
OS: os registros de auditoria são gravados na trilha de auditoria do SO.

DB: os registro de auditoria são gravados na SYS.AUD$ que é uma tabela do dicionário de dados.
DB_EXTENDED: Além de possuir as características do parâmetro de DB, adiciona informações nas colunas CLOB SQLBIND e SQLTEXT.

XML: grava todos registros no formato XML - Extensible Markup Language.
XML_EXTENDED: como o parâmetro XML, porém, com instruções de SQL- Structured Query Language e variáveis bind.


OBS: Para alterar parâmetro de instância AUDIT_TRAIL utiliza o comando, depois é necessário shutdown immediate:

SQL> alter system set audit_trail = DB_EXTENDED scope=spfile;

Auditoria de Login:
A auditoria de sessão registra cada conexão do banco de dados. Ela pode ser configurada NOT SUCCESSFUL para tentativas de falhas de login ou SUCCESSFUL para login efetuados com sucesso. Os registros de falhas de acesso pode indicar uma tentativa de invasão no banco de dados. Os logons são auditados com AUDIT SESSION (figura3).

Auditoria de instruções:

A auditoria de instruções possibilita auditar um tipo de instrução SQL ou um usuário específico. Utiliza a seguinte sintaxe de comando:

AUDIT cláusula_da_instrusão_sql BY {SESSION / ACCESS} WHENEVER [NOT] SUCCESSFUL;

Auditoria de Privilégios:

A auditoria de privilégios possui a mesma sintaxe básica que a de instruções, exceto que na cláusula_da_instrusão_sql é especificado o privilégio em vez da instrução. Por exemplo, auditar todas as vezes que o BDA criar um usuário novo no banco de dados.

SQL> audit create user by Access whenever successful.
Cada vez que o privilégio CREATE USER é executado com êxito, uma linha é adicionada na tabela SYS.AUD$.

Diferentemente da auditoria de banco de dados que o registro de auditoria não inclui os valores reais da linha que foi inserida, a auditoria baseada em valor de trigger possibilita que esses valores sejam armazenados.

De acordo com Watson (2010), um trigger de banco de dados é um bloco do PL/SQL - Procedural Language/Structured Query Language que executará automaticamente antes e/ou depois que um comando de INSERT, UPDATE ou DELETE for executado em uma tabela. Assim, pode desenvolver trigger para auditar uma tabela, para isso é necessário criar um tabela de LOG (figura 6), na qual será armazenado valor dos dados antes dele ser alterado, inserido ou apagado.

Considere a Trigger abaixo:

CREATE OR REPLACE TRIGGER DIDES.TR_FUNCIONARIO_IUD_L
AFTER INSERT OR UPDATE OR DELETE
ON DIDES.TB_FUNCIONARIO FOR EACH ROW
DECLARE
v_client_info VARCHAR2(64);
v_usuario VARCHAR2(58) := USER;
BEGIN
DBMS_APPLICATION_INFO.read_client_info (v_client_info);
IF v_client_info is not null THEN
v_usuario := v_client_info;

.....

OBS: Toda vez que a tabela que os dados da tabela tb_funcionario for alterado, inserido ou excluindo grava um registro na tabela de lg_funcionario, incluindo a data e o tipo da operação, e o usuário que fez.

A auditoria refinada ou FGA é uma solução da Oracle para adequar a auditoria ao negócio da empresa. Ela pode ser configurada para auditar colunas de uma tabela e condições específicas de uma instrução SQL. Os registros de auditoria criados podem ser visualizados pela tabela SYS.FGA$ ou pela view DBA_AUDIT_POLICIES, e as informações de acessos localizam na view DBA_FGA_AUDIT_TRAIL. E, o parâmetro AUDIT_TRAIL não precisa ser habilitado, pois a FGA utiliza o pacote DBMS_FGA para manipular os eventos que se deseja auditar.