Partilhar via


Compreendendo a auditoria do SQL Server

Auditar uma instância do SQL Server ou um banco de dados do SQL Server envolve eventos de rastreamento e de log que ocorrem no sistema. É possível usar vários métodos de auditoria do SQL Server, conforme descrito em Auditando (Mecanismo de Banco de Dados). Começando com SQL Server 2008 Enterprise, também é possível configurar uma auditoria automática usando a auditoria do SQL Server.

Dependendo dos requisitos ou padrões governamentais de sua instalação, ha vários níveis de auditoria no SQL Server. A auditoria do SQL Server fornece as ferramentas e os processos necessários para habilitar, armazenar e exibir auditorias em vários objetos de servidor e de banco de dados.

É possível gravar grupos de ação de auditoria de servidor por instância, e grupos de ação de auditoria de banco de dados ou ações de auditoria de banco de dados por banco de dados. O evento de auditoria ocorrerá sempre que a ação auditável for encontrada.

Componentes de auditoria do SQL Server

Uma auditoria é a combinação de vários elementos em um único pacote de um grupo específico de ações de servidor ou ações de banco de dados. Os componentes de auditoria do SQL Server são combinados para produzir uma saída conhecida como auditoria, da mesma forma que uma definição de relatório com elementos gráficos e de dados produz um relatório.

A auditoria no SQL Server usa Eventos Estendidos para ajudar na criação de uma auditoria. Para obter mais informações sobre Eventos Estendidos, consulte Introduzindo o SQL Server Extended Events.

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.

Especificação da Auditoria do Servidor

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.

Especificação da Auditoria do Banco de Dados

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.

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

Destino

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.

Observação importanteImportante

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 política de segurança (secpol.msc). Além disso, é necessário habilitar a política de segurança Auditar acesso ao objeto para Êxito e Falha. Esta configuração pode ser definida com o uso do snap-in de política de segurança (secpol.msc). No Windows Vista ou no Windows Server 2008, é possível definir a política mais detalhada de aplicativo gerado na linha de comando usando o programa de política 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.

Visão geral do uso de auditoria do SQL Server

É possível usar o SQL Server Management Studio ou o Transact-SQL para definir uma auditoria. Após a criação e habilitação da auditoria, o destino receberá entradas.

É possível ler os logs de eventos do Windows usando o utilitário Visualizador de Eventos do Windows. Para destinos de arquivo, é possível usar o Visualizador do Arquivo de Log no SQL Server Management Studio ou a função fn_get_audit_file para ler o arquivo de destino.

O processo geral para criar e usar uma auditoria do é o seguinte.

  1. Crie uma auditoria e defina o destino.

  2. Crie uma especificação da auditoria do servidor ou especificação da auditoria do banco de dados que mapeie para a auditoria. Habilite a especificação de auditoria.

  3. Habilite a auditoria.

  4. Leia os eventos de auditoria usando o recurso Visualizador de Eventos do Windows, o Visualizador do Arquivo de Log ou a função fn_get_audit_file.

O tópico Tópicos de instruções da auditoria do SQL Server fornece exemplos do SQL Server Management Studio e do Transact-SQL para usar o recurso de auditoria.

Considerações

No caso de falha durante o início da auditoria, o servidor não será iniciado. Nesse caso, é possível iniciar o servidor usando a opção –f na linha de comando.

Quando uma falha na auditoria faz com que o servidor seja desligado ou não seja iniciado devido à especificação de ON_FAILURE=SHUTDOWN para a auditoria, o evento MSG_AUDIT_FORCED_SHUTDOWN é gravado no log. Como o desligamento ocorrerá ao encontrar essa configuração pela primeira vez, o evento será gravado uma vez. Esse evento será gravado após a mensagem de falha da auditoria provocar o desligamento. Um administrador pode ignorar os desligamentos induzidos por auditoria iniciando o SQL Server no modo Usuário Único usando o sinalizador –m. Se você iniciar no modo Usuário Único, desatualizará qualquer auditoria na em que ON_FAILURE=SHUTDOWN for especificado para execução na sessão como ON_FAILURE=CONTINUE. Quando o SQL Server for iniciado pelo sinalizador –m, a mensagem MSG_AUDIT_SHUTDOWN_BYPASSED será gravada no log de erros.

Para obter mais informações sobre opções de inicialização de serviço, consulte Usando as opções de inicialização do serviço do SQL Server.

Anexando um banco de dados a uma auditoria definida

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.

Espelhamento de banco de dados e auditoria do SQL Server

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.