Auditoria de bancos de dados na grade Parte 2: observações pós-implantação

No post anterior desta série, falei sobre como coletamos os requisitos para este projeto, como tomamos uma decisão sobre qual ferramenta usar e como planejamos a implantação para evitar interrupções no serviço. Conforme prometido, esta postagem de acompanhamento se concentra nas observações pós-implantação e nos fatores que tornaram essa história de sucesso para nós.

Declarações preparadas e filtragem de classe de comando

Nosso design inicial para este projeto pretendia alavancar um recurso no plug-in percona que permite filtrar os eventos emitidos para usar uma lista de comandos incluídos ou comandos excluídos como forma de limitar o escopo ao que realmente precisamos auditar.

O recurso depende do plugin marcar cada comando sql detectado com uma classe baseada em uma lista inerente ao mysql e a partir daí decidir na camada de saída se a classe de comando detectada deve ser suprimida ou emitida.

Então, escrevemos o blueprint inicial para aproveitar o recurso audit_log_exclude_commands para excluir quaisquer comandos sql que não causaram gravações ou alterações nos dados da linha. Optamos por uma lista de exclusão porque sentimos que uma lista de inclusão trazia o risco de perder qualquer classe de comando no escopo e poderia se tornar um motivo para haver lacunas em nossos logs de auditoria.

No entanto, no primeiro cluster que testamos, vimos que todos os comandos auditados estavam sendo classificados como erro , embora estivesse claro que essas instruções foram executadas com sucesso e, em caso de alteração de dados, também estavam fazendo isso com sucesso. Também vimos que todas as consultas estavam sendo emitidas para o servidor syslog centralizado, independentemente da lista de exclusão que parece correlacionada com essa classificação de erro.

Isso significava que estávamos armazenando muito mais eventos no elasticsearch do que realmente precisávamos, o que definitivamente afetará nossa capacidade de analisar e detectar comportamentos errôneos em tempo hábil. Com a colaboração da equipe de segurança, decidimos informar a Percona sobre o problema por meio de seu rastreador de bugs, mas também mover a filtragem baseada em comandos para a camada syslog central.

Como tudo em engenharia, a compensação aqui era enviar mais dados através da camada de rede de banco de dados e tornar a filtragem na camada syslog centralizada mais complexa e, em troca, tornar nossas necessidades de escala de pesquisa elástica mais gerenciáveis ​​e a configuração no lado do banco de dados mais simples.

atuação

Uma das decisões mais cruciais neste projeto que nos salvou de muita dor de cabeça é decidir usar o recurso rsyslog para interceptar e enviar esses logs para um servidor syslog centralizado.

Mas nada é sem prós e contras.

Essa decisão significou que o tempo de atividade de um sistema separado e a confiabilidade da pilha de rede entre eles se tornaram cruciais para fornecer o SLA que precisávamos para dar à nossa equipe de auditoria a confiança nesta solução de auditoria.

Para aqueles que não estão dispostos a fazer esse compromisso e precisam manter a responsabilidade da persistência dos logs de auditoria dentro da pilha de banco de dados, recomendo usar o manipulador FILE no plug-in de auditoria e usar o logstash local para pegar os logs e encaminhá-los para seu sistema de análise de escolha.

Essa última escolha significa muito mais IOPs de disco consumidos fora do processo de banco de dados e ocupados pelo plug-in de auditoria e logstash e significa que você precisa equilibrar cuidadosamente o espaço em disco em suas instâncias entre os arquivos de tabela de banco de dados, logs operacionais e a auditoria logs de plug-ins. Pesar suas opções depende apenas de qual é o mais fácil de operar/aceitável pela empresa, mas você tem opções, no entanto.

No nosso caso, a escolha do rsyslog provou ser a menos impactante para nossos bancos de dados mais ocupados, atingindo um pico de cerca de 5.400 transações/s, durante as operações normais não vimos nenhum impacto no desempenho. O plugin de auditoria estava avançando, enviando seus eventos sem impacto no desempenho do banco de dados. Tudo porque elegemos uma arquitetura que evitava o consumo de operações baseadas em disco no lado do banco de dados.

Decisões anteriores valendo a pena

Uma das primeiras preocupações que tivemos quando embarcamos neste projeto foi o seu impacto no desempenho. Um dos clusters de banco de dados no escopo passou por momentos muito ocupados e seus aplicativos são sensíveis ao atraso, por isso precisávamos ter certeza de acompanhar as métricas de desempenho, como transações por segundo, utilização de disco e CPU para comparar os números após a implantação do plug-in e veja qual é a penalidade para isso.

Foi uma feliz surpresa ver que não incorremos em muitas penalidades em operações normais. Como mencionado anteriormente, como decidimos usar o manipulador SYSLOG, isso significava que normalmente não precisávamos usar nenhuma capacidade de disco local para rastrear esses eventos de auditoria.

Mas também não queríamos planejar com base apenas em tempos de 'operação normal'.

Também precisávamos saber que, quando o rsyslog precisa fazer fallback para arquivos de spool locais, esses eventos não se transformam em interrupções de serviço que afetam os clusters de banco de dados mais críticos. Ao testar o comportamento de spool do rsyslog sob vigilância atenta na produção, percebemos que os últimos anos de trabalho para fragmentar funcionalmente nossos bancos de dados nos trouxeram o benefício não planejado de muitos IOPs de disco capacidade para absorver eventos como o spool do rsyslog para o disco, então necessário para reenviar todos esses eventos.

Definitivamente, observamos o aumento na utilização do disco durante esses eventos, mas isso nunca levou as instâncias de banco de dados a um estado crítico ou afetou a atividade voltada para o cliente.

Trocas

Como tudo na engenharia de software, sempre há compensações. Neste projeto, consideramos um método de entrega de toras mais confiável e com menor potencial de perda de toras. Isso envolveria gravar os logs em disco e, em seguida, usar algo como logstash para ingeri-los e enviá-los para destinos de análise para uso da equipe de segurança.

Mas isso significaria um consumo significativo de IOPs de disco no lado do banco de dados, que sabíamos que poderia afetar a qualidade do serviço de chamadas voltadas para o cliente para esses bancos de dados.

Decidimos que nossas necessidades de negócios seriam suficientemente atendidas usando log resiliente em rsyslog, usando um spool de tamanho razoável e usando TCP para enviar os eventos para nossa pilha de monitoramento de log. Como tudo na vida, nada é para sempre. E estamos cientes de que essa decisão pode precisar ser revisada no futuro.

Finalmente

Esse projeto, embora abrangendo meia dúzia de clusters e um grande número de instâncias, foi concluído em um único trimestre, enquanto a equipe de operações de banco de dados ainda mantinha as luzes acesas em um negócio ainda em rápido crescimento. Isso não poderia ter acontecido sem uma estreita colaboração entre o DBE e a equipe de segurança e não sem um forte gerenciamento de produtos que manteve o escopo finito e conhecido para garantir que todos mantivéssemos nossos olhos no objetivo final de tornar nossos negócios mais seguros.