Técnicas de auditoria

  • Auditoria do SYSDBA: Qualquer pessoa com privilégio SYSDBA pode fazer absolutamente qualquer coisa dentro do banco de dados. Para seus colegas terem confiança que você não está abusando desse poder, é necessário auditar todas as atividades do SYSDBA;
  • Auditoria de banco de dados: pode rastrear o uso de certos privilégios, a execução de certos comandos, o acesso a certas tabelas ou tentativas de logon;
  • Auditoria baseada em valor: usa triggers de banco de dados. Sempre que uma linha é inserida, atualizada ou excluída, um código PL/SQL será executado para registrar os detalhes da operação;
  • Auditoria refinada (FGA): permite controlar o acesso a tabelas de acordo com quais linhas (ou quais colunas) foram acessadas. É mais precisa que as auditorias de banco de dados ou baseada em valor. Pode limitar o número de registros de auditoria gerados para somente aqueles que interessam.

Auditoria do SYSDBA

O parâmetro AUDIT_SYS_OPERATIONS define se a auditoria do SYSDBA como ativada ou não. Caso seja TRUE, cada instrução emitida por um usuário conectado como SYSDBA ou SYSOPER é gravada na trilha de auditoria do sistema operacional.

Separação de tarefas: a trilha de auditoria deve ser protegida, ou seja, os arquivos criados para registrar as atividades do DBA não podem ser acessados pelo próprio – só devem ser acessíveis para o administrador do servidor. Se o DBA também for o administrador do sistema, a auditoria torna-se inútil. Por essa razão, um auditor decente sempre afirmará que o DBA não deve ter a senha de “root” no Unix, ou a senha de “Administrador” do Windows.

Destino dos registros de auditoria: é específico para cada plataforma. No Windows é o Windows Application Log. No Unix é controlado pelo parâmetro AUDIT_FILE_DEST, que deve apontar para um diretório no qual o owner do Oracle tenha permissão de gravação, mas que o usuário do sistema operacional usado pelo DBA não tenha permissão, pelas razões já citadas acima.

Auditoria de banco de dados

Valores possíveis para o parâmetro de instância AUDIT_TRAIL:

  • NONE (ou FALSE): Auditoria desativada;
  • OS: os registros de auditoria são gravados na trilha de auditoria do sistema operacional;
  • DB: os registros de auditoria são gravados em uma tabela do dicionário de dados, SYS.AUD$. Existem views que permitem ver o conteúdo dessa tabela;
  • DB_EXTENDED: como o parâmetro DB, mas incluindo as instruções SQL com variáveis bind que geraram os registros de auditoria;
  • XML: como o parâmetro OS, mas formatado com tags XML;
  • XML_EXTENDED: como o parâmetro XML, mas com instruções SQL e variáveis bind.

Tendo configurado o AUDIT_TRAIL, você pode usar a auditoria de banco de dados para capturar tentativas de login, uso dos privilégios de sistema e objetos, e também a execução de comandos SQL. Você pode especificar se fará auditoria destes eventos quando eles forem bem-sucedidos, quando falharem por falta de permissões, ou ambos.

A auditoria de banco de dados é configurada através do comando AUDIT. Exemplos:

[et_pb_dmb_code_snippet _builder_version=”4.0.9″ code=”U1FMPiBhdWRpdCBjcmVhdGUgYW55IHRyaWdnZXI7ClNRTD4gYXVkaXQgc2VsZWN0IGFueSB0YWJsZSBieSBzZXNzaW9uOw==” hover_enabled=”0″]U1FMPiBhdWRpdCBjcmVhdGUgYW55IHRyaWdnZXI7ClNRTD4gYXVkaXQgc2VsZWN0IGFueSB0YWJsZSBieSBzZXNzaW9uOw==[/et_pb_dmb_code_snippet]

Por padrão, a auditoria irá gerar um registro de auditoria para cada sessão que violar uma condição de auditoria, sem considerar o número de vezes que ela viola a restrição. Isso é equivalente a anexar BY SESSION ao comando AUDIT. Anexar BY ACCESS gerará um registro para cada violação.

A auditoria também pode ser orientada a objetos, como nos exemplos:

[et_pb_dmb_code_snippet _builder_version=”4.0.9″ code=”U1FMPiBhdWRpdCBpbnNlcnQgb24gc2NvdHQuZW1wIHdoZW5ldmVyIHN1Y2Nlc3NmdWw7ClNRTD4gYXVkaXQgYWxsIG9uIHNjb3R0LmRlcHQ7″ hover_enabled=”0″]U1FMPiBhdWRpdCBpbnNlcnQgb24gc2NvdHQuZW1wIHdoZW5ldmVyIHN1Y2Nlc3NmdWw7ClNRTD4gYXVkaXQgYWxsIG9uIHNjb3R0LmRlcHQ7[/et_pb_dmb_code_snippet]

O primeiro comando irá gerar registros de auditoria se uma sessão inserir uma ou mais linhas na tabela scott.emp. As palavras-chave WHENEVER SUCCESSFUL restringem os registros de auditoria àqueles nos quais a operação foi bem-sucedida. Para registrar apenas as operações que não foram bem-sucedidas, a sintaxe é WHENEVER NOT SUCCESSFUL. Por padrão, todas as operações são auditadas, basta omitir a cláusula WHENEVER.

O segundo comando auditará cada sessão executar instruções DDL na tabela scott.dept.

Os logons são auditados com AUDIT SESSION. Exemplo:

[et_pb_dmb_code_snippet _builder_version=”4.0.9″ code=”U1FMPiBhdWRpdCBzZXNzaW9uIHdoZW5ldmVyIG5vdCBzdWNjZXNzZnVsOw==” hover_enabled=”0″]U1FMPiBhdWRpdCBzZXNzaW9uIHdoZW5ldmVyIG5vdCBzdWNjZXNzZnVsOw==[/et_pb_dmb_code_snippet]

O AUDIT SESSION registra cada conexão ao banco de dados. NOT SUCCESSFUL restringe a saída, fazendo com que somente as tentativas falhas sejam registradas. Isso pode ajudar a indicar se estão sendo feitas tentativas para invadir o banco de dados.

Se a auditoria foi direcionada para o banco de dados (AUDIT_TRAIL=DB ou DB_EXTENDED), os registros vão para a tabela SYS.AUD$, pertencente ao dicionário de dados. É possível consultar estes registros pela view DBA_AUDIT_TRAIL.

Outras views auxiliares: DBA_AUDIT_OBJECT, DBA_AUDIT_STATEMENT e DBA_AUDIT_SESSION.

No próximo artigos veremos a auditoria baseada em valor e a auditoria refinada.

Referência Bibliográfica

Este post, assim como todos os posts sobre Certificação OCA deste blog, são trechos do livro “OCA Oracle Database 11g – Administração I (Guia do Exame 1Z0-052)”, da editora Bookman – www.bookman.com.br
Recomendo este livro a todos que pretendem estudar para o exame. Meus posts são apenas algumas dicas para quem já está estudando por outros materiais, e por isso exige uma base de conhecimento anterior em cada um dos capitulos. Para uma referência completa de estudos é recomendado a compra do livro correspondente, bem como a documentação oficial da Oracle.