O número crescente de ataques cibernéticos em implantações de banco de dados de código aberto destaca as más práticas administrativas e operacionais do setor.

Se 2016 nos ensinou alguma coisa, foi a importância de boas práticas operacionais e medidas de segurança nas implantações de banco de dados de código aberto. Por vários anos, os pesquisadores alertaram sobre bancos de dados expostos publicamente - com estimativas variando de dezenas de milhares de servidores. Se a escala do problema não era aparente ou assustadora, certamente é agora.

Recentemente, grupos de ransomware excluíram mais de 10.000 bancos de dados MongoDB em apenas alguns dias. Outros bancos de dados de código aberto (ElasticSearch, Hadoop, CouchDB) também foram atingidos. Enquanto isso, o número de bancos de dados expostos subiu para cerca de 100.000 instâncias.

O que levou a isso? Bancos de dados de código aberto e software de código aberto em geral alimentam uma parte significativa dos serviços online atuais. Graças ao aumento do uso de ciclos de vida de desenvolvimento ágil, a nuvem tornou-se o lar de uma variedade de aplicativos que são implantados rapidamente. Muitas empresas também deixaram de usar a nuvem para funções não críticas e agora dependem da nuvem para armazenar dados valiosos. Isso significa que mais bancos de dados estão sendo implantados em nuvens públicas, em ambientes diretamente expostos à Internet.

O MongoDB, em particular, é muito popular entre os desenvolvedores, devido à sua conveniência e conveniência. Mas aqui está o problema - criar rapidamente um ambiente para desenvolvimento não é a mesma coisa que configurar para produção ao vivo. Ambos exigem níveis muito diferentes de especialização. Milhares de instâncias de banco de dados não eram protegidas e qualquer pessoa podia obter acesso de leitura e gravação aos bancos de dados (incluindo quaisquer dados confidenciais) sem ferramentas especiais ou sem ter que contornar nenhuma medida de segurança. Isso não é um lapso de concentração de alguns indivíduos que nos trouxeram até aqui, estamos enfrentando um problema que é mais generalizado do que qualquer um poderia imaginar. Precisamos reconhecer que é difícil encontrar o meio termo entre facilidade de uso, velocidade de implantação e prontidão operacional/de segurança. Então, isso levanta a questão - como podemos coletivamente superar esse tipo de problema?

Se pudéssemos treinar cada indivíduo que implanta o MongoDB em um engenheiro de implantação, isso pode ajudar. Pelo menos, haverá algum nível de proteção para que não seja qualquer um que possa entrar por uma porta aberta.

Operações não é ciência de foguetes, mas pode não ser razoável esperar que todos os desenvolvedores, que são os principais usuários do MongoDB, se transformem em engenheiros de sistemas/implantação completos. O setor de TI está se movendo para implementações e implantação de serviços mais rápidas e enxutas. O meio-termo entre facilidade de uso, velocidade de implantação e boas práticas operacionais pode parecer ainda mais distante. A automação pode ser o que nos ajuda a encontrar esse meio-termo.
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
As configurações de banco de dados adequadas para produção tendem a ser um pouco mais complexas, mas, uma vez projetadas, podem ser duplicadas muitas vezes com variação mínima.

A automação pode ser aplicada ao provisionamento e configuração inicial, bem como correções contínuas, backups, detecção de anomalias e outras atividades de manutenção. Esta é a base para nossa própria plataforma de automação para MongoDB, ClusterControl. Um sistema bem implantado e gerenciado pode mitigar o risco operacional e certamente impediria que esses milhares de bancos de dados fossem invadidos.