Auditoria do MongoDB 3.6

Este artigo apresenta a implementação da solução utilizada para realizar auditoria das operações executadas na base de dados MongoDB na versão 3.6. A definição e implementação foram realizadas pelo meu colega Gabriel Prestes e eu Inácio Klassmann.

Recursos do MongoDB

O MongoDB implementou o recurso nativo de extração dos dados de auditoria apenas na versão 4.0, sendo assim, em versões anteriores este recurso não existe.

Existem outras formas de implementar a extração dos dados de auditoria, a primeira opção é chamada *Tailing the Oplog* que consiste em notificações em tempo real de todas as alterações em seu banco de dados. Um cursor disponível é conceitualmente o mesmo que o comando “tail -f” do Unix. Quando você chegar ao final do conjunto de resultados, o cursor não será fechado, mas continuará aguardando para sempre novos dados e quando chegar, retornará também. Tailing the Oplog é muito simples para réplicas sets, mas quando se trata de sharded clusters, as coisas são um pouco mais complexas.

A segunda opção de extração dos dados de auditoria é chamada *Change Stream* que surgiu na versão 3.6 do MongoDB. O Change Stream permite que as aplicações acessem as alterações de dados em tempo real, sem a complexidade e o risco de utilizar o Oplog. As aplicações podem usar Change Stream para assinar todas as alterações de dados de uma única Collection, um DataBase ou um Deploy e reagir imediatamente a eles. Como o Change Stream utiliza a estrutura de agregação, os aplicativos também podem filtrar alterações específicas ou transformar as notificações à vontade.

Necessidade

É uma característica muito comum em organizações financeiras realizarem auditoria de seus sistemas por diversos motivos legais. O principal deles é a questão de segurança e a rastreabilidade histórica de eventos/ações que geram alterações em seus dados. Portanto, necessitamos garantir que todas as operações sejam historizadas com propósito de auditoria.

Solução

Para garantir a integridade dos dados entre a base original e a base de auditoria, devemos realizar a coleta dos dados de forma assíncrona através da utilização de um Message Broker. Desta forma, foi desenvolvido um Agent Publisher do Change Stream que irá publicar os dados no Message Broker. Esta abordagem permite que os dados não sejam perdidos devido a eventuais problemas de indisponibilidade com a base de auditoria ou com o Agent Subscriber pois as mensagens continuarão persistidas no Message Broker até que os demais componentes voltem a estar disponíveis. O Agent Subscriber citado anteriormente é responsável por consumir as mensagens do Message Broker e persistir na base de auditoria.

Segue o desenho da solução:

Agent Publisher

Agent Publisher realiza scan na base de dados a cada 1 minuto em busca das collections. Para cada collection encontrada é criado um Change Stream que irá receber os eventos das operações realizadas com a collection em questão. Além disso, é verificado se existem collections que foram removidas da base, caso encontre alguma, os Change Streams relacionados serão removidos do Agent Publisher.

Basicamente irá existir um Change Stream por collection que irá coletar as operações e irá enviar para o Message Broker.

Agent Publisher deverá ser implantado em apenas um servidor pois não deverão existir mais de uma instância deste serviço rodando em paralelo para evitar a duplicação de dados na base de auditoria.

Resume Token

Change Streams podem ser resumidos por um token quando o cursor é aberto. Isto significa que a cada evento recebido pelo Change Stream existirá um token que representa a linha de tempo do registro obtido. Este token pode ser utilizado posteriormente para resumir a extração dos Change Streams a partir do momento onde parou.

O recurso Resume Token foi implementado no Agent Publisher para possibilitar a extração dos dados de auditoria após um término inseperado ou devido a um redeploy da aplicação. Os token são armazenados em um arquivo temporário em disco para possibilitar a retomada dos mesmos quando o Agent Publisher estiver UP novamente.

Agent Subscriber

Basicamente este serviço irá consumir do Message Broker as mensagens e irá persistir na base de auditoria.

Agent Subscriber poderá ser implantado em diversos servidores e poderá possuir mais de uma instância rodando pois o comportamento será de balanceamento de carga através do Message Broker.

Conclusão

Encontramos diversas implementações utilizando diferentes linguagens de programação. Porém, não encontramos algo que atendesse os nossos requisitos de negócio e de arquitetura.

Optamos então em construir os agentes utilizando SpringBoot 2 e o message broker escolhido foi o RabbitMQ. Tivemos dificuldades em utilizar o driver do mongodb pois ele implementa recursos que ainda não existem na versão 3.6 do MongoDB, por este motivo tivemos que criar um Change Stream por collection, sabemos que numa versão mais atual do MongoDB podemos utilizar apenas um listener de eventos para a base inteira.

Referências

Pra quem tiver interesse em estudar um pouco mais sobre este assunto, seguem as referências utilizadas:

Fonte: ARQTI

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google

Você está comentando utilizando sua conta Google. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s