A segurança do banco de dados é um assunto amplo que se estende desde medidas preventivas até manter visitantes indesejados afastados. Mesmo que você possa proteger totalmente seus servidores MongoDB, você ainda gostaria de saber se alguém tentou invadir seu sistema. E se eles conseguirem violar sua segurança e instalar o hack de resgate do MongoDB, você precisará de uma trilha de auditoria para post-mortems ou para tomar novas medidas preventivas. Um log de auditoria permitiria que você acompanhasse qualquer pessoa que tente fazer login e veja o que eles fizeram em seu sistema.
A versão do MongoDB Enterprise contém a capacidade de habilitar o log de auditoria, mas a versão da comunidade não possui essa funcionalidade. A Percona criou sua própria funcionalidade de log de auditoria em seu servidor Percona derivado do MongoDB para MongoDB. As abordagens MongoDB e Percona são diferentes uma da outra e explicaremos como configurar e usar ambas.
Registro de auditoria do MongoDB
O log de auditoria do MongoDB é fácil de configurar:para habilitar o log de auditoria em um arquivo JSON, basta adicionar a seguinte seção ao seu arquivo de configuração e reiniciar o MongoDB:
auditLog:
destination: file
format: JSON
path: /var/lib/mongodb/auditLog.jsonMongoDB suporta arquivo, console e syslog como destinos. Para formatos de arquivo existem duas opções:JSON e BSON. Em JSON, as linhas do log de auditoria são semelhantes a esta:
{ "atype" : "authCheck", "ts" : { "$date" : "2017-02-15T22:20:08.322-0000" }, "local" : { "ip" : "127.0.0.1", "port" : 27017 }, "remote" : { "ip" : "127.0.0.1", "port" : 63357 }, "users" : [], "roles" : [], "param" : { "command" : "update", "ns" : "test.inserttest", "args" : { "update" : "preauth_case", "updates" : [ { "q" : { "createdByUserId" : -2 }, "u" : { "$set" : { "statusCode" : "Update" } }, "multi" : false, "upsert" : false } ], "ordered" : true } }, "result" : 0 }A configuração acima habilitaria o log de auditoria para cada ação de qualquer usuário do seu sistema. Se você tiver alta simultaneidade, isso diminuiria drasticamente o desempenho do seu cluster MongoDB. Felizmente, existe a opção de filtrar eventos que devem ser registrados.
Os filtros para o log de auditoria podem ser colocados no tipo de consulta, na consulta de usuário/função ou na coleção que está sendo consultada. A documentação sobre log de auditoria no MongoDB é muito ampla e extensa, com muitos exemplos. Daremos alguns dos exemplos mais importantes a seguir.
Autenticação em uma coleção específica:
filter: '{ atype: "authenticate", "param.db": "test" }'Log para vários tipos de auditoria:
filter: '{ atype: { $in [ "update", "delete" ]}, "param.db": "test" }'Registre todas as verificações de autenticação para inserção/atualização/exclusão em uma coleção específica:
filter: '{ atype: "authCheck", "param.ns": "test.orders", "param.command": { $in: [ "find", "insert", "delete", "update", "findandmodify" ] } }'Como você pode ver, os filtros podem ser bastante flexíveis e você poderá filtrar as mensagens necessárias para sua trilha de auditoria.
Vários noves Torne-se um DBA do MongoDB - Trazendo o MongoDB para a produçãoSaiba mais sobre o que você precisa saber para implantar, monitorar, gerenciar e dimensionar o MongoDBBaixe gratuitamente
Percona Server for MongoDB Audit Logging
O log de auditoria do Percona Server for MongoDB é limitado ao arquivo JSON. A maioria dos usuários fará login apenas em arquivos JSON, mas não está claro se o Percona adicionará outros recursos de registro no futuro.
Dependendo da versão do Percona Server for MongoDB, sua configuração pode ser diferente. No momento da escrita, todas as versões têm a seguinte sintaxe:
audit:
destination: file
format: JSON
path: /var/lib/mongodb/auditLog.jsonNo entanto, essa diferença de configuração foi resolvida recentemente, mas ainda precisa ser liberada. Após o lançamento, ele deve seguir a diretiva auditLog do MongoDB novamente:
auditLog:
destination: file
format: JSON
path: /var/lib/mongodb/auditLog.jsonO formato da Percona é um pouco diferente:
{ "atype" : "authenticate", "ts" : { "$date" : { "$numberLong" : "1487206721903" } }, "local" : { "host" : "n3", "port" : 27017 }, "remote" : { "host" : "172.16.140.10", "port" : 50008 }, "users" : [ { "user" : "admin", "db" : "admin" } ], "params" : { "user" : "admin", "db" : "admin", "mechanism" : "SCRAM-SHA-1" }, "result" : 0 }Ao contrário do MongoDB registrar tudo, Percona optou por registrar apenas os comandos importantes. A julgar pela fonte do plug-in de auditoria Percona, as seguintes consultas são suportadas:autenticação, criar/atualizar/excluir usuários, adicionar/atualizar/remover funções, criar/descartar banco de dados/índice e a maioria dos comandos administrativos importantes.
Além disso, a filtragem do log de auditoria do Percona Server for MongoDB não parece seguir o mesmo padrão do MongoDB. Não está claro qual é a sintaxe e as opções exatas do filtro, pois a documentação do Percona é muito concisa sobre isso.
Ativar o log de auditoria sem filtragem forneceria entradas mais do que suficientes em seu arquivo de log. A partir daqui, você pode restringir o filtro, pois segue a sintaxe JSON das entradas de log.
Uso do Registro de Auditoria
Para facilitar para você, pode ser melhor alimentar o log de auditoria em uma estrutura de análise de log. Uma pilha ELK é um excelente ambiente para fazer sua análise e permite que você faça drill down para níveis mais detalhados com bastante facilidade. Usar um mapeador de campo permitiria até mesmo fazer a trilha de auditoria dentro do ELK.
Conforme descrito na introdução, podemos usar o log de auditoria para vários fins de segurança. O mais óbvio é quando você precisa dele como referência durante uma autópsia. O log de auditoria do MongoDB fornece uma visão geral detalhada do que exatamente aconteceu. O log de auditoria da Percona contém um pouco menos de informações, mas deve ser suficiente para a maioria dos post-mortems. Usar o log de auditoria para post-mortems é ótimo, embora prefiramos ter evitado o problema em primeiro lugar.
Outra finalidade do log de auditoria é ver as tendências acontecendo e você pode definir armadilhas em uma determinada mensagem de log de auditoria. Um bom exemplo seria verificar a taxa de tentativas de autenticação (com falha) e, se exceder um determinado limite, agir de acordo. Dependendo da situação, a ação tomada pode ser diferente. Uma ação pode ser bloquear automaticamente o endereço IP de onde as solicitações estão vindo, mas em outro caso, você pode consultar o usuário sobre o motivo pelo qual a senha foi esquecida. Depende muito do caso e do ambiente em que você está trabalhando.
Outra medida preventiva avançada seria usar o MongoDB como um honeypot e aproveitar o log de auditoria para capturar usuários indesejados. Basta expor o MongoDB e permitir que qualquer pessoa se conecte ao seu servidor MongoDB. Em seguida, use o log de auditoria para detectar o que os usuários farão se tiverem permissão para fazer coisas além de seus poderes normais e bloqueá-los, se necessário. A maioria dos humanos prefere o caminho mais fácil do que o mais difícil, então o honeypot pode desviar um ataque e o hacker passará para o próximo alvo.
Conclusão
Além de explicar como configurar o log de auditoria para o MongoDB Enterprise e o Percona Server para MongoDB, também explicamos o que você poderia fazer com os dados registrados dentro do log de auditoria.
Por padrão, o ClusterControl não habilita o log de auditoria, mas é relativamente fácil habilitá-lo em todo o cluster usando nosso Config Manager. Você também pode habilitá-lo dentro dos modelos de configuração, antes de implantar um novo cluster.
Boa aglomeração!
