Em vários dos projetos em que trabalhamos, os clientes nos pediram para registrar mais ações do usuário no banco de dados. Eles querem saber todas as ações que os usuários realizam no aplicativo, mas capturar e registrar todas as interações humanas pode ser um desafio. Tivemos que registrar todas as modificações de dados realizadas através do sistema. Este artigo descreve algumas das armadilhas que encontramos e as abordagens que usamos para superá-las.
Introdução
Trabalho como arquiteto de soluções em serviços financeiros. É importante manter um registro do último usuário que modificou uma linha. Nos casos mais simples, basta registrar o timestamp da modificação para ter rastreabilidade de mudanças. Aqui está um exemplo simples de uma tabela que armazena contratos de clientes que incluem
last_changed colunas para usuário e carimbo de data/hora. No entanto, em alguns casos, isso não é suficiente. Muitas vezes, precisamos ter rastreabilidade total (incluindo antes e depois de "imagens" dos dados). Em alguns casos, também precisamos de auditabilidade (quem, o que, quando).
Infelizmente, muitos de nossos sistemas não foram projetados para fornecer rastreabilidade e auditabilidade. Precisávamos de engenharia reversa esses requisitos de operações de negócios nos sistemas.
Rastreabilidade
Em alguns casos, descobrimos que a rastreabilidade é fácil de alcançar. Enquanto, em outros, achamos difícil ou mesmo impossível. Dependendo do seu sistema, a solução pode ser simples. Seu acesso a dados pode permitir uma simples injeção de registro de imagens antes e depois dos dados. Esse log pode ser implementado de forma que os resultados sejam armazenados em uma tabela de banco de dados em vez de em um arquivo de log. Em alguns produtos, conseguimos isso de maneira direta por meio da persistência camada. Por exemplo, isso era possível com Hibernar .
Aqui você pode ver uma entrada para cada item da trilha de auditoria, além de haver valores antes e depois de cada coluna que foi alterada. Além disso, no caso de uma linha ser excluída, salvamos essa informação com o
functioncode indicando deletar. Optamos por usar varchar(1) para armazenar o código da função (C, R, D) especificando o tipo de modificação, em vez do nome ou descrição da “operação” (Create, Update, Delete) que foi executada . A instance_key contém a chave primária do item que foi adicionado, modificado ou excluído, para rastreabilidade. No entanto, pode ser que sua camada de acesso a dados não forneça a funcionalidade necessária para você. Para outros produtos, nossa camada de acesso a dados não. Nesses casos, a rastreabilidade exigia mudanças complexas. Por exemplo, você pode precisar de recuperação e registro de quaisquer dados antes da modificação. Como escrevi, isso é possível, mas pode ser complexo de implementar. Os desenvolvedores teriam que criar uma recuperação de cada linha antes de modificar uma linha. Não seria possível executar uma atualização sem um select.
Como você pode contornar a rastreabilidade? Uma solução possível é garantir que você conheça a situação inicial de todos os dados, ou seja, a situação inicial criada por quaisquer dados estáticos carregados no sistema. Então, você teria que registrar todas as modificações. Em outras palavras, quais são todas as imagens “depois” dos dados? Dessa forma, seria possível “avançar ” dos dados estáticos carregados. Todas as atualizações feitas até aquele momento são aplicadas. Esta é uma situação menos do que ideal, mas pode ser aceitável.
Uma tabela simples pode ser usada se a única informação disponível for o novo valor e não o valor anterior.
Auditoria
Em algumas situações, devemos garantir que todas as ações realizadas no sistema sejam totalmente auditáveis . Quem entrou a que horas? Quais ações cada usuário realizou no sistema, incluindo apenas a visualização de dados? Isso é importante porque pode ser significativo se um usuário analisar um pagamento.
Para alcançar o rastreamento refinado pode ser difícil olhar apenas para o acesso ao banco de dados. Muitas vezes devemos olhar para um nível superior e examinar as ações ou serviços realizados. Em alguns casos, conseguimos rastrear cada chamada de serviço para saber o que um usuário fez em que momento. Com um controlador de entrada/saída de serviço da Web, o registro de solicitações de serviço foi bastante fácil.
Aqui está um exemplo de um log de auditoria de usuário simples onde registramos a ação que cada usuário executa. Discuto algumas questões sobre essa abordagem na próxima seção “Prova”.
Uma breve descrição da tabela é fornecida abaixo:
O
user_audit A tabela contém entradas de auditoria de dados com registro de data e hora. A chave primária consiste no audit_entry_time carimbo mais o user_id e bank_id mais o nome da action realizado. Os campos têm significados que correspondem aos seus nomes. A tabela de auditoria armazena o result da ação, mais a class real que executou a ação, seus parameters de entrada e quaisquer errors . Aqui está outro exemplo de uma trilha de auditoria onde registramos as imagens antes e depois dos dados que foram modificados em uma tabela específica (junto com a ação realizada, credenciais do usuário e carimbo de data/hora).
O
audit_trail A tabela contém entradas de auditoria de imagens antes e depois dos dados. A chave primária consiste na audit_gen_key que é uma chave gerada pelo aplicativo. Os campos têm significados que correspondem aos seus nomes. O nome da tabela de banco de dados para a qual esta entrada de trilha de auditoria é registrada é armazenada em modified_table , mais a imagem "antes" é armazenada em prev_value e a imagem “depois” em new_value . O module que está realizando a modificação e o funct_type de modificação (Criar, Atualizar, Excluir) também são armazenados. Por fim, as informações de auditoria do user_id (e bank_id correspondente ) mais o carimbo de data/hora da alteração (date_last_changed ). Então nós batemos um desafio. Ao registrar as informações de rastreabilidade e auditabilidade, o registro ocorre duas vezes. Do ponto de vista da auditoria, isso é irritante. Os auditores devem garantir que as informações sejam as mesmas entre esses dois logs.
Prova
Outro desafio foi garantir o registro de todas as ações do usuário . Isso é muitas vezes exigido por auditores no setor de serviços financeiros.
Agora temos um verdadeiro desafio. Nossa solução foi garantir a rastreabilidade central e o registro de auditabilidade. As “interfaces” centrais garantem que todas as implementações dessa interface incluam registro. Foi direto garantir que todas as classes apropriadas estivessem implementando a interface.
Claro, isso não garante 100% de prova de registro. É uma forte verificação de segurança que todas as classes apropriadas foram registradas conforme necessário.
Conclusão
A engenharia reversa de novas funcionalidades de negócios em um sistema existente é sempre um desafio. Este pode ser ainda mais o caso quando a funcionalidade implementada vai para o núcleo.
