Auditing – Auditoria

Auditoria em bancos de dados é como ter um detetive particular para os dados da empresa. Com ela, podemos acompanhar de perto todas as ações realizadas dentro do sistema, garantindo que tudo esteja em conformidade e que os dados estejam seguros. Neste artigo, exploraremos as funcionalidades de auditoria do Oracle Database, passando por conceitos, comandos essenciais e exemplos práticos. Desde a visualização das views de auditoria até a aplicação de políticas avançadas, nosso objetivo é tornar o processo de auditoria não apenas compreensível, mas também eficiente e valioso para o gerenciamento e segurança dos dados.

O comando abaixo ajuda a visualizar todas as views de auditoria disponíveis no banco de dados:

SELECT view_name
FROM   dba_views
WHERE  view_name LIKE 'DBA%AUDIT%'
ORDER BY view_name;

Este comando revela que temos várias ferramentas para explorar o tema da auditoria. Para tornar o laboratório o mais real possível, vamos simular um ambiente onde o usuário USR_BANGUELA é auditado pelo usuário USR_AUDITOR. Por padrão, é necessário iniciar o processo de auditoria concedendo os privilégios apropriados ao auditor.

Para que o usuário USR_AUDITOR possa realizar a auditoria, é necessário conceder os seguintes privilégios:

GRANT AUDIT SYSTEM TO USR_AUDITOR;
GRANT AUDIT ANY TO USR_AUDITOR;
GRANT CREATE SESSION TO USR_AUDITOR;
GRANT RESOURCE TO USR_AUDITOR;
GRANT SELECT ON SYS.AUD$ TO USR_AUDITOR;
GRANT SELECT ANY TABLE TO USR_AUDITOR;

Com os privilégios concedidos, o próximo passo é iniciar a auditoria. Utilizaremos os seguintes comandos para configurar a auditoria das ações realizadas pelo usuário USR_BANGUELA:

AUDIT ALL BY USR_BANGUELA BY ACCESS;
AUDIT SELECT TABLE, UPDATE TABLE, INSERT TABLE, DELETE TABLE BY USR_BANGUELA BY ACCESS;
AUDIT EXECUTE PROCEDURE BY USR_BANGUELA BY ACCESS;

Esses comandos permitirão auditar todas as ações realizadas pelo usuário USR_BANGUELA. Cada operação—seja uma seleção, atualização, inserção ou exclusão de tabela, ou mesmo a execução de procedimentos—gerará um registro de auditoria.

Vamos ver isso na prática. O usuário USR_BANGUELA executará uma sequência de comandos DML.

O usuário USR_BANGUELA executa os seguintes comandos DML:

CREATE TABLE funcionarios (
    id_funcionario NUMBER(5),
    nome VARCHAR2(50),
    salario NUMBER(10, 2),
    departamento VARCHAR2(30)
);

INSERT INTO funcionarios VALUES (1, 'João Silva', 2000, 'TI');
INSERT INTO funcionarios VALUES (2, 'Maria Santos', 6000, 'MKT');
INSERT INTO funcionarios VALUES (3, 'Carlos Oliveira', 5000, 'Faturamento');
INSERT INTO funcionarios VALUES (4, 'Ana Pereira', 10000, 'Tesouria');
INSERT INTO funcionarios VALUES (5, 'Pedro Rocha', 7500, 'Vendas');
INSERT INTO funcionarios VALUES (6, 'Mariana Lima', 8001, 'RH');
INSERT INTO funcionarios VALUES (7, 'Rodrigo Costa', 3999, 'Facilities');
INSERT INTO funcionarios VALUES (8, 'João Reis', 1500, 'ADM');

A sequência de comandos acima ilustra o cotidiano de um usuário realizando suas operações DML sem saber que está sendo monitorado. Agora, vamos conferir o relatório gerado para o auditor.

Para visualizar o relatório gerado pela auditoria, utilizamos a seguinte consulta:

SELECT
    username,
    action_name,
    extended_timestamp,
    obj_name,
    sql_text
FROM
    dba_audit_trail
WHERE
    username = 'USR_BANGUELA';

Este relatório revela que o usuário USR_BANGUELA executou uma ação DML. O resultado inclui:

• username: O nome do usuário que executou a ação (neste caso, USR_BANGUELA).
• action_name: O tipo de ação realizada (neste caso, INSERT).
• extended_timestamp: Data e hora em que a ação ocorreu.
• obj_name: Nome do objeto afetado pela ação (neste caso, a tabela FUNCIONARIOS).
• sql_text: O texto SQL da operação executada.

Vale ressaltar que a auditoria implementada neste laboratório captura todas as ações, independentemente de serem ‘commitadas’ ou não. No nosso caso, o usuário USR_BANGUELA ainda não executou um commit.

Outro ponto crucial é que, por ser um ambiente de teste, a auditoria foi configurada com o parâmetro ALL. Isso significa que todas as ações são detectadas e geram relatórios. Em um ambiente produtivo, onde o volume de movimentações é alto, essa configuração pode impactar negativamente a performance. Portanto, antes de implementar uma política de auditoria, é essencial definir claramente seus objetivos, conhecer bem seu ambiente e agir com eficiência.

Seguindo com o laboratório, vamos implementar a Auditoria Fina (FGA). Ao contrário do exemplo anterior, vamos filtrar o retorno da auditoria. Para isso, consideremos uma tabela EMPREGADOS com 25 registros e seus respectivos salários.

A tabela EMPREGADOS contém registros com salários que variam de 2500 a 24000. Vamos configurar a auditoria para que retorne relatórios sempre que qualquer consulta buscar salários superiores a 12000. Ou seja, toda vez que qualquer usuário, inclusive o usuário SYS, realizar uma busca que retorne salários acima desse valor, será gerado um relatório.

Para isso, começaremos ativando a Auditoria Fina (FGA).

Para configurar a Auditoria Fina (FGA) e filtrar as consultas, utilizamos o comando a seguir:

BEGIN
  DBMS_FGA.add_policy(
    object_schema   => 'USR_BANGUELA',
    object_name     => 'EMPREGADOS',
    policy_name     => 'AUDIT_SALARIO',
    audit_condition => 'SALARY > 12000',
    audit_column    => 'SALARY');
END;
/

Este comando adiciona uma política de auditoria à tabela EMPREGADOS no esquema USR_BANGUELA. Vamos explicar cada parte:

• object_schema: Especifica o esquema que contém o objeto auditado, neste caso, USR_BANGUELA.
• object_name: Define o nome do objeto que será auditado, aqui é a tabela EMPREGADOS.
• policy_name: Nome da política de auditoria que estamos criando, chamada de AUDIT_SALARIO.
• audit_condition: Condição que, quando atendida, gera um relatório de auditoria. Aqui, a condição é SALARY > 12000, o que significa que qualquer consulta que retorne salários acima desse valor será auditada.
• audit_column: Indica a coluna que será monitorada para atender à condição, neste caso, SALARY.

A partir de agora, toda vez que uma busca no banco atingir o critério imposto pela política de FGA, ou seja, quando retornar salários maiores que 12000, será gerado um apontamento. Caso contrário, o relatório não será gerado, e o usuário pode ficar tranquilo.

SELECT FIRST_NAME, LAST_NAME, SALARY FROM USR_BANGUELA.EMPREGADOS
WHERE FIRST_NAME = 'Den';

O que vemos acima é uma prova viva. Quando o usuário USR_BANGUELA executa uma busca que não fere os critérios impostos, nenhum relatório é gerado.

SELECT SQL_TEXT FROM DBA_FGA_AUDIT_TRAIL;

Sendo assim, o usuário pode dormir tranquilo. A ausência de apontamentos não significa que a auditoria não está funcionando. Para verificar se a política de auditoria está ativa e configurada corretamente, podemos usar o seguinte comando:

Para verificar as políticas de auditoria ativas, podemos usar o seguinte comando:

SELECT policy_name, object_schema, object_name, policy_text
FROM dba_audit_policies;

Esse comando nos permite visualizar as políticas de auditoria que estão em vigor. Os campos retornados são:

• POLICY_NAME: Nome da política de auditoria.
• OBJECT_SCHEMA: Esquema onde o objeto auditado está localizado.
• OBJECT_NAME: Nome do objeto auditado (por exemplo, a tabela).
• POLICY_TEXT: Texto da política de auditoria, detalhando a condição e as colunas auditadas.

Na sequência, o usuário solicita o nome e o sobrenome de todos os empregados cadastrados.

SELECT FIRST_NAME, LAST_NAME FROM USR_BANGUELA.EMPREGADOS;

E é exatamente isso que vemos acima. O usuário solicita um relatório que mostra todos os funcionários da empresa, mas, mesmo assim, nenhum relatório de auditoria é gerado.

SELECT SQL_TEXT FROM DBA_FGA_AUDIT_TRAIL;

Pode dormir tranquilo, USR_BANGUELA. Apesar de ter obtido um retorno de 25 linhas, ele não violou os critérios impostos. No entanto, essa situação mudará com o próximo comando:

SELECT FIRST_NAME, LAST_NAME, SALARY FROM USR_BANGUELA.EMPREGADOS
WHERE FIRST_NAME = 'Nancy';

E agora, sim, foi feito o apontamento. Apenas uma linha foi suficiente para gerar um registro de auditoria.

SELECT SQL_TEXT FROM DBA_FGA_AUDIT_TRAIL;

A política de auditoria foi acionada porque houve uma consulta na tabela EMPREGADOS que acessou a coluna SALARY com uma condição que violou a política ao buscar um salário maior que 12.000. Isso gerou um registro na trilha de auditoria.

Condição de Auditoria: Mesmo que a condição SALARY > 12000 não esteja explicitamente na cláusula WHERE da consulta auditada, a auditoria verifica o valor de SALARY dos registros acessados. Se algum registro acessado atender à condição de auditoria, a política é acionada.

Assim como foi criada a FGA, vamos entender como removê-la.

BEGIN
  DBMS_FGA.drop_policy(
    object_schema   => 'USR_BANGUELA',
    object_name     => 'EMPREGADOS',
    policy_name     => 'AUDIT_SALARIO'),
END;
/

Com o usuário USR_AUDITOR, encerramos o ciclo de auditoria. É importante entender que os apontamentos detectados anteriormente permanecem registrados. Caso novos selects sejam feitos em salários maiores que 12.000, não serão gerados novos apontamentos, pois a política de auditoria foi removida.

Conclusão

A auditoria é um pilar fundamental na proteção de dados e na conformidade com regulamentações de segurança. Implementada corretamente, ela não só permite monitorar e analisar o comportamento dos usuários, mas também assegura a integridade das informações armazenadas no banco de dados. No entanto, é essencial aplicar a auditoria de maneira estratégica e bem planejada. Evitar uma abordagem excessiva e começar com áreas críticas pode prevenir impactos negativos no desempenho do sistema e garantir a eficácia da monitoria. Com boas práticas e um ajuste contínuo das políticas de auditoria, podemos transformar a auditoria em uma ferramenta poderosa para garantir a segurança e a eficiência no gerenciamento dos dados. Agradecemos a leitura e incentivamos a interação: compartilhem suas experiências e dúvidas para continuarmos aprimorando o entendimento e a aplicação da auditoria em nossos ambientes Oracle.