Por que eu devo ler este artigo:Este artigo aborda práticas de auditoria em servidores SQL Server 2012 baseado em monitorar ações realizadas a nível de instância e base de dados no cenário de produção, desenvolvimento ou teste.

A importância de auditar uma instância/base está em manter o controle do ambiente, notificando os responsáveis pelas ações, possibilitando acrescentar políticas de segurança para evitar tragédias no ambiente de banco de dados. A prática de auditoria é útil para qualquer ambiente de administração de banco de dados, onde o DBA responsável deseja melhorar sua segurança e integridade.

Este artigo descreve como criar um cenário de auditoria a nível de servidor e base de dados com as ferramentas nativas do SQL server 2012, evitando a criação de objetos que podem impactar no desempenho nas atividades operacionais como triggers, procedures e funções. O recurso de auditoria mantém o ambiente íntegro possibilitando o rastreamento das atividades incomuns que podem acarretar em exclusão, inserção ou atualização indesejada e os responsáveis por tal ação.

O conceito de auditoria baseia-se em uma análise cuidadosa e sistemática das atividades desenvolvidas em determinada empresa ou setor, cujo objetivo é averiguar se elas estão de acordo com as disposições planejadas e/ou estabelecidas previamente, se foram implementadas com eficácia e se estão adequadas (em conformidade) à consecução dos objetivos.

Auditoria de banco de dados do SQL Server não é usada apenas para atender às exigências de auditoria de conformidade. Tornou-se necessária para a análise das ações do banco de dados, resolução de problemas, investigando atividades suspeitas e mal-intencionadas. A auditoria também pode ajudar os usuários na prevenção de ações inadequadas.

A auditoria de uma instância do SQL Server ou de um banco de dados individual envolve o controle e o registro em log dos eventos que ocorrem no SGBD. O SQL Server permite criar auditorias a nível de servidor, que podem conter especificações de eventos do mesmo, além de especificações de auditoria a nível de banco de dados para seus eventos. Os eventos auditados podem ser gravados nos logs de eventos do sistema operacional, no log de eventos do SQL Server ou nos arquivos de auditoria.

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 por banco de dados. O evento de auditoria ocorrerá sempre que a ação auditável for encontrada.

Todas as edições do SQL Server oferecem suporte a auditorias no nível do servidor. As auditorias no nível de banco de dados são limitadas às edições Enterprise, Developer e Evaluation.

Rastreando alterações

As aplicações frequentemente têm requisitos para auditar alterações para uma ou mais tabelas. Antes do SQL Server 2008, os desenvolvedores tinham de criar tabelas e triggers DML para registras as informações de auditoria. O SQL Server 2008 vem com dois novos recursos para rastrear alterações de dados: change tracking e change data capture.

O change traking captura o fato de que uma linha foi alterada em uma tabela, mas não registra os dados reais que foram alterados.

Já o change data capture captura o fato de que uma linha foi alterada em uma tabela, bem como os dados reais que foram alterados.

Change Tracking

O change tracking está limitado a registrar que uma alteração foi feita em uma linha dentro de uma tabela. Após ativar o rastreamento de alteração em um nível de banco de dados, você ativa o change tracking em um nível de tabela para cada uma que deseja rastrear. Cada tabela de usuário com esse recurso ativado terá sua própria tabela de change tracking. As alterações podem ser rastreadas no nível de tabela ou no nível de coluna.

As alterações são capturadas e registradas por meio de um processo síncrono e leve, e armazenadas em uma tabela de alteração. O overhead associado ao change tracking é muito pequeno e depende em grande parte do tamanho de sua chave primária e do modo de change tracking que você está utilizando.

A tabela de change tracking armazena a chave primária, um número de versão para a criação da linha, um número de versão da última alteração de uma linha, o tipo d ...

Quer ler esse conteúdo completo? Seja um assinante e descubra as vantagens.
  • 473 Cursos
  • 10K Artigos
  • 100 DevCasts
  • 30 Projetos
  • 80 Guias
Tenha acesso completo