Como auditar acessos a tabelas com SQL Server Audit

Saber quem acede aos dados sensíveis é uma das bases da governança de dados. O SQL Server Audit, uma funcionalidade nativa do SQL Server, é a forma mais fiável de auditar acessos a tabelas: regista automaticamente cada leitura ou alteração e ajuda a responder à pergunta "quem viu esta informação e quando?". Toda a configuração se faz em T-SQL e demora poucos minutos.

Pré-requisitos

• Uma instância de SQL Server (on-premises, numa VM ou Azure SQL Managed Instance).
• O SQL Server Management Studio (SSMS) ou o Azure Data Studio para correr os comandos.
• Permissões de administrador — em concreto, ALTER ANY SERVER AUDIT ao nível do servidor.
• Uma pasta no servidor para guardar os ficheiros de auditoria, por exemplo C:\Auditoria\.

Antes de começar, convém conhecer as três peças que compõem uma auditoria: o Server Audit (onde os eventos são gravados), a Audit Specification (o que é registado) e o destino (um ficheiro ou o registo do Windows). Esta separação torna o sistema flexível — um único Server Audit pode receber eventos de várias bases de dados. Vamos configurá-las por esta ordem.

Passo 1: Criar o objeto de auditoria

O primeiro passo é criar o Server Audit, o "cofre" onde os eventos vão ser escritos. Neste exemplo gravamos num ficheiro dentro da pasta preparada; o SQL Server cria ficheiros .sqlaudit e vai rodando-os à medida que enchem.

USE master;
GO
CREATE SERVER AUDIT Auditoria_Acessos
TO FILE (FILEPATH = 'C:\Auditoria\', MAXSIZE = 100 MB)
WITH (ON_FAILURE = CONTINUE);
GO

A opção ON_FAILURE = CONTINUE permite que o SQL Server continue a funcionar mesmo que, por algum motivo, não consiga escrever um registo — evita que a base de dados pare. Em ambientes muito exigentes em conformidade pode preferir SHUTDOWN, mas para começar CONTINUE é o mais seguro.

Passo 2: Ativar a auditoria

Quando é criado, o objeto de auditoria fica desligado. Precisamos de o ativar explicitamente:

ALTER SERVER AUDIT Auditoria_Acessos
WITH (STATE = ON);
GO

A partir deste momento o "cofre" está pronto a receber eventos. Falta apenas indicar-lhe o que deve registar, e é isso que fazemos no passo seguinte.

Passo 3: Definir o que auditar

Agora criamos uma Database Audit Specification que descreve as ações a registar. No exemplo queremos saber quem executa um SELECT sobre a tabela dbo.Salarios da base de dados RH — um caso típico de dados sensíveis. A cláusula BY public abrange todos os utilizadores.

USE RH;
GO
CREATE DATABASE AUDIT SPECIFICATION Audit_Select_Salarios
FOR SERVER AUDIT Auditoria_Acessos
ADD (SELECT ON dbo.Salarios BY public)
WITH (STATE = ON);
GO

Pode acrescentar mais linhas dentro do ADD (...), separadas por vírgula, para auditar também INSERT, UPDATE ou DELETE noutras tabelas. Registar apenas o essencial mantém os ficheiros pequenos e fáceis de analisar.

Dica: evite auditar com SELECT tabelas muito acedidas (como tabelas de log da aplicação). O volume de registos cresce depressa e dificulta a análise. Comece pelas tabelas com dados pessoais ou financeiros.

Passo 4: Consultar os registos

Os eventos ficam guardados nos ficheiros .sqlaudit. Para os ler num formato de tabela legível, use a função de sistema sys.fn_get_audit_file, indicando o caminho dos ficheiros com um caractere universal:

SELECT event_time,
       server_principal_name,
       database_name,
       object_name,
       statement
FROM sys.fn_get_audit_file('C:\Auditoria\*.sqlaudit', DEFAULT, DEFAULT)
ORDER BY event_time DESC;

Cada linha mostra o utilizador, a data e a hora e o comando executado. Pode filtrar o resultado por utilizador ou por período acrescentando uma cláusula WHERE, o que é útil quando os ficheiros já contêm muitos eventos — exatamente o rasto de que precisa para investigar um acesso indevido ou provar conformidade com o RGPD.

Verificar o resultado

Para confirmar que tudo está a funcionar, execute uma consulta de teste à tabela auditada e volte a ler o registo:

SELECT * FROM RH.dbo.Salarios;   -- a ação que queremos apanhar

Ao correr novamente a consulta a sys.fn_get_audit_file do passo anterior, deve surgir uma nova linha com o seu nome de utilizador e o comando SELECT. Se essa linha aparecer, a auditoria está operacional e a registar acessos em tempo real.

Conclusão

Em quatro passos criou um mecanismo que regista quem acede aos dados sensíveis — um pilar essencial de qualquer política de governança e um requisito frequente em auditorias de conformidade. O passo seguinte é encaminhar estes registos para um local centralizado, como o registo de segurança do Windows, e definir alertas para acessos fora do horário normal. Que tabela da sua organização merecia ser a primeira a entrar nesta auditoria?