O uso de contêineres para o desenvolvimento e implantação de software há muito se torna uma prática padrão. A capacidade de fornecer facilmente ao programa um ambiente padrão independente do host em que está sendo executado, alterar rapidamente as configurações, adicionar ou alterar alguns componentes no contêiner foi apreciada por muitos desenvolvedores. Mas isso é apenas uma pequena parte de todos os chips que a tecnologia de contêiner fornece.

Como sempre, o desenvolvimento da tecnologia e o crescimento de sua popularidade são acompanhados pela identificação de vários métodos de uso fora do padrão, incluindo malware. Neste artigo, também examinaremos os riscos de segurança do processo de desenvolvimento associado ao uso de contêineres e falaremos sobre por que os processos DevOps devem ser transformados em DevSecOps.
Para começar, por que os contêineres ganham a simpatia dos desenvolvedores e como o uso da conteinerização altera o desenvolvimento como um todo.
Chips
LevezaComparado a máquinas virtuais e servidores "de ferro", os contêineres são completamente pouco exigentes para os recursos. Isso permite que você execute significativamente mais contêineres em uma única máquina do que máquinas virtuais. O desenvolvedor pode até executar componentes de aplicativos em seu computador na forma de microsserviços em contêiner e ele não precisa cochilar esperando a resposta do sistema. Devido ao fato de os contêineres compartilharem o núcleo do sistema, seu início e parada são muito mais rápidos do que reiniciar a máquina virtual.
IsolamentoApesar de compartilhar o kernel, o aplicativo no contêiner é executado isoladamente de outras partes do sistema e aplicativos. Isso significa que um erro no aplicativo afetará apenas um contêiner específico.
O uso de contêineres durante o desenvolvimento permite que você evite o eterno conflito de desenvolvedores e administradores de sistema em relação a privilégios. O contêiner separa com segurança o aplicativo do sistema, para que o programador possa fazer experimentos sem medo de destruir o sistema operacional.
PortabilidadeCada aplicativo é executado em sua própria instância de contêiner com seus próprios arquivos de configuração. Isso elimina a dor de cabeça associada à movimentação do aplicativo entre hosts: tudo o que é necessário para o trabalho é armazenado dentro do contêiner e transferido junto com os outros componentes do aplicativo.
Repositórios de contêineresO surgimento do padrão
Open Container Initiative tornou possível criar bibliotecas públicas de imagens de contêineres e criar um ecossistema poderoso que combina mecanismos de contêiner, plataformas em nuvem e ferramentas para gerenciar contêineres, verificações de segurança e outras tarefas.
AutomaçãoO uso de contêineres permite a criação de cadeias totalmente automatizadas de implementação / integração contínua de aplicativos (CI / CD), nas quais a parte “manual” será principalmente a escrita de código. Testes, verificação da qualidade do código, compactação do aplicativo em uma imagem do Docker, colocação da imagem no Docker Hub e implantação no servidor para execução podem ser executados sem intervenção humana.
Ameaças de contêineres
Obviamente, com todas as suas vantagens, os contêineres têm várias desvantagens. Por exemplo, esses são problemas com o desempenho de aplicativos que consomem muitos recursos e a portabilidade limitada de imagens criadas para várias arquiteturas. Mas, além dos problemas tecnológicos, os contêineres têm problemas de segurança.
Compartilhamento de kernelComo sempre, as desvantagens são o outro lado das vantagens. Compartilhar o kernel reduz a redundância de contêiner comparado às máquinas virtuais, mas o maior número de chamadas permitidas torna a barreira de segurança mais fina e a exploração das vulnerabilidades do kernel permite atacar todos os contêineres de uma só vez. Você não consegue se lembrar dos ataques sensacionais de
Spectre e
Meltdown , que permitem ler a memória de outro processo ou kernel no espaço do usuário.
Repositórios públicosA presença de registros públicos com imagens fornece uma ampla seleção de "invólucros" para contêineres, mas cria ameaças adicionais, porque, por padrão, o servidor de registro é confiável. Se os invasores conseguirem modificar as imagens de base com bibliotecas maliciosas, as alterações serão distribuídas automaticamente a todos os servidores que armazenam em cache essa imagem de base, e todos os contêineres que usam a biblioteca adquirem automaticamente funcionalidade maliciosa.
Exemplos
- Em junho de 2018, 17 contêineres com código malicioso foram removidos do portal do Docker Hub , mas antes disso, ao longo de vários meses, eles conseguiram ser baixados mais de um milhão de vezes.
- Em setembro de 2018, um exemplo de ataque aos pacotes de instalação do Python foi publicado no GitHub , durante o qual o arquivo setup.py foi modificado para executar código malicioso ao instalar o pacote. Como, geralmente, esse arquivo é usado apenas para adicionar um módulo, poucas pessoas verificam seu conteúdo .
- Em outubro de 2018, foram publicadas informações sobre 12 bibliotecas maliciosas carregadas no diretório PyPi . As bibliotecas continham código para coletar dados, manter presença no host infectado, iniciar um shell reverso e substituir os endereços da carteira Bitcoin pelo endereço de um invasor .
- Em novembro de 2018, uma das dependências da biblioteca Event-Stream usada em muitos projetos grandes detectou código malicioso projetado para roubar criptomoedas e conduzir ataques a serviços relacionados a ferramentas virtuais. O Event-Stream é uma biblioteca popular com cerca de 2 milhões de downloads diários do repositório NPM.
- Em janeiro de 2019, uma vulnerabilidade crítica foi relatada no módulo pickle da popular biblioteca NumPy Python , usando o qual você pode obter a capacidade de executar remotamente o código.
Assim, uma biblioteca maliciosa é suficiente para comprometer o aplicativo. Obviamente, vulnerabilidades e funções maliciosas em bibliotecas populares não são um problema de contêineres, mas uma tecnologia que garante a rápida disseminação de alterações nas imagens.
Recomendações
Obviamente, o processo de desenvolvimento moderno requer uma nova abordagem, uma abordagem na qual a segurança será integrada à cadeia de CI / CD, transformando o DevOps em DevSecOps.

Segundo o Gartner, em 2019
- mais de 70% dos processos de desenvolvimento corporativo incluirão monitoramento automatizado de vulnerabilidades e configurações de componentes de código aberto e pacotes comerciais.
- mais de 50% dos processos de CI / CD conterão verificações obrigatórias de segurança de código interno;
- mais de 60% das empresas usarão o controle de versão e os controles de automação de infraestrutura em seu desenvolvimento.
Considere alguns dos componentes que devem estar presentes no processo para que a palavra "Sec" em seu nome não seja uma frase vazia.
Integração de verificações em todos os processosUma verificação de segurança deve estar presente em todas as etapas do processo de desenvolvimento, desde a criação do código até sua conteinerização e implantação.
Automação de auditoria de segurançaÉ necessário por duas razões:
- Isso reduzirá erros de administração e configuração incorreta.
- Os profissionais de segurança não precisarão verificar manualmente o código e alterar as configurações.
API para recursos de segurançaA implementação dessa funcionalidade exige que o sistema de segurança forneça uma API para acesso a todos os recursos. Portanto, os desenvolvedores podem não apenas usar o sistema para verificação, mas também implementar as chamadas apropriadas no código.
Controle de Acesso Baseado em FunçãoDiferentes profissionais de segurança precisam de níveis diferentes de acesso aos mecanismos de verificação, dependendo de sua função, pois é necessário que os desenvolvedores não possam alterar as configurações de segurança, mas não sejam responsáveis subseqüentemente por ameaças penetradas.
Compatibilidade da API do Registro do DockerIdealmente, a proteção deve oferecer suporte à varredura de imagens do Docker em qualquer registro que suporte a API do Docker Registry V2 para garantir a compatibilidade com todos os registros populares.
Proteção de migraçãoPara usuários corporativos, um momento perigoso é a transição de uma arquitetura monolítica para uma de microsserviço. É importante que os recursos de segurança sejam integrados aos processos de integração, fornecendo proteção no modo automático.
Um exemplo de solução protetora é o Deep Security Smart Check da Trend Micro, que verifica continuamente imagens automaticamente, identifica vulnerabilidades e malware. O Smart Check oferece suporte às plataformas de contêiner Docker Trusted Registry, Amazon Elastic Container Registry, Azure Container Registry e Google Container Registry. Além disso, a Trend Micro se integra aos principais sistemas SIEM e ferramentas de orquestração, como Jenkins, Kubernetes, SumoLogic, Splunk.
Um recurso importante do Smart Check é a conformidade com todos os requisitos regulamentares em termos de verificação crítica de vulnerabilidades e registro de eventos.
A implementação da segurança de contêiner nos processos DevOps nos estágios iniciais de desenvolvimento antes do lançamento de aplicativos permitirá o desenvolvimento de software mais confiável e produtivo, além de
- Detecte malware e bibliotecas.
- Identifique vulnerabilidades.
- Corrija os erros antes que as imagens sejam transferidas para as ferramentas de orquestração (por exemplo, Kubernetes).
- Impedir que código malicioso execute e implante software vulnerável.