Pensando em um projeto de banco de dados para log de auditoria? Lembre-se do que aconteceu com João e Maria:eles achavam que deixar um rastro simples de migalhas de pão era uma boa maneira de rastrear seus passos.
Quando projetamos um modelo de dados, somos treinados para aplicar a filosofia de que agora é tudo o que existe . Por exemplo, se projetarmos um esquema para armazenar os preços de um catálogo de produtos, podemos pensar que o banco de dados precisa apenas nos informar o preço de cada produto no momento. Mas se quiséssemos saber se os preços foram modificados e, em caso afirmativo, quando e como essas modificações ocorreram, estaríamos em apuros. É claro que poderíamos projetar o banco de dados especificamente para manter um registro cronológico das alterações – comumente conhecido como trilha de auditoria ou log de auditoria.
O registro de auditoria permite que um banco de dados tenha uma 'memória' de eventos passados. Continuando com o exemplo da lista de preços, um log de auditoria adequado permitirá que o banco de dados nos diga exatamente quando um preço foi atualizado, qual era o preço antes de ser atualizado, quem o atualizou e de onde.
Soluções de registro de auditoria de banco de dados
Seria ótimo se o banco de dados pudesse manter um instantâneo de seu estado para cada alteração que ocorresse em seus dados. Dessa forma, você pode voltar a qualquer ponto no tempo e ver como os dados estavam naquele exato momento, como se estivesse rebobinando um filme. Mas essa maneira de gerar log de auditoria é obviamente impossível; o volume resultante de informações e o tempo que levaria para gerar os logs seriam muito altos.
As estratégias de registro de auditoria são baseadas na geração de trilhas de auditoria apenas para dados que podem ser excluídos ou modificados. Qualquer alteração neles deve ser auditada para reverter as alterações, consultar os dados nas tabelas de histórico ou rastrear atividades suspeitas.
Existem várias técnicas populares de registro de auditoria, mas nenhuma delas atende a todos os propósitos. Os mais eficazes geralmente são caros, consomem muitos recursos ou degradam o desempenho. Outros são mais baratos em termos de recursos, mas são incompletos, difíceis de manter ou exigem um sacrifício na qualidade do projeto. A estratégia escolhida dependerá dos requisitos do aplicativo e dos limites de desempenho, recursos e princípios de design que você precisa respeitar.
Soluções de registro prontas para uso
Essas soluções de log de auditoria funcionam interceptando todos os comandos enviados ao banco de dados e gerando um log de alterações em um repositório separado. Esses programas oferecem várias opções de configuração e relatórios para rastrear as ações do usuário. Eles podem registrar todas as ações e consultas enviadas a um banco de dados, mesmo quando vierem de usuários com os privilégios mais altos. Essas ferramentas são otimizadas para minimizar o impacto no desempenho, mas isso geralmente tem um custo monetário.
O preço das soluções dedicadas de trilha de auditoria pode ser justificado se você estiver lidando com informações altamente confidenciais (como registros médicos) onde qualquer alteração dos dados deve ser perfeitamente monitorada e auditável e a trilha de auditoria deve ser inalterável. Mas quando os requisitos de trilha de auditoria não são tão rigorosos, o custo de uma solução de registro dedicada pode ser excessivo.
As ferramentas nativas de monitoramento oferecidas pelos sistemas de banco de dados relacional (RDBMSs) também podem ser usadas para gerar trilhas de auditoria. As opções de customização permitem filtrar quais eventos são registrados, para não gerar informações desnecessárias ou sobrecarregar o mecanismo de banco de dados com operações de log que não serão utilizadas posteriormente. Os logs gerados desta forma permitem um acompanhamento detalhado das operações executadas nas tabelas. No entanto, eles não são úteis para consultar tabelas de histórico, pois registram apenas eventos.
A opção mais econômica para manter uma trilha de auditoria é projetar especificamente seu banco de dados para registro de auditoria. Essa técnica é baseada em tabelas de log que são preenchidas por gatilhos ou mecanismos específicos do aplicativo que atualiza o banco de dados. Não existe uma abordagem universalmente aceita para o projeto de banco de dados de log de auditoria, mas existem várias estratégias comumente usadas, cada uma com seus prós e contras.
Técnicas de design de registro de auditoria de banco de dados
Versão de linha para log de auditoria no local
Uma maneira de manter uma trilha de auditoria para uma tabela é adicionar um campo que indique o número da versão de cada registro. As inserções na tabela são salvas com um número de versão inicial. Quaisquer modificações ou exclusões realmente se tornam operações de inserção, onde novos registros são gerados com os dados atualizados e o número da versão é incrementado em um. Você pode ver um exemplo desse design de log de auditoria no local abaixo:
Observação:Os designs de tabela com versão de linha incorporada não podem ser vinculados por relacionamentos de chave estrangeira.
Além do número da versão, alguns campos extras devem ser adicionados à tabela para determinar a origem e a causa de cada alteração feita em um registro:
- A data/hora em que a alteração foi registrada.
- O usuário e o aplicativo.
- A ação realizada (inserir, atualizar, excluir), etc. Para que a trilha de auditoria seja efetiva, a tabela deve suportar apenas inserções (atualizações e exclusões não devem ser permitidas). A tabela também requer necessariamente uma chave primária substituta, pois qualquer outra combinação de campos estará sujeita a repetição.
Para acessar os dados atualizados da tabela por meio de consultas, você deve criar uma visualização que retorne apenas a versão mais recente de cada registro. Em seguida, você deve substituir o nome da tabela pelo nome da exibição em todas as consultas, exceto aquelas especificamente destinadas a exibir a cronologia dos registros.
A vantagem dessa opção de versionamento é que ela não requer o uso de tabelas adicionais para gerar a trilha de auditoria. Além disso, apenas alguns campos são adicionados às tabelas auditadas. Mas tem uma enorme desvantagem:forçará você a cometer alguns dos erros mais comuns de design de banco de dados. Isso inclui não usar integridade referencial ou chaves primárias naturais quando necessário, impossibilitando a aplicação dos princípios básicos do design do diagrama entidade-relacionamento. Você pode visitar esses recursos úteis sobre erros de design de banco de dados, para ser avisado sobre quais outras práticas devem ser evitadas.
Tabelas de sombra
Outra opção de trilha de auditoria é gerar uma tabela de sombra para cada tabela que precisa ser auditada. As tabelas de sombra contêm os mesmos campos que as tabelas auditadas, mais os campos de auditoria específicos (os mesmos mencionados para a técnica de controle de versão de linha).
As tabelas de sombra replicam os mesmos campos que as tabelas auditadas, mais os campos específicos para fins de auditoria.
Para gerar trilhas de auditoria em tabelas shadow, a opção mais segura é criar triggers de inserção, atualização e exclusão, que para cada registro afetado na tabela original geram um registro na tabela de auditoria. Os gatilhos devem ter acesso a todas as informações de auditoria que você precisa registrar na tabela de sombra. Você terá que usar a funcionalidade específica do mecanismo de banco de dados para obter dados como data e hora atuais, usuário registrado, nome do aplicativo e o local (endereço de rede ou nome do computador) de origem da operação.
Se o uso de triggers não for uma opção, a lógica para gerar as trilhas de auditoria deve fazer parte da pilha da aplicação, em uma camada idealmente localizada logo antes da camada de persistência de dados, para que possa interceptar todas as operações direcionadas ao banco de dados.
Esse tipo de tabela de log deve permitir apenas a inserção de registros; se permitirem a modificação ou exclusão, a trilha de auditoria não cumprirá mais sua função. As tabelas também devem usar chaves primárias substitutas, pois as dependências e relacionamentos das tabelas originais não podem ser aplicadas a elas.
Se a tabela para a qual você criou uma trilha de auditoria tiver tabelas das quais depende, elas também devem ter tabelas de sombra correspondentes. Isso é para que a trilha de auditoria não fique órfã se forem feitas alterações nas outras tabelas.
As tabelas de sombra são convenientes devido à sua simplicidade e porque não afetam a integridade do modelo de dados; as trilhas de auditoria permanecem em tabelas separadas e são fáceis de consultar. A desvantagem é que o esquema não é flexível:qualquer alteração na estrutura da tabela principal deve ser refletida na tabela sombra correspondente, o que dificulta a manutenção do modelo. Além disso, se o log de auditoria precisar ser aplicado a um grande número de tabelas, o número de tabelas de sombra também será alto, dificultando ainda mais a manutenção do esquema.
Tabelas genéricas para registro de auditoria
Uma terceira opção é criar tabelas genéricas para logs de auditoria. Essas tabelas permitem o registro de qualquer outra tabela no esquema. Apenas duas tabelas são necessárias para esta técnica:
Uma tabela de cabeçalho que registra:
- A data e a hora da alteração.
- O nome da tabela.
- A chave da linha afetada.
- Os dados do usuário.
- O tipo de operação realizada.
Uma tabela de detalhes que registra:
- Os nomes de cada campo afetado.
- Os valores do campo antes da modificação.
- Os valores do campo após a modificação. (Você pode omitir isso se necessário, pois pode ser obtido consultando o seguinte registro na trilha de auditoria ou o registro correspondente na tabela auditada.)
O uso de tabelas de log de auditoria genéricas limita os tipos de dados que podem ser auditados.
A vantagem dessa estratégia de log de auditoria é que ela não requer nenhuma tabela além das duas mencionadas acima. Além disso, os registros são armazenados nele apenas para os campos afetados por uma operação. Isso significa que não há necessidade de replicar uma linha inteira de uma tabela quando apenas um campo é modificado. Além disso, essa técnica permite que você mantenha um log de quantas tabelas desejar – sem sobrecarregar o esquema com um grande número de tabelas adicionais.
A desvantagem é que os campos que armazenam os valores devem ser de um único tipo – e amplos o suficiente para armazenar até mesmo o maior dos campos das tabelas para as quais você deseja gerar um log de auditoria. É mais comum usar campos do tipo VARCHAR que aceitam um grande número de caracteres.
Se, por exemplo, você precisar gerar um log de auditoria para uma tabela que tenha um campo VARCHAR de 8.000 caracteres, o campo que armazena os valores na tabela de auditoria também deverá ter 8.000 caracteres. Isso é verdade mesmo se você armazenar apenas um inteiro nesse campo. Por outro lado, se sua tabela possui campos de tipos de dados complexos, como imagens, dados binários, BLOBs, etc., você precisará serializar seus conteúdos para que possam ser armazenados nos campos VARCHAR das tabelas de log.
Escolha seu design de log de auditoria de banco de dados com sabedoria
Vimos várias alternativas para gerar log de auditoria, mas nenhuma delas é realmente ideal. Você deve adotar uma estratégia de log que não afete substancialmente o desempenho de seu banco de dados, não o faça crescer excessivamente e possa atender aos seus requisitos de rastreabilidade. Se você deseja armazenar logs apenas para algumas tabelas, as tabelas de sombra podem ser a opção mais conveniente. Se você deseja a flexibilidade de registrar qualquer tabela, as tabelas de registro genéricas podem ser melhores.
Você descobriu outra maneira de manter um log de auditoria para seus bancos de dados? Compartilhe na seção de comentários abaixo – seus colegas designers de banco de dados ficarão muito gratos!
