Em janeiro de 2017, o popular MongoDB sofreu o que parece estar se tornando uma tática bastante previsível para invasores: tomar dados como reféns. Uma investigação subsequente sobre o comprometimento observou que, na maioria dos casos, os invasores não exploraram... nada. O problema não estava no software, mas na configuração. A configuração padrão , executada principalmente na AWS, deixava os bancos de dados abertos para qualquer pessoa com conexão à Internet.
Isso incluiu o agora infame drama dos CloudPets , no qual mensagens de voz (presumivelmente privadas) entre crianças e seus pais eram publicamente acessíveis a qualquer pessoa experiente o suficiente para obter o banco de dados (uma instância não segura do MongoDB) ou entender a arquitetura do aplicativo e seu uso do Amazon S3. A Cloud Pets usou o S3 para armazenar fotos de perfil e gravações de voz e aparentemente ignorou qualquer tipo de segurança, deixando-os acessíveis a qualquer pessoa com a devida referência.
Agora, para que você não pense que estou escolhendo o CloudPets, deixe-me observar que a equipe RedLock CSI descobriu recentemente que "82% dos bancos de dados em ambientes de computação em nuvem pública, como o Amazon Relational Database Service e o Amazon RedShift, não são criptografados".
[pausa dramática]
Além disso, “31% desses bancos de dados estavam aceitando solicitações de conexão de entrada da Internet”.
Gostaria de ressaltar ainda que mais de 27.000 servidores MongoDB foram comprometidos nas primeiras semanas de janeiro de 2017. Muito mais do que a CloudPets foi afetada por suas próprias práticas de segurança precárias em relação a esse incidente. Como um blog do MongoDB observou quando os primeiros ataques foram divulgados: “Esses ataques podem ser prevenidos com as amplas proteções de segurança incorporadas ao MongoDB. Você precisa usar esses recursos corretamente , e nossa documentação de segurança o ajudará a fazer isso. [ênfase minha]”
O MongoDB não era inseguro, ele simplesmente não era seguro. O problema realmente não está no produto, mas sim nas práticas precárias daqueles que se apressam para colocar a IoT e os aplicativos móveis nas mãos dos consumidores por meio da nuvem.
No datacenter – local – há portões, tanto físicos (firewalls e similares) quanto operacionais (processos e aprovações), que devem ser passados antes que o software seja liberado no mundo e usado para fornecer dados. A nuvem, por definição, tem menos portas físicas e – como infelizmente muitas vezes parece – menos portas operacionais para os aplicativos passarem antes de serem oferecidos ao mundo em geral. A redução de portões operacionais é realmente onde o conceito de “TI desonesta” ou “TI oculta” foi parar. As partes interessadas da linha de negócios, frustradas com os longos prazos de entrega e cronogramas de projetos que abrangem anos em vez de meses, começaram a adotar a nuvem para "contornar" a TI. Só que isso significava que eles também estavam contornando os portões operacionais implementados para garantir a segurança e o desempenho desses aplicativos.
Isso não é um problema com a nuvem, é um problema com aqueles que a adotam. Porque não é apenas a linha "demora muito para provisionar hardware físico" que temos ouvido por dez anos; é a "demora muito para passar pelos processos de aprovação de TI" que realmente irrita as partes interessadas do negócio que só querem chegar ao mercado agora, antes da concorrência.
Os entrevistados de uma pesquisa patrocinada pela Arxan/IBM em 2017 sobre segurança móvel e IoT comprovam isso. Os entrevistados citaram a pressão sobre as equipes de desenvolvimento de aplicativos como responsável pela baixa segurança da IoT e de aplicativos móveis, com 69% apontando o dedo para o desenvolvimento apressado de aplicativos móveis como a fonte do código vulnerável, e 75% dizendo o mesmo sobre os aplicativos de IoT.
Essa mesma pressão se estende à configuração e proteção dos bancos de dados e do armazenamento em nuvem que tornam as coisas úteis em primeiro lugar. Toda a premissa do Cloud Pets não é construída com base no brinquedo, mas na capacidade do brinquedo de enviar e receber dados pela Internet. Isso significa que seu sucesso está em um desses aplicativos de IoT que está sendo desenvolvido e implantado rapidamente na nuvem para atingir a data de lançamento no dia de Natal.
Os desenvolvedores não são os únicos responsáveis por proteger os aplicativos que eles têm a tarefa de entregar. Quem for responsável pelo provisionamento de serviços em nuvem que dão suporte a esse aplicativo – seja banco de dados, compartilhamento de arquivos ou serviços de aplicativo em geral – deve assumir parte da responsabilidade por protegê-lo. E o mesmo deveria acontecer com as partes interessadas do negócio, que impõem prazos irrealistas e incentivam procedimentos operacionais mínimos para a entrega final.
Sim, a TI precisa adotar a transformação digital e otimizar os portões operacionais que levam à entrega bem-sucedida — e segura — dos produtos aos consumidores. Mas empresas e desenvolvedores não podem continuar a simplesmente evitar esses portões operacionais na nuvem e deixar não apenas os consumidores, mas também as partes interessadas corporativas em risco com práticas de segurança de má qualidade que dependem de configurações "padrão". Não se trata tanto de produtos, mas sim de processos; trata-se de garantir que as políticas sejam implantadas e as configurações estejam corretas antes de expor os aplicativos — e seus usuários — a comprometimentos evitáveis.
Se você quiser evitar um incidente embaraçoso, precisa começar colocando algumas apostas básicas de segurança no céu, definindo (e aplicando) pelo menos alguns portões operacionais básicos que devem ser passados antes de ir ao mercado.
As organizações precisam desses portões operacionais mais do que nunca, porque o ritmo de migração para a nuvem pública de aplicativos que dão suporte à produtividade e aos lucros está acelerando. E junto com esse ritmo acelerado de migração, aumentam as oportunidades para invasores explorá-los.