6 erros comuns de segurança de contêineres que precisam ser evitados

Views: 82
0 0
Read Time:6 Minute, 41 Second

Contêineres são uma maneira segura de implantar aplicativos e serviços, mas somente se você os usar corretamente

À medida que mais organizações transferem dados e cargas de trabalho para a nuvem, muitas dependem de contêineres – unidades de software que empacotam o código e suas dependências, para que os aplicativos sejam executados de maneira confiável ao passar de um ambiente de computação para outro. A conteinerização é anunciada como uma tecnologia robusta para implantar aplicativos e serviços de maneira segura, diz Cole McKnight, Arquiteto de Nuvem do Departamento de Genética e Bioquímica da Universidade Clemson.

Mecanismos de contêiner, como Docker e Singularity, fornecem uma maneira de implementar e distribuir as políticas de segurança recomendadas para um determinado aplicativo, em vez de depender de usuários individuais para configurar uma instalação segura, diz McKnight. “As plataformas de orquestração de contêineres, como Kubernetes, Mesos ou Docker Swarm, têm mecanismos de segurança integrados específicos para implantar e executar contêineres”, diz McKnight. “O resultado é um ecossistema facilmente configurável para o desenvolvimento e implantação de contêineres”.

Enquanto essas tecnologias abstraem grande parte da complexidade tradicionalmente envolvida no fornecimento de aplicativos e serviços seguros, algumas equipes de desenvolvimento interpretam essa possibilidade de segurança como uma garantia, diz McKnight. O problema é que a implementação do contêiner não é infalível e os erros que as equipes cometem ao usá-los podem criar e não resolver problemas de segurança.

1. Focar demais nos próprios contêineres

“O erro mais comum ao implementar contêineres seguros é focar apenas no próprio contêiner”, diz McKnight. Manter as melhores práticas para a segurança de uma imagem é importante, ele diz, mas os desenvolvedores geralmente se concentram muito na segurança de uma imagem sem considerar o ambiente de execução.CIO2503

Nenhuma quantidade de segurança dentro de um contêiner pode protegê-lo da exploração de seu host”, diz McKnight. “Cada máquina que hospeda um mecanismo de contêiner deve ser protegida em cada camada contra qualquer vulnerabilidade tradicionalmente explorável”.

O mecanismo de contêiner e a plataforma de orquestração de contêiner, se aplicável, devem ser configurados para usar corretamente os mecanismos de segurança de contêiner integrados, diz McKnight. “Portanto, a segurança do contêiner começa com o sistema operacional e a rede do host”, diz ele.

2. Supondo que as bibliotecas de código sejam seguras

Ao implantar contêineres, algumas organizações cometem o erro de incluir bibliotecas de códigos e assumir que elas são seguras, diz Tony Asher, consultor independente de segurança cibernética. “Isso inclui bibliotecas [no] conjunto de desenvolvimento”, diz Asher. “E ainda mais críticas são as bibliotecas de terceiros [que são] frequentemente importadas para acelerar o desenvolvimento”.

O problema de segurança é que as vulnerabilidades estão potencialmente nessas bibliotecas de códigos de aplicativos, diz Asher. “Compilar aplicativos e iniciá-los em contêineres de produção pode apresentar sérios riscos por meio de explorações de vulnerabilidades”.

Para resolver isso, o Asher aconselha as empresas a limitar as bibliotecas ao necessário para que o contêiner de aplicativos atenda aos critérios de sucesso, verifique o código em busca de vulnerabilidades e aplique um processo de revisão de segurança ao considerar a importação de bibliotecas de terceiros.

As organizações também precisam desenvolver um processo formal de revisão da arquitetura segura. “Esse processo deve incluir a revisão de contêineres que atendam aos critérios de risco a serem revisados por um grupo de pessoas”, diz Asher. Isso fornece responsabilidade para ajudar a garantir que os riscos tenham sido considerados.

3. Conceder privilégios desnecessários aos contêineres

É comum conceder privilégios demais aos contêineres, que os atacantes podem abusar para aproveitar os recursos aos quais um contêiner não deveria ter acesso, mas sim, diz Jay Leek, Sócio-Gerente da empresa de capital de risco ClearSky. “Aplique o princípio do menor privilégio aqui, mas faça o monitoramento comportamental do tempo de execução para ajudar a garantir que os abusos de todos os privilégios necessários sejam detectados”, diz Leek.

Uma prática comum é executar contêineres como privilegiados no ambiente de execução, diz McKnight. “Dependendo da pilha de software do host, isso pode significar coisas diferentes”, diz ele. “Mas conceder privilégios desnecessários aos contêineres no ambiente host pode levar a escalações que resultam não apenas no comprometimento do contêiner, mas também na máquina host”.

Assim como nenhuma quantidade de segurança dentro de um contêiner pode protegê-lo da exploração de seu host, nenhuma quantidade de segurança dentro de um host pode protegê-lo da exploração de um contêiner privilegiado. “Um contêiner deve ser projetado para ser executado de uma maneira que não lhe conceda privilégios desnecessários no ambiente host”, diz McKnight.

Quando privilégios são necessários, eles devem ser concedidos moderadamente com uma granularidade fina, diz McKnight. “A melhor prática é evitar o provisionamento de contêineres com permissões abrangentes no ambiente host”.

4. Superexposição dos contêineres

Da mesma forma, os contêineres que precisam ser expostos às redes públicas quando são executados precisam ser projetados com a mesma mentalidade. “Em vez de políticas abrangentes que expõem o contêiner a ataques em potencial, apenas canais absolutamente necessários devem ser abertos”, diz McKnight.

Inúmeras considerações precisam ser feitas ao implementar o próprio contêiner. “Os contêineres são criados por meio de uma série de comandos definidos na especificação da imagem e executados com permissões de root quando a imagem é criada”, diz McKnight. “Os desenvolvedores geralmente cometem o erro de deixar essas permissões intactas quando o contêiner é implantado e executado”.

Se um processo dentro de um contêiner que está sendo executado com permissões de raiz for explorado em tempo de execução, os dados e o software dentro desse contêiner serão comprometidos. Para resolver isso, os comandos a serem executados dentro de um contêiner devem ser executados por usuários não raiz sem permissões, quando possível, para evitar escalações de privilégios no contêiner.

No lado da rede, as maneiras como os dados e processos de um contêiner são expostos a outras entidades precisam ser cuidadosamente considerados. “Mais uma vez, a segurança do contêiner começa com o sistema operacional tradicional e a segurança da rede”, diz McKnight. “Qualquer interação entre o contêiner e os volumes, redes e processos externos deve ser revisada”.

5. Falha ao examinar adequadamente uma imagem

Outro fator que as organizações geralmente ignoram ao implantar contêineres é a imagem em que se baseiam. “As equipes rotineiramente cometem o erro de não avaliar adequadamente uma imagem desenvolvida por outra parte antes de integrá-la à sua solução”, diz McKnight.

Antes de implantar um contêiner a partir de um registro público ou usá-lo como imagem de base, verifique se há malware e vulnerabilidades. Além disso, as organizações devem ter um desenvolvedor experiente para revisar minuciosamente a imagem em busca de vulnerabilidades desnecessárias, diz McKnight.

“Assumir que as imagens enviadas para um registro público são seguras pode ser muito perigoso, especialmente ao criar imagens adicionais a partir delas”, diz McKnight.

6. Não respeitar o princípio das imagens imutáveis

Uma imagem imutável é aquela que não muda, observa Asher. “Este é um princípio do Docker, Kubernetes e outras soluções de contêineres”, diz ele. “Ao implantar sistemas e dados pela Internet, que é um meio não confiável, você precisa criar um processo que garanta integridade”.

Imagens imutáveis oferecem vários benefícios, como previsíveis, vendáveis e oferecendo recuperação automática. Eles também fornecem integridade, diz Asher, que é um dos principais objetivos da segurança.

“Quando os contêineres de produção não seguem o princípio imutável, o suporte ao aplicativo pode se conectar a eles e fazer alterações”, diz Asher. “Esse comportamento gera várias bandeiras vermelhas de segurança. Especificamente, remove a integridade do contêiner”.

Um dos riscos mais preocupantes é um ator malicioso que modifica o contêiner para incluir código malicioso. Isso pode causar um impacto material em uma empresa, diz Asher. O monitoramento da integridade dos contêineres pode reduzir bastante esse risco.

“Melhore e corrija o pipeline de implantação para evitar alterações nos contêineres de produção”, diz Asher. “Verifique se estão sendo feitas alterações nos ambientes [garantia de qualidade] e de teste, [que] elas estão sendo aprovadas e, em seguida, novas imagens imutáveis são implantadas para substituir as antigas”.

Fonte: CIO

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *