Como habilitar o SQL Server Audit e revisar o Log de Auditoria

Auditar o Microsoft SQL Server é essencial para identificar problemas de segurança e violações. Além disso, a auditoria do SQL Server é um requisito para a conformidade com regulamentos como PCI DSS e HIPAA.

O primeiro passo é definir o que auditar. Por exemplo, você pode auditar logins de usuários, configuração de servidores, alterações de esquema e modificações de dados de auditoria. Em seguida, você deve escolher quais recursos de auditoria de segurança utilizar. Recursos úteis incluem os seguintes:

• Auditoria C2
• Critérios Comuns de Conformidade
• Auditoria de Login
• Auditoria do SQL Servering
• SQL Trace
• Eventos Estendidos
• Captura de Dados de Mudança
• Gatilhos DML, DDL e de Logon

Este artigo é para administradores de banco de dados (DBAs) que estão considerando o uso de auditoria C2, Critérios Comuns de Conformidade e Auditoria do SQL Server. Não estaremos analisando ferramentas de auditoria de terceiros, embora elas possam ser de grande ajuda, especialmente para ambientes maiores e em indústrias regulamentadas.

Habilitando Auditoria C2 e Conformidade com Critérios Comuns

Se você atualmente não está auditando seu SQL Server, o lugar mais fácil para começar é habilitando a auditoria C2. A auditoria C2 é um padrão internacionalmente aceito que pode ser ativado no SQL Server. Ela audita eventos como logins de usuários, procedimentos armazenados e a criação e remoção de objetos. Mas é tudo ou nada — você não pode escolher o que ela audita, e pode gerar uma grande quantidade de dados. Além disso, a auditoria C2 está em modo de manutenção, então é provável que seja removida em uma versão futura do SQL Server.

A Conformidade com os Critérios Comuns é um padrão mais recente que substitui a auditoria C2. Foi desenvolvido pela União Europeia e pode ser ativado nas edições Enterprise e Datacenter do SQL Server 2008 R2 e posteriores. No entanto, pode causar problemas de desempenho se o seu servidor não estiver suficientemente equipado para lidar com a sobrecarga adicional.

Veja como habilitar a auditoria C2 no SQL Server 2017:

1. Abra o SQL Server Management Studio.

2. Conecte-se ao mecanismo de banco de dados para o qual deseja habilitar a auditoria C2. Na caixa de diálogo Conectar ao Servidor, certifique-se de que Server type esteja definido como Database Engine e então clique em Connect.

3. No painel Explorador de Objetos à esquerda, clique com o botão direito na sua instância do SQL Server no topo e selecione Properties no menu.

4. Na janela Propriedades do Servidor, clique em Security em Select a page.

5. Na página de Segurança, você pode configurar o monitoramento de login. Por padrão, apenas logins mal-sucedidos são registrados. Alternativamente, você pode auditar apenas logins bem-sucedidos ou ambos, logins mal-sucedidos e bem-sucedidos.

Figura 1. Configurando a auditoria de acesso

6. Marque Habilitar rastreamento de auditoria C2 em Options.

7. Se você deseja habilitar a auditoria de conformidade com os Critérios Comuns C2, marque Enable Common Criteria compliance.

A conformidade com os Critérios Comuns (CC) é um padrão flexível que pode ser implementado com diferentes Níveis de Garantia de Avaliação (EALs), de 1 a 7. Níveis EAL mais altos possuem um processo de verificação mais exigente. Quando você ativa a opção Enable Common Criteria compliance no SQL Server, está habilitando a Conformidade CC EAL1. É possível configurar o SQL Server manualmente para EAL4+.

Habilitar mudanças de CC Compliance altera o comportamento do SQL Server. Por exemplo, permissões de DENY a nível de tabela terão precedência sobre GRANTs a nível de coluna, e tanto logins bem-sucedidos quanto falhos serão auditados. Além disso, a Proteção de Informações Residuais (RIP) é ativada, que sobrescreve alocações de memória com um padrão de bits antes de serem usadas por um novo recurso.

8. Clique em OK.

9. Com base nas opções selecionadas, você pode ser solicitado a reiniciar o SQL Server. Se receber esta mensagem, clique em OK no diálogo de aviso. Se você ativou a Conformidade com Critérios Comuns C2, reinicie o servidor. Caso contrário, clique com o botão direito do mouse na sua instância do SQL Server no Object Explorer novamente e selecione Restart no menu. No diálogo de aviso, clique em Yes para confirmar que deseja reiniciar o SQL Server.

Habilitando o SQL Server Audit

A auditoria do SQL Server pode ser ativada em vez da auditoria C2; você também pode optar por ativar ambas. Os objetos de Auditoria do SQL Server podem ser configurados para coletar eventos no nível do servidor ou no nível do banco de dados do SQL Server.

Criar Objeto de Auditoria de Servidor

Vamos criar um objeto de auditoria do SQL Server no nível do servidor:

1. No painel Object Explorer à esquerda, expanda Security.

2. Clique com o botão direito em Audits e selecione New Audit… no menu. Isso criará um novo objeto SQL Server Audit para auditoria no nível do servidor.

3. Na janela Criar Auditoria, dê um nome às configurações de auditoria em Audit name

4. Especifique o que deve acontecer se a auditoria do SQL Server falhar usando a opção On Audit Log Failure. Você pode escolher Continue ou optar por desligar o servidor ou interromper as operações de banco de dados que são auditadas. Se você selecionar Fail operation, as operações de banco de dados que não são auditadas continuarão funcionando.

Figura 2. Criando um objeto de auditoria de nível de servidor SQL Server

5. No menu suspenso Audit destination, você pode escolher gravar o rastro de auditoria SQL em um arquivo ou nos eventos de auditoria do log de Segurança do Windows ou log de Eventos de Aplicativo. Se escolher um arquivo, você deve especificar um caminho para o arquivo.

Observe que, se você deseja escrever no log de eventos de Segurança do Windows, o SQL Server precisará receber permissão. Para simplificar, selecione o log de eventos de Aplicativo. Além disso, você pode incluir um filtro como parte do objeto de auditoria para fornecer um conjunto restrito de resultados; os filtros devem ser escritos em Transact-SQL (T-SQL).

6. Clique em OK.

7. Agora você encontrará a nova configuração de auditoria no Object Explorer abaixo de Audits. Clique com o botão direito na nova configuração de auditoria e selecione Enable Audit no menu.

8. Clique em Close no diálogo Enable Audit.

Criar Objeto de Auditoria de Banco de Dados

Para criar um objeto de auditoria SQL Server para auditoria em nível de banco de dados, o processo é um pouco diferente e você precisa criar pelo menos um objeto de auditoria em nível de servidor primeiro.

1. Expanda Databases no Object Explorer e expanda o banco de dados no qual você deseja configurar a auditoria.

2. Expanda a pasta Security, clique com o botão direito em Database Audit Specifications e selecione New Database Audit Specification… no menu.

Figura 3. Criando uma especificação de auditoria de servidor para auditoria a nível de banco de dados

3. Na janela Propriedades, na seção Ações, utilize os menus suspensos para configurar um ou mais tipos de ação de auditoria, selecionando as declarações que deseja auditar (como DELETE ou INSERT), a classe de objeto na qual a ação é realizada, e assim por diante.

4. Quando terminar, clique em OK e depois ative o objeto de auditoria clicando com o botão direito e selecionando Enable Database Audit Specification.

Visualizando Logs de Auditoria do SQL Server

Os logs de auditoria do C2 Audit SQL Server são armazenados no diretório de dados padrão da instância do SQL Server. Cada arquivo de log pode ter no máximo 200 megabytes. Um novo arquivo é criado automaticamente quando o limite é atingido.

Uma solução nativa recomendada para visualizar os logs de auditoria do SQL Server chamada Log File Viewer. Para usá-la, siga os passos a seguir:

1. No SQL Server Management Studio, no painel Object Explorer, expanda Security e

2. Clique com o botão direito do mouse no objeto de auditoria que deseja visualizar e selecione View Audit Logs no menu.

3. No Log File Viewer, os registros serão exibidos no lado direito. Independentemente de os registros serem escritos em um arquivo ou no Windows Event Log, o Log File Viewer exibirá os registros.

4. No topo do Log File Viewer, você pode clicar em Filter para personalizar quais entradas de log são exibidas. Os logs de arquivo do SQL Server são salvos no formato .sqlaudit e não são legíveis, então o Log File Explorer permite que você clique em Export para salvar os logs em um formato de arquivo delimitado por vírgulas .log.

Figura 4. Revisando o registro de auditoria do SQL Server no Log File Viewer

FAQ

Como verificar se o audit do SQL Server está habilitado?

Para verificar se a auditoria do SQL Server está ativada, consulte a visualização de gerenciamento dinâmico sys.dm_server_audit_status ou verifique a pasta Segurança no SQL Server Management Studio (SSMS). No SSMS, expanda Segurança > Auditorias para ver todas as auditorias configuradas e o seu status atual – auditorias ativadas mostrarão um ícone verde, enquanto as desativadas aparecerão com um ícone vermelho. Você também pode executar esta consulta para verificar o status da auditoria programaticamente:

      SELECT name, is_state_enabled FROM sys.server_audits
      

Lembre-se de que tanto a auditoria do servidor quanto a especificação de auditoria do banco de dados devem estar ativadas para uma cobertura de auditoria completa. Data Security That Starts with Identity exige uma visibilidade abrangente sobre quem está acessando quais dados, e a auditoria do SQL Server fornece essa base quando configurada e verificada adequadamente.

Por que meu arquivo de auditoria do SQL Server está crescendo tanto?

O crescimento excessivo do arquivo de auditoria geralmente ocorre quando você está auditando muitos eventos ou não configurou as definições de gerenciamento de arquivos adequadamente. Os culpados mais comuns são a ativação de TODOS os grupos de ações de auditoria, auditando instruções SELECT em tabelas de alto tráfego ou definindo crescimento ilimitado do arquivo sem rotação. Para controlar o crescimento, concentre-se em auditar apenas os eventos que você realmente precisa para conformidade – tipicamente LOGIN_CHANGE_PASSWORD_GROUP, DATABASE_PERMISSION_CHANGE_GROUP, e operações DML específicas em tabelas sensíveis. Configure limites máximos de tamanho de arquivo e habilite a rotação de arquivos com as opções MAXSIZE e MAX_ROLLOVER_FILES. Para ambientes de alto volume, considere usar o destino APPLICATION_LOG em vez de destino FILE, ou implemente filtragem de auditoria com cláusulas WHERE para reduzir a captura de eventos desnecessários. Auditar de forma inteligente significa rastrear o que importa sem se afogar em ruído de dados.

Como solucionar problemas quando o auditório do SQL Server não inicia?

Quando a auditoria do SQL Server falha ao iniciar, o problema geralmente está relacionado a permissões de arquivo, acessibilidade do caminho ou conflitos de configuração. Primeiro, verifique se a conta de serviço do SQL Server tem permissões de escrita para o diretório do arquivo de auditoria – essa é a causa mais comum de falhas na inicialização. Verifique o log de erros do SQL Server para mensagens de erro específicas, que normalmente fornecem orientações claras sobre o problema. Certifique-se de que o diretório de destino existe e está acessível a partir da instância do SQL Server, especialmente em ambientes clusterizados onde os caminhos de armazenamento compartilhado devem ser válidos em todos os nós. Se estiver usando o Log de Aplicativos do Windows como destino, verifique se a conta de serviço tem permissões apropriadas de escrita no log de eventos. Erros de configuração, como nomes de auditoria duplicados ou caminhos de arquivo inválidos, também impedirão a inicialização. A chave é a resolução de problemas metódica: verifique as permissões primeiro, depois os caminhos e, em seguida, a sintaxe da configuração. Netwrix simplifica essa complexidade ao fornecer gerenciamento de auditoria centralizado que elimina essas armadilhas comuns.

Qual é o impacto no desempenho da auditoria do SQL Server?

A auditoria do SQL Server tem um impacto mínimo no desempenho quando configurada corretamente, adicionando tipicamente uma sobrecarga de 2-5% na maioria dos ambientes. O impacto real depende de três fatores-chave: quais eventos você audita, com que frequência eles ocorrem e o desempenho do subsistema de armazenamento. Auditar operações de alta frequência como instruções SELECT em sistemas OLTP movimentados criará mais sobrecarga do que focar em eventos relevantes para a segurança, como logins, alterações de permissões e operações DML em tabelas sensíveis. Destinos de auditoria assíncronos (o padrão) oferecem melhor desempenho do que as opções síncronas, mas com um registro de eventos ligeiramente atrasado. Para minimizar o impacto, use filtragem de auditoria com cláusulas WHERE, evite auditar operações desnecessárias do sistema e garanta que seu armazenamento de arquivos de auditoria tenha capacidade de E/S adequada. Eventos Estendidos geralmente têm menor sobrecarga do que o SQL Server Audit para cenários de alto volume, mas o SQL Server Audit oferece recursos de conformidade superiores e gerenciamento mais fácil. Um design de auditoria inteligente foca no valor de segurança em vez de um registro abrangente – você quer visibilidade que proteja sem paralisar o desempenho.

Auditoria do SQL Server vs SQL Trace: qual devo usar?

SQL Server Audit é a escolha moderna para novas implementações, enquanto SQL Trace está obsoleto e deve ser evitado para novos projetos. SQL Server Audit oferece melhor segurança, desempenho e capacidades de gestão em comparação com a funcionalidade legada do SQL Trace. Ao contrário do SQL Trace, os eventos do SQL Server Audit não podem ser modificados ou excluídos pelos usuários (incluindo sysadmins), garantindo a integridade da auditoria para requisitos de conformidade. A estrutura de auditoria oferece processamento assíncrono para melhor desempenho, capacidades de filtragem integradas e integração com o Log de Eventos de Segurança do Windows. SQL Trace requer codificação manual com procedimentos armazenados e foi marcado para remoção em versões futuras do SQL Server. Extended Events é a substituição recomendada para as capacidades de diagnóstico do SQL Trace, enquanto SQL Server Audit lida com monitoramento de segurança e conformidade. Se você está atualmente usando SQL Trace para auditoria de segurança, migre para SQL Server Audit imediatamente – ele fornece o registro de auditoria à prova de adulteração que a verdadeira segurança de dados exige. As soluções da Netwrix constroem sobre essas capacidades de auditoria nativas para fornecer visibilidade centralizada em todo o seu ambiente de dados.