Por que proteger containers e microsserviços é um desafio - CIO
Por que proteger containers e microsserviços é um desafio
A granularidade, velocidade de implantação e volume de tráfego de dados exigem novas abordagens para proteger os ambientes de container
Publicada em 08 de maio de 2018 às 06h51
Os containers são uma maneira pequena, rápida e fácil de configurar e executar software em diferentes ambientes de computação. Estão disponíveis em todos os principais provedores de nuvem, bem como em data centers on-premise e nuvens híbridas. Além disso, eles podem economizar muito dinheiro para as empresas. Usando containers, os desenvolvedores podem criar "microsserviços", que são componentes essencialmente pequenos e reutilizáveis ​​de um aplicativo. Por serem reutilizáveis, os microsserviços podem economizar tempo dos desenvolvedores e podem ser implantados em diferentes plataformas. Mantendo o ambiente de tempo de execução completo de um aplicativo, incluindo bibliotecas, binários e arquivos de configuração, a plataforma e a infraestrutura são abstraídas, permitindo que aplicativos sejam executados mais ou menos em qualquer lugar.
Não é surpresa, portanto, que a adoção de containers seja alta. Infelizmente, a segurança ainda está aprendendo como funcionam e como bloqueá-los. Cerca de 80% das organizações com mais de 500 funcionários já usam containers, de acordo com uma recente pesquisa da McAfee com 1,5 mil profissionais de TI globais . Apenas 66% têm uma estratégia de segurança para os containers. Na verdade, os containers estão empatados com os dispositivos móveis como maiores desafios de segurança para as organizações, de acordo com pesquisa da CyberEdge, realizada em março, ouvindo 1,2 mil tomadores de decisões de TI.
Existem vários motivos pelos quais a segurança é um desafio no universo de containers. Um é a velocidade na qual os containers são implantados. Outro é que os containers normalmente exigem que os aplicativos sejam divididos em serviços menores, resultando em maior tráfego de dados e regras complexas de controle de acesso. Por fim, os containers são executados geralmente em ambientes baseados em nuvem, com novos tipos de controles de segurança.
O ecossistema de ferramentas de segurança de containers ainda não está maduro, de acordo com Ali Golshan, cofundador e CTO da StackRox, fornecedora de segurança em nuvem baseada em Mountain View. "É como nos primeiros dias das máquinas virtuais e da nuvem", diz ele. "As organizações precisam criar ferramentas proprietárias e infraestrutura para fazê-lo funcionar, e precisam de muitos recursos para implementar. Não há muitas soluções de segurança prontas por aí, suficientes para cobrir todos os casos de uso."
A vida de um container é mal administrada e curta
O processo tradicional de desenvolvimento de software - compilar, testar, implantar - rapidamente se torna irrelevante na era dos containers. Na verdade, os desenvolvedores costumam pegar imagens prontas para uso em repositórios públicos e colocá-las na nuvem.
"Há algum nível implícito de confiança que pode ou não ser garantido", diz Robert Huber, diretor de segurança e estratégia da Eastwind Networks. Uma imagem de container é um pacote conveniente de código pronto para uso, mas os provedores podem não ter tempo ou interesse em monitorar problemas de segurança ou publicar notas de versionamento, diz ele.
"Idealmente, deve haver algum processo para verificar versões, mas não conheço nenhuma organização que tenha o tenha implementado", diz Huber. "As empresas devem verificar continuamente se as versões mais recentes dos containers são as que estão sendo usadas e se todo o código está atualizado. Por enquanto, isso se resume a uma verificação manual por parte dos desenvolvedores. Acreditamos que as organizações passarão para um processo mais automatizado, mas hoje essa lacuna persiste."
E a situação não é muito diferente nos casos nos quais os desenvolvedores criam seus próprios containers. A velocidade de desenvolvimento está diretamente relacionada ao tempo gasto com garantia de qualidade e/ou testes de segurança.
"O ciclo de vida pode acabar no momento em que a equipe de segurança entrar", diz Bo Lane, diretor de arquitetura de soluções da Kudelski Security. "Esse é o desafio, e requer uma mentalidade diferente para segurança".
A conscientização de segurança precisa ser construída logo no início do processo de desenvolvimento, diz ele, e automatizada o máximo possível. Por exemplo, se os desenvolvedores estiverem baixando uma imagem de uma fonte externa, ela precisará ser verificada quanto a vulnerabilidades, códigos sem patches e outros possíveis problemas antes que o container seja colocado em operação.
Tomemos por exemplo o Skyhigh Networks. O fornecedor de segurança em nuvem tem suas próprias ofertas de serviços em nuvem, por isso está lidando com todos esses desafios, diz Sekhar Sarukkai, co-fundador da Skyhigh Networks e vice-presidente de engenharia da McAfee Cloud, que adquiriu a Skyhigh no início deste ano.
"Estamos implantando as mais recentes pilhas de arquitetura e microsserviços", diz ele. "Na verdade, podemos implantar e colocar algo em produção várias vezes ao dia. Tradicionalmente, teríamos que investir algum tempo em testes de segurança ou testes de penetração - que não funcionam em um ambiente de DevOps."
As empresas precisam encontrar maneiras de automatizar muitas dessas funções, diz ele. Isso significa ser capaz de identificar todos os containers que estão sendo implantados, garantir que todos os elementos estejam seguros, que estejam sendo implantados em um ambiente seguro com controles de aplicativo ou lista de permissões de aplicativos e, em seguida, fazer o acompanhamento com monitoramento contínuo.
A McAfee agora tem um produto que faz exatamente isso, anunciado em abril na conferência RSA - a plataforma McAfee Cloud Workload Security. "Ela protege containers e cargas de trabalho em ambientes de nuvem pública e privada", diz Sarukkai. Isso inclui AWS, Azure e VMWare. "É a primeira solução de carga de trabalho na nuvem que pode colocar em quarentena as cargas de trabalho e os contêineres infectados", diz ele.
Uma enorme rede de serviços
O gerenciamento de configurações e o gerenciamento de patches são difíceis de serem feitos e fáceis de serem explorados pelos invasores, mas são problemas solucionáveis. Um desafio mais assustador é o da complexidade criada pela quebra de um aplicativo em um grande número de serviços menores e interconectados.
Com aplicativos tradicionais e monolíticos, há um serviço e apenas algumas portas. "Você sabe exatamente onde os bandidos vão tentar entrar", diz Antony Edwards, CTO da Eggplant.
Isso torna mais fácil garantir a segurança, diz ele. "No entanto, com microservices, você tem muitos serviços e muitas portas, o que significa que há muito mais portas para proteger. Além disso, cada porta tem menos informações sobre o que está acontecendo, por isso é mais difícil identificar se algumas delas foi ou está sendo atacada."
Garantir que a segurança dos serviços individuais seja a mais rígida possível se torno um ônus, diz ele. Exige privilégios mínimos, controles rígidos de acesso, isolamento e auditoria.
"As organizações estão quebrando seus monólitos em partes cada vez menores, e os fluxos de dados ficam muito mais complexos dentro do aplicativo, e fica difícil dizer o que cada microsserviço faz", diz Manish Gupta, co-fundador e CEO da ShiftLeft. Se houver uma credencial de acesso codificada no mix, ou um token de autenticação sendo vazado, todo o sistema ficará vulnerável. "Este é um problema muito grande, e as pessoas não reconhecem isso, ainda", diz Gupta.
O problema só está aumentando, acrescentou, à medida que sistemas mais críticos são transferidos para um modelo de entrega de software como serviço. "Isso significa que você está concentrando muitos dos seus dados em seus aplicativos - a Equifax é um ótimo exemplo de comprometimento; a Uber é outro ótimo exemplo", diz ele. "Agora, dados muito importantes estão fluindo entre microsserviços e poucas pessoas têm uma boa visibilidade da segurança do ambiente".
Contêineres com vazamento criam vulnerabilidades
Há outro possível desafio de segurança com containers. Eles correm em um ambiente compartilhado, o que é particularmente preocupante em nuvens públicas, onde os clientes não sabem quem são seus vizinhos.
As empresas que estão executando containers em uma nuvem pública estão começando a reconhecer esse problema, depois que vulnerabilidades nos sistemas de gerenciamento de containers Docker e Kubernetes foram descobertas nos últimos dois anos. "Ouço, da maioria dos clientes com os quais falo, questionamentos as ferramentas disponíveis para isolar o host de problemas com os containers e para isolar containers uns dos outros", diz Kirsten Newcomer, gerente sênior de produtos da plataforma de containers da Red Hat, OpenShift.
Mais de 70% dos entrevistados executam seus containers no Linux, de acordo com a pesquisa de adoção de containers da Portworx, realizada em 2017. Os recursos que os administradores podem usar para garantir que os containers permaneçam isolados incluem o uso de namespaces do Linux e o uso do Security Enhanced Linux para uma camada adicional de controles de acesso obrigatórios, diz Newcomer. "E há algo chamado Capacidades do Linux, que permite limitar os diferentes tipos de privilégios dentro de um sistema Linux ao qual um processo tem acesso."
Esses podem ser conceitos familiares para especialistas em segurança Linux, mas podem ser novos para equipes envolvidas em implementações recentes de containers - ou para organizações que recentemente migraram do Windows. Pelo menos as empresas que executam seus próprios ambientes de container, seja em nuvens públicas ou privadas, têm controle total sobre essas configurações de segurança. Quando estão usando containers prontos para uso, precisam confiar no provedor da nuvem para acertar a infraestrutura de segurança subjacente.
Até agora, nenhuma das vulnerabilidades que permitem que os processos escapem dos containers resultou em uma grande violação pública. O fato de o espaço ser dominado por apenas algumas plataformas - sendo Docker e Kubernetes os grandes nomes aqui - significa que uma única vulnerabilidade pode ter um impacto muito amplo se os invasores a explorarem rapidamente, então vale a pena estar preparado.