Em janeiro de 2017, o popular MongoDB foi alvo do que parece estar se tornando uma tática bastante previsível entre invasores: sequestrar dados. Uma investigação posterior sobre o comprometimento constatou que, na maioria dos casos, os invasores não haviam explorado... 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 totalmente expostos a qualquer pessoa com conexão à Internet.
Isso incluiu o agora infame escândalo da CloudPetsno qual mensagens de voz (supostamente privadas) entre crianças e seus pais estavam publicamente acessíveis a qualquer pessoa com conhecimento suficiente para obter o banco de dados (uma instância não protegida do MongoDB) ou entender a arquitetura do aplicativo e seu uso do Amazon S3. A CloudPets usava o S3 para armazenar fotos de perfil e gravações de voz e, aparentemente, ignorou qualquer tipo de segurança, deixando-as acessíveis a qualquer pessoa com a referência correta.
Agora, para que você não pense que estou implicando com a CloudPets, vale observar que a equipe de CSI da RedLock descobriu recentemente que “82% dos bancos de dados em ambientes públicos de computação em nuvem, 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 aceitavam solicitações de conexão de entrada provenientes da internet”.
Cabe ainda observar que houve mais de 27.000 servidores MongoDB comprometidosnas primeiras semanas de janeiro de 2017. A CloudPets esteve longe de ser a única vítima de suas próprias práticas de segurança inadequadas nesse incidente. Como observou uma publicação no blog do MongoDB quando os primeiros ataques foram divulgados: “Esses ataques são evitáveis graças às amplas proteções de segurança integradas ao MongoDB. É preciso usar esses recursos corretamente, e nossa documentação de segurança ajudará você a fazer isso. [grifo meu]”
O MongoDB não era inseguro; ele simplesmente não tinha nenhuma proteção configurada. O problema não está exatamente no produto, mas nas práticas inadequadas daqueles que têm pressa em disponibilizar aplicativos móveis e de IoT aos consumidores por meio da nuvem.
A nuvem como catalisadora de práticas inseguras
No data center — no ambiente local — há barreiras, tanto físicas (firewalls e afins) quanto operacionais (processos e aprovações), que precisam ser transpostas antes que um software seja disponibilizado ao mundo e usado para fornecer dados. Por definição, a nuvem tem menos barreiras físicas e — como infelizmente muitas vezes parece ocorrer — menos barreiras operacionais pelas quais os aplicativos precisam passar antes de serem disponibilizados ao público em geral. É justamente com a redução das barreiras operacionais que o conceito de “TI clandestina” ou “TI paralela” ganhou força. Frustradas com os longos prazos de entrega e com cronogramas de projetos que se estendiam por anos, em vez de meses, as partes interessadas das áreas de negócio começaram a recorrer à nuvem para “contornar” a TI. Só que isso também significava contornar as barreiras operacionais implementadas para garantir a segurança e o desempenho desses aplicativos.
Isso não é um problema da nuvem, mas de quem a adota. Afinal, não é apenas aquela história de que “leva tempo demais para provisionar o hardware físico” que ouvimos há dez anos; é o fato de que “leva tempo demais para passar pelos processos de aprovação da TI” que realmente irrita os responsáveis pelas áreas de negócios, que só querem lançar seus produtos no mercado agora, antes da concorrência.
Os participantes de uma pesquisa de 2017 patrocinada pela Arxan/IBM sobre segurança móvel e de IoT confirmam isso. Os participantes apontaram a pressão sobre as equipes de desenvolvimento de aplicativos como responsável pela baixa segurança dos aplicativos móveis e de IoT: 69% atribuíram a existência de códigos vulneráveis à pressa no desenvolvimento de aplicativos móveis, e 75% disseram 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, antes de tudo, tornam esses dispositivos úteis. Toda a proposta do Cloud Pets não se baseia no brinquedo em si, mas na capacidade dele de enviar e receber dados pela Internet. Isso significa que seu sucesso depende de um desses aplicativos de IoT ser desenvolvido e implantado às pressas na nuvem para cumprir a data de lançamento no Natal.
Os desenvolvedores não são os únicos responsáveis por garantir a segurança dos aplicativos que devem entregar. Quem quer que seja responsável por provisionar os serviços de nuvem que dão suporte a esses aplicativos — sejam bancos de dados, compartilhamento de arquivos ou serviços de aplicativos em geral — também deve assumir parte da responsabilidade por protegê-los. O mesmo vale para as partes interessadas da empresa que impõem prazos irrealistas e incentivam a adoção de requisitos operacionais mínimos para a entrega final.
Sim, a TI precisa adotar a transformação digital e simplificar os controles operacionais que levam à entrega bem-sucedida — e segura — de produtos aos consumidores. Mas as empresas e os desenvolvedores não podem continuar simplesmente ignorando esses controles operacionais na nuvem e colocando em risco não apenas os consumidores, mas também as partes interessadas da empresa, com práticas de segurança precárias que dependem de configurações “padrão”. A questão não diz respeito tanto aos produtos quanto aos processos; trata-se de garantir que as políticas sejam implementadas e as configurações estejam corretas antes de expor os aplicativos — e seus usuários — a violações que poderiam ser evitadas.
Se você quiser evitar um incidente constrangedor, precisa começar estabelecendo alguns parâmetros básicos de segurança na nuvem, definindo (e aplicando) pelo menos alguns controles operacionais básicos que devem ser cumpridos antes do lançamento no mercado.
As organizações precisam dessas barreiras operacionais mais do que nunca, pois o ritmo da migração para a nuvem pública de aplicativos que sustentam tanto a produtividade quanto os lucros está se acelerando. E, com esse ritmo mais intenso de migração, também aumentam as oportunidades para que invasores explorem esses aplicativos.
Sobre o autor
Lori MacVittie é engenheira distinta e evangelista-chefe no Escritório do CTO da F5, com ampla experiência em entrega de aplicações, estratégia de automação e infraestrutura. Ela é conhecida por transformar complexidade em clareza, seja definindo diretrizes para agentes de IA, analisando arquiteturas multinuvem frágeis ou investigando os limites de sistemas escaláveis. Ela acumula mais de trinta anos de experiência no setor, abrangendo desenvolvimento de aplicações, arquitetura de TI e operações de redes e sistemas. Antes de ingressar na F5, atuou como editora de tecnologia e recebeu diversos prêmios. MacVittie tem mestrado em Ciência da Computação e é uma autora prolífica, com publicações que abrangem segurança, nuvem e arquitetura empresarial. Ela também é uma entusiasta de jogos de tabuleiro e videogames, além de ter opiniões assumidamente fortes sobre queijos.
Mais publicações de Lori Mac VittiePublicações relacionadas no blog
Entrega e proteção de agentes de IA em fábricas de IA: F5 para a arquitetura de referência NVIDIA OpenShell para agentes de IA seguros
As soluções da F5 ampliam a Arquitetura de Referência NVIDIA OpenShell para agentes de IA seguros.
Como medir – e minimizar – o custo total de propriedade do seu Kubernetes
O Kubernetes pode ser baixado e executado gratuitamente, mas sua manutenção está longe de não ter custos. Assim como outras grandes plataformas de código aberto que são “gratuitas” apenas em um sentido simplista, o Kubernetes quase certamente exigirá investimentos para ser implantado e operado.
As-Code: a pilha de TI contínua
Infraestrutura, configuração, pipeline, operações. De repente, tudo é “como código”. Lori MacVittie busca esclarecer a terminologia e identificar os diferentes componentes de uma stack contínua de TI.
O estado da entrega de aplicações em 2017: automação, APIs e DevOps
Explore o relatório State of Application Delivery de 2017. Leia o blog retrospectivo da F5 sobre o início da ascensão das redes declarativas e dos pipelines de DevOps.
DevOps Summit: onde a rede foi convidada para a festa
No DevOps Summit NY, falou-se muito não apenas sobre DevOps, mas também sobre contêineres, IoT e microsserviços. As sessões se concentraram não só na mudança cultural necessária para crescer em escala com uma abordagem DevOps, mas também fizeram questão de incluir...
F5 e Nutanix convergem em infraestrutura no .NEXT
Aplicações empresariais como Microsoft SharePoint e Exchange, juntamente com a VDI, continuam sendo a espinha dorsal da sua empresa. A produtividade, embora não seja tão atraente quanto o lucro, é um fator essencial para o sucesso das operações empresariais atuais. Deixar de...