Gravar eventos de auditoria do SQL Server no log de segurança

Aplica-se a: SQL Server (somente para Windows)

em um ambiente de alta segurança, o log de Segurança do Windows é o local apropriado para gravar eventos que registram o acesso a objetos. Outros locais de auditoria têm suporte, mas estão mais sujeitos a falsificações.

Há três requisitos essenciais para gravar auditorias do servidor do SQL Server no log de segurança do Windows:

• É necessário configurar o acesso ao objeto de auditoria para capturar os eventos. A ferramenta de política de auditoria (auditpol.exe) expõe várias configurações de subpolíticas na categoria acesso ao objeto de auditoria . Para permitir que o SQL Server audite o acesso a objetos, defina a configuração de aplicativo gerado.

• A conta que o serviço SQL Server está executando deve ter a permissão gerar auditorias de segurança para gravar no log de Segurança do Windows. Por padrão, as contas LOCAL SERVICE e NETWORK SERVICE têm essa permissão. Esta etapa não será necessária se o SQL Server estiver sendo executado em uma dessas contas.

• Fornecer permissão total para a conta do serviço SQL Server para o hive de registro HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Security.

  Importante

  A edição incorreta do Registro pode danificar seriamente o sistema. Antes de fazer alterações no Registro, é recomendável fazer backup dos dados importantes no computador.

Limitações e restrições

• As configurações locais do log de segurança podem ser substituídas por uma política de domínio. Nesse caso, a política de domínio pode substituir a configuração de subcategoria (auditpol /get /subcategory:"application generated"). O SQL Server não tem como detectar que os eventos que está tentando auditar não serão registrados.

• Os eventos poderão ser perdidos se a política de auditoria estiver configurada incorretamente. A política de auditoria do Windows poderá afetar a auditoria do SQL Server se estiver configurada para gravar no log de Segurança do Windows. Normalmente, o log de segurança do Windows é definido para substituir os eventos mais antigos. Isso preserva os eventos mais recentes. Porém, se o log de segurança do Windows não estiver definido para substituir eventos mais antigos, quando ele estiver cheio, o sistema emitirá o evento 1104 do Windows (O log está cheio). Nesse momento:

  • Nenhum outro evento de segurança é registrado

  • O SQL Server não conseguirá detectar que o sistema não pode registrar os eventos no log de segurança, o que resultará na possível perda de eventos de auditoria

  • Depois que o administrador do computador corrigir o log de segurança, o comportamento de log voltará ao normal.

• Os registros de auditoria do SQL Server contêm muito mais dados do que as entradas regulares do log de eventos do Windows. Além disso, conforme a configuração da especificação de auditoria, o SQL Server pode gerar muitos milhares de registros de auditoria em pouco tempo (milhares por segundo). Em períodos de alta carga, pode resultar em condições adversas se os registros de auditoria forem gravados no log do aplicativo ou no log de segurança.

  Essas condições adversas podem incluir:

  • Ciclo rápido do log de eventos (os eventos são substituídos logo à medida que o arquivo de log atinge o limite de tamanho)

  • Outros aplicativos ou serviços que leem o log de eventos do Windows podem ser afetados negativamente

  • O log de eventos de destino pode ser inutilizável pelos administradores porque os eventos são substituídos tão rapidamente

  Etapas que administradores podem realizar para mitigar condições adversas:

  1. Aumentar o tamanho do log de destino (4 GB é razoável quando a especificação de auditoria é muito detalhada).

  2. Reduza o número de eventos em auditoria.

  3. Saída dos registros de auditoria para um arquivo em vez de logs de eventos.

Permissões

Você deve ser um administrador do Windows para definir essas configurações.

Definir a configuração de acesso ao objeto de auditoria no Windows usando auditpol

1. Abra um prompt de comando com permissões administrativas.

   1. No menu Iniciar, navegue até Prompt de comando e selecione Executar como administrador.

   2. Se a caixa de diálogo Controle de Conta de Usuário for aberta, escolha Continuar.

2. Execute a instrução a seguir para habilitar a auditoria de SQL Server.

   auditpol /set /subcategory:"application generated" /success:enable /failure:enable
   

3. Feche a janela do prompt de comando.

Conceder a permissão gerar auditorias de segurança a uma conta usando secpol

1. Para qualquer sistema operacional Windows, no menu Iniciar, escolha Executar.

2. Digite secpol.msc e selecione OK. Se a caixa de diálogo Controle de Acesso de Usuário for exibida, escolha Continuar.

3. Na ferramenta Política de segurança local, expanda Configurações de segurança > Políticas locais > Atribuição de direitos do usuário.

4. No painel de resultados, abra Gerar auditoria de segurança.

5. Na guia Configuração de segurança local, escolha Adicionar usuário ou grupo.

6. Na caixa de diálogo Selecionar usuários, computadores ou grupos, digite o nome da conta de usuário, como domain1\user1 e escolha OK ou Avançado e procure a conta.

7. Selecione OK.

8. Feche a ferramenta Política de Segurança.

9. Reinicie o SQL Server para habilitar essa configuração.

Definir a configuração de acesso ao objeto de auditoria no Windows usando secpol

1. Se o sistema operacional for anterior ao Windows Vista ou Windows Server 2008, no menu Iniciar, escolha Executar.

2. Digite secpol.msc e selecione OK. Se a caixa de diálogo Controle de Acesso de Usuário for exibida, escolha Continuar.

3. Na ferramenta Política de segurança local, expanda Configurações de segurança > Políticas locais > Política de auditoria.

4. No painel de resultados, abra Auditar acesso ao objeto.

5. Na guia Configuração de Segurança Local , na área Fazer a auditoria dessas tentativas , selecione Êxito e Falha.

6. Selecione OK.

7. Feche a ferramenta Política de Segurança.

Confira também

• Auditoria do SQL Server (Mecanismo de Banco de Dados)