Compreendendo a auditoria do SQL Server

O objeto Auditoria do SQL Server coleta uma instância única de ações no nível do servidor e/ou do banco de dados e grupos de ações a serem monitoradas. A auditoria do está no nível de instância do SQL Server. Você pode ter várias auditorias por instância do SQL Server.

Ao definir uma auditoria, especifique o local de saída dos resultados. Esse é o destino da auditoria. A auditoria é criada em um estado desabilitado e não audita automaticamente nenhuma ação. Após a habilitação da auditoria, o destino da auditoria recebe dados da auditoria.

O objeto Especificação da Auditoria do Servidor pertence a uma auditoria. É possível criar uma especificação de auditoria de servidor por auditoria, já que ambos são criados no escopo da instância do SQL Server.

A especificação da auditoria do servidor coleta muitos grupos de ação no nível do servidor gerados pelo recurso Eventos Estendidos. É possível incluir grupos de ação de auditoria em uma especificação da auditoria do servidor. Os grupos de ação de auditoria são grupos de ações predefinidos, que são eventos atômicos que ocorrem no Mecanismo de Banco de Dados. Essas ações são enviadas à auditoria, que por sua vez os registra no destino.

Os grupos de ação de auditoria no nível do servidor são descritos no tópico Ações e grupos de ações de auditoria do SQL Server.

O objeto Especificação da Auditoria do Banco de Dados também pertence à auditoria do SQL Server. É possível criar uma especificação da auditoria do banco de Dados por banco de dados do SQL Server por auditoria.

Uma especificação da auditoria do banco de dados coleciona ações de auditoria no nível do banco de dados geradas pelo recurso Eventos Estendidos. É possível adicionar grupos de ações de auditoria ou de eventos de auditoria a uma especificação da auditoria do banco de dados. Eventos de auditoria são ações atômicas que podem ser examinadas pelo mecanismo do SQL Server. Grupos de ação de auditoria são grupos de ações predefinidos. Ambos estão no escopo do banco de dados do SQL Server. Essas ações são enviadas à auditoria, que por sua vez os registra no destino. Não inclua objetos do escopo de servidor, como as exibições do sistema, em uma especificação de auditoria de banco de dados do usuário.

Os grupos de ação de auditoria no nível do banco de dados e as ações de auditoria são descritos no tópico Ações e grupos de ações de auditoria do SQL Server.

Os resultados de uma auditoria são enviados ao destino, que pode ser um arquivo, o log de eventos de Segurança do Windows ou o log de eventos de Aplicativo do Windows. (A gravação no log de Segurança não está disponível no Windows XP.) É necessário verificar e arquivar os logs periodicamente para certificar-se de que o destino tenha espaço suficiente para gravar mais registros.

Importante
Qualquer usuário autenticado pode fazer a leitura ou gravação no log de eventos de Aplicativo do Windows. O log de eventos de Aplicativo requer menos permissões que o log de eventos de Segurança do Windows e é menos seguro.

Gravar no log de Segurança do Windows exige que a conta de serviço do SQL Server seja adicionada à política Gerar auditorias de segurança. Por padrão, Sistema Local, Serviço Local e Serviço de Rede fazem parte dessa política. Esta configuração pode ser definida com o uso do snap-in de diretiva de segurança (secpol.msc). Além disso, é necessário habilitar a diretiva de segurança Auditar acesso ao objeto para Êxito e Falha. Esta configuração pode ser definida com o uso do snap-in de diretiva de segurança (secpol.msc). No Windows Vista ou no Windows Server 2008, é possível definir a diretiva mais detalhada de aplicativo gerado na linha de comando usando o programa de diretiva de auditoria (AuditPol.exe). Para obter mais informações sobre as etapas para habilitar a gravação no log de Segurança do Windows, consulte Como gravar eventos de auditoria do servidor no log de segurança. Para obter mais informações sobre o programa Auditpol.exe, consulte o artigo 921469 How to use Group Policy to configure detailed security auditing da Base de Dados de Conhecimento. Os logs de eventos do Windows são globais ao sistema operacional Windows. Para obter mais informações sobre os logs de eventos do Windows, consulte Event Viewer Overview. Se você precisar de permissões mais exatas na auditoria, use o destino de arquivo binário.

Quando você está salvando informações de auditoria em um arquivo, para ajudar a impedir falsificação, você pode restringir o acesso ao local do arquivo das seguintes maneiras:

• A Conta de Serviço SQL Server deve ter permissão de Leitura e Gravação.

• Os Administradores de Auditoria geralmente requerem permissão de Leitura e Gravação. Isso pressupõe que os Administradores de Auditoria sejam contas do Windows para a administração de arquivos de auditoria, por exemplo, copiando-os em compartilhamentos diferentes, armazenando-os em backup e assim por diante.

• Os Leitores de Auditoria que são autorizados a ler os arquivos de auditoria precisam ter permissão de Leitura.

Até mesmo quando o Mecanismo de Banco de Dados estiver gravando em um arquivo, outros usuários do Windows poderão ler o arquivo de auditoria se eles tiverem permissão. O Mecanismo de Banco de Dados não possui um bloqueio exclusivo que impeça operações de leitura.

Como o Mecanismo de Banco de Dados pode acessar o arquivo, os logons do SQL Server que tiverem a permissão do CONTROL SERVER poderão usar o Mecanismo de Banco de Dados para acessar os arquivos de auditoria. Para registrar qualquer usuário que esteja lendo o arquivo de auditoria, defina uma auditoria em master.sys.fn_get_audit_file. Isso registra os logons com permissão CONTROL SERVER que acessaram o arquivo de auditoria usando SQL Server.

Se um Administrador de Auditoria copiar o arquivo para um local diferente (para fins de arquivamento, entre outros), as ACLs no novo local deverão ter apenas as seguintes permissões:

• Administrador de Auditoria – Leitura/Gravação

• Leitor de Auditoria - Leitura

É recomendável gerar relatórios de auditoria de uma instância separada do SQL Server, como uma instância do SQL Server Express a que apenas Administradores de Auditoria ou Leitores de Auditoria tenham acesso. Ao usar uma instância separada do Mecanismo de Banco de Dados para relatório, você pode ajudar a impedir que usuários não autorizados obtenham acesso ao registro de auditoria.

Você pode oferecer proteção adicional contra acesso não autorizado criptografando a pasta na qual o arquivo de auditoria é armazenado usando Criptografia de Unidade de Windows BitLocker ou Sistema de Arquivo do Windows Encrypting.

Para obter mais informações sobre os registros de auditoria gravados no destino, consulte Registros de auditoria do SQL Server.

Anexar um banco de dados que tenha uma especificação de auditoria e especifica um GUID inexistente ao servidor gerará uma especificação de auditoria órfã. Como não existe uma auditoria com um GUID correspondente na instância do servidor, nenhum evento de auditoria será gravado. Para corrigir isso, use o comando ALTER DATABASE AUDIT SPECIFICATION para conectar a especificação de auditoria órfã a uma auditoria de servidor existente. Ou use o comando CREATE SERVER AUDIT para criar uma nova auditoria de servidor com o GUID especificado.

É possível anexar um banco de dados que tenha uma especificação de auditoria definida a outra edição do SQL Server que não dê suporte ao SQL Server Audit, como SQL Server Express, mas não gravará eventos de auditoria.

Um banco de dados com uma especificação de auditoria de banco de dados definida e que usa espelhamento de banco de dados incluirá a especificação de auditoria de banco de dados. Para funcionar corretamente na instância de SQL espelhada, é necessário configurar os seguintes itens:

• É necessário que o servidor espelho tenha uma auditoria com o mesmo GUID para habilitar a especificação de auditoria de banco de dados para gravar registros de auditoria. Isso pode ser configurado com o uso do comando CREATE AUDIT WITH GUID=<GUID from source Server Audit>.

• Para destinos de arquivos binários, é necessário que a conta do serviço de servidor espelho tenha as permissões apropriadas onde a trilha de auditoria começou a ser gravada.

• Para destinos de log de eventos do Windows, a política de segurança no computador em que se encontra o servidor espelho deve permitir acesso de conta de serviço ao log de eventos de aplicativo ou de segurança.