Segurança de contêineres
Are your containers secure?
Os contêineres geralmente são invadidos por ataques como controle de acesso ou exploração de código de aplicativos, ou os invasores se aproveitam das vulnerabilidades da imagem do contêiner. Isso pode levar ao pânico do kernel, à execução de escalonamentos de privilégios ou a outras ameaças contra seu sistema.
Apesar desses riscos, a conteinerização oferece vários benefícios. Eles são rápidos e leves, facilitando a replicação dos ambientes de seus aplicativos. Eles também são um grande trunfo durante a fase de teste e refinamento do processo de desenvolvimento.
Sem medidas de segurança adequadas, os contêineres podem expor seu processo a ameaças com as quais você não precisaria lidar de outra forma. Os benefícios, no entanto, certamente superam os riscos. Aqui estão cinco etapas práticas que você pode seguir para aprimorar a segurança do seu contêiner.
5 etapas que você pode seguir para aprimorar a segurança do seu contêiner
1. Corte a gordura do sistema operacional
Você deve remover quaisquer sinos, assobios e ativos desnecessários do sistema operacional em que seu contêiner será executado. Embora isso possa parecer uma abordagem alarmista, o fato é que os cibercriminosos usam cada um dos vários serviços executados pelos sistemas operacionais como superfícies de ataque. Mesmo se você tiver um sistema hospedado via nuvem pública ou privada, removendo tudo o que é extra (além do segurança na nuvem características) podem evitar um problema crítico de segurança.
Portanto, você deve tentar o seguinte:
- Identifique os sistemas que precisam dar suporte ao seu contêiner
- Descarte todo o resto
- Teste seu contêiner após a primeira rodada de exclusões
- Procure por quaisquer funções desnecessárias que você possa ter esquecido na primeira vez e descarte-as
- Teste o recipiente novamente
Por que você precisa retirar recursos em excesso do sistema operacional do seu contêiner
O raciocínio que justifica essa abordagem é relativamente simples. Cada carga de trabalho tem seus próprios requisitos. A carga de trabalho do contêiner, por exemplo, tem ciclos de atualização, arquiteturas de pilha, parâmetros de controle de acesso, ferramentas de segurança e outros recursos importantes dos processos de DevOps que um sistema operacional precisa gerenciar. Isso é verdade se você usa máquinas virtuais ou ambientes tradicionais.
Cada um desses recursos tem protocolos de segurança adequados para atender às suas necessidades. Ao mesmo tempo, outro aplicativo em execução no sistema operacional host tem seus próprios requisitos de infraestrutura. Esses aplicativos estranhos não apenas roubam recursos do sistema operacional de suas equipes de DevOps, mas cada um deles, inadvertidamente, cria uma superfície de ataque adicional. Isso ocorre porque as medidas de segurança de contêineres invariavelmente exigem recursos diferentes daqueles projetados para proteger os outros programas. Embora seu sistema operacional possa proteger o código do aplicativo auxiliar, ele pode deixar seus contêineres expostos.
2. Desconfie do software que veio com o contêiner
É importante ter em mente que, além das alegações do fornecedor, você não tem ideia de quão fortes são as medidas de segurança de contêineres, não importa como elas funcionam. Algumas perguntas importantes incluem:
- O provedor realizou a verificação de vulnerabilidades necessária?
- Que tipo de sistema de prevenção de intrusões eles implementaram?
- Quando combinado com seus aplicativos em contêineres, o ambiente os expõe a riscos inesperados?
Como você não conhece os detalhes das ferramentas de segurança fornecidas com o contêiner, não consegue ver nem prever possíveis vulnerabilidades. Portanto, antes de confiar nas proteções que vêm com seu pacote de contêiner, tente implementar essas melhores práticas de segurança:
- Verifique novamente o conteúdo do contêiner
- Não execute um contêiner se ele tiver um software obsoleto
- Se você não estiver familiarizado com o software, entenda como ele funciona antes de implantá-lo
- Verifique cada programa e biblioteca para ver se eles realmente oferecem as melhores e mais recentes proteções
3. Inspecione o tempo de execução do contêiner
Como os tempos de execução são responsáveis pelo lançamento e gerenciamento de contêineres, você precisa rastrear cuidadosamente seus patches de segurança. Sabe-se que os tempos de execução têm vulnerabilidades distintas. Embora isso não seja necessariamente comum, as consequências potenciais são significativas.
Por exemplo, em alguns casos, a configuração de tempo de execução pode dar ao contêiner acesso total aos dispositivos do host, bem como a seus diretórios. Nesse caso, o contêiner, uma vez infectado com malware, pode ser usado para lançar um ataque ao host. Além disso, se você não implementou adequadamente segmentação de rede, outros contêineres e áreas afetadas pelas comunicações de rede também podem ser infectados.
As vulnerabilidades podem ser mais pronunciadas em programas de execução mais antigos. Embora o programa possa ter sido sólido quando foi codificado pela primeira vez, desde seu início, os cibercriminosos vêm criando novos métodos de ataque. Portanto, as chances de vulnerabilidades serem exploradas em programas de tempo de execução legados aumentam mês a mês. Além disso, em um ambiente de código aberto, pode ser difícil diferenciar fontes confiáveis de fontes suspeitas, o que ressalta ainda mais a necessidade de cautela.
4. Garanta visibilidade total
Com a adoção de contêineres, o número de sistemas executados em cargas de trabalho de máquinas virtuais bare metal pode aumentar exponencialmente. Devido à natureza encapsulada dos contêineres, você não pode presumir que a visibilidade da carga de trabalho que hospeda o contêiner forneça visibilidade adequada para o contêiner em si. É importante ver cada contêiner como sua própria entidade e implementar medidas de visibilidade adequadas. Para garantir visibilidade total, você deve:
- Detalhe a localização de cada contêiner
- Descreva o que cada contêiner está fazendo
- Mapeie o fluxo de dados de e para o contêiner
- Descreva os recursos que cada contêiner pode consumir, incluindo aplicativos, arquivos e os do sistema operacional
Essa última medida é crucial porque, embora o contêiner em si possa ser seguro, ele extrai recursos de outros lugares. Portanto, pode, inadvertidamente, causar vulnerabilidades em outro lugar. Além disso, dependendo do seu setor, talvez seja necessário estabelecer os padrões de conformidade necessários que se apliquem aos dados de cada contêiner.
5. Use a segmentação de rede
Quando uma rede é cuidadosamente segmentada, você obtém os benefícios de soluções de segurança personalizadas para cada segmento, combinadas com o controle aprimorado resultante da minimização de suas respectivas superfícies de proteção.
Como a segmentação de rede protege seus contêineres
Uma rede não segmentada é como um apartamento sem paredes. Se as pragas entrassem, elas teriam liberdade para se propagar por todos os espaços habitáveis. Uma rede sem segmentação tem o mesmo tipo de vulnerabilidade central. Os contêineres, apesar do nome, não são inerentemente “contidos” e protegidos contra malware, vírus e outras pragas cibernéticas.
Se você usa segmentação de rede para estruturar sua rede de forma que os contêineres tenham seus próprios segmentos, uma ameaça a um segmento não afeta os outros. Na verdade, você está construindo paredes à prova de pragas. Mesmo que uma ameaça cibernética conseguisse entrar, ela ficaria presa dentro desse único segmento. Isso impede a contaminação lateral ou leste-oeste, deixando sua equipe livre para manter a produtividade, mesmo que um ataque cibernético penetre em uma seção da rede.
Por meio do uso da segmentação de rede, da verificação tripla da segurança do contêiner, da inspeção de programas de tempo de execução, da remoção de aplicativos em excesso do sistema operacional e da garantia de visibilidade total, você pode criar um ambiente mais seguro e produtivo para suas equipes de DevOps.
Saiba mais
Descubra como Segmentação Zero Trust protege implantações de contêineres, incluindo as plataformas Kubernetes e RedHat OpenShift.